我正在学习Paxos算法（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为事件之间的差距填补无操作值仍然是合法的呢？ （如果整个记录集可能因为我上面提到的无操作值而无效。）另外，有没有更好的方法从这些间隙中恢复而不是使用no-op？
答案 0 :(得分：4)
这是一个多部分的答案。
提出无操作值是发现尚未到达节点的命令的方法。我们不是简单地使用no-op命令填充间隙中的每个插槽：我们建议每个插槽都填充一个no-op。如果任何对等方已经接受了命令，它将在Prepare-ack消息中返回该命令，并且提议者将在Accept round中使用那个命令无操作。
例如，假设某个节点位于临时网络分区后面，并且无法与其他节点一起播放插槽6-9。它知道它在第10个插槽中学习命令后错过了。然后它建议无操作来学习那些插槽中的决定。
实际实施还有一个带外学习协议，可以批量学习大量过渡。
在完全决定; 之前，命令不是命令，直到那时它只是提议的命令。 Paxos是关于在多个客户端的竞争命令之间进行选择。客户必须准备好拒绝他们的命令，因为选择了另一个客户端。
实际的实现都是关于选择客户端命令的 order 。他们的世界观是预写日志，他们将命令放在该日志中。如果没有选择命令，他们会在下一个插槽中重试。 （有很多方法可以减少争用; Lamport提到向领导者转发请求，例如在Multi-Paxos中完成。）
在提出命令之前，实际系统还有一些方法可以知道命令是否无效;例如知道一组读取和一组写入。这有两个重要原因。首先，它是一个异步的多客户端系统，当客户端的命令到达服务器时，任何事情都可能发生变化。其次，如果两个并发命令不冲突，那么两者都应该能够成功。
答案 1 :(得分：0)
系统模型允许网络丢失命令（消息）。如果消息丢失，则客户端最终将重试该请求;所以可以放下一些。如果客户端的命令必须按客户端顺序执行，则客户端只能同步发送命令;或者命令必须在库中的更高级别进行排序，并在执行之前保存在某个客户端会话对象中。
AFAIK Zab协议保证客户订单，如果您不想在更高级别实现它。