一、Paxos是什么？
Paxos，它是一个基于消息传递的一致性算法，Leslie Lamport在1990年提出，近几年被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。有个问题要提一下，Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。
那么拜占庭将军问题（Byzantine Generals Problem）是什么呢？
1982年，Leslie Lamport发表了名为《The Byzantine Generals Problem》 的论文，描述了拜占庭将军投票问题，借以映射分布式系统中计算机通信容错问题。
一组拜占庭将军分别各率领一支军队共同围困一座城市。为了简化问题，将各支军队的行动策略限定为进攻或撤离两种。因为部分军队进攻部分军队撤离可能会造成灾难性后果，因此各位将军必须通过投票来达成一致策略，即所有军队一起进攻或所有军队一起撤离。因为各位将军分处城市不同方向，他们只能通过信使互相联系。在投票过程中每位将军都将自己投票给进攻还是撤退的信息通过信使分别通知其他所有将军，这样一来每位将军根据自己的投票和其他所有将军送来的信息就可以知道共同的投票结果而决定行动策略。
投票系统的问题在于，军队中可能存在叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序。这时候在已知有成员可能不可靠的情况下，其他忠诚的将军如何在不受叛徒和间谍影响的情况下意见达成一致，这就是拜占庭将军问题。
拜占庭将军问题是对分布式系统的模型化，将军是计算机，信使则是通信系统，由于硬件错误或者恶意攻击等，计算机和网络可能会出现拜占庭将军问题。
二、Paxos描述了这样一个场景：
1、有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。
2、议员的总数(SenatorCount)是确定的，不能更改。
3、岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。
4、每个提议都需要超过半数((SenatorCount)/2+1)的议员同意才能生效。
5、每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。
6、如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。
现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。
三、Paxos运作过程
1、现在议会开始运作，所有议员一开始记事本上面记录的编号都是0。
2、有一个议员发了一个提议：将电费设定为1元/度。
（1）他首先看了一下记事本，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。
（2）其他议员收到消息以后查了一下记事本，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。
（3）发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。
3、让我们来看看冲突的解决：
（1）假设总共有三个议员S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。
（2）S1想设为1元/度, S2想设为2元/度。
（3）结果S3先收到了S1的提议，于是他做了和前面同样的操作。
（4）紧接着他又收到了S2的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号1，于是他拒绝了这个提议：对不起，这个提议先前提过了。
（5）于是S2的提议被拒绝，S1正式发布了提议: 1号提议生效。
（6）S2向S1或者S3打听并更新了1号法令的内容，然后他可以选择继续发起2号提议。
四、ZK里面Paxos是如何运作的呢？
1、现在让我们来对号入座，看看在ZK Server里面Paxos是如何得以贯彻实施的。
小岛(Island)——ZK Server Cluster
议员(Senator)——ZK Server
提议(Proposal)——ZNode Change(Create/Delete/SetData…)
提议编号(PID)——Zxid(ZooKeeper Transaction Id)
正式法令——所有ZNode及其数据
2、貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。
如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos的作者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。
总统——ZK Server Leader
3、总统怎么选举呢？
完成的协议包含了一个选举唯一的发起表决的议员的过程，这个议员称为president（总统）。在多数形式的政府中，选举一个总统是困难的，因为大多数政府都要求在任何时刻只能有唯一的一个总统。比如在美国，如果一些人认为Bush已经被选为总统，而另一些人认为Dukakis才是总统就会造成混乱，因为其中某个总统可能会签署某个法令而另一个总统不赞成该法令。在Paxon圣会，拥有多个总统只是会阻碍可进展性，并不会引起不一致的情况。为了满足可进展性，选举唯一总统的方法只需要满足presidential selection requirement：
“如果没有人进出会议室，那么在T分钟之后，会议室中的牧师可以认为自己是总统。”
如果总统的选举条件被满足，那么完整的协议将保证，如果多数派议员在会议室中且T+99分钟内没有人进入或离开会议室，在这样一个周期结束时，会议室中的每个议员的律簿上都会增加一条法令。
Paxon公民按照议员名字的字典序来选择成为总统的议员。presidential selection requirement会被满足，如果议员没T-11分钟发送一次包含他名字的消息给其他的议员，如果他T分钟内没有收到更高级别的名字的消息，那么他认为自己是总统。
通过要求基础协议中的议员快速的执行步骤（2）-（6），并且增加一个选举总统用于发起表决的方法，要求总统在合适的时机发起表决来得到完整的协议。更多的协议细节还不清楚，以上只是简单的描述了选举总统的办法和总统发起表决的时机。
但显然这不是Paxons公民所使用的办法。我给出的规则要求在一个法令被选出后总统需要继续发起表决，以让刚进入会议室的议员能知道被选中的法令。显然还有更好的办法让刚进入会议室的议员学习被选中的法令。另外，在挑选总统时，每个议员可以发送lastTried[p]给其他议员，以便于总统在第一次发起表决时能选择一个足够大的表决编号。
Paxons的公民意识到，任何涉及到进展性的条件都需要测量时间的推移。在拥有精准计时器的前提下，上面描述的总统选举和表决的发起都可以通过超时的方式被描述为准确的算法。更详细的分析表明，这种算法可以在时间有精准性边界的情况下工作。Paxons上熟练的工匠可以造出满足精度要求的沙漏。
4、选举好总统之后，来看看ZK Sever是怎么实施的。
情况一：
屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况(ZNode的数据)，议员毫不犹豫的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再告诉你。
情况二：
屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，自己将问题反映给了总统，总统询问所有议员的意见，多数议员表示欠屁民的钱一定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。
情况三：
总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间政府停业，拒绝屁民的请求。
参考文章：
1.https://blog.csdn.net/cxhzqhzq/article/details/6568040
2.https://www.cnblogs.com/hzmark/p/The_Part-Time_Parliament.html