Zookeeper 灵魂
Zookeeper 是基于 paxos 算法实现的,下面我们用最简单的方式加以描述并建立起
Paxos 和 ZKServer 的对应关系。
Paxos 描述了这样一个场景:
1、有一个叫做 Paxos 的小岛(Island)上面住了一批居民,岛上面所有的事情由一些
特殊的人决定,他们叫做议员(Senator)。C
2、议员的总数(SenatorCount)是确定的,不能更改。C
3、岛上每次环境事务的变更都需要通过一个提议(Proposal),每个提议都有一个编
号(PID),这个编号是一直增长的,不能倒退。C
4、每个提议都需要超过半数((SenatorCount)/2+1)的议员同意才能生效。C
5、每个议员只会同意大于当前编号的提议,包括已生效的和未生效的。C
6、如果议员收到小于等于当前编号的提议,他会拒绝,并告知对方:你的提议已经
有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号,他不断更新这个
编号。整个议会不能保证所有议员记事本上的编号总是相同的。C
现在议会有一个目标:保证所有的议员对于提议都能达成一致的看法。
好,现在议会开始运作,所有议员一开始记事本上面记录的编号都是 0。C
有一个议员发了一个提议:C
将电费设定为 1 元/度。他首先看了一下记事本,嗯,当前提议编号是 0,那么我的这
个提议的编号就是 1,于是他给所有议员发消息:1 号提议,设定电费 1 元/度。其他议员
收到消息以后查了一下记事本,哦,当前提议编号是 0,这个提议可接受,于是他记录下
这个提议并回复:我接受你的 1 号提议,同时他在记事本上记录:当前提议编号为 1。发
起提议的议员收到了超过半数的回复,立即给所有人发通知: 1 号提议生效!收到的议员
会修改他的记事本,将 1 好提议由记录改成正式的法令,当有人问他电费为多少时,他会
查看法令并告诉对方:1 元/度。C
现在看冲突的解决:C
假设总共有三个议员 S1-S3,S1 和 S2 同时发起了一个提议:1 号提议,设定电费。S1 想
设为 1 元/度,S2 想设为 2 元/度。结果 S3 先收到了 S1 的提议,于是他做了和前面同样的
操作。紧接着他又收到了 S2 的提议,结果他一查记事本,咦,这个提议的编号小于等于
我的当前编号 1,于是他拒绝了这个提议:对不起,这个提议先前提过了。于是 S2 的提议
被拒绝,S1 正式发布了提议:1 号提议生效。S2 向 S1 或者 S3 打听并更新了 1 号法令的内
容,然后他可以选择继续发起 2 号提议。C
好,我觉得 Paxos 的精华就这么多内容。现在让我们来对号入座,看看在 ZKServer
里面 Paxos 是如何得以贯彻实施的。C
小岛(Island)——ZKServerCluster
议员(Senator)——ZKServer
提议(Proposal)——ZNodeChange(Create/Delete/SetData…)
提议编号(PID)——Zxid(ZooKeeperTransactionId)
正式法令——所有 ZNode 及其数据:C
貌似关键的概念都能一一对应上,但是等一下,Paxos 岛上的议员应该是人人平等的
吧,而 ZKServer 好像有一个 Leader 的概念。没错,其实 Leader 的概念也应该属于
Paxos 范畴的。如果议员人人平等,在某种情况下会由于提议的冲突而产生一个“活锁”