如果领导者在Multi-Paxos中出现主从系统失败怎么办？

Question

Backgound：

在Lamport的论文Paxos Made Simple中命名为实现状态机的第3部分中，描述了Multi-Paxos。 Multi-Paxos用于Google Paxos Made Live。 （多张Paxos用于Apache ZooKeeper ）。在Multi-Paxos中，可能会出现差距：

  

通常，假设领导者可以提前α命令 - 也就是说，在选择命令1到i + 1之后，它可以提出命令i + α到i命令。然后可能出现最多α - 1个命令的差距。

现在考虑以下情况：

  

整个系统使用主从架构。只有主服务器提供客户端命令。 Master和Slaves通过Multi-Paxos就命令序列达成共识。 Master是Multi-Paxos实例的领导者。现在假设主设备和两个从设备具有下图所示的状态（已选择命令）：

     

。

     

请注意，主状态中存在多个间隙。由于不同步，这两个奴隶落后了。这时，主人失败了。

问题：

  

  

1. 在检测到主设备故障后，从设备应该做什么（例如，通过心跳机制）？

  

2. 特别是，如何处理与旧主人的差距和缺失的命令？

  

关于Zab的更新：

正如@sbridges所指出的，ZooKeeper使用Zab代替Paxos。引用，

  

Zab主要用于主备份（即主从）系统，如ZooKeeper，而不是用于状态机复制。

Zab似乎与我上面列出的问题密切相关。根据{{​​3}}，Zab协议包括两种模式：恢复和广播。在恢复模式下，有两个特定的保证：永远不会忘记已提交的消息和放弃被跳过的消息。我对Zab的困惑是：

  

  
1. 在恢复模式下Zab是否也存在间隙问题？如果是这样，扎布做了什么？
  

Answer 1

gap 应该是未达成协议的Paxos实例。在论文 Paxos Made Simple 中，通过提出一个特殊的“无操作”命令来填补空白，使得状态保持不变。

如果您关心Paxos实例的所选值的顺序，则最好使用Zab，因为Paxos不保留因果顺序。 https://cwiki.apache.org/confluence/display/ZOOKEEPER/PaxosRun

缺失命令应该是已达成一致但未由学习者学习的Paxos实例。该值是不可变的，因为它已被接受为接受者的法定数量。当您运行此实例id的paxos实例时，将选择该值并将其恢复到阶段1b上的相同值。

当奴隶/追随者发现领导者失败，或者领导者失去了奴隶/追随者的法定人数支持时，他们应该选出新的领导者。

在zookeeper中，跟随者通过TCP保持FIFO与领导者通信时应该没有间隙。

在恢复模式下，在选举领导者之后，跟随者首先与领导者同步，并在状态上应用修改，直到收到NEWLEADER。

在广播模式下，关注者将 pendingTxns 中的PROPOSAL排队，并以相同的顺序等待COMMIT。如果COMMIT的zxid与 pendingTxns 的头部的zxid不匹配，则关注者将退出。

https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0

Answer 2

  

在Apache ZooKeeper中使用Multi-Paxos

Zookeeper使用zab，而不是paxos。请参阅difference的此链接。

特别是，集合中的每个zookeeper节点以与每个其他节点相同的顺序提交更新，

  

与客户端请求不同，必须严格应用状态更新   原始的生成顺序，从原始开始   初级的初始状态。如果主要版本失败，则为新的主要版本   执行恢复不能随意重新排序未提交状态   更新，或从不同的初始状态开始应用它们。

Answer 3

具体来说，ZAB文件说新当选的领导者进行发现以了解要设置的下一个纪元号以及谁拥有最新的提交历史记录。关注者打出一条ACK-E消息，指出它已经看到的最大连续zxid。然后它表示它进行同步阶段，在那里它传输他们错过的追随者的状态。它指出，有趣的优化是只选择一个具有最新提交历史的领导者。

使用Paxos you don't have to allow gaps。如果您确实允许间隙，那么论文Paxos Made Simple将解释如何从第9页解决它们。新的领导者知道它看到的最后一个提交的值以及可能上面的一些提交值。它通过运行阶段1来探测来自它所知道的最低间隙的槽，以建议那些槽。如果这些插槽中有值，则运行阶段2以修复这些值，但如果可以自由设置值，则设置无操作值。最终它到达了没有提出值的插槽号，它正常运行。

回答你的问题：

  

  
1. 在检测到主设备故障后，从设备应该做什么（例如，通过心跳机制）？
  

他们应该在随机延迟之后尝试领导，以试图降低两个候选人同时提出的风险，这会浪费消息和磁盘刷新，因为只有一个人可以领先。 Raft论文详细介绍了随机领导超时;同样的方法可以用于Paxos。

  

  
1. 特别是，如何处理与旧主人的差距和缺失的命令？
  

新领导者应该探测并将差距修正为建议到该位置的最高值，否则为无操作，直到填补了缺口然后它可以正常导致。

Answer 4

@Hailin的答案解释了 gap 问题如下：

  

在zookeeper中，应该没有间隙，因为跟随者通过TCP与领导者进行通信，这保持了FIFO“

补充：

在论文一个简单的完全有序的广播协议中，它提到ZooKeeper需要前缀属性：

  

如果$ m $是为领导者$ L $发送的最后一条消息，那么在$ m $之前提出的任何消息也必须以$ L $的形式发送“。

此属性主要依赖于Zab中使用的TCP机制。在Zab Wiki中，它提到Zab的实施必须遵循以下假设（除了其他假设）：

  

服务器必须按接收顺序处理数据包。由于TCP在发送数据包时保持排序，这意味着数据包将按发送方定义的顺序进行处理。