我正在学习Paxos算法（http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf），有一点我不明白。
我们知道，事件遵循及时的顺序，例如，当事件 1-5 和 10 已经决定，但之后的 6-9 和 11 尚未决定时，就会发生这种情况。在上面的论文中，它说我们只需用无操作值填充 6-9 之间的间隙，并简单地记录 11 及以后的新事件。
所以在这种情况下，由于事件 10 已经被记录，我们知道某些类型的事件一定在 5 到 10 之间发生，但由于某些故障而没有被 Paxos 记录。如果我们只是填写无操作值，这些事件将在我们的记录中丢失。
更糟糕的是，如果正如我上面链接的论文所说，事件实际上是来自客户端的命令，那么中间缺少一些命令可能会使整个操作集非法（如果没有任何命令可以跳过或顺序其中很重要）。
那么为什么 Paxos 为事件之间的间隙填充无操作值仍然是合法的呢？ （如果正如我上面所关心的，由于无操作值，整个记录集可能无效。）此外，是否有更好的方法来从此类间隙中恢复，而不是使用无操作？
这是一个由多部分组成的答案。
提出无操作值是发现命令的方法还没有到达节点。我们不简单地用无操作命令填充间隙中的每个槽：我们propose每个槽都填充有一个空操作。如果any的对等点已经接受了命令，它将在Prepare-ack消息并且提议者将使用that接受回合中的命令而不是空操作。
例如，假设一个节点位于临时网络分区后面，并且无法与其他节点一起使用插槽 6-9。它知道它在学习槽 10 中的命令时错过了。然后它提出无操作来了解这些槽中决定的内容。
实际实现还具有带外学习协议来批量学习大量转换。
一个命令只有在它完全完成后才算命令decided;在那之前它只是一个proposed命令。 Paxos 是关于在来自多个客户端的竞争命令之间进行选择的。客户必须做好准备，因为他们的命令被选择为另一个客户的命令而被拒绝。
实际的实施都是关于选择order客户端命令。他们的世界观是预写日志的世界观，并且他们将命令放置在该日志中。如果未选择命令，他们会在下一个插槽中重试。 （有很多方法可以减少争用；Lamport 提到将请求转发给领导者，就像在 Multi-Paxos 中所做的那样。）
实际系统还有一些方法可以在提出命令之前知道该命令是否无效；例如知道一组读取和一组写入。这很重要，原因有二。首先，它是一个异步的多客户端系统，当客户端的命令到达服务器时，任何事情都可能发生变化。其次，如果两个并发命令不冲突，那么两个命令都应该能够成功。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
