这篇文章我们重点理解Zookeeper选举机制的思路。

一，Zookeeper选举过程中服务器的状态。

LOOKING：寻找leader状态，该状态下，服务器认为当前集群没有leader，会发起leader选举。在选举过程中，所有服务器的状态都是LOOKING。

FOLLOWING：跟随者状态，该状态下，当前服务器是follower，并且知道leader是谁。此时选举已经结束。

LEADING：领导者状态，该状态下，当前服务器是leader，会与follower维持心跳检测。此时选举已经结束。

OBSERVING：观察者状态，该状态下的服务器是observer，不参与选举。

二，Zookeeper选票数据结构

每个服务器在进行leader选举时，都会发送以下几个关键属性信息：

logicalclock：投票轮次，自增的，volatile的，初始值为1，也就是第一轮选举。

state：当前服务器的状态。

self_id：当前服务器的myid。

self_zxid：当前服务器的最新的zxid。

vote_id：当前服务器推举的leader服务器的myid。

vote_zxid：当前服务器推举的leader服务器的最新的zxid。

三，Zookeeper选举算法

从3.4.0版本开始，Zookeeper使用FastLeaderElection选举算法，可以解决之前的LeaderElection算法收敛慢的问题。更为重要的是，FastLeaderElection算法解决了脑裂问题，保证leader的唯一性。也就是说，从Zookeeper3.4.0版本开始，Zookeeper可能存在的问题只有2个了：

1，客户端没有缓存。

2，没有自我保护机制。

四，Zookeeper选举流程

1，自增选举轮次。

Zookeeper选举机制有一个前提条件：在一个轮次的选举中，所有选票必须属于该轮次。在选举的某一时刻，确实可能存在某张选票不属于该轮次的情况。所以Zookeeper在选举过程中，始终会先核对选票的轮次。

2，初始化选票。

每个服务器在广播自己的选票时，都会先清空投票箱，这个投票箱存放的是所有接收到的来自其他服务器的选票。投票箱中只记录每个服务器的最后一次投票，如果服务器更新自己的投票，则其他服务器会更新该服务器的选票。

举个例子：服务器2投票给服务器3，服务器3投票给服务器1，则服务器1的投票箱中有如下记录

(2,3),(3,1),(1,1)

当然，这里的选票的结构是简化版的，如果加上选举轮次logicalclock，可能是这样的：

(8,2,3),(8,3,1),(8,1,1)

第一位代表当前的选举轮次，第8轮选举。

3，发送初始化选票。

每个服务器在投票开始阶段，都把票投给自己，然后通过广播通知其他服务器。

4，接收外部选票。

每台服务器都会尝试从其他服务器获取选票，并保存到自己的投票箱。

5，判断选举轮次logicalclock。

确保是同一轮次的投票。如果当前服务器发现自己的轮次落后了，则自增logicalclock，然后重新发送广播告诉其他服务器。

6，选票PK确认自己最终的投票。

注意，在这个阶段，每台服务器都可能改变自己的想法，重新确定把选票投给谁。

有3条规则：

第一条规则：如果当前服务器的logicalclock小于其他服务器，说明自己的选举轮次过期了，此时更新自己的logicalclock，然后重新把自己的选票发送出去。

第二条规则：如果当前服务器的logicalclock等于其他服务器，说明大家进行的是同一轮次的选举，此时比较二者的vote_zxid，vote_zxid大者获胜。如果当前服务器输了，则更新自己的投票为胜者，然后广播告诉其他服务器。

第三条规则：如果当前服务器的logicalclock等于其他服务器，说明大家进行的是同一轮次的选举，此时比较二者的vote_zxid，如果vote_zxid也相等，则比较二者的vote_myid，vote_myid大者获胜。如果当前服务器输了，则更新自己的投票为胜者，然后广播告诉其他服务器。

7，统计选票。

如果已经确定有过半服务器认可了自己的投票，则终止投票。否则继续接收其他服务器的投票。

8，更新服务器状态。

投票结束后，服务器更新自己的状态serverState，如果投给自己的选票过半了，则将自己更新为LEADING，否则将自己更新为FOLLOWING。

这里思考一个问题：Zookeeper启动阶段，myid最大的服务器是不是一定会被选举为leader？