有谁可以告诉我为什么提案ID在Paxos中必须是唯一的？ 我认为这个提案需要独特的原因是我们需要用它来拒绝旧提案并对最大投票进行排序。因此，如果我们制定第一阶段：接受者只接受大于promisedId的提议并且它是增量的，它仍然可以保证一致性。
我们假设提议者A向受体提出建议（proposalId x，值y），然后他获得批准的多数答复，另一个提议者B具有相同的提案ID（x）发出提案请求，这个提议者B将是拒绝了吧？最终，我们仍然可以达到一致性，对吗？
答案 0 :(得分：4)
简短的回答是，正确性的证明取决于每一轮中每个节点唯一的数字。
直观的答案如下：
如果提案编号在群集中的节点之间不是唯一的，则可以让两个节点为相同的编号提出不同的值。在任意消息丢失下，一些节点可以接受一个值而另一个节点可以接受潜在的新领导者将询问所有节点的最高接受价值。然后它将返回相同数字的不同值的响应。然后，它无法消除歧义并决定接下来要选择哪个值以使群集保持一致。使用唯一数字可确保每个值在每一轮中都有唯一的数字。这可确保新领导者能够正确选择最高可接受价值。
Contrived Scenario：
节点为A的五节点集群。网络变得混乱。节点B认为它需要引导，因为它怀疑节点A由于丢失消息而死亡。节点B建议A上次使用的号码相同。节点A和B实际上都是向上并尝试将不同的值传输到其他节点。由于滚动电源故障导致网络中断，电源发生故障，所有节点都变暗，部分但并非所有消息都通过。
接下来，电源重新启动，但节点A和E仍然无效。节点B，C和D可构成法定人数。节点C建议一个新的高数字，并为最高可接受值返回两个不同的值。一个来自A，另一个来自B。它现在必须在它们之间进行选择。保证哪个值能使集群达到正确的一致性？
想象一下，在幸存的仲裁中，只有一个节点具有A值，但两个节点具有B值。所以，让我们说我们猜测B的值，但这可能是错误的。死节点A和E可能具有A的值。节点A恰好在电源故障之前看到了大部分响应值，因为它的消息恰好通过其他两个节点。价值是付款，当它看到多数回应时，它将钱汇出公司。然而，幸存的法定人数决定A的值永远不会发生，并使集群与B的值保持一致。
修复：
您需要做的就是对每个节点进行唯一编号，并将节点唯一编号编码为选票编号的最低有效位。然后，每个节点使用对其唯一的数字，并且可以轻松生成一个刚好高于群集中使用的最后一个最大数字的新数字。如果我们这样做，那么在任何一轮中只有一个值是最高的。
如果最后一位领导者得到多数回应，那么任何拥有多数的新领导者都会看到最后一位领导人使用的最高价值。新领导人不会反对它将合作的最后一位领导人。新领导人不需要知道死去的领导人是否真的看到了多数回应并采取了行动。相反，它做出了保守的选择，并假设它可能具有适当的行为。
答案 1 :(得分：1)
还有一个额外的细节可能值得指出，@ ideawu在@ simbo1905的答案的注释线程中对其进行了润饰。我在下面给出的答案可能更适合作为对该线程的评论，但是我没有发表评论所需的堆栈溢出信誉。
在Paxos的经典描述中（例如Paxos Made Simple），确实要求每个提议者都具有唯一的投票号/标识，即，没有两个提议者可以在同一投票中提议一个值，并且每个提议者都不能重复使用投票不同提案的编号。我的理解是，这仅仅是为了确保针对给定的选票最多建议一个价值。
正如@ simbo1905指出的那样，一种确保提案中唯一的选票编号的方法是，为每个提案者预先分配一组不相交的选票ID。但是，这不是获得投票唯一性的唯一方法。如果接受者要求他们答复的准备邮件（第1a阶段）的选票编号严格大于其最新承诺的选票编号，那么这可以确保提议者永远不会在给定的选票编号上发生冲突，即使不同的提议者尝试对不同的提议使用相同的投票号码。仲裁重叠属性确保了这一点，这是海蒂·霍华德（Heidi Howard）的技术报告Distributed Consensus Revised中指出的一个事实，她在第3.9节中指出（使用术语“时代”代替“投票”）：
众所周知，经典Paxos不需要那个时代 如果接受者要求严格限制提议者的纪元，那么它是唯一的 比最后一个承诺的提案更大。这意味着最多 自到达阶段以来，提议者将进入给定时期的第二阶段 两个要求提议者已经达成多数同意 第一阶段，从而确保唯一性。
这支持@ideawu在上面的评论中提出的想法。因此，如果我们确保接受者的这种“严格大于”行为，那么外部就不需要投票号唯一性，即协议将自动强制执行。
或者，如果我们允许接受者响应准备的投票号大于或等于其最新承诺的投票号的准备邮件，则确实不会自动保证提案的投票号的唯一性。大概这是Paxos要求全局投票号唯一性的原始动机。我们可以通过稍微修改协议来解决此问题。我们可以在每个接受者上添加一个额外的状态，用于存储其对最近承诺的投票所响应的提议者的身份。如果它收到来自其他提议者的相同投票的准备请求，则可以拒绝。霍华德在参考论文部分给出了一个精确的例子。这也是在Raft共识协议中采用的方法，该协议是使用每个服务器上维护的 votedFor 变量实现的。
您可以在this TLA+ specification中看到上述概念的更正式说明，该概念扩展了one of Lamport's Paxos specifications以添加提议者的明确概念。注意，规范中没有任何内容可以确保不同的提议者从不相交的集合中选择投票号码。这是使用“ an error trace”条件并检查安全性模型（仅选择一个值）时生成的greater than or equal to（反示例）。使用“ strictly greater than”条件时，模型检查器在其中Proposer集定义为{p1,p2}（两个提议者）和Nat（确定一组可能的选票）被覆盖为{1,2,3}。这绝不是安全性的证明，但它使推理更加正确。