当Paxos证明“设计算法不可能安全同意”时，如two generals这样的共识算法如何“保证安全（不存在不一致）”？
当我考虑最简单的情况是获得两个服务器（1）可靠地交换一个号码（即两个服务器最终知道另一个肯定收到了号码）或（2）两个服务器最终都知道交换失败了不要改变他们的状态，似乎（像两个将军）消息失败总是会以一种不一致的方式发生（即，一个服务器认为另一个服务器完成了交换，但事实并非如此）。 p>
那么Paxos（或其他任何东西）如何真正保证“免于不一致”？用简单的语言有解释吗？什么是最简单的伪代码，证明两台服务器进行有保证的交换，或完全放弃交换失败？
答案 0 :(得分：2)
关键是Paxos的这个假设：
活力（C; L）：如果已经提出了值C，那么最终学习者L将学习一些价值（如果有足够的处理器保持无故障）。
两个将军问题的不利情况是信使不断被截获。 “如果足够的处理器保持无故障”部分消除了这种可能性。
换句话说，如果邮件被连续删除，那么Paxos不需要（也不会）完成。
答案 1 :(得分：1)
Paxos实际上并没有解决2个将军的问题。正如维基百科文章引用的那样：
通常，尽管任何F处理器同时发生故障，但使用2F + 1处理器的共识算法仍可取得进展。
在2个将军问题中，处理1个节点的故障意味着您需要2*1 + 1 = 3个节点来处理这么多故障。 2将军问题的不可能性并未推广到N将军。
人们在现实世界中解决2个将军问题的一种方法是fencing。
答案 2 :(得分：1)
Paxos是一种点对点协作算法。如其他答案中所述，它需要2F+1个节点继续接受F失败下的写入，这意味着群集大小3, 5, 7可以在1, 2, 3个失败后继续存在。 Byzantine_Generals谈到需要更多节点来交叉检查事实以排除错误信息。使用标准paxos，您可以假设节点没有谎言或有错误，它们都运行相同的良好代码，问题是崩溃，丢失或不可读的消息（例如传输噪声），或延迟或重新排序的消息（例如闪烁的网络链接） ）。它不使用全局时钟，因为它使用对等方式递增节点之间传递的计数器。
最初你没有领导者。节点需要听到群集配置（或DNS）中列出的大多数节点的积极响应才能引导。因此，除非你启动大多数节点，否则它们都会喋喋不休，但没有一个会引导。当足够的节点启动时，将随机超时propose(N)，其中N是尝试设置全局序列中的下一个数字并成为领导者。尚未听到较高N的所有节点都积极响应（ack）。听到更多号码的节点会做出负面反应（nack），并且会通过他们听过的最高号码。这使得节点最终都能发现N的当前最高值。你不希望很多节点在同一时间超时，并且争取成为领导者，因为他们只会不断地提出更高的N提案。因此，获得领导者是一个微妙的时刻。节点应该在他们提出建议之前等待随机超时，如果他们听到另一个具有更高数字的潜在领导者，则应该退出。
每个节点使用交错的数字至关重要。例如，它可以是N=C*100+X，其中C是计数器，X<100是节点编号。如果任何节点看到的另一个节点比上次发送的节点高N，则可以反向计算C，增加它，然后创建一个新的最高N。这意味着N不是顺序的（有差距<100），但每个节点是唯一的，并且可以命令所有N看到最高。
当一个节点听到大多数ack时，它知道它现在是领导者。现在我们遇到了任何前任领导人未提交工作的问题。之前的领导者可能刚刚失去了网络，因为当网络挂起时，当它发送提交消息时，大多数节点都接受了它的最后一个值。没有证据表明它已经死亡。在任何时候，它的提交消息都可以到达并竞争并击败新领导者的任何新消息。因此，新领导者不会试图忽略或覆盖最后一位领导者的工作：它合作并承诺左边的工作。使用N数字和承诺完成赛车消息的协作和写入安全性。承诺是接受提案的节点将拒绝具有较低N的所有邮件。
当节点回应新任领导者的任何新提案时，他们会回复前任领导人的任何剩余工作Vold，其中Nold,Vold Nold这是旧领导人的工作建议{{} 1}}。节点只需告诉新的领导者任何具有最高Vold的未提交作品，因为承诺拒绝较低价值的消息。新领导者将了解任何节点已经看到的最高未提交工作，并选择提交N作为其第一个操作。它首先在消息Vmax中发送该作品。当大多数节点响应accept(N,V)时（如果他们没有做出新的承诺），领导者知道工作已经提交。然后它可以告诉所有节点accepted(N)已提交，并且他们可以提交N。一旦它完成了最后一位领导者留下的任何未完成的工作，它就会通过发送这些新值并等待听到多数人的接受确认，然后告诉客户工作已经完成而开始新的客户工作。如果领导者崩溃，那么工作将继续保持，因为下一个领导者将完成提交的工作，其中任何节点尚未学习已经提交的值。
这个答案中的一些术语可能含糊不清，导致更多问题。我不能指望说服任何人立刻理解完整算法就足够了。我的希望是，让读者对于paxos核心的优雅感到好奇;点对点协作。数学和形式证明它非常坚固很难;但直觉是，如果节点互相帮助，它们将最终保持一致应该很容易。我建议the-paper-trail blogs作为阅读更多细节的良好来源。