WAIT命令能否在Redis中提供强一致性?

WAIT命令能否在Redis中提供强一致性?,redis,consistency,redis-sentinel,redis-cluster,Redis,Consistency,Redis Sentinel,Redis Cluster,向飞越者致意 在Redis sentinel/cluster设置中,我们是否可以对从机的总数使用WAIT命令来确保Redis服务器之间的强一致性?为什么不呢 等待为Redis实现同步复制。为了实现强一致性,需要同步复制,但这还不够。强一致性实际上是两件事的总和: 同步复制到分布式系统上的大多数节点 协调领导层变更(基本上是故障转移)的一种方法,以确保只有保留前一领导层中已确认操作的完整历史记录的节点才能当选 等待不提供“2”。Redis中的复制过程由Sentinel或Redis Cluster执

向飞越者致意

在Redis sentinel/cluster设置中,我们是否可以对从机的总数使用WAIT命令来确保Redis服务器之间的强一致性?为什么不呢


等待

为Redis实现同步复制。为了实现强一致性,需要同步复制,但这还不够。强一致性实际上是两件事的总和:

  • 同步复制到分布式系统上的大多数节点
  • 协调领导层变更(基本上是故障转移)的一种方法,以确保只有保留前一领导层中已确认操作的完整历史记录的节点才能当选
  • 等待不提供“2”。Redis中的复制过程由Sentinel或Redis Cluster执行,并且无法提供属性
    2
    (因为Redis中的同步复制是例外而不是规则,所以在这方面没有太多关注)。然而,Redis复制所做的是尝试升级似乎保存了最大数据量的从机。虽然这并没有改变Redis故障切换的理论保证,但仍然可能会丢失已确认的写入,这意味着如果使用
    等待
    ,则会有更多的从机将给定的操作放入其内存中,而反过来,在发生故障切换时,操作很可能会被保留。但是,尽管这将使放弃已确认操作的故障模式难以触发,但始终存在具有此属性的故障模式


    TLDR:
    等待
    不会使Redis线性化,它所做的是确保指定数量的从机将接收写入,这反过来使故障切换更加健壮,但没有任何硬保证。

    如果您想要具有硬保证的分布式锁,您有更好的方法来实现这一点!该算法是一个使用N个不同主机的实现,同步复制在客户端实现,可用于多种语言。我希望这有帮助!我认为你的算法不安全。例如,故障切换后会发生什么?如果在没有给定锁的情况下选择从机,即使锁本身到达了其他N/2+1节点,(新)主机中的SETNX也将成功,并且等待也将成功,因为现在其他实例正在从新主机复制。如果您不进行故障切换,那么您可以只使用一个实例:-),因为在发生故障时,您仍然有一个不可用的系统。顺便说一句,处理多主系统非常简单,所以我会选择redlock。问题是已经提供给其他客户端的锁。示例:向N/2+1服务器提供锁和写操作。这里发生的FAILVER不是在N/2+1服务器之间发生的,现在所有的从服务器都从中复制,因此旧锁不再存在于Redis中。然而,客户机正在使用它。但是,将向另一个客户端提供相同的pock:安全违规,游戏结束。是的,正如我所说,您没有考虑在故障切换后,您可以选择一个未收到最后一个锁(或从接收该锁的客户端的POV中仍然有效的任何其他过去的锁)的从机。是@ptentialUnrlsd,通过在故障期间完全牺牲任何类型的可用性,您确实是安全的。因此,您的副本将不允许在故障中生存,但会使写入更安全,因为您可以在不同的地理位置运行不同的节点。如果您在
    fsync=always
    模式下运行AOF,所有这些都是有意义的,否则在重新启动期间,每个副本可能会丢失写操作,从而使模式变弱。