Zookeeper的选举机制主要分为两种情况，一种是第一次启动时选举Leader，另一种是其他服务器在运行期间无法和Leader保持连接。下面详细介绍两种情况下的选举机制
1. 核心概念解释
SID：服务器ID，用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID：事务ID，ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch：每个Leader任期的代号，没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加
2. 第一次启动(初始化)
所此时有服务器初始化启动，假设总共有5台服务器
1. 服务器1启动
发起一次选举，服务器1先投自己一票，此时服务器1的票数为一票，不够半数以上(3票)，选举还未结束，无法完成选举，服务器1的状态保持为LOOKING
2. 服务器2启动
发起一次选举，服务器1和服务器2分别投自己一票并交换选票结果，此时服务器1发现服务器2的myid比自己目前投票选举的(服务器1自身)myid大，更改选票为推举服务器2。此时服务器1的票数为0票，服务器2的票数为2票，不够半数以上(3票)，选举还未结束，服务器1和服务器2状态保持为LOOKING
3. 服务器3启动
发起一次选举，服务器1、服务器2和服务器3分别投自己一票并交换选票信息，此时服务器1和服务器2发现服务器3的myid比自己目前投票选举的myid大，于是服务器1和服务器2更改选票为推举服务器3。此次选举结果是服务器1和服务器2的票数为0票，服务器3的票数为3票，此时服务器3的票数已经超过半数，服务器3当选为Leader。服务器1和服务器2更改状态为FOLLOWING，服务器3更改状态为LEADING
4. 服务器4启动
发起一次选举，此时服务器1、服务器2和服务器3已经不是LOOKING状态，不会再更改选票信息。交换选票结果，服务器3为3票，服务器4为1票，此时服务器4服从票数多的服务器3，更改选票信息为服务器3，并更改状态为FOLLOWING
5. 服务器5启动
发起一次选举，此次选举结果跟服务器4一样投票给服务器3，并更改状态为FOLLOWING
最终的选举结果
服务器3当选为Leader，状态为LEADING，其余服务器为Follower，状态为FOLLOWING
3. 非第一次启动(运行期间)
此时部分服务器初始化启动和服务器运行期间无法与Leader保持连接
当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：
3.1.集群中本来就已经存在一个Leader
对于已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
3.2.集群中确实不存在Leader
假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举。
SID为1、2、4的机器投票情况如下：
EPOCH ZXID SID
1 8 1
1 8 2
1 7 4
选举Leader的规则是：
- EPOCH最大的直接胜出
- EPOCH相同时，事务ID(ZXID)最大的胜出
- 事务ID(ZXID)相同时，服务器ID(SID)最大的胜出