背景:
在Lamport的论文Paxos Made Simple的名为实现状态机的第3节中，描述了Multi-Paxos。 Google Paxos Made Live中使用了Multi-Paxos。 (在Apache ZooKeeper中使用了多Paxos)。在Multi-Paxos中，可能会出现差距:
现在考虑以下情形:
问题:
关于Zab的更新:
正如@sbridges指出的那样，ZooKeeper使用Zab而不是Paxos。报价，
似乎Zab与上面列出的我的问题密切相关。根据the short overview paper of Zab，Zab协议(protocol)包括两种模式:恢复和广播。在恢复模式下，有两个特定的保证:永不忘记已提交的消息和释放被跳过的消息。我对Zab的困惑是:
最佳答案
差距应该是尚未达成共识的Paxos实例。在Paxos Made Simple论文中，通过提出一个特殊的“no-op”命令来填补空白，该命令使状态保持不变。
如果您关心Paxos实例的选定值的顺序，则最好改用Zab，因为Paxos不会保留因果顺序。 https://cwiki.apache.org/confluence/display/ZOOKEEPER/PaxosRun
缺少的命令应该是已经达成一致但学习者没有学到的Paxos实例。该值是不可变的，因为已经接受了法定人数的接受者。当您运行此实例ID的paxos实例时，将选择值并将其恢复到阶段1b上的相同值。
当奴隶/跟随者检测到领导者发生故障时，或者领导者失去对奴隶/跟随者的法定支持时，他们应选举新的领导者。
在Zookeeper中，跟随者通过TCP保持FIFO与跟随者通信时，应该没有任何间隙。
在恢复模式下，选举领导者后，跟随者首先与领导者同步，并在状态上应用修改，直到收到NEWLEADER。
在广播模式下，关注者将PROPOSAL排队在未决的Txns中，并以相同的顺序等待COMMIT。如果COMMIT的zxid与pendingTxns的头部的zxid不匹配，则关注者将退出。
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0
关于distributed-computing - 如果领导者在主从系统的Multi-Paxos中失败，该怎么办？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/19208997/