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

作者: 青年@
发布时间: 2025-03-02 07:28:34 (2天前)
转自：

3 条回复

0#
回复此人
Ni | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 为了对接受的答案给出一个对应点，算法本身永远不需要 终止 在任何非常明确的意义上。讨论每个节点单独终止其对算法的参与更有意义，该算法是实现定义的。那么也许你可以说当所有参与节点都退出时算法本身已经终止，如果这是一个有用的东西想知道。 该算法有效 融合 一旦大多数接受者发送了他们的 <code> AcceptPropose </code> 相同选票的消息（从某种意义上说，一旦发生这种情况，就没有关于最终决定什么价值的选择）但这不是在实践中可以观察到的事态：例如，如果网络开始下降就在这一组之前的消息 <code> AcceptPropose </code> 消息被发送，没有节点能够知道算法已经收敛，直到恢复连接。 但是，曾经 一 节点知道算法已经收敛（通过接收 <code> AcceptPropose </code> 来自多数人的消息）通过传统方式共享所选择的值是安全的，例如，发送一个 <code> Decide </code> 通过广播或八卦消息，以及其他节点将其转发，直到每个节点都知道已实现收敛。 一旦知道算法收敛的值，每个节点就可以终止其参与算法，尽管它可能更愿意保持参与更长时间，具体取决于您的实现约束。 你必须考虑一下容忍失败，以说服自己终止决定保留活力：如果所有知道决定了什么价值的节点在他们可以共享之前就死了，那么进展是否还有可能？答案是，幸运的是，是的：只要大多数节点仍然存活，如果它们中的任何一个知道决定的值，那么它就可以与其他节点共享它，如果没有，那么大多数参与节点只需要选择更高的选票数并再次运行。 <HR /> 在接受的答案中要注意的一件事是这句话： <BLOCKQUOTE> 一旦大多数人收到他们未承诺忽略的接受！（n，v）消息，就会做出选择。 </BLOCKQUOTE> 首先，协议中没有任何内容 承诺忽视 <code> AcceptPropose </code> 消息。承诺属于哪个 <code> Propose </code> 应该忽略/拒绝消息。绝大多数 <code> AcceptPropose </code> 消息可以 总是 用于学习所选择的值，无论选票号码如何。 其次，只要多数人有效地做出选择 发送 <code> AcceptPropose </code> 消息。您无法直接观察到此情况，因此您必须等到至少收到一个节点 <code> AcceptPropose </code> 在知道已经做出选择之前，来自大多数的消息。一旦发生这种情况，您可以通过更多分享所选择的价值 <code> AcceptPropose </code> 消息或通过广播/八卦 <code> Decided </code> 消息，取决于哪些更符合您的实施限制。 </DIV>

编辑
1#
回复此人
流浪海。 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 只是要重新定义这些术语（让我们也抛弃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。 </DIV>

编辑

登录后才能参与评论