Zookeeper选举机制

zookeeper节点的4种状态:

• LEADING：说明此节点已经是leader节点，处于领导者地位的状态，差不多就是一般集群中的master。但在zookeeper中，只有leader才有写权限，其他节点（FOLLOWING）是没有写权限的，可以读
• LOOKING：选举中，正在寻找leader，即将进入leader选举流程中
• FOLLOWING：跟随者，表示当前集群中的leader已经选举出来了，主要具备以下几个功能点 ：

1. 向leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）
2. 接收leader消息并进行处理；
3. 接收client发送过来的请求，如果为写请求，会发送给Leader进行投票处理，然后返回client结果。

• OBSERVING：OBSERVING和FOLLOWING差不多，但不参加投票和选举，接受leader选举后的结果。

Server id（或sid）：服务器ID

比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大，比如初始化启动时就是根据服务器ID进行比较。

Zxid：事务ID

服务器中存放的数据的事务ID，值越大说明数据越新，在选举算法中数据越新权重越大。

Epoch：逻辑时钟

也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的，每投完一次票这个数据就会增加。

什么场景下 Zookeeper 需要选举？

当 Zookeeper 集群中的一台服务器出现以下两种情况之一时，需要进入 Leader 选举。

（1）服务器初始化启动。
（2）服务器运行期间 Leader 故障。

启动时期的 Leader 选举

假设这些服务器从id1-5，依序启动：

因为一共5台服务器，只有超过半数以上，即最少启动3台服务器，集群才能正常工作。

1. 服务器1启动，发起一次选举。
   服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成；
   服务器1状态保持为LOOKING；

2. 服务器2启动，再发起一次选举。
   服务器1和2分别投自己一票，此时服务器1发现服务器2的id比自己大，更改选票投给服务器2；
   此时服务器1票数0票，服务器2票数2票，不够半数以上（3票），选举无法完成；
   服务器1，2状态保持LOOKING；

3. 服务器3启动，发起一次选举。
   与上面过程一样，服务器1和2先投自己一票，然后因为服务器3id最大，两者更改选票投给为服务器3；
   此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数（3票），服务器3当选Leader。
   服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

4. 服务器4启动，发起一次选举。
   此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。
   此时服务器4服从多数，更改选票信息为服务器3；
   服务器4并更改状态为FOLLOWING；

5. 服务器5启动，同4一样投票给3，此时服务器3一共5票，服务器5为0票；
   服务器5并更改状态为FOLLOWING；

运行时期的Leader选举

Epoch大的直接当选

（1）状态变更。Leader 故障后，余下的非 Observer 服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。

（2）每个Server会发出投票。

（3）接收来自各个服务器的投票，如果其他服务器的数据比自己的新会改投票。

（4）处理和统计投票，没一轮投票结束后都会统计投票，超过半数即可当选。

（5）改变服务器的状态，宣布当选。