--- highlight: a11y-dark theme: awesome-green --- ![v2-090aa07e884b33949119d1db6d87d09b_1440w](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/43e5f6ef8b7243ae84c5e4e9e8861e18~tplv-k3u1fbpfcp-zoom-1.image) Google的粗粒度锁服务Chubby的设计开发者Burrows曾经说过：“所有一致性协议本质上要么是Paxos要么是其变体”。在学习zookeeper过程中经常可以看到这句话，这个算法既然这么神奇，当然很有必要来好好的研究一番。网上有很多讲解Paxos算法的文章，但是质量层次不齐。为此，笔者阅读了相关论文、百科、博客等资料之后，试图通过简单的语言清楚的描述Paxos算法。 ## 一、Paxos是什么 > Paxos算法是基于**消息传递**且具有**高度容错特性**的**一致性算法**，是目前公认的解决**分布式一致性**问题**最有效**的算法之一。 Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。但是它也有两个明显的缺点：1.难以理解、2.在工程是实现上比较复杂。 ## 问题产生的背景在常见的分布式系统中，总会发生诸如**机器宕机**或**网络异常**（包括消息的延迟、丢失、重复、乱序，还有网络分区）等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对**某个数据的值**达成**一致**，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。注：这里**某个数据的值**并不只是狭义上的某个数，它可以是一条日志，也可以是一条命令（command）。根据应用场景不同，**某个数据的值**有不同的含义。

## 二、相关概念在Paxos算法中，有三种角色： * Proposer (提案者) * Acceptor (人大代表) * Learners (广大群众) 需要注意的是，在具体的算法实现过程中，并不是一个进程只能担任其中一种角色，它有可能会同时充当多个。比如一个进程**既是Proposer又是Acceptor还是Learner**。还有一个很重要的概念叫**提案（Proposal）**。最终要达成一致的value就在提案里。注： * 这个提案包括什么呢？是仅仅包括一个信息数值吗？到底是如何咱们继续向下阅读，目前咱们先认为仅仅是一个普普通通的value。

#### 初次认识 Paxos算法过程和我国的立法过程是极其相似的（法律案的提出、法律案的审议、法律案的表决、法律的公布四个阶段），所谓的提案就是新颁布法律。 Proposer (提案者)可以提出（propose）提案；Accoptor可以接受（accept）提案；如果某个提案被选定（chosen），那么该提案里的value就被选定了。回到刚刚说的『对某个数据的值达成一致』，指的是Proposer、Acceptor、Learner都认为同一个value被选定（chosen）。那么，Proposer、Acceptor、Learner分别在什么情况下才能认为某个value被选定呢？ - Proposer：只要Proposer发的提案被Acceptor接受（刚开始先认为只需要一个Acceptor接受即可，在推导过程中会发现需要半数以上的Acceptor同意才行），Proposer就认为该提案里的value被选定了。 - Acceptor：只要Acceptor接受了某个提案，Acceptor就认为该提案里的value被选定了。 - Learner：作为一个学习者，Acceptor告诉Learner哪个value被选定，Learner就认为那个value被选定。 ## 三、问题描述假设有一组可以**提出（propose）value**的进程集合（提案者团队），一个一致性算法需要保证提出的这么多value中，仅仅**只有一个相同的**value被选定（chosen）。也就是说要么没有value被提出，只要提出了value并且被选定，那么大家最终学习到的value必须是一致的。对于一致性算法，**安全性**（safaty）要求如下： - 只有被提出的value才能被选定。 - 只有一个value被选定。 - 如果某个进程认为某个value被选定了，那么这个value必须是真的被选定的那个。 > Paxos的目标：保证最终有一个value会被选定，当value被选定后，进程最终也能获取到被选定的value。俗话说的好，**哪里有需求，哪里就会出现糟糕的问题**。如果假设不同角色之间可以通过发送消息来进行通信，那么： * 每个角色以各自任意的速度进行通信执行，在这个过程中可能会因为各种原因出错而导致执行停止或重启。当一个value被选定之后，因为故障原因才恢复正常的角色因为失去了某些重要的信息，导致它们无法确定被选定的值。 * 消息在传递过程中可能出现任意时长的延迟，可能会重复，也可能丢失。但是消息不会被损坏，即消息内容不会被篡改（拜占庭将军问题）。以上都是可能会遇到的问题，要怎么解决？？？ ## 四、推导过程 #### 最简单的方案——只有一个Acceptor 假设只有一个Acceptor（可以有多个Proposer），只要Acceptor接受它收到的第一个提案，则该提案被选定，该提案里的value就是被选定的value。这样就保证只有一个value会被选定。但是，如果这个唯一的Acceptor宕机了，那么整个系统就**无法工作**了！因此，一个Acceptor是不可行的，必须要有**多个Acceptor**！

#### 多个Acceptor 当有多个Acceptor的时候，如何保证在多个Proposer和多个Acceptor的情况下选定一个value呢？大家可以自己先进行思考。首先，我们的最终目标是无论有多少Proposer提出提案，有且仅有一个value被选定。那么，我们可以先定义一个约束： > P1：一个Acceptor必须接受它收到的第一个提案。但是，这样又会出现其它的问题：如果每个Proposer所提出的提案value是不同的，并且将提案发送给不同的Acceptor。根据P1约束，每个Acceptor都接受它收到的第一个提案，就会出现不同value被选定的情况，出现了不一致。

刚刚是因为『一个提案只要被一个Acceptor接受，则该提案的value就被选定了』才导致了出现上面不一致的问题。因此，我们需要加一个规定： > 规定：一个提案被选定需要被**半数以上**的Acceptor接受一个提案被半数以上接受，说明『一个Acceptor必须能够接受不止一个提案！』，不然可能导致最终没有value被选定。比如上图的情况。v1、v2、v3都没有被选定，因为它们都只被一个Acceptor的接受，并没有被超过半数以上的Acceptor接受。最开始将【**提案 = value**】已经无法满足现在的需求，因为当一个Proposer发送多个提案到一个Acceptor的时候，需要使用一个编号来区分被提出的顺序。现在【**提案=提案编号+value**】。虽然允许多个提案被选定，但必须保证所有被选定的提案都具有相同的value值。否则又会出现不一致。 > P2：如果某个value为v的提案被选定了，那么每个编号更高的被选定提案的value必须也是v。一个提案只有被Acceptor接受才可能被选定，因此我们可以把P2约束改写成对Acceptor接受的提案的约束P2a。 > P2a：如果某个value为v的提案被选定了，那么每个编号更高的被Acceptor接受的提案的value必须也是v。只要满足了P2a，就能满足P2。但是，考虑如下的情况：以立法过程为背景，假设总的有5个人大代表（Acceptor）。**人民法院**（Proposer2）提出[M1,V1]的提案，**人大代表2-5号**（半数以上）均接受了该提案，于是对于人大代表2-5号和人民法院来讲，它们都认为V1提案是被选定的。此时，**人大代表1**在办完其它事务之后也参与到其中（之前人大代表1没有收到过任何提案），此时**最高人民检察院**（另一个提案者Proposer1）向人大代表1发送了[M2,V2]的提案（V2≠V1且M2>M1），对于人大代表1来讲，这是它收到的第一个提案。根据P1（一个Acceptor必须接受它收到的第一个提案。）,人大代表1必须接受该提案！同时人大代表1认为V2被选定。这就出现了两个问题： 1. 人大代表1认为V2被选定，人大代表2-5和人民法院认为V1被选定。出现了不一致。 2. V1被选定了，但是编号更高的被人大代表1接受的提案[M2,V2]的value为V2，且V2≠V1。这就跟P2a（如果某个value为v的提案被选定了，那么每个编号更高的被Acceptor接受的提案的value必须也是v）矛盾了。

所以，我们要对P2a约束进行加强！ P2a是对Acceptor接受的提案约束，但其实提案是Proposer提出来的，所有我们可以对Proposer提出的提案进行约束。得到P2b： > P2b：如果某个value为v的提案被选定了，那么之后任何Proposer提出的编号更高的提案的value必须也是v。那么，如何确保在某个value为v的提案被选定后，Proposer提出的编号更高的提案的value都是v呢？只要满足P2c即可： > P2c：对于任意的N和V，如果提案[N, V]被提出，那么存在一个半数以上的Acceptor组成的集合S，满足以下两个条件中的任意一个： > > - S中每个Acceptor都没有接受过编号小于N的提案。 > - S中Acceptor接受过的最大编号的提案的value为V。 #### Proposer生成提案为了满足P2b，这里有个比较重要的思想：Proposer生成提案之前，应该先去**『学习』**已经被选定或者可能被选定的value，然后以该value作为自己提出的提案的value。如果没有value被选定，Proposer才可以自己决定value的值。这样才能达成一致。这个学习的阶段是通过一个**『Prepare请求』**实现的。于是我们得到了如下的**提案生成算法**： 1. Proposer选择一个**新的提案编号N**，然后向**某个Acceptor集合**（半数以上）发送请求，要求该集合中的每个Acceptor做出如下响应（response）。 (a) 向Proposer承诺保证**不再接受**任何编号**小于N的提案**。 (b) 如果Acceptor已经接受过提案，那么就向Proposer响应**已经接受过**的编号小于N的**最大编号的提案**。我们将该请求称为**编号为N**的**Prepare请求**。 2. 如果Proposer收到了**半数以上**的Acceptor的**响应**，那么它就可以生成编号为N，Value为V的**提案[N,V]**。这里的V是所有的响应中**编号最大的提案的Value**。如果所有的响应中**都没有提案**，那么此时V就可以由Proposer**自己选择**(一般为当前提案)。生成提案后，Proposer将该**提案**发送给**半数以上**的Acceptor集合，并期望这些Acceptor能接受该提案。我们称该请求为**Accept请求**。（注意：此时接受Accept请求的Acceptor集合**不一定**是之前响应Prepare请求的Acceptor集合） #### Acceptor接受提案 Acceptor**可以忽略任何请求**（包括Prepare请求和Accept请求）而不用担心破坏算法的**安全性**。因此，我们这里要讨论的是什么时候Acceptor可以响应一个请求。我们对Acceptor接受提案给出如下约束： > P1a：一个Acceptor只要尚**未响应过**任何**编号大于N**的**Prepare请求**，那么他就可以**接受**这个**编号为N的提案**。如果Acceptor收到一个编号为N的Prepare请求，在此之前它已经响应过编号大于N的Prepare请求。根据P1a，该Acceptor不可能接受编号为N的提案。因此，该Acceptor可以忽略编号为N的Prepare请求。当然，也可以回复一个error，让Proposer尽早知道自己的提案不会被接受。因此，一个Acceptor**只需记住**：1. 已接受的编号最大的提案 2. 已响应的请求的最大编号。 #### Paxos算法描述经过上面的推导，我们总结下Paxos算法的流程。 Paxos算法分为**两个阶段**。具体如下： - **阶段一：** (a) Proposer选择一个**提案编号N**，然后向**半数以上**的Acceptor发送编号为N的**Prepare请求**。 (b) 如果一个Acceptor收到一个编号为N的Prepare请求，且N**大于**该Acceptor已经**响应过的**所有**Prepare请求**的编号，那么它就会将它已经**接受过的编号最大的提案（如果有的话）** 作为响应反馈给Proposer，同时该Acceptor承诺**不再接受**任何**编号小于N的提案**。 - **阶段二：** (a) 如果Proposer收到**半数以上**Acceptor对其发出的编号为N的Prepare请求的**响应**，那么它就会发送一个针对[N,V]提案的Accept请求给**半数以上**的Acceptor（和之前的Acceptor不一定相同）。注意：V就是收到的响应中编号最大的提案的value，如果响应中**不包含任何提案**，那么V就由Proposer**自己决定**。 (b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor**没有**对编号**大于N**的**Prepare请求**做出过**响应**，它就**接受该提案**。

## 五、Learner学习被选定的value Learner学习（获取）被选定的value有如下三种方案： **方案一：** Acceptor接受到一个提案，就将该提案发送给所有Learners. * 优点：Learner能够快速获取被选定的value * 缺点：通信次数为M*N（M为提案数，N为Learner数） **方案二：** Acceptor接受一个提案，就将提案发送给**主Learner**,主Learner再通知其它Learner * 优点：通信次数减少（M+N-1）（M为提案数，N为Learner数，M个提案发送给主Learner，然后主Learner通知N-1个Learner） * 缺点：单点故障问题（主Learner可能出现故障） **方案三：** Acceptor接受一个提案，就将提案发送给**Learner团**,Learner团再通知其它Learner * 优点：解决了方案二单点故障问题，可靠性好 * 缺点：实现复杂，网络通信复杂度高 ## 六、如何保证Paxos算法的活性

通过选取**主Proposer**，就可以保证Paxos算法的活性。通过选取主Proposer，并规定只有主Proposer才能提出议案。这样一来只要主Proposer和过半的Acceptor能够正常进行网络通信，那么但凡主Proposer提出一个编号更高的提案，该提案终将会被批准，这样通过选择一个主Proposer，整套Paxos算法就能够保持活性。至此，我们得到一个**既能保证安全性，又能保证活性**的**分布式一致性算法**——**Paxos算法**。 ## 七、总结到此，我们针对Paxos算法是什么、它的特性以及算法的具体推导过程做了详细的阐述。**Paxos算法**是现在很多一致性算法的变体，非常值得我们学习。感兴趣的朋友可以关注点赞，谢谢。

#### 参考资料 * 百科的Paxos * 论文《Paxos Made Simple》 * [Paxos算法原理与推导](https://www.cnblogs.com/linbingdong/p/6253479.html)