聊聊分布式一致性算法协议 Paxos-分布式一致性算法

Google的粗粒度锁服务Chubby的设计开发者Burrows曾经说过：所有一致性协议本质上要么是Paxos要么是其变体。

网上有很多讲解Paxos算法的文章，但是质量层次不齐。今天笔者带大家深入聊一下Paxos。

Paxos是什么？

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

Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。

自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。

Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。

但是它也有两个明显的缺点：

难以理解
在工程是实现上比较复杂。

问题产生的背景

在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

这里某个数据的值并不只是狭义上的某个数，它可以是一条日志，也可以是一条命令（command）。根据应用场景不同，某个数据的值有不同的含义。

问题描述

假设有一组可以提出（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认为V2被选定，人大代表2-5和人民法院认为V1被选定。出现了不一致。
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）：

向Proposer承诺保证不再接受任何编号小于N的提案。
如果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只需记住：

已接受的编号最大的提案
已响应的请求的最大编号。

Paxos算法描述

经过上面的推导，我们总结下Paxos算法的流程。

Paxos算法分为两个阶段。具体如下：

阶段一：

Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。
如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。

阶段二：

如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor（和之前的Acceptor不一定相同）。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定。
如果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