Zookeeper系列--详述Zookeeper集群选举机制

1、选举过程中服务器的状态

• looking：寻找leader状态。当服务器处于该状态时，它会认为当前集群中没有leader，因此需要进去leader选举状态。
• leading：领导者状态。服务器角色为leader
• following：跟随者状态。服务器角色为follower。
• observing：观察者状态。服务器角色是observer。

2. 选举机制

每个server首先会给自己投票，然后用自己的选票和其他server选票对比，权重大的胜出，servers使用权重较大的更新自身选票箱。

选举过程：

1. 每个server发出一个选票；集群中的每台服务器接收来自集群中各个服务器的投票。
2. 处理投票。规则如下：优先检查ZXID(事务ID)，zxid大者胜出；如果zxid相同，那么就比较myid，myid大者胜出。
3. 统计投票。每次投票后，服务器会统计投票信息，判断是否已经有过半机器接收到相同的投票信息。
4. 改变服务器状态。一旦确定了leader，每个服务器就会更新自己的状态，如果是follower，那么就变更为following，如果是leader，就变更为leading。
   1、Leader等待Follower连接，Follower连接Leader，将最大的ZxId发送给leader。
   2、leader根据follower的zxid确定同步点，至此选举阶段完成。
   3、选举阶段完成之后，leader通知follower可以对外服务。

3、集群启动阶段的选举

假设有三台机器：zookeeper01、zookeeper02、zookeeper03。

1） 服务器1启动，给自己投票，然后广播投票信息，由于其他机器还没启动，服务器1的状态一直处于Looking，且集群不能对外提供服务。

此时zookeeper01的服务状态：

此时zookeeper服务是不对外提供服务的，当我们进入zkCli的时候，会一直报错：

2） 服务器2启动，给自己投票，投票信息使用(myid, zxid)来标识。同时与服务器1交换结果，由于服务器2的Myid大，服务器1也投票给服务器2。此时服务器2获取的票数（2 > (2 + 1) / 2）过半，服务器2胜出，成为集群leader，集群开始对外提供服务。

查看zookeeper02实例的状态，发现其已经是集群的leader：

再观察zookeeper01服务的日志，发现其做为follower加入集群中：

此时，我们在进入zkCli，发现已经可以正常加入，证明集群已经对外提供服务了：

3） 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，发现已经有Leader了，那么服务器3只能作为小弟了。

4、服务运行时期的Leader选举

一旦leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮leader选举，其过程和启动时期的leader选举过程基本一致。

假设正在运行的zookeeper01、zookeeper02、zookeeper03三台服务器，当前leader是zookeeper02，若某一时刻leader挂了，此时便开始leader选举。选举过程如下：

1）变更集群状态：leader挂掉后，余下的服务器都将自己的服务器状态变更为looking，然后开始进入leader选举过程。
我们观察zookeeper01的日志发现，集群状态进入到了LOOKING状态：

2）每个server会发出一个投票。在运行期间，每个服务器上的zxid可能不同，在第一轮投票中，server1和server3都会投自己，产生投票(1,122)，(3,122)，然后各自将投票广播给集群中所有机器。

3）处理投票。以zookeeper01实例为例，其发现zookeeper03的zxid与自己相等，便比较两者的myid，由于zookeeper03的myid=3 > zookeeper01的myid=1，所以投票给zookeeper03，广播投票结果给zookeeper03，并将投票结果维护在自己的投票结果池。zookeeper03实例同样投票给zookeeper03，广播投票结果给zookeeper01，并维护自己的投票结果池。最终zookeeper01和zookeeper03的投票结果池中zookeeper03获取了两票，zookeeper03被选举为leader。

4）改变服务器状态。开始对外服务。

5、当集群中的节点只剩一个时

我们再把leader(03)停掉，此时只剩下一个01，我们发现集群状态已经再次进入到了LOOKING状态，停止对外服务。