ZK的选举过程

zookeeper在我们系统做分布式数据一致性的时候使用还是比较多的，所以对于一些比较重要的场景，实现原理还是有必要深入了解一下的，今天就对zk的Leader选举过程来说明一下。

首先要明确zk集群中要发生Leader选举的两种场景 ：

1. 服务器初始化启动
2. 服务器运行期间无法和Leader建立连接

然后还要先明确一下zk集群中服务器的四种状态 ：

• LOOKING : 寻找Leader状态，当服务器处于该状态时，会认为当前集群中没有Leader，因此需要进入Leader选举流程
• FOLLOWING : 跟随者状态，表明当前服务器的角色是Follower
• LEADER : 领导者状态，表明服务器在集群中当前状态为Leader
• OBSERVING : 观察者状态，表明服务器当前的角色是Observer

所以2~4状态是和服务器在集群中的角色对应的，只有当服务器的状态为LOOKING的时候，集群是需要进行Leader选举的。

不过在说明zk选举流程之前有两个术语要提前说明 ：

• SID ：在zk集群中SID标识一台Zookeeper机器，每台机器不能重复和myid的值是一致的
• ZXID ： ZXID是一个事务ID，用来唯一标识一次服务器的状态变更，在某一个时刻集群中每台机器的ZXID的值可能不一致

先说明这两个术语是因为zk的选举投票过程是和这两个概念有很大关联。

我们首先以服务器启动的时候Leader选举为例子。因为zk集群是的一个隐含条件就是最少需要两台机器，所以这里面我们以3台机器为例子。

• 首先启动第一台机器，这个时候是无法进行Leader选举的
• 启动第二台机器，这个时候这两台机器已经可以进行互相通信了，于是进入选举阶段
• 开始阶段每台机器都会讲自己投票为Leader，然后将自己的投票发送给集群中的其他机器。这里就要用到上面说的内容了，这个选票是个什么东西？这里要说明一下每台机器的选票包括所推举的服务器的myid和服务器的ZXID -->(myid,ZXID)的形式。
• 因为集群中每台服务都会收到其他机器发送过来的投票信息，在处理投票数据的时候会基于下面两个原则：

1. 优先检查ZXID，ZXID比较大的服务器会优先被选择为Leader
2. 如果ZXID相同，那么就比较myid，myid比较大的服务器作为Leader服务器

所以基于上述的两个原则，在两台服务器收到所有的投票之后，因为是在服务器启动阶段，两台机器的ZXID都是0，然后第二台机器的myid是比第一台的大，

这个时候对于每台服务器会有两个选择 ： 改变自己的投票  和   坚持自己的投票

那么对于机器1来说，因为接收到机器2的投票信息，所以这个时候需要他改变自己的投票，他会讲机器2推举为Leader，然后再次将投票信息发送到集群中。

而对于机器2来说，自己的myid比机器1的大，所以自己要坚持自己的投票，所以只需要再次将自己的选票发送到集群中即可。

那么在第二次投票之后，集群就会选出机器2作为整个集群的Leader，而在这之后加入到集群中的机器，在向集群获取信息的时候，就可以获取到Leader的信息，所以只需要与Leader建立起连接即可，无需再次进行Leader的选举。