这篇文章我们重点理解Zookeeper选举机制的思路。
一,Zookeeper选举过程中服务器的状态。
LOOKING:寻找leader状态,该状态下,服务器认为当前集群没有leader,会发起leader选举。在选举过程中,所有服务器的状态都是LOOKING。
FOLLOWING:跟随者状态,该状态下,当前服务器是follower,并且知道leader是谁。此时选举已经结束。
LEADING:领导者状态,该状态下,当前服务器是leader,会与follower维持心跳检测。此时选举已经结束。
OBSERVING:观察者状态,该状态下的服务器是observer,不参与选举。
二,Zookeeper选票数据结构
每个服务器在进行leader选举时,都会发送以下几个关键属性信息:
logicalclock:投票轮次,自增的,volatile的,初始值为1,也就是第一轮选举。
state:当前服务器的状态。
self_id:当前服务器的myid。
self_zxid:当前服务器的最新的zxid。
vote_id:当前服务器推举的leader服务器的myid。
vote_zxid:当前服务器推举的leader服务器的最新的zxid。
三,Zookeeper选举算法
从340版本开始,Zookeeper使用FastLeaderElection选举算法,可以解决之前的LeaderElection算法收敛慢的问题。更为重要的是,FastLeaderElection算法解决了脑裂问题,保证leader的唯一性。也就是说,从Zookeeper340版本开始,Zookeeper可能存在的问题只有2个了:
1,客户端没有缓存。
2,没有自我保护机制。
四,Zookeeper选举流程
1,自增选举轮次。
Zookeeper选举机制有一个前提条件:在一个轮次的选举中,所有选票必须属于该轮次。在选举的某一时刻,确实可能存在某张选票不属于该轮次的情况。所以Zookeeper在选举过程中,始终会先核对选票的轮次。
2,初始化选票。
每个服务器在广播自己的选票时,都会先清空投票箱,这个投票箱存放的是所有接收到的来自其他服务器的选票。投票箱中只记录每个服务器的最后一次投票,如果服务器更新自己的投票,则其他服务器会更新该服务器的选票。
举个例子:服务器2投票给服务器3,服务器3投票给服务器1,则服务器1的投票箱中有如下记录
(2,3),(3,1),(1,1)
当然,这里的选票的结构是简化版的,如果加上选举轮次logicalclock,可能是这样的:
(8,2,3),(8,3,1),(8,1,1)
第一位代表当前的选举轮次,第8轮选举。
3,发送初始化选票。
每个服务器在投票开始阶段,都把票投给自己,然后通过广播通知其他服务器。
4,接收外部选票。
每台服务器都会尝试从其他服务器获取选票,并保存到自己的投票箱。
5,判断选举轮次logicalclock。
确保是同一轮次的投票。如果当前服务器发现自己的轮次落后了,则自增logicalclock,然后重新发送广播告诉其他服务器。
6,选票PK确认自己最终的投票。
注意,在这个阶段,每台服务器都可能改变自己的想法,重新确定把选票投给谁。
有3条规则:
第一条规则:如果当前服务器的logicalclock小于其他服务器,说明自己的选举轮次过期了,此时更新自己的logicalclock,然后重新把自己的选票发送出去。
第二条规则:如果当前服务器的logicalclock等于其他服务器,说明大家进行的是同一轮次的选举,此时比较二者的vote_zxid,vote_zxid大者获胜。如果当前服务器输了,则更新自己的投票为胜者,然后广播告诉其他服务器。
第三条规则:如果当前服务器的logicalclock等于其他服务器,说明大家进行的是同一轮次的选举,此时比较二者的vote_zxid,如果vote_zxid也相等,则比较二者的vote_myid,vote_myid大者获胜。如果当前服务器输了,则更新自己的投票为胜者,然后广播告诉其他服务器。
7,统计选票。
如果已经确定有过半服务器认可了自己的投票,则终止投票。否则继续接收其他服务器的投票。
8,更新服务器状态。
投票结束后,服务器更新自己的状态serverState,如果投给自己的选票过半了,则将自己更新为LEADING,否则将自己更新为FOLLOWING。
这里思考一个问题:Zookeeper启动阶段,myid最大的服务器是不是一定会被选举为leader?
欢迎分享,转载请注明来源:浪漫分享网
评论列表(0条)