为什么 Paxos 设计分两个阶段

Question

为什么 Paxos 需要两个阶段（prepare/promise+ accept/accepted）而不是一个阶段？也就是说，仅使用prepare/promise部分，如果提议者收到了大多数接受者的回复，则选择该值。

问题出在哪里，它是否破坏了安全性或活力？

Answer 1

不遵循完整的协议会破坏安全。

multi-paxos 的典型实现具有稳态模式，其中稳定的领导者流式传输Accept包含新值的消息。仅当出现问题（领导者崩溃、停滞或因网络问题而分区）时，新领导者才需要发出准备消息以确保安全。对此的完整描述在开源 Paxos 库TRex 如何实现 Paxos 的文章中。

考虑TRex可以正确处理的以下崩溃场景：

1. 节点A, B,C带A前导
2. 客户端应用程序发送V1给领导者A
3. 节点A处于稳定状态，因此发送accept(n, V1)到节点B和C。但网络开始出现故障，因此只能B看到该消息并回复accepted(n)
4. 节点A看到响应并拥有多数{A,B}，因此它知道由于协议的安全性证明该值是固定的。
5. 节点A尝试在服务器挂掉时向每个人广播结果。只有发出该消息的客户端应用程序才会V1收到该消息。想象一下，这V1是一个客户订单，在得知订单已确定后，客户应用程序会向客户信用卡欠款。
6. 节点C在死亡领导者上超时并尝试领导。它从来没有看到价值V1。它不能在不回滚订单的情况下任意选择任何新值V1，但客户已经被收费。
7. 所以节点C首先发出 aprepare(n+1)并且节点B响应promise(n+1, V1)。
8. C然后节点发出消息accept(n+1, V1)，只要剩余的消息通过节点B，C就会获知所选择的值V1。

直观上我们可以说，Node通过选择的值来C选择与死亡节点协作。所以直观上我们就可以明白为什么必须有两轮了。第一轮需要发现是否有任何待完成的工作。第二轮用于修复正确的值，以保证系统内所有进程的一致性。AA