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