zookeeper原理知识
Paxos
摘自：https://www.douban.com/note/208430424/
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是如何得以贯彻实施的。
小岛(Island)——ZK Server Cluster
议员(Senator)——ZK Server
提议(Proposal)——ZNode Change(Create/Delete/SetData…)
提议编号(PID)——Zxid(ZooKeeper Transaction Id)
正式法令——所有ZNode及其数据
貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos的作者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。
总统——ZK Server Leader
现在我们假设总统已经选好了，下面看看ZK Server是怎么实施的。
情况一：
屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况(ZNode的数据)，议员毫不犹豫的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再告诉你。
情况二：
屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，自己将问题反映给了总统，总统询问所有议员的意见，多数议员表示欠屁民的钱一定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。
情况三：
总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间政府停业，拒绝屁民的请求。
ZAB
- 1- 客户端创建了一个abc 的提议提交给follower
- 2- follower把同样的创建提议提交给leader
- 3- leader收到创建提议后 自己记录id（记事本）这里暂且当它是8
- 4-1 leader先给follower一个日志（log） 因为是险些到磁盘再写到内存
- 4-1 follower返回一个ok给leader
- 4-2 write 此时写入的是内存
- over - 从leader依次到follower再到client返回OK
ZK集群怎么选举leader
每个节点有自己的myid,
每个节点本地会记录一个Zxid,这个是它"看到"的最新的Zxid,但未必是真的最新;过半节点达成一致的是最新的
绝大多数情况下,各个节点的Zxid都是一样的
leader挂掉后,怎么选新的leader? 通过推选制
首先要选数据最全的,即Zxid最大的
如果有多个节点Zxid都是最大,那么选myid最大的
(过半通过的数据才是真数据.)
ZK选举过程:
- 每个节点投票时,都会广播给其他所有的节点(3888端口两两通信),票中带着自己的观点以及自己的Zxid和myid;
- 准leader收到投票时,会经过判断后再次发起投票(任何节点投票,都会触发那个准leader发起自己的投票)
有个略复杂的场景:
如果leader挂了,某个Zxid比较低的节点先发现了leader挂了,其他Zxid高的节点没发现,节点们会通过多次广播投票后达成一致:
设有4个节点的集群,
n1: myid=1, Zxid=10 ,follower
n2: myid=2, Zxid=10 ,follower
n3: myid=3, Zxid=9 ,follower
n4: myid=4, Zxid=10, leader
假设n4挂了,n1和n2没发现,n3发现了,就会有这个故事
- n3 向 n1 和 n2(其他所有follower)广播消息投票,说leader挂了,我myid最大,投我自己一票;此时n3觉得自己是准leader
- n1收到后,觉得我的Zxid大,投了自己一票.并广播给n2,n3;此时n1觉得自己是准leader
- n2先后收到了n3的票,觉得我的Zxid最大且myid最大,所以投了自己一票,并广播给n1,n3;此时n2觉得自己是准leader
并且,因为n2的Zxid和myid最大,所以中间每次其他投票时,n2也一直会认为自己是准leader - n3收到了n2的票后,改变想法了,投了n2一票,并广播给n1,n2;此时n3觉得n2是leader了
- n1收到了n2的票后,改变想法了,投了n2一票,并广播给n2,n3;此时n1觉得n2是leader了
此时三个节点本地都是给n2三票了,n2成为leader
其实谁先发现都无所谓,只是这种n3先发现了,会多几轮投票,但也很快了
可以这么简单的复现场景,配置四个节点的集群:
-
依次启动n1,n2,n4 ,现在n4是leader.
-
写几条数据,让Zxid大一些
-
关掉n4,启动n3,此时会选n2为leader,因为n3的Zxid比较小
watch
假设两个客户端A和B,B想监控A的状态,如果不用ZK,就需要B不停发送心跳到A
也可以使用ZK的watch,
客户端A创建临时节点/ooxx/a,当A挂掉 断开连接(session)时,a节点就消失了;
a节点消失时,会产生事件 event (节点的变化会产生事件)
如果客户端B watch了 /ooxx/a,当a消失触发事件时,ZK会回调客户端B
ZK的watch,方向性和时效性更好一些
