zoukankan      html  css  js  c++  java
  • 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原理、历程及实战

  • 相关阅读:
    elment ui 日期限制
    javascript中的编码与解码
    vue3 px 转ref
    css 波浪线
    初始化css
    vue 3 的复制功能 vue-clipboard3
    二维数组转一维数组、对象数组互斥去重
    分享几个数组方法
    前端生成图形验证码
    rem自适应布局,移动版
  • 原文地址:https://www.cnblogs.com/stevenczp/p/8618158.html
Copyright © 2011-2022 走看看