zookeeper领导者leader的选举机制

zk的选举机制 面试重点

第一次启动

假设该集群中有5台服务器

• server A启动，发起一次选举，1投自己一票，但是此时1一票，未超过半数，选举未完成，1保持looking

• B启动，再发起选举。A，B都投自己一票并交换选票信息。此时A发现B的id比自己当前投票的id要更大，改选2。此时1=0，2=2，都未超过半数，选举未完成，1、2保持looking

• C启动，再发起选举。此时三台都会改选票选C，因为C的id最大。此时投票超过半数，C当选leader，AB变为follower

• D启动，再次发起选举。但是此时ABC已经不是looking的状态了，不会更改选票信息。D一开始将选票投给自己，此时服从多数，D改选C，C是leader，ABD是follower。

• E启动，再次发起选举。和D一样，先投给自己，然后改选C，C是leader，其余的服务器为follwer

• 一些额外概念

1. 服务器除了myid之外，还会有一个SID，用于唯一标识一台zk集群中的机器，每台机器的SID不能够重复，和myid保持一致
2. 客户端每次向服务器上发起写操作的时候都会有一个事务id（zxid），用于标识一次服务器状态的变更。在某一个时刻，集群中的每台机器的zkid不一定完全一致。
3. 每个leader任期会有一个代号epoch。在没有产生leader的时候，这个值使用逻辑时钟，epoch的编号是相同的。每完成一个投票该值就会增加。

非第一次启动

• 当zk集群中的一台服务器出现这两种情况的时候就会开始进入leader选举

  1. 服务器初始化
  2. 服务器运行期间无法与leader保持连接

• 当一台机器进入leader选举流程中，可能出现两种情况

  1. 集群中本身已经有了一个leader了（follower自己掉线了，他现在所在的集群只有他自己一台机器没有leader了）

     • 该机器此时会尝试选举leader，此时zk会告知当前的leader信息。对于该follwer，只需要重新与leader建立连接并同步即可。

  2. 集群中确实已经不存在leader了（leader掉线了）
     假设当前集群中5台服务器，sid分别为12345，zxid分别为88877，之前是3为leader，现在3和5发生故障，124重新开始leader选举

     服务器编号	epoch	zxid	sid
     1	1	8	1
     2	1	8	2
     4	1	7	4

     此时选举的原则遵循

     1. epoch最大的直接当选
     2. epoch相同的，zxid最大的当选
     3. zxid相同，sid最大的当选