分布式系统中一致性问题Paxos算法的简单解释 | 点融黑帮

Posted 2021-04-17 点融黑帮

导语：

最近身边好多同事遇到了分布式系统的一致性问题，正好在看Quora看到一篇Vineet Gupta关于Paxos的算法的分享，给大家翻译过来分享一下，可供参考算是一种解决一致性的方法。如果有翻译不对的地方，请大家指正。

我觉得利用在其他情况下解决一致性问题的方法和这种方法的缺点可以简单的理解Paxos算法。

我们用结婚誓言来直观的说明如何达成一致性：

• “你愿意......”“我愿意”“我愿意”

• “我现在宣布你们...”

现在假定婚姻不是两个人之间，而是有点像罗伯特·乔丹的时光之轮系列里的艾伊尔人民风俗一样———一个或多个艾伊尔女人可以是 first-sisters（同母所生女儿或经过智者同意的闺蜜），一个男人要娶全部都娶，要么一个都娶不了。艾伊尔人婚姻誓言可能是这样的：

• “你愿意......？”“我愿意！”“我愿意！”“我愿意！”......

• “我现在宣布你们......”

如果任何一个将成为配偶的艾伊尔人没有说“我愿意！”婚礼就会无法进行下去。

计算机科学家称此为两段提交。

1

两段提交

1. 投票阶段 - 一个事件处理器向所有节点发送一个值，并收集他们的反应（不管他们同意与否）。在我们的场景中，交易处理器要求所有的资源管理器（数据库服务器实例）反馈事件是否进行。资源管理器返回是或否。

   
   

2. 确认阶段 - 如果每个资源管理器都同意，交易处理器告诉所有节点，让他们知道该值是最终值。如果有一个节点不同意，则通知该值不是最终值。在我们的场景中，交易处理器要求的资源管理器进行事件或终止事件。

要注意的是票只能投给（事件处理器）建议的值，每个节点只能说是或否。节点不能再提出一个可供选择的值。如果一个节点想提出自己的 值，它需要开始它自己的2PC。算法很简单，由节点来决定某一个节点提出的值。它也不是非常低效的，对于N个节点，将交换3N条消息。

但是如果一个节点崩溃了会发生什么？例如，假设在阶段一事件处理器将提议的值发送给部分节点（并非全部）后，然后事件处理器就挂掉了。（这是会发生什么？）

• 现在一些节点已经开始了2PC循环，而另一些节点没有意识到2PC循环已经发生。那些已经开始2PC循环的节点被阻塞在等待下一个阶段上。

  
  

• 在我们的场景中，已经投票的资源管理单元也可能不得不锁定一些资源，这样资源管理不会因为等待事件处理器恢复并启动阶段二而耗尽时间。

如果阶段二中的事件处理器未能把所有的提交信息发送给全部节点而只是部分节点后就崩溃了，相似的问题依然存在。我们可以让另一个节点接管事件处理器职责观察时间超时来解决部分存在的问题。这个节点会和其它节点取得联系并获得它们的投票情况（要求它们必须投票）以及推动事务完成，但这一过程中进一步参与者可能发生故障，同时事务可能永远不会恢复。我们的底线-在节点故障的情况下2PC无法可靠地操作。

2

三段提交（3PC）

2PC的关键问题是，万一事件处理器挂掉了，没有节点具备足够的信息来完成整个协议。这一点可以通过添加额外的步骤来解决：

1. 阶段1和（2PC）相同-事件处理器给所有的节点发送一个值。

   
   

2. 阶段2-新的步骤-一旦从上一步中所有节点都接收到“是”，事件处理器发送出“准备提交”消息。我们期望的是节点能够执行可以撤消的工作，而且没有什么是不能撤消的。每一个节点向事件处理器确认它已经接收到“准备提交”消息了。

   
   

3. 阶段3-类似2PC中阶段二-如果事件处理器从所有节点接收到关于“准备提交”的确认信息，它就继续工作，将投票的结果发送给所有的节点要求他们提交。但是，如果所有节点都不确认，事件处理器会终止事务。

现在如果事件处理器在任何时刻崩溃，任何参与者都可以接管事件处理器的角色并查询来自其它节点的状态。

• 如果任何资源管理器向恢复节点报告说它并没有接收到“准备提交”的信息，恢复节点便知道事务没有提交给任何资源管理器。现在要么事务被悲观地终止，要么协议实例重新运行。

  
  

• 如果有一个管理器提交事务后崩溃了，我们知道的是，其它每一个资源管理器可能会收到“准备提交”的确认信息，否则事件处理器不会进入提交阶段。所以事件处理器是可以进入到最后一个阶段的。

因此3PC能够很好地工作尽管有节点故障。这是以在N个节点添加一个新的步骤为代价的，它导致了较高的延时。

3PC在网络分区情况下存在不足。假设所有收到“准备提交”信息的资源管理都在分区的一侧，其余的都在另一边。现在这会导致每个分区都选择一个恢复节点，这两个恢复节点要么提交事务，要么终止事务。一旦网络分区被移除，系统会得到不一致的状态。

3

Paxos算法-为什么麻烦？

先说重要的事-考虑下3PC，我们还需要更好的算法吗？3PC唯一的问题是网络分区，真的吗？首先，我们假设网络分区是唯一的问题（并不是，下面我们会看到）。在网络分区的情况下，正确性真的是值得解决的问题吗？今天，在云计算和互联网规模的服务下，其中的节点有可能在大陆的不同侧或者跨越了大洋，我们确实需要分区容错算法。

第二点是网络分区并不是唯一的问题。当我们解决了单个节点永久故障的情况时，更一般的情况是，节点崩溃了，接着它重新恢复并且从崩溃的地方工作。这种故障-恢复模式也可以描述一个异步网络模型，这种网络模型中一个节点用来响应消息的时间是没有上限的，因此你不能假设一个节点死了-也许它仅仅是响应缓慢或者是网络缓慢。在这种模型中你不能判断超时。

3PC是故障-停止容错，而不是故障-恢复容错。不幸的是现实生活中需要的是故障-恢复容错，因此我们需要更一般的解决方案。而这正是Paxos的用武之地。

4

Paxos算法-它如何运行?

Paxos中的基本步骤和2PC很像：

• 选择一个节点作为领导者/提议者。

  
  

• 领导者选择一个值并将它发给所有节点（Paxos中被称为接收者），（这个值）封装在接收-请求消息中，接收者可以回复拒绝或接受。

  
  

• 一旦多数节点都接受，共识就达成了同时事件处理器向所有节点广播提交信息。

Paxos与2PC主要不同点在于Paxos不要求所有节点都要同意（才会提交事务），只要大部分节点同意就行。这是一个有趣的想法因为在两个独立的多数节点中至少存在一个正常工作的节点。这确保在给定的循环中，如果大部分节点赞同给定的值，任何随后努力提出一个新值的节点将会获得来自其它节点的值而且这个节点也只会赞同那个值（不会再提出自己的值了）。这也意味着Paxos算法不会阻塞即使一半的节点无法回复消息。

当然也可能发生是领导节点自己故障了。为了解决这个问题，Paoxs在给定的时间点不会只向一个领导节点授权。它允许任何节点（在领导节点故障时）成为领导者并协调事务。这也自然意味着在特定情况下至少存在一个节点能称为领导者。在上述情况下很可能存在两个领导者并且他们发送了不同的值。所以如何达成共识呢？为了在这样的设置下达成共识，Paxos介绍了两种机制：

• 给领导者指定顺序。这让每个节点能够区分当前领导者和旧的领导者，它阻止旧领导者（或许刚从旧的故障中恢复）扰乱已经达成的共识。

  
  

• 限制领导者对值的选择。一旦就某个值`达成了共识，Paxos强制将来的领导只能选择相同的值确保共识能延续下去。这一点是这样实现的-接收节点发送它赞同的最新的值和它收到的领导者的序列号（来实现上一点）。新的领导者可以从接受者发送的值中选择一个，万一没有任何接收节点发送值，领导者也可以选择自己的值。

5

协议步骤

准备阶段：

1. 一个节点被选为领导者并且选择序列号x和值v创建提议P1(x,v)。领导者把P1发送给接收者并等待大部分节点响应。

2. 接收者一旦接收到提议P1(x,v)会做下面的事：

• 如果是接收者第一次收到提议而且它选择赞同，回复“赞同”-这是接收者的承诺，它将承诺拒绝将来所有小于x的提议请求。

• 如果接收者已经赞同了提议：

• 比较x和接收者赞同的提议的最高序列号，称为P2(y,v2)

• 若x<y,回应“拒绝”以及y的值

• - 若x>y,回应“赞同”以及P2(y,v2)

接受阶段

• 如果大部分接收节点未能回应或者回应“拒绝”，领导者放弃这次协议并重新开始。

• 如果大部分接收节点回应“赞同”，领导者也会接受大部分节点接受的协议的值。领导者选择这些值的任意一个并发送接受请求以及提议序列号和值。

• 当接收者收到接受请求消息，它只在下面两种情况符合时发送“接受”信息，否则发送“拒绝”：

• 值和之前接受的提议中的任一值相同

• 序列号和接收者赞同的最高提议序列号相同

• 如果领导者没有从大部分节点那接收到“接受”消息，它会放弃这次提议重新开始。但是如果接收到了大部分的“接受”消息，深思熟虑后协议也可能被终止。作为优化，领导者要给其它节点发送“提交”信息。

6

Paxos对故障的处理

如果Paxos算法中我们一次只授权唯一一个领导者，同时授权小部分节点，那样会发生什么？所有节点都要投票吗？是的，（这时）我们使用2PC。2PC是Paxos中的特例。

正如人们所看到的，在故障容错上Paxos要优于2PC：

• 领导者故障了-另一位（新的）领导者可以通过发出自己的协议来接管协议。

• 原先的（故障）领导者恢复后-两个领导者可以同时存在，这归功于下面的规则：只赞同更高序列号的协议以及只提交以前接受的值。

Paxos也比3PC更加容错。具体地讲，Paxos是分区容错3PC不是。在3PC中，如果两个分区分别赞同一个值，当分区合并的时候，会留给你一个不一致的状态。在Paxos中，大部分情况下这不会发生。除非某个分区占绝大多数，否则不会达成共识。如果某个分区占绝大多数并达成一个共识，那值就需要被其它分区中的节点接受。

Paxos存在的一个问题是，两个领导者因为处于不同的分区导致不能互相观察，他们会努力向另一方投标，发布一个比先前协议有更高序列号的协议。这可能导致Paxos无法终止。最终这两个互相观察的领导者必须有一个需要做出退让。

这样做是安全和活性间的折中。Paxos是安全的算法-一旦达成共识，赞同的值不会改变。但是，Paxos不能保证处在工作状态-Paxos在稀少的情况下可能不被终止。事实上一个异步一致算法不能被保证既安全又处于活动状态。我们称这为FLP不可能结果。