通俗易懂的Paxos算法-基于消息传递的一致性算法

通俗易懂Paxos算法（屁民）讲解：

  先说Paxos，它是一个基于消息传递的一致性算法，Leslie Lamport在1990年提出，近几年被普遍应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止惟一的分布式一致性算法，其它的算法都是Paxos的改进或简化。有个问题要提一下，Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。

  关于Paxos的具体描述能够在Wiki中找到：zh.wikipedia.org/zh-cn/Paxos… Server的对应关系。

  Paxos描述了这样一个场景，有一个叫作Paxos的小岛(Island)上面住了一批居民，岛上面全部的事情由一些特殊的人决定，他们叫作议员(Senator)。议员的总数(Senator Count)是肯定的，不能更改。岛上每次环境事务的变动都须要经过一个提议(Proposal)，每一个提议都有一个编号(PID)，这个编号是一直增加的，不能倒退。每一个提议都须要超过半数((Senator Count)/2 +1)的议员赞成才能生效。每一个议员只会赞成大于当前编号的提议，包括已生效的和未生效的。若是议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每一个议员在本身记事本上面记录的编号，他不断更新这个编号。整个议会不能保证全部议员记事本上的编号老是相同的。如今议会有一个目标：保证全部的议员对于提议都能达成一致的见解。

  好，如今议会开始运做，全部议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么个人这个提议的编号就是1，因而他给全部议员发消息：1号提议，设定电费1元/度。其余议员收到消息之后查了一下记事本，哦，当前提议编号是0，这个提议可接受，因而他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的议员收到了超过半数的回复，当即给全部人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改为正式的法令，当有人问他电费为多少时，他会查见解令并告诉对方：1元/度。

  如今看冲突的解决：假设总共有三个议员S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。S1想设为1元/度, S2想设为2元/度。结果S3先收到了S1的提议，因而他作了和前面一样的操做。紧接着他又收到了S2的提议，结果他一查记事本，咦，这个提议的编号小于等于个人当前编号1，因而他拒绝了这个提议：对不起，这个提议先前提过了。因而S2的提议被拒绝，S1正式发布了提议: 1号提议生效。S2向S1或者S3打听并更新了1号法令的内容，而后他能够选择继续发起2号提议。

  好，我以为Paxos的精华就这么多内容。如今让咱们来对号入座，看看在ZK Server里面Paxos是如何得以贯彻实施的。

ZK Server与ZK Server映射关系：

1. 小岛(Island)——ZK Server Cluster

2. 议员(Senator)——ZK Server

3. 提议(Proposal)——ZNode Change(Create/Delete/SetData…)

4. 提议编号(PID)——Zxid(ZooKeeper Transaction Id)

5. 正式法令——全部ZNode及其数据

貌似关键的概念都能一一对应上，可是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。若是议员人人平等，在某种状况下会因为提议的冲突而产生一个“活锁”（所谓活锁个人理解是你们都没有死，都在动，可是一直解决不了冲突问题）。Paxos的做者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在全部议员中设立一个总统，只有总统有权发出提议，若是议员有本身的提议，必须发给总统并由总统来提出。好，咱们又多了一个角色：总统。

总统——ZK Server Leader

又一个问题产生了，总统怎么选出来的？oh, my god! It’s a long story. 在淘宝核心系统团队的Blog上面有一篇文章是介绍如何选出总统的，有兴趣的能够去看看：rdc.taobao.com/blog/cs/?p=…

如今咱们假设总统已经选好了，下面看看ZK Server是怎么实施的。

状况一：

屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的状况(ZNode的数据)，议员坚决果断的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明：个人数据不必定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再告诉你。

状况二：

屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，本身将问题反映给了总统，总统询问全部议员的意见，多数议员表示欠屁民的钱必定要还，因而总统发表声明，从国库中拿出一万元还债，国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。

状况三：

总统忽然挂了，议员连续不断的发现联系不上总统，因而各自发表声明，推选新的总统，总统大选期间政府停业，拒绝屁民的请求。

呵呵，到此为止吧，固然还有不少其余的状况，但这些状况老是能在Paxos的算法中找到原型并加以解决。这也正是咱们认为Paxos是Zookeeper的灵魂的缘由。固然ZK Server还有不少属于本身特性的东西：Session, Watcher，Version等等等等，须要咱们花更多的时间去研究和学习。

转载于文章《Zookeeper全解析——Paxos做为灵魂》 连接：www.douban.com/note/208430…