basic paxos解析

basic paxos是我见过最难懂的算法，我最近一个月都在研究这个东西，自认有一些粗浅的心得，在这里写一下我对它的理解

为了降低理解难度，本文使用了大量的比喻，可能词不达意，见谅

basic paxos只为了解决一个问题：一个分布式系统如何就某个值（决议）达成一致。

先给出Wiki上对paxos的流程说明：

basic paxos分为两个阶段：

prepare 阶段：

1a) proposer选择一个提案编号n并将prepare请求发送给acceptors中的一个多数派；

1b) acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息，则acceptor将自己上次接受的提案回复给proposer，并承诺不再回复小于n的提案；

accept 阶段：

2a) 当一个proposer收到了多数acceptors对prepare的回复后，就进入批准阶段。它要向回复prepare请求的acceptors发送accept请求，包括编号n和根据P2c决定的value（如果根据P2c没有已经接受的value，那么它可以自由决定value）。

2b) 在不违背自己向其他proposer的承诺的前提下，acceptor收到accept请求后即接受这个请求。

p2c：如果一个编号为n的提案具有value v，那么存在一个多数派，要么他们中所有人都没有接受（accept）编号小于n的任何提案，要么他们已经接受（accept）的所有编号小于n的提案中编号最大的那个提案具有value v。

当然，上面说的简直不像是人话。下面我会尝试用更容易理解的方式来描述这个算法。

在拍卖行里拍卖商品时，需要对某个商品竞价。

我们使用basic paxos来限制竞价者（proposer）与记账员（acceptor），希望能在有限轮竞价之后，确定某个商品的归属。

前提

　　1. 记账员有一张纸，一只铅笔，一只钢笔和一块橡皮。铅笔写下的字迹可以被抹掉，钢笔写下的字迹不能被抹掉。

　　2. 竞价员可以给自己改名

　　3. 有一种特殊的机制，可以让竞价者每次的报价都不相同而且递增

竞价过程分为两个阶段：

准备阶段：

1a) 竞价者选择报价n，并将报价n发给超过一半的记账员

1b) 记账员收到竞价者的报价n之后

　　if(发现这个报价大于他之前收到过的所有报价) {

　　　　if(记账员已经用钢笔写下其他竞价者的报价) {

　　　　　　记账员将之前用钢笔写下的报价和竞价者的名字返回

　　　　} else {

　　　　　　if(记账员已经用铅笔写下其他竞价者的报价) {

　　　　　　　　记账员用橡皮抹去上一次用铅笔写下的报价

　　　　　　}

　　　　　　用铅笔写下报价n

　　　　}

　　} else {

　　　　忽略

　　}

确认阶段：

2a) 竞价者收到了大多数记账员的回复后，竞价者会查看收到的所有回复。

　　如果记账员的回复中带有其他竞价者的名字以及他的报价，那么竞价者会选择其中报价最高的那个回复，然后将自己的名字改成这个回复中带有的名字。

　　竞价者会向这些记账员发起确认请求，确认请求中含有自己的报价n和自己的名字（名字可能在上一行中被更新）

2b) 记账员收到确认请求之后

　　if(纸上只有铅笔写的报价n && 纸上用铅笔写下的报价n == 确认请求里的n) {

　　　　记账员确认这个请求，用钢笔将确认请求中竞价者的名字和报价n写在纸上

　　}

补充：如果竞价者没有收到多数派的返回，会提高自己的报价（不与其他竞价者的竞价重复）然后重新尝试竞价

场景分析

前提：我们有p1p2两个竞价者，和a1a2a3三个记账员

场景1

a. p1提出竞价请求：(1)

b. a1a2a3全部收到，都用铅笔在纸上记下（1），并回复p1

c. p1收到a1a2a3的回复，然后向a1a2a3发起确认请求（1,p1）

d. a1a2a3确认，都用钢笔将（1,p1）写在纸上

总结

这是一次正常情况下的请求，a1a2a3最终都记录了相同的值。

实际上，在这个场景里，paxos已经退化成了两阶段提交协议。

场景2

a. p1提出竞价请求：(1)

b. a1a2收到，都用铅笔在纸上记下（1），并回复p1，a3网络中断没有收到请求

c. p1收到a1a2的回复，然后向a1a2发起确认请求（1,p1）

d. a1a2确认，用钢笔将（1,p1）写在纸上

总结

虽然有一台机失效，但是依然保证了多数派写入数据的一致性。

场景3

a. p1提出竞价请求：(1)

b. a1a2a3全部收到，都用铅笔在纸上记下（1），并回复p1

c. p2提出竞价请求：（2）

d. a1a2a3全部收到，由于p2开价更高，于是放弃p1的竞价请求，都用铅笔在纸上记下（2），并回复p2

e. p1收到步骤b中a1a2a3的回复，向a1a2a3发起确认请求（1,p1）

f. 由于a1a2a3的纸上记录的价格都是2，因此不会理睬p1的确认请求

g. p2收到步骤d中a1a2a3的回复，向a1a2a3发起确认请求（2,p2）

h. a1a2a3确认，用钢笔将(2,p2)写在纸上

总结

虽然有两次竞价请求，但是最终只对其中一次竞价请求做出了回应

场景4

a. p1提出竞价请求（1）

b. a1a2收到，都用铅笔在纸上记下（1），并回复p1。而a3没有收到

c. p2提出竞价请求：（2）

d. a2a3收到，a3直接用铅笔在纸上写下（2），a2已经在纸上用铅笔记下（1），但是由于p2开价更高，于是放弃p1的竞价请求，用铅笔在纸上记下（2），并回复p2

e. p1收到步骤b中的回复，向a1a2发起确认请求（1,p1）

f. a1先收到确认请求，用钢笔在纸上记下（1,p1）。a2后收到确认请求，由于a2纸上写的是（2），因此不做反应

g. p1未能达成多数派确认

h. p2收到步骤d中的回复，向a2a3发起确认请求（2,p2）

i. a2a3收到确认请求，用钢笔在纸上记下（2,p2）

j. p2达成多数派确认

总结

两次时序上有交叉的竞价请求，导致a1a2a3的最终结果不完全一致，但是a2a3依然达成了多数派的一致性。

如果想要获得最终确认后的结果，不能只做单点读取（如果读到a1就不对了），需要做一次多数派读取才行。

场景5

a. p1提出竞价请求（1）

b. a1a2a3全部收到，都用铅笔在纸上记下（1），并回复p1

c. p2提出竞价请求：（2）

d. a1a2a3全部收到，由于p2开价更高，于是放弃p1的竞价请求，都用铅笔在纸上记下（2），并回复p2

e. p1收到步骤b中a1a2a3的回复，向a1a2a3发起确认请求（1,p1）

f. 由于a1a2a3的纸上记录的价格都是2，因此不会理睬p1的确认请求

g. p1提高价格，发起竞价请求（3）

h. a1a2a3全部收到，由于p1这次开价更高，于是放弃p2的竞价请求，都用铅笔在纸上记下（3），并回复p1

i. p2收到步骤d中a1a2a3的回复，向a1a2a3发起确认请求（2,p2）

j. 由于a1a2a3的纸上记录的价格都是3，因此不会理睬p2的确认请求

k. p2提高价格，发起竞价请求（4,p2）

。。。

总结

p1和p2不断发起时序上交叉的竞价请求，导致竞价请求不断被互相覆盖

无法形成统一的竞价结果

这个就是所谓的活锁(live lock)

场景6

a. p1提出竞价请求：(1)

b. a1a2收到，都用铅笔在纸上记下（1），并回复p1，a3没有收到请求

c. p1收到a1a2的回复，然后向a1a2发起确认请求（1, p1）

d. a1a2确认，用钢笔将（1,p1）写在纸上

e. p2提出竞价请求（2）

f. a2a3收到，a3直接将(2)用铅笔写在纸上，a2的纸上已经用钢笔写下了（1,p1），因此将此信息返回给p2

g. p2收到a2和a3的回复，发现a2的纸上已经用钢笔写下了（1,p1），因此p2将自己的名字改名为p1，然后向a2a3发起确认请求（2,p1）

h. a3纸上用铅笔写下了（2），与收到的确认请求里的价格相等，因此a3将确认请求（2,p1）用钢笔写在纸上

i. p1在a1a2a3上达成全部确认

总结

虽然p1只在a1和a2上完成多数派确认，但是后来的p2会将这个确认传递给其他的记账员

参考资料

微信自研生产级paxos类库PhxPaxos实现原理介绍

微信PaxosStore：深入浅出Paxos算法协议

架构师需要了解的Paxos原理、历程及实战