Zookeeper选举机制和同步策略

Zookeeper选举机制-第一次启动

• 未启动

  此时所有节点无状态，无角色，但是zkService知道参与选举的节点数量

• Server 1 启动

  Server 1启动，选举开始，投自己一票，此时Server 1票数不过半，Server 1保持LOOKING状态。

• Server 2 启动

  Server 2启动，Server 2投自己一票，并与Server 1 互换投票信息，Server 2的myID大于Server 1 的myID，Server 1改投票给Server 2，此时Server 2票数不过半，Server 2保持LOOKING状态。

• Server 3 启动

  Server 3启动，Server 3投自己一票，并与Server 1 、 Server 2 互换投票信息，Server 3的myID大于Server 1 、Server 2 的myID，Server 1 、Server 2 改投票给Server 3，此时Server 3票数过半，Server 3当选leader，状态为LEADING，Server 1、Server 2 为Follower，状态为FOLLOWING 。

• Server 4 启动

  Server 4 启动，Server 4发起选举，发现Server 3 已当选leader，且Server 1、Server 2状态不为LOOKING，无法再次投票，Server 4少数服从多数，改投票给Server 3，Server 4角色为Follower，状态为FOLLOWING 。

• Server 5 启动

  与Server 4 同理。

Zookeeper选举机制-非第一次启动

当集群中确实不存在leader后，集群剩余节点会重新进行选举，选举规则如下：

1. Epoch大的直接胜出（Epoch为该节点当选Leader次数）
2. Epoch相同，则ZXID大的胜出（ZXID为事务ID，用来记录服务器状态的每次事务变更，ZXID大的节点表示事务状态新）
3. ZXID相同，myID大的胜出（myID为人工声明的服务器ID）

• 比对Epoch

  Server 3宕机后，其他节点比对Epoch，此时Epoch相等。

• 比对ZXID

  server1、server2的ZXID为8，比server4、server5大。

• 比对myID

  server1的myID为1，server2的myID为2，server2当选。

Zookeeper Follower和Leader状态同步流程