图解分布式一致性协议Paxos

Paxos协议/算法是分布式系统中比较重要的协议,它有多重要呢?html

<分布式系统的事务处理>算法

Google Chubby的做者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。shell

<大规模分布式存储系统>promise

理解了这两个分布式协议以后(Paxos/2PC),学习其余分布式协议会变得至关容易。网络

学习Paxos算法有两部分:a) 算法的原理/证实;b) 算法的理解/运做。less

理解这个算法的运做过程其实基本就能够用于工程实践。并且理解这个过程相对来讲也容易得多。分布式

网上我以为讲Paxos讲的好的属于这篇:paxos图解Paxos算法详解,我这里就结合wiki上的实例进一步阐述。一些paxos基础经过这里提到的两篇文章,以及wiki上的内容基本能够理解。学习

算法内容

Paxos在原做者的《Paxos Made Simple》中内容是比较精简的:spa

Phase 1code

(a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors.

(b) If an acceptor receives a prepare request with number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered pro-posal (if any) that it has accepted.

Phase 2

(a) If the proposer receives a response to its prepare requests (numbered n) from a majority of acceptors, then it sends an accept request to each of those acceptors for a proposal numbered n with a value v , where v is the value of the highest-numbered proposal among the responses, or is any value if the responses reported no proposals.

(b) If an acceptor receives an accept request for a proposal numbered n, it accepts the proposal unless it has already responded to a prepare request having a number greater than n.

借用paxos图解文中的流程图可归纳为:

实例及详解

Paxos中有三类角色ProposerAcceptorLearner,主要交互过程在ProposerAcceptor之间。

ProposerAcceptor之间的交互主要有4类消息通讯,以下图:

这4类消息对应于paxos算法的两个阶段4个过程:

  • phase 1
    • a) proposer向网络内超过半数的acceptor发送prepare消息
    • b) acceptor正常状况下回复promise消息
  • phase 2
    • a) 在有足够多acceptor回复promise消息时,proposer发送accept消息
    • b) 正常状况下acceptor回复accepted消息

由于在整个过程当中可能有其余proposer针对同一件事情发出以上请求,因此在每一个过程当中都会有些特殊状况处理,这也是为了达成一致性所作的事情。若是在整个过程当中没有其余proposer来竞争,那么这个操做的结果就是肯定无异议的。可是若是有其余proposer的话,状况就不同了。

paxos中文wiki上的例子为例。简单来讲该例子以若干个议员提议税收,肯定最终经过的法案税收比例。

如下图中基本只画出proposer与一个acceptor的交互。时间标志T2老是在T1后面。propose number简称N。

状况之一以下图:

A3在T1发出accepted给A1,而后在T2收到A5的prepare,在T3的时候A1才通知A5最终结果(税率10%)。这里会有两种状况:

  • A5发来的N5小于A1发出去的N1,那么A3直接拒绝(reject)A5
  • A5发来的N5大于A1发出去的N1,那么A3回复promise,但带上A1的(N1, 10%)

这里能够与paxos流程图对应起来,更好理解。acceptor会记录(MaxN, AcceptN, AcceptV)

A5在收到promise后,后续的流程能够顺利进行。可是发出accept时,由于收到了(AcceptN, AcceptV),因此会取最大的AcceptN对应的AcceptV,例子中也就是A1的10%做为AcceptV。若是在收到promise时没有发现有其余已记录的AcceptV,则其值能够由本身决定。

针对以上A1和A5冲突的状况,最终A1和A5都会广播接受的值为10%。

其实4个过程当中对于acceptor而言,在回复promise和accepted时因为均可能由于其余proposer的介入而致使特殊处理。因此基本上看在这两个时间点收到其余proposer的请求时就能够了解整个算法了。例如在回复promise时则可能由于proposer发来的N不够大而reject:

若是在发accepted消息时,对其余更大N的proposer发出过promise,那么也会reject该proposer发出的accept,如图:

这个对应于Phase 2 b):

it accepts the proposal unless it has already responded to a prepare request having a number greater than n.

总结

Leslie Lamport没有用数学描述Paxos,可是他用英文阐述得很清晰。将Paxos的两个Phase的内容理解清楚,整个算法过程仍是不复杂的。

至于Paxos中一直提到的一个全局惟一且递增的proposer number,其如何实现,引用以下:

如何产生惟一的编号呢?在《Paxos made simple》中提到的是让全部的Proposer都从不相交的数据集合中进行选择,例如系统有5个Proposer,则可为每个Proposer分配一个标识j(0~4),则每个proposer每次提出决议的编号能够为5*i + j(i能够用来表示提出议案的次数)

参考文档

相关文章
相关标签/搜索