我正在研究 Paxos，我对算法在这个人为的例子中应该如何表现感到困惑。我希望下图能解释这个场景。
几点：
(instance, proposal_num)(instance, proposal_num, proposal_val)这里似乎虽然协议是“正确的”，即只S2选择了一个值，但 Server1 和 Server2 认为选择它是因为不同的提案编号。
Decide(...)Paxos 算法是否仅在消息发送给学习者时才终止？我一定是误解了Paxos Made Simple，但我认为选择是在提议者达到他们的Propose(...)消息的法定人数的那一刻做出的。
Decide(...)如果仅在将消息发送给代理后才做出选择，那么 Server2 是否应该Decide(1, 5, S2)在它恢复时终止其发送，因为它看到了较晚的消息Prepare(1, 7)？
只是要重新定义这些术语（让我们也扔掉 1 因为我们只检查一个 Paxos 迭代）：
1) Propose(n) == proposal(n)，来自当前身份为 n 的提议者的消息
2) AcceptPrepare(n,v) == ack(n,v)，消息发送给提议者n。如果此节点尚未接受任何值，则 v 为空，ow v 等于它已接受的值
3) CreateDecide(n,v) == accept!(x,v)，要求节点接受来自身份为 x 的提议者的这个值。如果节点已确认 n > x 的 prepare(n) 消息，则节点将拒绝该消息
一旦prepare(n) 达到了法定人数——也就是说，大多数人已经确认了消息——那么身份为n 的提议者就会发出一个命令accept!(n,v)。如果一个prepare(n+x), x > 0, 是由一个身份为n+x的提议者发出的——并且它被多数人确认——在ack(n,v)消息和accept之间！( n,v)，然后多数人承诺不接受时间戳 < n+x, x > 0 的值（也就是节点将拒绝接受！(n,v)）
一旦大多数人收到他们没有承诺忽略的接受！（n，v）消息，就会做出选择。
因此，当 server2 重新上线并发送 accept!(5,S2) 时，它将被忽略，因为 5 < 7。
为了与已接受的答案形成对比，算法本身永远不需要在任何非常明确的意义上终止。讨论每个节点单独终止其参与算法更有意义，这是实现定义的。那么也许你可以说当所有参与节点都退出时算法本身已经终止，如果这是一件有用的事情想知道的话。
一旦大多数接受者为同一张选票发送了他们的消息，该算法就有效地收敛AcceptPropose了（从某种意义上说，一旦发生这种情况，就无法选择最终决定什么价值），但这不是一种事态，即在实践中可以观察到：例如，如果网络在发送这组消息之前开始丢弃消息AcceptPropose，那么在恢复连接之前，没有节点能够得知算法已经收敛。
然而，一旦一个节点知道算法已经收敛（通过接收到AcceptPropose来自多数的消息），它就可以安全地通过传统方式共享所选值，例如通过Decide广播或八卦发送消息，并让其他节点转发它一直打开，直到每个节点都知道已经实现了收敛。
一旦知道算法收敛到的值，每个节点就可以终止其参与算法，尽管它可能更愿意继续参与更长时间，具体取决于您的实现限制。
您必须考虑一下容错性，以说服自己终止决定保留活性：如果所有知道决定什么值的节点都在共享它之前就死了，那么进步仍然可能吗？幸运的是，答案是肯定的：只要大多数节点还活着，如果其中任何一个知道决定的值，那么它可以与其他节点共享它，如果没有，那么大多数参与节点只需要选择更高的选票号码并运行另一轮。
在接受的答案中要注意的一件事是这句话：
一旦大多数人收到他们没有承诺忽略的接受！（n，v）消息，就会做出选择。
首先，协议中没有关于承诺忽略 AcceptPropose消息的内容。承诺与Propose应该忽略/拒绝哪些消息有关。无论选票号码如何，大多数AcceptPropose消息始终可用于学习所选值。
其次，一旦多数人发送 AcceptPropose消息，就可以有效地做出选择。您无法直接观察到这一点，因此您必须等到至少一个节点收到AcceptPropose来自多数人的消息后才能知道已做出选择。一旦发生这种情况，您可以通过更多AcceptPropose消息或通过消息的广播/八卦共享所选值Decided，具体取决于哪个更适合您的实现约束。