zookeeper系列--如何选举leader
Zookeeper集群是如何选举leader的呢？
Leader 选举会分两种场景：
- 启动的时候的 leader 选举
- leader 崩溃时候的选举
服务器启动时的 leader 选举
每个节点启动的时候状态都是 LOOKING，处于观望状态，接下来就开始进行选主流程进行 Leader 选举，至少需要两台机器，我们选取 3 台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器 Server1 启动时，它本身是无法进行和完成 Leader 选举，当第二台服务器 Server2 启动时，这个时候两台机器可以相互通信，每台机器都试图找到 Leader，于是进入 Leader 选举过程。
选举过程如下
- 每个 Server 发出一个投票。由于是初始情况，Server1 和 Server2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID、epoch，使用 (myid, ZXID) 和 epoch 来表示，此时：
- Server1 的投票为 (1, 0)
- Server2 的投票为 (2, 0)
然后各自将这个投票发给集群中其他机器。
接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自 LOOKING 状态的服务器。
处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行 PK，PK 规则如下：
- 优先检查 ZXID。ZXID 比较大的服务器优先作为 Leader
- 如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为 Leader 服务器。
对于 Server1 而言，它的投票是 (1, 0)，接收 Server2 的投票为 (2, 0)，首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为 (2, 0)，然后重新投票。
对于 Server2 而言，它不需要更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了 (2, 0) 的投票信息，此时便认为已经选出了 Leader。
改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态：
- 如果是 Follower，那么就变更为 FOLLOWING，
- 如果是 Leader，就变更为 LEADING。
运行过程中的 leader 选举
当集群中的 leader 服务器出现宕机或者不可用的情况时，那么整个集群将无法对外提供服务，而是进入新一轮的 Leader 选举，服务器运行期间的 Leader 选举和启动时期的 Leader 选举基本过程是一致的。
变更状态。Leader 挂后，余下的非 Observer 服务器都会将自己的服务器状态变更为 LOOKING，然后开始进入 Leader 选举过程。
每个 Server 会发出一个投票。在运行期间，每个服务器上的 ZXID 可能不同，此时假定 Server1 的 ZXID 为 123，Server3 的 ZXID 为 122；在第一轮投票中，Server1 和 Server3 都会投自己，产生投票 (1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
接受来自各个服务器的投票。与启动时过程相同。
处理投票。与启动时过程相同，此时，Server1 将会成为 Leader。
统计投票。与启动时过程相同。
改变服务器的状态。与启动时过程相同
