zookeeper的选主过程

目前默认的版本是FastLeaderElection，另两种已经被标记为deprecated。其过程如下：
数据恢复阶段。首先，每个ZooKeeper服务器先读取当前保存在磁盘的事务数据，从而得知当前自己能看到的最大zxid
首次发送自己的投票值。在读取数据之后，每个ZooKeeper服务器发送自己提议的leader，这个协议中包含了以下几部分的数据：

1. 所选举leader的id，在初始阶段，每台服务器的这个值都是自己的id
2. 服务器的最大zxid，因为FIFO原则，这个值越大说明该服务器离主越近
3. 逻辑时钟的值，也就是epoch，每次选举leader这个值会加1
4. 本机在当前选举过程中的状态，有以下几种：LOOKING，FOLLOWING，OBSERVING，LEADING

每台服务器将自己的上两种数据发送到集群中的其他服务器，同时也会接收来自其他服务器的这两种数据，此时如果该服务器的状态是在选举阶段(LOOKING状态)，那么首先要判断逻辑时钟值，分为以下三种情况：

1. 如果发送过来的逻辑时钟大于目前的逻辑时钟，那么说明这个提议比本机发起的提议更接近最新数据，此时需要更新本机的逻辑时钟值，同时将之前收集到的来自其他服务器的提议清空，因为这些数据已经不再有效了。然后判断是否需要更新当前自己的提议，这里是根据提议的leader id和保存的最大zxid来进行判断的，判断逻辑是：首先看zxid，大者胜出；其次再判断leader id，大者胜出。然后再将自身最新的提议数据广播给其他服务器
2. 发送过来的逻辑时钟小于本机的逻辑时钟，说明对方在一个相对较早的选举进程中，这时只需要将本机的提议发送过去即可
3. 两边的逻辑时钟相同，此时只是调用totalOrderPredicate函数判断是否需要更新本机的数据，如果更新了再将自己最新的提议广播出去即可

以上三种情况处理完毕之后，再执行两个判断：

1. 判断是不是已经收集到了所有服务器的提议状态，如果是那么根据选举结果设置自己的角色（FOLLOWING还是LEADER），然后退出选举过程
2. 即使没有收集到所有服务器的提议状态，也可以判断一下根据以上过程之后最新的选举leader是不是得到了超过半数以上法定人数的支持，如果是，那么尝试在200ms内（默认）接收一下数据，如果没有新的数据到来，说明大家都已经默认了这个结果，同样也设置角色退出选举过程
3. 如果所接收服务器不在选举状态，也就是在FOLLOWING或者LEADING状态，做以下两个判断：

• 1) 如果逻辑时钟相同，将该数据保存到recvset，如果接收服务器处于LEADING状态，那么将判断是不是有半数以上的服务器选举它，如果是则设置选举状态，退出选举过程
• 2) 否则这是一条与当前逻辑时钟不符合的消息，说明在另一个选举过程中已经有了选举结果，于是将该选举结果加入到outofelection集合中，再根据outofelection来判断是否可以结束选举，如果可以也保存逻辑时钟，设置选举状态，退出选举过程

1. Follower

    Follower的逻辑就比较简单了。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。Follower处理提议的过程已经在ZAB一章中描述过了。
    另外需要注意的是，leader和follower构成ZooKeeper集群的法定人数，也就是说，只有他们才参与新leader的选举、响应leader的提议。

Observer

    如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。