我在Wiki上阅读“ paxos”，内容为： “当多个提议者发送有冲突的“准备”消息时，或者当提议者没有收到答复的法定人数（“承诺”或“已接受”）时，回合失败。在这些情况下，必须以更高的提议编号开始下一回合。 但是我不明白提议者如何区分提议未被批准和消息传递需要更多时间之间的区别？
答案 0 :(得分：1)
理解Paxos的棘手部分之一是原始论文和大多数其他文章（包括Wiki）都没有描述能够在现实世界中使用的完整协议。他们只关注算法的必要性。例如，他们说提议者必须选择一个比任何以前使用的数字都高的数字“ n”。但是他们没有提及如何实际执行此操作，可能发生的失败种类，或者如果两个提议者同时尝试使用相同的提议编号（如两个都选择n = 2）如何解决情况。这实际上完全破坏了协议，并会导致错误的结果，但是我不确定我是否见过专门提到的问题。我想这应该是“显而易见的”。
具体针对您的问题，没有使用原始算法来分辨差异的完美方法。实际的实现通常通过向提案人发送Nack消息而不是默默地忽略它来付出更大的努力。还有许多其他技巧可以使用，但是所有这些技巧，包括弊端，都有不同的缺点。哪种方法最好，通常取决于采用Paxos的应用程序的类型以及打算在其中运行的环境。
如果您有兴趣，我整理了一个much longer-winded description of Paxos，其中除了核心组件之外，还包括许多实际实现必须解决的问题。它涵盖了这个问题以及其他几个问题。
答案 1 :(得分：0)
针对您的问题，建议者无法区分丢失的消息，延迟的消息，崩溃的接收器或停止的接收器。在每种情况下，您都不会得到回应。通常，实现将在收到少于法定响应的超时后超时，并在消息被丢弃或接受方正在重新启动的假设下重新发送提案。
通常，实现会将“ nack”消息添加为否定确认，以作为优化以加快恢复。提议者仅从已接受更高承诺的可达节点获得“无应答”响应。 “ nack”既可以显示最高的承诺，也可以显示已知的最高实例。这将如何帮助将在下面概述。
我写了一个名为TRex的Paxos实现，其中的某些技术尽可能地与论文Paxos Made Simple中对算法的描述保持一致。我在blog post上写了有关超时和漏洞的实际考虑的描述。
它使用的一种有趣的技术是对一个超时的节点提出数量很少的第一个建议。这将始终获得“ nack”消息。为什么？考虑一个三节点群集，其中一个网络链路在稳定的提议者和另一个节点之间中断。另一个节点将超时并发出准备。如果准备充分，它将获得第三个节点的承诺。这将打断稳定的领导者。这样，您就具有了对称性，即两个无法互相发送消息的节点可以与领导层交换战斗，而没有前进的进度。
为避免这种情况，超时的节点可以从低准备开始。然后，它可以查看“ nack”消息，以从第三个节点获悉有领导者在进步。它将被视为已知在小块中固定的最高实例将大于本地值。然后，超时的节点无法发出高准备，而是要求第三个节点向其发送最新的固定值和可接受值。通过该增强功能，超时的节点现在可以区分稳定的提议者崩溃或连接失败。这种基于“小技巧”的技术不会影响实现的正确性，它们只是为了确保快速故障转移和转发进度而进行的优化。