一致性协议之Paxos算法。

最新推荐文章于 2021-11-25 14:56:00 发布

软件求生

最新推荐文章于 2021-11-25 14:56:00 发布

阅读量511

点赞数

分类专栏：分布式文章标签：分布式算法事务

分布式专栏收录该内容

42 篇文章 1 订阅

订阅专栏

是一种基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。

在常见的分布式系统中，总会发生诸如机器宕机或网络异常等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确的在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常都不会破坏整个系统的一致性。

问题描述

假设有一组可以提出提案的进程集合，那么对于一个一致性算法来说需要保证以下几点：

在这些被提出的提案中，只有一个会被选定。
如果没有提案被提出，那么就不会有被选定的提案。
当一个提案被选定后，进程应该可以获取被选定的提案信息。

对于一致性来说，安全性（Safety）需求如下：

只有被提出的提案才能被选定（Chosen）。
只能有一个值被选定。
如果某个进程认为某个提案被选定了，那么这个提案必须是真的被选定的那个。

在对Pax算法的讲解过程中，我们不去精确的定义其活性（Liveness）需求，从整体来说，Paxos算法的目标就是要保证最终有一个提案会被选定，当提案被选定后，进程最终也能获取到被选定的提案。

在该一致性算法中，有三种参与角色，我们用Proposer、Acceptor和Learner来表示。在具体的实现中，一个进程可能充当不止一种角色，在这里我们并不关心进程如何映射到各种角色。假设不同参与者之间可以通过收发消息来进行通信，那么：

每个参与者以任意的速度执行，可能会因为出错而停止，也可能会重启。同时，即使一个提案被选定后，所有的参与者也都有可能失败或重启，因此除非那些失败或重启的参与者可以记录某些信息，否则将无法确定最终的值。
消息在传输过程中可能会出现不可预知的延迟，也可能会重复或丢失，但是消息不会被损坏，即消息内容不会被篡改（拜占庭式的问题）。

提案的选定

要选定一个唯一提案的最简单方式莫过于只允许一个Accpetor存在，这样的话，Proposer只能发送提案给该Accpetor，Acceptor会选择他接收到的第一个提案作为被选定的提案。这种解决方案尽管实现起来非常简单，但是却很难让人满意，因为一旦这个Accpetor出现问题，那么整个系统就无法工作了。

因此，应该寻找一种更好的解决方式，例如可以使用多个Accpetor来避免Accpetor的单点问题。现在我们就来看看，在存在多个Acceptor的情况下，如何进行提案的选取：Proposer向一个Acceptor集合发送提案，同样，集合中的每个Acceptor都可能会批准（Accept）该提案，当有足够多的Acceptor批准这个提案的时候，我们就可以认为该提案被选定了。那么，什么是足够多呢？我们假定足够多的Acceptor是整个Acceptor集合的一个子集，并且让这个集合大的可以包含Acceptor集合中的大多数成员，因为任意两个包含大多数Acceptor的子集至少有一个公共成员。另外我们再规定，每一个Acceptor最多只能批准一个提案，那么就能保证只有一个提案被选定了。

推导过程

在没有失败和消息丢失的情况下，如果我们希望即使在只有一个提案被提出的情况下，仍然可以选出一个提案，这就按时了如下的需求。

P1：一个Acceptor必须批准他收到的第一个提案。

上面这个需求就引出了另外一个问题：如果有多个提案被不同的Proposer同时提出，这可能会导致虽然每个Acceptor都批准了他收到的第一个提案，但是没有一个提案是由多数人都批准的。下图就是这样的场景。

上图所示就是不同的Proposer分别提出了多个提案的场景，在这种场景下，是无法选定一个提案的。另外，即使只有两个提案被提出，如果每个提案都被差不多一般的Acceptor批准了，此时即使只有一个Acceptor出错，都有可能导致无法确定该选定哪个提案，下图所示就是这样的场景。

上图所示就是一个典型的在任意一个Acceptor出现问题的情况下，无法选定提案的情况。在这个例子中，共有5个Acceptor，其中2个批准了提案V1，另外3个批准了提案V2，此时如果批准V2的3个Acceptor中有一个（上图的第5个Acceptor）出错了，那么V1和V2的批准者都变成了2个，此时无法选定最终的提案了。

因此，在P1的基础上，再加上一个提案被选定需要由半数以上的Acceptor批准的需求按时着一个Acceptor必须能够批准不止一个提案。在这里，我们使用一个全局的编号（这种全局唯一编号的生成并不是Paxos算法需要关注的地方，就算法本身而言，其假设当前已经具备这样的外部组件能够生成一个全局唯一的编号）来唯一标识每一个被Acceptor批准的提案，当一个具有某Value值的提案被半数以上的Acceptor批准后，我们就认为该Value被选定了，此时我们也认为该提案被选定了。需要注意的是，此处讲到的提案已经和Value不是同一个概念了，提案变成了一个由编号和Value组成的组合体，因此我们以“[编号 , Value]”来表示一个提案。

根据上面讲到的额内容，我么你虽然允许多个提案被选定，但同时必须要保证所有被选定的提案都具有相同的Value值——这是一个关于提案Value的约定，结合提案的编号，该约定可以定义如下：

P2：如果编号为M0、Value值为V0的提案（即[M0 , V0]）被选定了，那么所有比编号M0更高的，且被选定的提案，其Value值必须也是V0。

因为提案的编号是全序的，条件P2就保证了只有一个Value值被选定这一关键安全性属性。同时，一个提案要被选定，其首先必须被至少一个Acceptor批准，因此我们可以通过满足如下条件来满足P2。

P2a：如果编号为M0、Value值为V0的提案（即[M0 , V0]）被选定了，那么所有比编号M0更高的，且被Acceptor批准的提案，其Value值必须也是V0。

至此，我们仍然需要P1来保证提案会被选定，但是因为通信是异步的，一个提案可能会在某个Acceptor还未受到任何提案时就被选定了。如下图所示。

如上图所示，在Acceptor I 没有收到任何提案的情况下，其他4个Acceptor已经批准了来自Proposer2的提案[M0，V1]，而此时，Proposer 1 产生了一个具有其他Value值的、编号更高的提案[M1，V2]，并发送给了Acceptor 1。根据P1，就需要Acceptor 1 批准该提案，但是这与P2a矛盾，因此如果要同时满足P1和P2a，需要对P2a进行如下强化：

P2b：如果一个提案[M0 , V0]被选定后，那么之后任何Proposer产生的编号更高的提案，其Value值都为V0。

因为一个提案必须在被Proposer提出后才能被Acceptor批准，因此P2b包含了P2a，进而包含了P2。于是，接下去的重点就是论证P2b成立即可：

假设某个提案[M0 , V0]已经被选定了，证明任何编号Mn>M0的提案，其Value值都是V0。

Proposer生成提案

现在我们来看看，在P2c的基础上如何进行提案的生成。对于一个Proposer来说，获取那些已经被通过的提案远比预测未来可能会被通过的提案来的简单。因此，Proposer在产生一个编号为Mn的提案时，必须要知道当前某一个将要或已经被半数以上Acceptor批准的编号小于Mn但为最大编号的提案。并且，Proposer会要求所有的Acceptor都不要再批准任何编号小于Mn的提案——这就引出了如下的提案生成算法。

Proposer选择一个新的提案编号Mn，然后向某个Acceptor集合的成员发送请求，要求该集合中的Acceptor做出回应。
- 向Proposer承诺，保证不再批准任何编号小于Mn的提案。
- 如果Acceptor已经批准过任何提案，那么其就向Proposer反馈当前该Acceptor已经批准的编号小于Mn但为最大编号的那个提案的值。

我们将该请求称为编号为Mn的提案的Prepare请求。

如果Proposer收到了来自半数以上的Acceptor的响应结果，那么他就可以产生编号为Mn、Value值为Vn的提案，这里的Vn是所有响应中编号最大的提案的Value值。当然还存在另一种情况，就是半数以上的Acceptor都哦没有批准过任何提案，即响应中不包含任何的提案，那么此时Vn值就可以由Proposer任意选择。

在确定提案之后，Proposer就会将该提案再次发送给某个Acceptor集合，并期望获得他们的批准，我们称此请求为Accept请求。需要注意的一点事，此时接受Accept请求的Acceptor集合不一定是之前响应Prepare请求的Acceptor集合——这点相信读者也能够明白，任意两个半数以上的Acceptor集合，必定包含至少一个公共Acceptor。

Acceptor批准提案

在上文中，我们已经讲解了Paxos算法中Proposer的处理逻辑，下面我们来看看Acceptor是如何批准提案的。

根据上面的内容，一个Acceptor可能会收到来自Proposer的两种请求，分别是Prepare请求和Accept请求，对这两类请求做出响应的条件分别如下。

Prepare请求：Acceptor可以在任何时候响应一个Prepare请求。
Accept请求：在不违背Accept现有承诺的前提下，可以任意响应Accept请求。

因此，对Acceptor逻辑处理的约束条件，大体可以定义如下。

P1a：一个Acceptor只要尚未响应过任何编号大于Mn的Prepare请求，那么他就可以接受这个编号为Mn的提案。

从上面这个约束条件中，我们可以看出，P1a包含了P1。同时，值得一提的是，Paxos算法允许Acceptor忽略任何请求而不用担心破坏其算法的安全性。

算法优化

在上面的内容中，我们分别从Proposer和Acceptor对提案的生成和批准两方面来讲解了Paxos算法在提案选定过程中的算法细节，同时也在提案的编号全局唯一的前提下，获得了一个满足安全性需求的提案选定算法，接下来我们再对这个初步算法做一个小优化。尽可能的忽略Prepare请求：

假设一个Acceptor收到了一个编号为Mn的Prepare请求，但此时该Acceptor已经对编号大于Mn的Prepare请求做出了响应，因此他肯定不会再批准任何新的编号为Mn的提案，那么很显然，Acceptor就没有必要对这个Prepare请求做出响应，于是Acceptor可以选择忽略这样的Prepare请求。同时，Acceptor也可以忽略掉那些他已经批准过的提案的Prepare请求。

通过这个优化，每个Acceptor只需要记住他已经批准的提案的最大编号以及他已经做出Prepare请求响应的提案的最大编号，以便在出现故障或节点重启的情况下，也能保证P2c的不变性。而对于Proposer来说，只要他可以保证不会产生具有相同编号的提案，那么就可以丢弃任意的提案以及他所有运行时状态信息。

算法陈述

综合前面讲解的内容，我们来对Paxos算法的提案选定过程进行一个陈述。结合Proposer和Acceptor对提案的处理逻辑，就可以得到如下类似于两阶段提交的算法执行过程。

阶段一

Proposer选择一个提案编号Mn，然后向Acceptor的某个超过半数的子集成员发送编号为Mn的Prepare请求。
如果一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的所有Prepare请求的编号，那么他就会将它已经批准过的最大编号的提案作为响应反馈给Proposer，同时该Acceptor会承诺不会再批准任何编号小于Mn的提案。

举个例子来说，假定一个Acceptor已经响应过的所有Prepare请求对应的提案编号分别为1、2、...、5和7，那么该Acceptor在接收到一个编号为8的Prepare请求后，就会将编号为7的天作为响应反馈给Proposer。

阶段二

如果Proposer收到来自半数以上的Acceptor对于其发出的编号为Mn的Prepare请求的响应，那么他就会发送一个针对[Mn , Vn]提案的 Accept 请求给 Acceptor。注意，Vn的值就是收到的响应中编号最大的提案的值，如果响应中不包含任何提案，那么他就是任意值。
如果Acceptor收到这个针对[Mn , Vn]提案的Accept请求，只要该Acceptor尚未对编号大于Mn的Prepare请求做出响应，他就可以通过这个提案。

当然，在实际运行过程中，每一个Proposer都有可能会产生多个提案，但只要每个Proposer都遵循如上所述的算法运行，就一定能够保证算法执行的正确性。值得一提的是，每个Proposer都可以在任意时刻丢弃一个提案，哪怕针对该提案的请求和响应在提案被丢弃后会到达，但根据Paxos算法的一系列规约，依然可以保证其在提案选定上的正确性。事实上，如果某个Proposer已经在试图生成编号更大的提案，那么丢弃一些旧的提案未尝不是一个好的选择。因此，如果一个Acceptor因为已经收到过更大编号的Prepare请求而忽略某个编号更小的Prepare或者Accept请求，那么他也应当通知其对应的Proposer，以便该Proposer也能够将该提案进行丢弃——这和上面“”算法优化“”部分中提到的提案丢弃是一致的。

提案的获取

在上文中，我们已经介绍了如何而来选定一个天，下面我们再来看看如何让Learner获取提案，大体可以有以下几种方案。

方案一

Learner获取一个已经被选定的提案的前提是，该提案已经被半数以上的Acceptor批准。因此，最简单的做法就是一旦Acceptor批准了一个提案，就将该提案发送给所有的Learner。

很显然这种做法虽然可以让Learner尽快的获取被选定的提案，但是却需要让每个Acceptor与所有的Learner逐个进行一次通信，通信的次数至少为二者个数的乘积。

方案二

另一种可行的方案是，我们可以让所有的Acceptor将他们对提案的批准情况，统一发送给一个特定的Learner（下文中我们将这样的Learner称为主Learner“”），在不考虑拜占庭将军问题的前提下，我们假定Learner之间可以通过消息通信来互相感知提案的选定情况。基于这样的前提，当主Learner被通知一个提案已经被选定时，他会负责通知其他的Learner。

在这种方案中，Acceptor首先会将得到批准的提案发送给主Learner，再由其同步给其他Learner，因此较方法以而言，方案二虽然需要多一个步骤才能将提案通知到所有的Learner，但其通信次数却大大减少了，通常只是Acceptor和Learner的个数总和。但同时，该方案引入了一个新的不稳定因素：主Learner随时可能出现故障。

方案三

在讲解方案二的时候，我们提到，方案二最大的问题在于主Learner存在单点问题，即主Learner随时可能出现故障。因此对方案二进行改进，可以将主Learner的范围扩大，即Acceptor可以加你个批准的提案发送给一个特定的Learner集合，该集合中的每个Learner都可以在一个提案被选定后通知所有其他的Learner。这个Learner集合中的Learner个数越多，可靠性就越好，但同时网路通信的复杂度也就越高。

通过选取主Proposer保证算法的活性

根据前面的内容讲解，我们已经基本上了解了Paxos算法的核心逻辑，下面我们再来看看Paxos算法在实际运行过程中的一些细节。假设存在这样一种极端情况，有两个Proposer依次提出了一系列编号递增的议案，但是最终都无法被选定，具体流程如下：

Proposer P1 提出了一个编号为M1的提案，并完成了上述阶段一的流程。但与此同时，另外一个Proposer P2 提出了一个编号为M2（M2>M1）的提案，同样也完成了阶段一的流程，于是Acceptor已经承诺不再批准编号小于M2的提案了。因此，当P1进入阶段二的时候，其发出的Accept请求将被Acceptor忽略，于是P1再次进入阶段一并提出了一个编号为M3（M3>M2）的提案，而这又导致P2在第二阶段的Accept请求被忽略，以此类推，提案的选定过程将陷入死循环，如下图所示。

为了保证Paxos算法流程的可持续性，以避免陷入上述提到的“死循环”，就必须选择一个主Proposer，并规定只有主Proposer才能提出议案。这样一来，只要主Proposer和过半的Acceptor能够正常进行网络通信，那么但凡主Proposer提出一个编号更高的提案，该提案终将会被批准。当然，如果Proposer发现当前算法流程中已经有一个编号更大的提案。因此，如果系统中有足够多的组件（包括Proposer、Acceptor和其他网络通信组件）能够正常工作，那么通过选择一个主Proposer，整套Paxos算法流程就能够保持活性。