Zookeeper选举机制——第一次启动
zookeeper集群三个重要的参数(决定选举结果)
SID : 服务器 ID 。 用来唯一标识一台 ZooKeeper集群中的机器,每台机器不能重 , 和 myid 一致 。
ZXID :事务 ID 。 ZXID 是一个事务 ID ,用来标识一次服务器状态的变更。 在某一时刻,集群中的每台机器的ZXID 值不一定完全一致,这和ZooKeeper 服务器对于客户端“更新请求”的处理逻辑有关。
Epoch : 每个 Leader 任期的代号 。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加
假设现在zookeeper集群有5台机器那么选举机制具体步骤为
- (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的票数已经超过半数,服务器3当选Leader。服务器1,2更改状态为FOLLOWING,服务器3更改状态为LEADING;
- (4)服务器4启动,发起一次选举。此时服务器1,2,3已经不是LOOKING状态,不会更改选票信息。交换选票信息结果:服务器3为3票,服务器4为1票。此时服务器4服从多数,更改选票信息为服务器3,并更改状态为FOLLOWING;
- (5)服务器5启动,同4一样当小弟。
Zookeeper选举机制——非第一次启动
( 1 )当 ZooKeeper 集群中的一台服务器出现以下两种情况之一时,就会开始进入 Leader 选举:
- 服务器初始化启动。
- 服务器运行期间无法和Leader保持连接。
( 2 )而当一台机器进入 Leader 选举流程时,当前集群也可能会处于以下两种状态:
- 集群中本来就已经存在一个Leader。
- 对于第一种已经存在Leader的情况,机器试图去选举Leader时,会被告知当前服务器的Leader信息,对于该机器来说,仅仅需要和Leader机器建立连接,并进行状态同步即可。
- 集群中确实不存在Leader。
- 假设ZooKeeper由5台服务器组成,SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID为3的服务器是Leader。某一时刻,3和5服务器出现故障,因此开始进行Leader选举。
SID | EPOCH | ZXID |
1 | 1 | 8 |
2 | 1 | 8 |
4 | 1 | 7 |
选举 Leader 规则:
① EPOCH 大的直接胜出
② EPOCH 相同,事务 id 大的胜出
③事务 id 相同,服务器 id 大的胜出
所以sid为2的机器最终被选为的新的leader