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