腾讯开源的 Paxos库 PhxPaxos 代码解读---Accept阶段(一)

腾讯开源的 Paxos库 PhxPaxos 代码解读---Accept阶段(一)

在看Accept阶段代码之前, 我们再回想一下 Basic Paxos算法;

    1.  Basic Paxos 算法是为了使集群中的Acceptor们达成一个最终的值, 或者不能达成一个最终的值;

        就是说, 要么达成一个最终的值, 某个时间点上, 多数派节点都是一个一致的值, 这个值就是最终的值;

        否则, 没有多数派在某个时间点达成一个一致的值, 这个值不断被新的提议(Proposal)刷新, 无法达成最终值;

        这种情况一般意味着发生了活锁;

    2.  一个最终的值一旦被确定, 不能再有Proposor发出提议进行修改, 为了确保这点, 有了针对Proposor的约束:

        Proposor必须收到多数派的响应, 才能进行Accept提议; 原因如下:

           

            Proposor只有收到多数派响应消息, 才能确定是否已经有多数派接受过提议(Proposal),

            如果多数派响应消息里面已经携带了接受过的提议, 则有两种可能:

                1. 多数派已经已经达成了一致, 必然会有某些Acceptor的响应携带了这个值;

                2. 多数派还没有达成一致, 但是Proposor正好收到了某个已经接受过提议的Acceptor的响应;

            上述情况不论是哪种, Proposor都需要用已有的提议发起Accept请求,

            这样是为了促使Acceptor们尽快的达成一致;

    3.  对于Acceptor的约束, 则是必须要大于等于当前已经接受过的最大ProposalID, 才能刷新这个值,;

        我们给出一个典型的场景来说明, 以 2个Proposor, 3个Acceptor为例:

       

        第1个时间片段:

            Proposor1发起Prepare请求(1, 100), 成功到达 Acceptor1和Acceptor2, Acceptor的状态如下:

                Acceptor1(1, null); Acceptor2(1, null); Acceptor3(null, null)

        第2个时间片段:

            Proposor2发起Prepare请求(2, 101), 成功到达 Acceptor1和Acceptor2, Acceptor的状态如下:

                Acceptor1(2, null); Acceptor2(2, null); Acceptor3(null, null)

        第3个时间片段:

            Proposor1发起Accept请求(1, 100), 1 < 2, 被Acceptor拒绝, Acceptor的状态如下:

                Acceptor1(2, null); Acceptor2(2, null); Acceptor3(null, null)

        第4个时间片段:

            Proposor2发起Accept请求(1, 100), 2=2, 被Acceptor接受, Acceptor的状态如下:

                Acceptor1(2, 100); Acceptor2(2, 100); Acceptor3(null, null)

在处理Prepare和Accept请求时, 我们不仅要考虑网络中的异步情况, 还要考虑在接受一个提议时代码执行的异步情况;

前面一篇博客已经简单介绍过phxpaxos中Prepare阶段的代码, 下面简单的介绍一下Accept阶段的代码;

phxpaxos\src\algorithm\proposer.cpp

这里的代码是Proposor的逻辑

phxpaxos\src\algorithm\acceptor.cpp

这里的代码是Acceptor的逻辑

下面的图是Proposor发起Accept请求的操作:

下面的图是Acceptor收到Accept请求的操作:

下面的图是Propsor收到Acceptor返回响应的操作:

结束:
微信开源的Paxos库有很多照顾性能的实现, 后面慢慢讲吧;