在这种情况下，Paxos代理的正确行为是什么？

Question

我正在研究Paxos，我对算法在这个人为的例子中应该如何表现感到困惑。我希望下面的图解释了这个场景。

几点：

• 每个代理都充当提议者/接受者/学习者
• 准备邮件的格式为(instance, proposal_num)
• 建议邮件格式为(instance, proposal_num, proposal_val)
• Server1和Server2都决定同时启动提案流程
• 在开始时，消息M1，M2和M3同时发生

在这看来，尽管协议是“正确的”，即只选择了一个值S2，但Server1和Server2认为它是因为提案号不同而被选中的。

Paxos算法是否仅在Decide(...)消息发送给学习者时终止？我必须误解 Paxos Made Simple ，但我认为，当提议者达到Propose(...)消息的法定人数时，就做出了选择。

如果仅在Decide(...)消息发送给代理后才进行选择，那么Server2应该在其恢复时终止发送Decide(1, 5, S2)，因为它看到后来的Prepare(1, 7)？< / p>

Answer 1

要重新定义这些术语（让我们也抛弃1，因为我们只检查一个Paxos迭代）：

1）建议（n）==建议（n）来自具有当前身份n的提议者的消息

2）AcceptPrepare（n，v）== ack（n，v），发送给提议者n的消息。如果此节点尚未接受任何值，则为空白，o.w。 v等于它接受的值

3）CreateDecide（n，v）== accept！（x，v），要求节点接受来自具有标识x的提议者的这个值。节点将拒绝该消息，如果他们已经准备了一个准备（n）消息，其中n> X

一旦达到准备（n）的法定人数 - 也就是说，大多数人已经确认了消息 - 然后具有身份n的提议者发出命令接受！（n，v）。如果准备（n + x），则x> 0，由一个身份为n + x的提议者发出 - 并且它被多数人所取代 - 在ack（n，v）消息和accept！（n，v）之间，然后多数人承诺不接受以时间戳＆lt;时间戳建议的值。 n + x，x> 0（AKA节点将拒绝接受！（n，v））

一旦多数人收到他们未承诺忽略的接受！（n，v）消息，就会做出选择。

因此，当server2重新联机并发送accept！（5，S2）时，它将被忽略，因为5＆lt; 7。

Answer 2

为了对接受的答案给出一个对应点，算法本身永远不需要以任何非常明确的意义终止。讨论每个节点单独终止其对算法的参与更有意义，该算法是实现定义的。那么也许你可以说当所有参与节点都退出时，算法本身已经终止，如果这是一个有用的东西想知道。

一旦大多数接受者为同一张选票发送了他们的AcceptPropose消息，该算法就会有效融合（从某种意义上说，一旦发生这种情况，就没有选择最终可能决定了这个值）但这不是在实践中可以观察到的事态：例如，如果网络在发送这组AcceptPropose消息之前就开始丢弃消息，那么没有节点可以了解算法已经收敛，直到恢复连接。

然而，一旦一个节点知道算法已经收敛（通过接收来自多数的AcceptPropose个消息），它就可以通过传统方式共享所选择的值，例如，通过广播或八卦发送Decide消息，以及其他节点将其转发，直到每个节点都知道已实现收敛。

每个节点一旦知道算法收敛的值就可以终止其参与算法，尽管它可能更愿意继续参与，具体取决于您的实现约束。

你必须考虑一下容忍失败，以说服自己终止决定保留活力：如果知道决定了什么价值的所有节点在他们可以共享之前死亡，那么进展是否仍然可能？答案是，幸运的是，是的：只要大多数节点保持活动状态，如果其中任何一个节点知道决定的值，那么它就可以与其他节点共享它，如果没有，那么大多数参与节点只需要选择更高的选票数并再次进行。

在接受的答案中要注意的一件事就是这句话：

  

一旦多数人收到他们未承诺忽略的接受！（n，v）消息，就会做出选择。

首先，协议中没有关于承诺忽略 AcceptPropose消息的内容。承诺涉及哪些Propose消息应被忽略/拒绝。无论选票号如何，大多数AcceptPropose条消息都可以始终用于了解所选择的值。

其次，只要大多数发送 AcceptPropose消息，就会有效地做出选择。您无法直接观察到此情况，因此您必须等到至少有一个节点收到来自多数人的AcceptPropose条消息，然后才能知道已做出选择。一旦发生这种情况，您可以通过更多AcceptPropose消息或Decided消息的广播/八卦来共享所选值，具体取决于您的实施限制哪些更好。