zookeeper的选举机制

Leader选举机制是保证分布式数据一致性的关键所在，在zk集群中有两种情况需要进入leader选举:
1.服务器初始化启动
2.服务器运行期间无法与leader保持连接（leader服务器挂掉了）

在zk中投票的实体Vote，但是每次投票的信息都是基于id与zxid，但是有些校验的判断需要用到其他的信息，Vote的属性如下
version：版本信息，重写equals的时候使用
id：被推荐的leader的sid也就是myid
zxid：被推荐的leader的事务id
electionEpoch：逻辑时钟，用来判断多个投票是否在同一个选举周期中，该值在服务端是一个自增序列，每次进入新的一轮投票后，都会对该值进行加1操作
peerEpoch：被推荐leader的epoch
state：当前服务器的状态

如果要进行leader选举的话，至少需要两台服务器，一台服务器也无法投票

服务器启动时期的leader选举流程（假设三台服务器）

1.每台服务器发出一个投票
由于是初始化启动，所有的服务器都会选取自己为leader进行投票，每次投票的信息否是Vote，但是PK的时候比较的信息还是sid与zxid两个信息。因为是初始化启动，S1启动时无法进行选举，当S2启动时，有两台服务器了，就可以互相通信了，可以先执行选举
2.接收来自各个服务器的投票
集群中每个服务器除了投票以外还要接收其他服务器的投票，首先判断该选票的有效性，如果有效的选票才会接着处理
3.处理投票
针对其他服务器的选票，服务器都需要将别人的选票与自己的选票进行PK。
PK规则主要有两个：
1.优先对比zxid，zxid较大的服务器优先作为leader
2.如果zxid想的，则对比sid，sid大的作为leader
假设S1的sid与zxid为（1,0），S2的sid与zxid（2，0）（都是初次启动，zxid都为0）
S1内部比较：
zxid相等，比较sid，S2的sid大，所以S1更新选票，改投S2为leader，重新将选票发给其他服务器
S2内部比较：
同上规则，S2还是将选票给自己，然后再把选票发给其他服务器
4.统计投票
每次投票后，服务器都会统计投票信息，如果有超过半数的机器有相同的投票，那么就可以选举出leader。这次是三台机器，两台都选S2，所以S2为leader
5.改变服务器状态
一旦确定了leader，每个服务器都需要更新自己的状态，定位自己的角色，根据角色更新成不同的状态

服务器运行期间的leader选举

服务器运行期间的leader选举与启动时的选举只有前两步不一样，后面的都是一样的逻辑操作。
1.变更服务器状态(因为是运行期间)
Leader挂掉以后，剩下的能参加选举的服务器（主要是Follower）将会把自己的服务器状态改为LOOKING，然后进去选举Leader过程。
2.每个服务器开始选举Leader
与初始化启动类似，主要信息还是sid与zxid，第一次都是选自己为leader，将选票发送到其他服务器
3.其他步骤与启动时一致（接收选票，处理选票，统计选票，更改状态）