zookeeper启动时的选举机制

本文是基于在b站上所学zk的课程所作出的总结

zk的选举机制

首先介绍几个概念:

  • Sid:服务器id,用于在集群中唯一的标识一台zk的机器,集群中不能够重复,和myid是一致的。
  • ZXID:事务id,用来表示一次服务器状态的变更;在某一时刻,集群中的每台机器的ZXID值是不一定完全一致,这和zk对于客户端的变更请求的处理逻辑有关。
  • Epoch:每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟是相同的,每次投完票这个值就会增加。

第一次启动

  1. 服务器1启动时发起一次选举,服务器1投给自己一票,此时服务器1的票数为1,不够半数3,因此服务器1保持Looking状态;
  2. 服务器2启动时也发起一次选举,服务器1和服务器2分别投给自己一票并交换选票信息;此时服务器1发现服务器2的myid比自己推举的服务器(服务器1)要大,因此更改选票推举服务器2;此时服务器1的选票为0,服务器2的选票为2,也没有超过半数,因此服务器1和服务器2都保持Looking状态。
  3. 服务器3启动发起一次选举,此时服务器1和服务器2都将选票改选为服务器3,此次投票的结果为服务器1为0票,服务器2为0票,服务器3为3票超过半数,服务器3当选为leader;服务器1和2更改状态为Following,服务器更改状态为Leading。
  4. 服务器4启动时,发起一次选举,此时服务器的状态不是Looking状态,不会更改选票信息。交换选票结果:服务器3为3票,服务器4为1票,此时服务器服从多数,更改选票为服务器3,并更改状态为Following.
  5. 服务器5启动,同服务器4的方式一样。

非第一次启动

1.当zookeeper集群中出现如下两种情况之一就会进行leader的选举:

  • 服务器初始化(及第一次选举)
  • 服务器运行期间无法与Leader保持联系
    比如说集群运行期间,server5无法与leader进行联系,此时server5认为整个leader服务器宕机,server5就会发起leader的选举
    2.当一台服务器进入leader选举流程中,当前集群可能存在两种情况
  • 集群中本来已经存在leader
    当机器试图去选举leader时,需要进行投票并交换信息,会被告知当前集群已经存在leader节点,对于该机器来说只需要与leader进行连接并同步状态即可。
  • 集群中不存在leader
    假设zk集群由5台服务器组成,SID分别为1、2、3、4、5,ZXID为8、8、8、7、7,并且此时SID为3的机器为leader,某一时刻server3与server5都宕机,此时开始Leader的选举;
    此时的选举规则为,a.先比较epoch的值大的直接胜出;b.再比较zxid,谁大谁胜出;c.最后比较sid的值谁大谁胜出;
    举例:server1,server2,server4的epoch、zxid、sid分别为(1,8,1)、(1,8,2)、(1,7,4),则最终的选举结果为server2当选leader。
posted @ 2021-11-16 22:33  桂花载酒少年游O  阅读(247)  评论(0编辑  收藏  举报