本文是《循序渐进分布式一致性算法》第一篇-paxos。写这一篇也是有些战战兢兢。自己只是看了一些文章跟部分源码实现，简单总结一下自己学习之后的理解，以及学习过程中用到的一些资料。如有不对，请指出。
写本文之前，我在构思按照什么思路进行展开。 想了好几个，最终按照 “如果面试官让你介绍paxos,你会怎么讲？” 这个思路展开。如下几点讲解：

paxos 为了解决什么问题
paxos之前有没有一些其他方案？
为什么非要paxos?
paxos 算法内容
paxos 的工程实现

1 paxos 为了解决什么问题

Paxos 算法的目的就是确定分布式系统中的一个不可变变量的值。并且一旦确定，将不再更改，并且可以被获取到。

我们想一下，在分布式系统中，为了达成上述要求，应该要解决那些问题呢？

• 系统有多个存储的节点，这些节点之间的数据要保持一致。
• 系统有多个写入的节点，这些写入的节点会存在并发，如何确定由哪个节点写入？
• 多个写入节点可能会出现故障
• 多个存储节点也可能出现故障，但是要保证半数以上的存储节点是可用并且值是一致的。

(存储跟决定选择哪个数据的节点在paxos中叫acceptor, 写入的节点称作 proposer)

2 paxos之前有没有一些其他方案？

针对上面提到的几个问题，我们想一下几个特殊场景的解决方案。

2.1 one acceptor multi proposer --互斥锁

我们可以让多个proposer去争夺互斥锁来决定，谁来写入。那么这个锁的决定权有acceptor决定。这样就解决了多个proposer并发的问题。
这种方案会有问题吗？
比如一个proposer抢到了锁，但是在执行第二阶段实际写入数据（后面paxos中称之为提议阶段）阶段，这个proposer 挂了，那么这就悲剧了，因为这个proposer抢到了锁但是不能写入，而其他proposer又抢不到锁，系统就悲剧了。这种方案不允许proposer故障。

2.2 one acceptor , multi proposer--抢占式

通过引入抢占式访问权，acceptor可以让某个proposer获取到的访问权失效，之后将访问权发放给其他proposer。

2.2.1 acceptor

存储了两种状态
（1）当前var的取值 （accepted_epoch, accepted_value）
其中accepted_epoch 就是 proposer的编号， accepted_value 是已经被确认的值。
（2）最新发放访问权的epoch(latest_prepared_epoch) 就是当前接收到的最大的proposer的编号。
prepare阶段需要做的事情
只接收比latest_prepared_epoch更大的proposer的编号;
记录当前的latest_prepared_epoch = 更大的proposer的编号， 但是var 是返回当前的值（这样保证了“后者认同前者”）。
accept阶段需要做的事情
验证latest_prepared_epoch = prepared_epoch;
设置 （accepted_epoch, accepted_value） = （prepared_epoch， v）。

2.2.2 proposer

第一阶段需要做的事情
获取epoch轮次的访问权以及当前确定的var的取值。

第二阶段需要做的事情
采用“后者认同前者”的原则。
怎么讲？
如果prepare阶段返回的var为空，则肯定旧的epoch无法生成确定性取值，则提交自己的V值。
如果var值存在，则此取值肯定是确定性取值，此时认同它，不再更改，直接使用这个值。

这个场景下，已经很好地解决了场景2.1 的问题，那么如果多个acceptor呢？
那就采用paxos吧。

3 paxos- multi acceptor , multi proposer.

3.1 Acceptor

在2.2的基础上，支持了多acceptor. paxos采用了“少数服从多数”的原则，一旦某epoch 的取值f 被半数以上的acceptor接受，则认为此var取值被确定为f,不再更改。

3.2 Proposer

3.2.1 第一阶段

选定epoch，获取epoch访问权和对应的var取值。必须半数以上的accepor同意。

3.2.2 第二阶段

采用“后者认同前者”的原则执行。

• 如果var为空，则使用proposer自己的V，如果得到半数以上的acceptor统一，则OK。 如果失败，则返回error, 重新进入prepare阶段。
• 如果var不为空，认同最大accepted_epoch对应的取值f, 努力使<当前epoch, f > 成为确定性取值。

4 paxos 算法内容

先给个结论（来自维基百科）：

通过一个决议分为两个阶段：

• prepare阶段：
  proposer选择一个提案编号n并将prepare请求发送给acceptors中的一个多数派；
  acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息(回复消息表示接受accept)，则acceptor将自己上次接受的提案回复给proposer，并承诺不再回复小于n的提案；
• 批准阶段：
  当一个proposer收到了多数acceptors对prepare的回复后，就进入批准阶段。它要向回复prepare请求的acceptors发送accept请求，包括编号n和根据P2c决定的value（如果根据P2c没有已经接受的value，那么它可以自由决定value）。
  在不违背自己向其他proposer的承诺的前提下，acceptor收到accept请求后即批准这个请求。

再来个图：

paxos.png

5 paxos 的工程实现

微信开源的phxpaxos：https://github.com/Tencent/phxpaxos

一个简版的go paxos实现： https://github.com/zhanglvmeng/paxos

6 总结

本文参考知行学社的视频讲解，从paxos能解决什么问题，特殊场景下的解决方案，最后引出了paxos。 然后讲解了paxos的算法内容，最后罗列了两个工程上的实现。希望对你有所帮助~

7 参考文献

看过讲解paxos 最经典的中文视频了: https://www.bilibili.com/video/av36134550/?spm_id_from=333.788.videocard.6
这是我整理的视频笔记： https://pan.baidu.com/s/1Gl1tgbffWXu0fcJ0HVykDg
图解分布式一致性协议Paxos http://codemacro.com/2014/10/15/explain-poxos/
维基百科的paxos https://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95#%E5%AE%9E%E4%BE%8B

8 其他

本文是《循序渐进分布式一致性算法》的第一篇-《paxos》。
如果有疑问，可以直接留言，也可以关注公众号 “链人成长chainerup” 提问留言，或者加入知识星球“链人成长”~