paxos一致性算法（大白话+图解）

Paxos是什么

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

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。

问题产生的背景

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

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

相关概念

在Paxos算法中，有三种角色：

• Proposer
• Acceptor
• Learners

在具体的实现中，一个进程可能同时充当多种角色。比如一个进程可能既是Proposer又是Acceptor又是Learner。

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。注意：V就是收到的响应中编号最大的提案的value**，如果响应中不包含任何提案，那么V就由Proposer自己决定。

  (b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。

图解

案例：三军问题（拜占庭将军问题简化）

在没有通信设备，只能靠通信兵的情况下，三位将军需要协商同一时间进攻敌军（不是现实中的问题，只是类比，不要转牛角尖，先抛开通信兵（协商的进攻时间）被敌军篡改，只保留可能被敌军拦截的情况）

将军（Acceptor，就是接受者）可以有参谋（Proposer，就是提案者），暂时不管Learner

参谋（Proposer）派出的通信兵（啥也不是，就是起一个通信作用）都会携带自增长的提案编号（N）

自家的将军（Acceptor）也要听从自家参谋（Acceptor）的安排

进攻时间（value）

时间会议通知（Prepare）、提案（Accept）为请求

黄色为保存的通知请求（Prepare）的提案编号（N）

红色为保存的提案请求（Accept）的提案编号（N）和进攻时间（value）

简单情况

1、Proposer（参谋 1）向半数以上Acceptor（将军 1、2、3）发送带提案编号N（编号 1）的Prepare请求

2、Acceptor（将军 1、2、3）收到请求并回复ok

Acceptor（将军 1、2、3）保存提案编号N（编号 1），并拒绝小于编号 N（编号 1）的 提案请求（Accept）（这里是简单情况，并没有拒绝案例，后面复杂情况展示）

由于Acceptor（将军 1、2、3）并没有保存的提案（编号N和value），只需要回复ok

3、Proposer（参谋 1）向回复ok的Acceptor（将军 1、2、3）发送带提案编号N（编号 1）和value（进攻时间 1）的提案请求Accept

4、Acceptor（将军 1、2、3）给予Proposer（参谋 1）回复同意（Accepted）

半数以上Acceptor（将军 1、2、3）同意并保存提案（编号N（编号 1）和value（进攻时间 1））

结束（SUCESS），Acceptor（参谋 1）无需继续发请求

5、Proposer（参谋 2）向半数以上Acceptor（将军 1、2、3）发送带提案编号N（编号 2）的Prepare请求

6、Acceptor（将军 1、2、3）收到请求并回复保存的提案（编号N（编号 1）和value（进攻时间 1））

Acceptor（将军 2）再次改value（更改顺序：进攻时间 2 --> 进攻时间 1 --> 进攻时间 1）

7、Proposer（参谋 2）向回复ok的Acceptor（将军 1、2、3）发送带提案编号N（编号 2）和value（进攻时间 1）的提案Accept

由于 将军 2 节点的 value 被改了（改成了进攻时间 1），所以发送的 value 就是进攻时间 1

8、Acceptor（将军 1、2、3）给予 Proposer（参谋 2）回复（Accepted）

半数以上Acceptor（将军 1、2、3）同意并保存提案（编号N（编号 2）和value（进攻时间 1））

结束（SUCESS），Proposer（参谋 2）无需继续发请求

至此全部节点保存相同的value（进攻时间 1）

9、Learner节点（该例子没有）同步value（这里就不画了，就是具有学习的节点会同步value）

复杂情况

1、Proposer（参谋 1）向半数以上 Acceptor（将军 1、2、3）发送带提案编号N（编号 1）的Prepare请求，但是某个 Acceptor（将军 2）请求超时或者丢失（被敌军拦截）

2、Acceptor（将军 1、3）收到请求并回复ok，并保存编号N（编号 1）

Acceptor（将军 1、3）保存提案编号N（编号 1），并拒绝小于编号 N（编号 1）的 提案请求（Accept）

由于Acceptor（将军 1、3）并没有保存的提案（编号N和value），只需要回复ok

3、与此同时 Proposer（参谋 2）也向半数以上 Acceptor（将军 1、2、3）发送带提案编号N（编号 2）的Prepare请求，但是某个 Acceptor（将军 1）请求超时或者丢失（被敌军拦截）

4、Acceptor（将军 2、3）收到请求并回复ok，并保存编号N（编号 2）

将军 2、3 并没有保存的提案（编号N、value）所以只需要回复ok

5、Proposer（参谋 1）由于收到半数以上的Acceptor（将军 1、3）回复ok，向回复ok的 Acceptor（将军 1、3）发送带提案编号N（编号 1）和value（进攻时间 1）的提案请求 Accept

6、一个Acceptor（将军 1）成功同意提案，保存提案（编号 1、进攻时间 1），发送给 Proposer（参谋 1）成功 accepted，另一个Acceptor（将军 3）失败，不保存任何信息，返回Proposer（参谋 1）失败 rejected

注意：将军 3 节点由于保存了 编号 2（ 参谋 2 发送的 perpare 请求 携带的 编号 N），所以后续需要拒绝小于编号 2 的请求

因为 编号 2 > 编号 1

所以 将军 3 节点拒绝了 参谋 1 发送的 accepted 请求中的提案（编号 1、进攻时间 1）

而 将军 1 节点本来只有 编号 1，编号 1 不小于 编号 1，所以就同意了该 accept 请求，保存了提案（编号 1、进攻时间 1）

由于三个节点只有一个成功，不符合多半以上节点同意提案，该请求失败（failure），Proposer（参谋 1）后续还会发请求

7、Proposer（参谋 2），向Acceptor（将军 2、3）发起提案请求 accept（携带 编号 2、进攻时间 2）

8、Acceptor（将军 2、3）同意并保存提案（编号 N（编号 2）和 value（进攻时间 2））

Proposer（参谋 2） 收到 半数以上 Acceptor（将军 2、3）节点同意的回复，之后就不会再发请求了

9、Proposer（参谋 1）再次向半数以上 Acceptor（将军 1、2、3）发送带提案编号N（编号 3）的 Prepare 请求（上次失败了，所以还得发）

10、Acceptor（将军 1、2、3）回复各自的提案，并保存编号 3，后续会拒绝掉小于编号 3 的请求

参谋 1 收到了两个提案，分别是 提案 1（编号 1、进攻时间 1）和 提案 2（编号 2、进攻时间 2），因为提案 2 的编号比提案 1 的编号大（编号 2 > 编号 1），所以更新提案（编号 2、进攻时间 2）

11、Proposer（参谋 1）向回应的 Acceptor（将军 1、2、3）发起提案请求 Accept

12、Acceptor（将军 1、2、3）同意Proposer（参谋 1）的提案请求，并保存提案（编号 3、进攻时间 2）

13、Learner节点（该例子没有）同步value（这里就不画了，就是具有学习的节点会同步value）

Paxos问题

一、活锁问题

看懂了上面的三军问题，我就用最简单的 Proposer、Acceptor 来展示 paxos 会出现的问题

1、Proposer 1 发送带 编号 1 的 prepare 请求

2、Proposer 1 也发送带 编号 2 的 prepare 请求

3、Proposer 1 发送带 编号 1 和 value 1 的 Accept 提案，显而是行不通的

4、Proposer 1 只能增大编号 继续发请求（编号 3）

5、那么 Proposer 2 发送带 编号 2 和 value 2 的 Accept 提案，就行不通了

6、那么 Proposer 2 也需要增大编号（编号 4）去发 prepare 请求，这样周而复始，就是 Paxos 的活锁问题（这里就不画了）

7、解决方案也很简单，就是给每个 Proposer 增加一个随机时间，总有一次不冲突就好了

二、性能差

每次 Proposer 都需要发一次 prepare 和 Accept 请求，为了解决活锁问题还需要添加一个随机时间，就导致了 Paxos 的性能问题

那 Paxos 解决不了，就得升级算法了，这就引出了 raft 算法了，这里只为了讲解 Paxos ，就不说 raft 了，感兴趣的小伙伴可以自己去搜搜看，博主后续也会更新 raft 算法的博客的，时间优先就先写了这一篇

参考文章：

分布式系列文章——Paxos算法原理与推导 - lzslbd

十五分钟带你了解Paxos算法