Paxos算法

Paxos算法

 

 参考：

http://www.cnblogs.com/shangxiaofei/p/5206657.html

https://blog.csdn.net/cnh294141800/article/details/53768464

http://www.cnblogs.com/shangxiaofei/p/5207218.html

 

 

分布式事务一致性协议paxos通俗理解

维基的简介：Paxos算法是莱斯利·兰伯特（Leslie Lamport，就是 LaTeX 中的"La"，此人如今在微软研究院）于1990年提出的一种基于消息传递且具备高度容错特性的一致性算法。

Paxos算法目前在Google的Chubby、MegaStore、 Spanner等系统中获得了应用，Hadoop中的ZooKeeper也使用了Paxos算法，在上面的各个系统中，使用的算法与Lamport提出的 原始Paxos并不彻底同样，这个之后再慢慢分析。本博文的目的是，如何让一个小白在半个小时以内理解Paxos算法的思想。小白可能对数学不感兴趣，对 分布式的复杂理论不熟悉，只是一个入门级程序员。之因此想写这篇博文，是由于本身看了网上不少介绍Paxos算法的文章，以及博客，包括Lamport的论文，感受仍是难以理解，大多过于复杂，本人一直认为，复杂高深的理论背后必定基于一些通用的规律，而这些通用的规律在生活中其实咱们早就遇到过，甚至用过。因此，咱们先忽略Paxos算法自己，从生活中的小事开始谈起。

 假若有一群驴友要决定中秋节去旅游，这群驴友分布在全国各地，假定一共25个 人，分别在不一样的省，要决定到底去拉萨、昆明、三亚等等哪一个地点（会合时间中秋节已经定了，此时须要决定旅游地）。最直接的方式固然就是建一个QQ群，大 家都在里面投票，按照少数服从多数的原则。这种方式相似于“共享内存”实现的一致性，实现起来简单，但Paxos算法不是这种场景，由于Paxos算法认 为这种方式有一个很大的问题，就是QQ服务器挂掉怎么办？Paxos的原则是容错性必定要很强。因此，Paxos的场景相似于这25我的相互之间只能发短 信，须要解决的核心问题是，哪怕任意的一部分人（Paxos的目的实际上是少于半数的人）“失联”了，其它人也可以在会合地点上达成一致。好了，怎么设计 呢？

这25我的找了另外的5我的（固然这5我的能够从25我的中选，这里为了描述方 便，就单拿出另外5我的），好比北京、上海、广州、深圳、成都的5我的，25我的都给他们发短信，告诉本身倾向的旅游地。这5我的相互之间能够并不通讯， 只接受25我的发过来的短信。这25我的咱们称为驴友，那5我的称为队长。

先来看驴友的逻辑。驴友能够给任意5个队长都发短信，发短信的过程分为两个步骤：

第一步（申请阶段）：询问5个队长，试图与队长沟通旅游地。由于每一个队长一直会收 到不一样驴友的短信，不能跟多个驴友一块儿沟通，在任什么时候刻只能跟一个驴友沟通，按照什么原则才能作到公平公正公开呢？这些短信都带有发送时间，队长采用的原 则是赞成与短信发送时间最新的驴友沟通，若是出现了更新的短信，则与短信更 新的驴友沟通。总之，做为一个有话语权的人，只有时刻保持倾听最新的呼声，才能作出最明智的选择。在驴友发出短信后，等着队长。某些队长可能会说，你这条 短信太老了，我不与你沟通；有些队长则可能返回说，你的短信是我收到的最新的，我赞成跟你沟通。对于后面这些队长，还得返回本身决定的旅游地。关于队长是 怎么决定旅游地的，后面再说。

对于驴友来讲，第一步必须至少有半数以上队长都赞成沟通了，才能进入下一步。不然，你连沟通的资格都没有，一直在那儿狂发吧。你发的短信更新，你得到沟通权的可能性才更大。。。。。。

由于至少有半数以上队长（也就是3个队长以上）赞成，你才能与队长们进行实质性的沟通，也就是进入第二步；而队长在任什么时候候只能跟1个驴友沟通，因此，在任什么时候候，不可能出现两个驴友都达到了这个状态。。。固然，你能够经过狂发短信把沟通权抢了。。。。

对于得到沟通权的那个驴友（称为A），那些队长会给他发送他们本身决定的旅游地（也可能都尚未决定）。能够看出，各个队长是本身决定旅游地的，队长之间无需沟通。

第二步（沟通阶段）：这个幸运的驴友收到了队长们给他发的旅游地，可能有几种状况：

第一种状况：跟A沟通的队长们（不必定是所有5个队长，可是半数以上）所有都尚未决定到底去那儿旅游，此时驴友A心花盛开，给这些队长发第二条短信，告诉他们本身但愿的旅游地（好比马尔代夫）；

可能会收到两种结果：一是半数以上队长都赞成了，因而代表A建议的马尔代夫被半数以上队长都 赞成了，整个决定过程完毕了，其它驴友早晚会知道这个消息的，A先去收拾东西准备去马尔代夫；除此以外，代表失败。可能队长出故障了，好比某个队长在跟女 朋友打电话等等，也可能被其它驴友抢占沟通权了（由于队长喜新厌旧嘛，只有要更新的驴友给本身发短信，本身就与新人沟通，A的建议队长不一样意）等等。无论 怎么说，苦逼的A还得从新从第一步开始，从新给队长们发短信申请。

第二种状况：至少有一个队长已经决定旅游地了，A可能会收到来自不一样队长决定的多 个旅游地，这些旅游地是不一样队长跟不一样驴友在不一样时间上作出的决定，那么，A会先看一下，是否是有的旅游地已经被半数以上队长赞成了（好比3个队长都赞成 去三亚，1个赞成去昆明，另一个没搭理A），若是出现了这种状况，那就别扯了，说明整个决定过程已经达成一致了，收拾收拾准备去三亚吧，结束了；若是都 没有达到半数以上（好比1个赞成去昆明，1个赞成去三亚，2个赞成去拉萨，1个没搭理我），A做为一个高素质驴友，也不按照本身的意愿乱来了（Paxos 的关键所在，后者认同前者，不然整个决定过程永无止境），虽然本身原来可能想去马尔代夫等等。就给队长们发第二条短信的时候，告诉他们本身但愿的旅游地， 就是本身收到的那堆旅游地中最新决定的那个。（好比，去昆明那个是北京那个队长前1分钟决定的，去三亚的决定是上海那个队长1个小时以前作出来的，因而顶 昆明）。驴友A的想法是，既然有队长已经作决定了，那我就干脆顶最新那个决定。

从上面的逻辑能够看出，一旦某个时刻有半数以上队长赞成了某个地点好比昆明，紧跟着后面的驴友B继续发短信时，若是得到沟通权，由于半数以上队长都赞成与B沟通了，说明B收到了来自半数以上队长发过来的消息，B必然会收到至少一个队长给他发的昆明这个结果（不然说明半数以上队长都没有赞成昆明这个结果，这显然与前面的假设矛盾），B因而会顶这个最新地点，不会更改，由于后面的驴友都会顶昆明，所以赞成昆明的队长愈来愈多，最终必然达成一致。

看完了驴友的逻辑，那么队长的逻辑是什么呢？

队长的逻辑比较简单。

在申请阶段，队长只会选择与最新发申请短信的驴友沟通，队长知道本身接收到最新短信的时间，对于更老的短信，队长不会搭理；队长赞成沟通了的话，会把本身决定的旅游地（或者还没决定这一信息）发给驴友。

在沟通阶段，驴友C会把本身但愿的旅游地发过来（同时会附加上本身申请短信的时 间，好比3分钟前），因此队长要检查一下，若是这个时间（3分钟前）确实是当前本身最新接收到申请短信的时间（说明这段时间没有驴友要跟本身沟通），那 么，队长就赞成驴友C的这个旅游地了（好比昆明，哪怕本身1个小时前已经作过去三亚的决定，谁让C更新呢，因而更新为昆明）；若是不是最新的，说明这3分 钟内又有其它驴友D跟本身申请了，由于本身是个喜新厌旧的家伙，赞成与D沟通了，因此驴友C的决定本身不会赞成，等着D一下子要发过来的决定吧。

 

Paxos的基本思想大体就是上面的过程。能够看出，其实驴友的策略才是Paxos的关键。让咱们来跟理论对应一下。

Paxos主要用于保证分布式存储中副本（或者状态）的一致性。副本要保持一致， 那么，全部副本的更新序列就要保持一致。由于数据的增删改查操做通常都存在多个客户端并发操做，到底哪一个客户端先作，哪一个客户端后作，这就是更新顺序。如 果不是分布式，那么能够利用加锁的方法，谁先申请到锁，谁就先操做。可是在分布式条件下，存在多个副本，若是依赖申请锁+副本同步更新完毕再释放锁，那么 须要有分配锁的这么一个节点（若是是多个锁分配节点，那么又出现分布式锁管理的需求，把锁给哪个客户端又成为一个难点），这个节点又成为单点，岂不是可 靠性不行了，失去了分布式多副本的意义，同时性能也不好，另外，还会出现死锁等状况。

因此，说来讲去，只有解决分布式条件下的一致性问题，彷佛才能解决本质问题。

如上面的例子，Paxos解决这一问题利用的是选举，少数服从多数的思想，只要 2N+1个节点中，有N个以上赞成了某个决定，则认为系统达到了一致，而且按照Paxos原则，最终理论上也达到了一致，不会再改变。这样的话，客户端不 必与全部服务器通讯，选择与大部分通讯便可；也无需服务器都所有处于工做状态，有一些服务器挂掉，只有保证半数以上存活着，整个过程也能持续下去，容错性 至关好。所以，之前看有的博客说在部署ZooKeeper这种服务的时候，须要奇数台机器，这种说法固然有必定来源背景，好比若是是5台，那么任意客户端 与任意其中3台达成一致就至关于投票结束，不过6台有何不可？只是此时须要与4台以上达成一致。

Paxos中的Acceptor就至关于上面的队长，Proposer就至关于上 面的驴友，epoch编号就至关于例子中申请短信的发送时间。关于Paxos的正式描述已经不少了，这里就不复述了，关于Paxos正确性的证实，由于比 较复杂，之后有时间再分析。另外，Paxos最消耗时间的地方就在于须要半数以上赞成沟通了才能进入第二步，试想一下，一开始，全部驴友就给队长狂发短 信，每一个队长收到的最新短信的是不一样驴友，这样，就难以达到半数以上都赞成与某个驴友沟通的状态，为了减少这个时间，Paxos还有Fast Paxos的改进等等，有空再分析。

却是有一些问题能够思考一下：在Paxos以前，或者说除了Chubby，ZooKeeper这些系统，其它分布式系统一样面临这样的一致性问题，好比HDFS、分布式数据库、Amazon的Dynamo等等，解决思路又不一样，有空再进行对比分析。

最后谈谈一致性这个名词。

关于Paxos说的一致性，我的理解是指冗余副本（或状态等，但都是由于存在冗余）的一致性。这与关系型数据库中ACID的一致性说的不是一个东西。在关系数据库里，能够连副本都没有，何谈副本的一致性？按照经典定义，ACID中的C指的是在一个事务中，事务执行的结果必须是使数据库从一个一致性状态变到另外一个一致性状态。那么，什么又是一致性状态呢，这跟业务约束有关系，好比经典的转帐事务，事务处理完毕后，不能出现一个帐户钱被扣了，另外一个帐户的钱没有增长的状况，若是二者加起来的钱仍是等于转帐前的钱，那么就是一致性状态。

从不少博文来看，对这两种一致性每每混淆起来。另外，CAP原则里面所说的一致 性，我的认为是指副本一致性，与Paxos里面的一致性接近。都是处理“由于冗余数据的存在而须要保证多个副本保持一致”的问题，NoSQL放弃的强一致 性也是指副本一致性，最终一致性也是指副本达到彻底相同存在必定延时。

固然，若是数据库自己是分布式的，且存在冗余副本，则除了解决事务在业务逻辑上的一致性问题外，同时须要解决副本一致性问题，此时能够利用Paxos协议。但解决了副本一致性问题，还不能彻底解决业务逻辑一致性；若是是分布式数据库，但并不存在副本的状况，事务的一致性须要根据业务约束进行设计。

另外，谈到Paxos时，还会涉及到拜占庭将军问题，它指的是在存在消息丢失的不 可靠信道上试图经过消息传递的方式达到一致性是不可能的。Paxos自己就是利用消息传递方式解决一致性问题的，因此它的假定是信道必须可靠，这里的可 靠，主要指消息不会被篡改。消息丢失是容许的。

关于一致性、事务的ACID，CAP，NoSQL等等问题，之后再详细分析。本文的描述也许可能存在一些举例不太恰当的地方，若是错误，欢迎批评指正。

 

 

 

Paxos协议超级详细解释+简单实例

Paxos算法的目的

Paxos算法的目的是为了解决分布式环境下一致性的问题。

    多个节点并发操纵数据，如何保证在读写过程当中数据的一致性，而且解决方案要能适应分布式环境下的不可靠性（系统如何就一个值达到统一）

Paxos的两个组件

Proposer

提议发起者，处理客户端请求，将客户端的请求发送到集群中，以便决定这个值是否能够被批准。

Acceptor

提议批准者，负责处理接收到的提议，他们的回复就是一次投票。会存储一些状态来决定是否接收一个值

Paxos有两个原则

1)安全原则---保证不能作错的事

a） 针对某个实例的表决只能有一个值被批准，不能出现一个被批准的值被另外一个值覆盖的状况；(假设有一个值被多数Acceptor批准了，那么这个值就只能被学习)

b） 每一个节点只能学习到已经被批准的值，不能学习没有被批准的值。

2)存活原则---只要有多数服务器存活而且彼此间能够通讯，最终都要作到的下列事情：

a）最终会批准某个被提议的值；

b）一个值被批准了，其余服务器最终会学习到这个值。

Paxos具体流程图

 

 

第一阶段（prepare）

1）.获取一个proposal number, n；

2）.提议者向全部节点广播prepare(n)请求；

3）.接收者（Acceptors比较善变，若是还没最终承认一个值，它就会不断认同提案号最大的那个方案）比较n和minProposal，若是n>minProposal,表示有更新的提议minProposal=n；若是此时该接受者并无承认一个最终值，那么承认这个提案，返回OK。若是此时已经有一个accptedValue, 将返回(acceptedProposal,acceptedValue)；

4）.提议者接收到过半数请求后，若是发现有acceptedValue返回，表示有承认的提议，保存最高acceptedProposal编号的acceptedValue到本地

 

第二阶段(Accept)

5）广播accept(n,value)到全部节点；

6).接收者比较n和minProposal，若是n>=minProposal,则acceptedProposal=minProposal=n，acceptedValue=value，本地持久化后，返回；

不然，拒绝而且返回minProposal

7).提议者接收到过半数请求后，若是发现有返回值>n，表示有更新的提议，跳转1（从新发起提议）；不然value达成一致。

 

 

Paxos议案ID生成算法

       在Google的Chubby论文中给出了这样一种方法：假设有n个proposer，每一个编号为ir(0<=ir<n)，proposal编号的任何值s都应该大于它已知的最大值，而且知足：

     s %n = ir    =>     s = m*n + ir

    proposer已知的最大值来自两部分：proposer本身对编号自增后的值和接收到acceptor的拒绝后所获得的值。

例：  以3个proposer P一、P二、P3为例，开始m=0,编号分别为0，1，2。

1） P1提交的时候发现了P2已经提交，P2编号为1 >P1的0，所以P1从新计算编号：new P1 = 1*3+1 = 4；

2） P3以编号2提交，发现小于P1的4，所以P3从新编号：new P3 = 1*3+2 = 5。

 

Paxos原理

任意两个法定集合，一定存在一个公共的成员。该性质是Paxos有效的基本保障

 

活锁

     当某一proposer提交的proposal被拒绝时，多是由于acceptor 承诺返回了更大编号的proposal，所以proposer提升编号继续提交。 若是2个proposer都发现本身的编号太低转而提出更高编号的proposal，会致使死循环，这种状况也称为活锁。

       好比说当此时的 proposer1提案是3, proposer2提案是4, 但acceptor承诺的编号是5，那么此时proposer1,proposer2 都将提升编号假设分别为6,7，并试图与accceptor链接，假设7被接受了，那么提案5和提案6就要从新编号提交，从而不断死循环。

 

异常状况——持久存储

     在算法执行的过程当中会产生不少的异常状况：proposer宕机，acceptor在接收proposal后宕机，proposer接收消息后宕机，acceptor在accept后宕机，learn宕机，存储失败，等等。

     为保证paxos算法的正确性，proposer、aceptor、learn都实现持久存储，以作到server恢复后仍能正确参与paxos处理。

    propose存储已提交的最大proposal编号、决议编号（instance id）。

    acceptor存储已承诺（promise）的最大编号、已接受（accept）的最大编号和value、决议编号。

    learn存储已学习过的决议和编号

具体实例：

假设的3军问题

 

1） 1支红军在山谷里扎营，在周围的山坡上驻扎着3支蓝军；

2） 红军比任意1支蓝军都要强大；若是1支蓝军单独做战，红军胜；若是2支或以上蓝军同时进攻，蓝军胜；

3） 三支蓝军须要同步他们的进攻时间；但他们唯一的通讯媒介是派通讯兵步行进入山谷，在那里他们可能被俘虏，从而将信息丢失；或者为了不被俘虏，可能在山谷停留很长时间；

4） 每支军队有1个参谋负责提议进攻时间；每支军队也有1个将军批准参谋提出的进攻时间；很明显，1个参谋提出的进攻时间须要得到至少2个将军的批准才有意义；

5） 问题：是否存在一个协议，可以使得蓝军同步他们的进攻时间？

 

接下来以两个假设的场景来演绎BasicPaxos；参谋和将军须要遵循一些基本的规则

1） 参谋以两阶段提交（prepare/commit）的方式来发起提议，在prepare阶段须要给出一个编号；

2） 在prepare阶段产生冲突，将军以编号大小来裁决，编号大的参谋胜出；

3） 参谋在prepare阶段若是收到了将军返回的已接受进攻时间，在commit阶段必须使用这个返回的进攻时间；

两个参谋前后提议的场景

 

1） 参谋1发起提议，派通讯兵带信给3个将军，内容为（编号1）；

2） 3个将军收到参谋1的提议，因为以前尚未保存任何编号，所以把（编号1）保存下来，避免遗忘；同时让通讯兵带信回去，内容为（ok）；

3） 参谋1收到至少2个将军的回复，再次派通讯兵带信给3个将军，内容为（编号1，进攻时间1）；

4） 3个将军收到参谋1的时间，把（编号1，进攻时间1）保存下来，避免遗忘；同时让通讯兵带信回去，内容为（Accepted）；

5） 参谋1收到至少2个将军的（Accepted）内容，确认进攻时间已经被你们接收；

 

6） 参谋2发起提议，派通讯兵带信给3个将军，内容为（编号2）；

7） 3个将军收到参谋2的提议，因为（编号2）比（编号1）大，所以把（编号2）保存下来，避免遗忘；又因为以前已经接受参谋1的提议，所以让通讯兵带信回去，内容为（编号1，进攻时间1）；

8） 参谋2收到至少2个将军的回复，因为回复中带来了已接受的参谋1的提议内容，参谋2所以再也不提出新的进攻时间，接受参谋1提出的时间；

两个参谋交叉提议的场景

 

 

1） 参谋1发起提议，派通讯兵带信给3个将军，内容为（编号1）；

2） 3个将军的状况以下

a) 将军1和将军2收到参谋1的提议，将军1和将军2把（编号1）记录下来，若是有其余参谋提出更小的编号，将被拒绝；同时让通讯兵带信回去，内容为（ok）；

b) 负责通知将军3的通讯兵被抓，所以将军3没收到参谋1的提议；

 

3） 参谋2在同一时间也发起了提议，派通讯兵带信给3个将军，内容为（编号2）；

4） 3个将军的状况以下

a) 将军2和将军3收到参谋2的提议，将军2和将军3把（编号2）记录下来，若是有其余参谋提出更小的编号，将被拒绝；同时让通讯兵带信回去，内容为（ok）；

b) 负责通知将军1的通讯兵被抓，所以将军1没收到参谋2的提议；

 

5） 参谋1收到至少2个将军的回复，再次派通讯兵带信给有答复的2个将军，内容为（编号1，进攻时间1）；

6） 2个将军的状况以下

a) 将军1收到了（编号1，进攻时间1），和本身保存的编号相同，所以把（编号1，进攻时间1）保存下来；同时让通讯兵带信回去，内容为（Accepted）；

b) 将军2收到了（编号1，进攻时间1），因为（编号1）小于已经保存的（编号2），所以让通讯兵带信回去，内容为（Rejected，编号2）；

 

7） 参谋2收到至少2个将军的回复，再次派通讯兵带信给有答复的2个将军，内容为（编号2，进攻时间2）；

8） 将军2和将军3收到了（编号2，进攻时间2），和本身保存的编号相同，所以把（编号2，进攻时间2）保存下来，同时让通讯兵带信回去，内容为（Accepted）；

9） 参谋2收到至少2个将军的（Accepted）内容，确认进攻时间已经被多数派接受；

 

10） 参谋1只收到了1个将军的（Accepted）内容，同时收到一个（Rejected，编号2）；参谋1从新发起提议，派通讯兵带信给3个将军，内容为（编号3）；

11） 3个将军的状况以下

a) 将军1收到参谋1的提议，因为（编号3）大于以前保存的（编号1），所以把（编号3）保存下来；因为将军1已经接受参谋1前一次的提议，所以让通讯兵带信回去，内容为（编号1，进攻时间1）；

b) 将军2收到参谋1的提议，因为（编号3）大于以前保存的（编号2），所以把（编号3）保存下来；因为将军2已经接受参谋2的提议，所以让通讯兵带信回去，内容为（编号2，进攻时间2）；

c) 负责通知将军3的通讯兵被抓，所以将军3没收到参谋1的提议；

12） 参谋1收到了至少2个将军的回复，比较两个回复的编号大小，选择大编号对应的进攻时间做为最新的提议；参谋1再次派通讯兵带信给有答复的2个将军，内容为（编号3，进攻时间2）；

13） 将军1和将军2收到了（编号3，进攻时间2），和本身保存的编号相同，所以保存（编号3，进攻时间2），同时让通讯兵带信回去，内容为（Accepted）；

14） 参谋1收到了至少2个将军的（accepted）内容，确认进攻时间已经被多数派接受；

 

 

 

分布式事务一致性协议paxos的分析

最近研究paxos算法，看了许多相关的文章，概念仍是很模糊，以为仍是没有掌握paxos算法的精髓，因此花了3天时间分析了libpaxos3的全部代码，此代码能够从https://bitbucket.org/sciascid/libpaxos 下载。对paxos算法有初步了解以后，再看此文的效果会更好；若是你也想分析libpaxos3的话，此文应该会对你有不小帮助；关于paxos的历史这里很少作介绍，关于描述paxos算法写的最好的一篇文章应该就是维基百科了，地址戳这里：http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95

 

在paxos算法中，分为4种角色：

  Proposer ：提议者

  Acceptor：决策者

  Client：产生议题者

  Learner：最终决策学习者

上面4种角色中，提议者和决策者是很重要的，其余的2个角色在整个算法中应该算作 打酱油的，Proposer就像Client的使者，由Proposer使者拿着Client的议题去向Acceptor提议，让Acceptor来决 策。这里上面出现了个新名词：最终决策。如今来系统的介绍一下paxos算法中全部的行为：

Proposer提出议题
Acceptor初步接受 或者 Acceptor初步不接受
若是上一步Acceptor初步接受则Proposer再次向Acceptor确认是否最终接受
Acceptor 最终接受 或者Acceptor 最终不接受
上面Learner最终学习的目标是Acceptor们最终接受了什么议题？注意，这里是向全部Acceptor学习，若是有多数派个Acceptor最终接受了某提议，那就获得了最终的结果，算法的目的就达到了。画一幅图来更加直观：
 为何须要3个Acceptor？由于Acceptor必须是最少大于等于3个，而且必须是奇数个，由于要造成多数派嘛，若是是偶数个，好比4个，2个接受2个不接受，互不相让，无法搞下去了。为何是3个Proposer？ 其实无所谓是多少个了，1~n 均可以的；若是是1个proposer，毫无竞争压力，很顺利的完成2阶段提交，Acceptor们最终批准了事。若是是多个proposer就比较复杂了，请继续看。 上面的图中是画了不少节点的，每一个节点须要一台机器么？答案是不须要的，上面的图 是逻辑图，物理中，能够将Acceptor和Proposer以及Client放到一台机器上，只是使用了不一样的端口号罢了，Acceptor们启动不一样 端口的TCP监听，Proposer来主动链接便可；彻底能够将Client、Proposer、Acceptor、Learner合并到一个程序里面； 这里举一个例子：好比开发一个JOB程序，JOB程序部署在多台服务器上(数量为奇数)，这些JOB有可能同时处理一项任务，如今使用paxos算法让这 些JOB本身来商量由谁(哪台机器)来处理这项任务，这样JOB程序里就须要包含Client、Proposer、Acceptor、Learner这4 大功能，而且须要配置其余JOB服务器的IP地址。再举一个例子，zookeeper经常用来作分布式事务锁。Zookeeper所 使用的zad协议也是相似paxos协议的。全部分布式自协商一致性算法都是paxos算法的简化或者变种。Client是使用zookeeper服务的 机器，Zookeeper自身包含了Acceptor, Proposer, Learner。Zookeeper领导选举就是paxos过程，还有Client对Zookeeper写Znode时，也是要进行Paxos过程的，因 为不一样Client可能链接不一样的Zookeeper服务器来写Znode，到底哪一个Client才能写成功？须要依靠Zookeeper的paxos保 证一致性，写成功Znode的Client天然就是被最终接受了，Znode包含了写入Client的IP与端口，其余的Client也能够读取到这个 Znode来进行Learner。也就是说在Zookeeper自身包含了Learner(由于Zookeeper为了保证自身的一致性而会进行领导选 举，因此须要有Learner的内部机制，多个Zookeeper服务器之间须要知道如今谁是领导了)，Client端也能够 Learner，Learner是广义的。 如今经过一则故事来学习paxos的算法的流程(2阶段提交)，有2个Client(老板，老板之间是竞争关系)和3个Acceptor(政府官员)：如今须要对一项议题来进行paxos过程，议题是“A项目我要中标！”，这里的“我”指每一个带着他的秘书Proposer的Client老板。Proposer固然听老板的话了，赶忙带着议题和现金去找Acceptor政府官员。做为政府官员，固然想谁给的钱多就把项目给谁。Proposer-1小姐带着现金同时找 到了Acceptor-1~Acceptor-3官员，1与2号官员分别收取了10比特币，找到第3号官员时，没想到遭到了3号官员的鄙视，3号官员告诉 她，Proposer-2给了11比特币。不过不要紧，Proposer-1已经获得了1,2两个官员的承认，造成了多数派(若是没有造成多数 派，Proposer-1会去银行提款在来找官员们给每人20比特币，这个过程一直重复每次+10比特币，直到多数派的造成)，满意的找老板复命去了，但 是此时Proposer-2保镖找到了1,2号官员，分别给了他们11比特币，1,2号官员的态度马上转变，都说Proposer-2的老板懂事，这下子 Proposer-2放心了，搞定了3个官员，找老板复命去了，固然这个过程是第一阶段提交，只是官员们初步接受贿赂而已。故事中的比特币是编号，议题是 value。　　　　这个过程保证了在某一时刻，某一个proposer的议题会造成一个多数派进行初步支持； ===============华丽的，第一阶段结束================　　5.　如今进入第二阶段提交，如今proposer-1小姐使用分身术(多线 程并发)分了3个本身分别去找3位官员，最早找到了1号官员签合同，遭到了1号官员的鄙视，1号官员告诉他proposer-2先生给了他11比特币，因 为上一条规则的性质proposer-1小姐知道proposer-2第一阶段在她以后又造成了多数派(至少有2位官员的赃款被更新了);此时她赶忙去提 款准备从新贿赂这3个官员(从新进入第一阶段)，每人20比特币。刚给1号官员20比特币， 1号官员很高兴初步接受了议题，还没来得及见到2,3号官员的时候这时proposer-2先生也使用分身术分别找3位官员(注意这里是 proposer-2的第二阶段)，被第1号官员拒绝了告诉他收到了20比特币，第2,3号官员顺利签了合同，这时2，3号官员记录client-2老板 用了11比特币中标，由于造成了多数派，因此最终接受了Client2老板中标这个议题，对于proposer-2先生已经出色的完成了工做；这时proposer-1小姐找到了2号官员，官员告诉她合同已经签了，将合同给 她看，proposer-1小姐是一个没有什么职业操守的聪明人，以为跟Client1老板混没什么前途，因此将本身的议题修改成“Client2老板中 标”，而且给了2号官员20比特币，这样造成了一个多数派。顺利的再次进入第二阶段。因为此时没有人竞争了，顺利的找3位官员签合同，3位官员看到议题与 上次一次的合同是一致的，因此最终接受了，造成了多数派，proposer-1小姐跳槽到Client2老板的公司去了。===============华丽的，第二阶段结束===============　　Paxos过程结束了，这样，一致性获得了保证，算法运行到最后全部的 proposer都投“client2中标”全部的acceptor都接受这个议题，也就是说在最初的第二阶段，议题是先入为主的，谁先占了先机，后面的 proposer在第一阶段就会学习到这个议题而修改本身自己的议题，由于这样没职业操守，才能让一致性获得保证，这就是paxos算法的一个过程。原来 paxos算法里的角色都是这样的不靠谱，不过不要紧，结果靠谱就能够了。该算法就是为了追求结果的一致性。