distributed-computing - 为什么 Paxos 分两个阶段进行设计

Question

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

问题是什么，是破坏安全还是破坏活力？

Answer 1

不遵循完整的协议(protocol)会破坏安全性。

multi-paxos 的典型实现具有稳定的状态模式，其中稳定的领导者流 Accept包含新值的消息。只有当问题发生(leader 崩溃、停顿或被网络问题分区)时，新的 leader 才需要发布准备消息以确保安全。 write-up of how TRex 中有对此的完整描述。一个开源 Paxos 库实现了 Paxos。

考虑以下崩溃场景 TRex会妥善处理:

节点 A , B , C与 A领先

客户端应用程序发送 V1致领导A

节点 A处于稳定状态，因此发送 accept(n, V1)到节点 B和 C .网络开始出现故障，但只有 B看到消息并回复 accepted(n)

节点 A看到响应并拥有多数 {A,B}因此它知道由于协议(protocol)的安全性证明该值是固定的。

节点 A尝试在服务器死机时向所有人广播结果。仅发布 V1 的客户端应用程序得到消息。想象一下 V1是客户订单，并且在得知订单已修复后，客户应用程序欠客户信用卡。

节点 C对死去的领导者超时并试图领导。它从未见过 V1 的值.它不能在不回滚命令的情况下任意选择任何新值V1但是客户已经被收费了。

所以节点C第一个问题 prepare(n+1)和节点 B回复 promise(n+1, V1) .

节点 C然后发出 accept(n+1, V1)并且只要剩余的消息通过节点 B和 C将学习值 V1被选中。

直观地说，节点 C已选择与死节点合作 A通过选择 A的值(value)。所以直观地我们可以看到为什么必须有两轮。需要第一轮来发现是否有任何未完成的工作要完成。第二轮用于确定正确的值，以使系统内的所有进程保持一致。