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原理、历程及实战

posted @ 2018-03-21 18:06  qeDVuHG  阅读(308)  评论(0编辑  收藏  举报