zookeeper的选举机制

1 选举机制

（1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。 （2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为leader，其他则为Follower，leader是通过内部的选举机制临时产生的。 （3）以一个简单的例子来说明整个选举的过程。 假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

1.1 Zookeeper的选举机制

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING； （2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING （3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING； （4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING； （5）服务器5启动，同4一样当小弟。

1.2Zookeeper的选举机制（文字描述）

选举的总原则：当zk集群中任意一台机器得到选票数超过机器总数的一半以上， 它就是当前集群的leader。 1. 新搭建的集群（没有数据） 举例说明：以5台机器为例 前提：集群配置没问题！1,2,3,4,5 顺时启动   （1） server1 启动，此时它会给自己投票，因为当前票数没有过半，它的投票结果出于（LOOKING） （2） server2 启动，此时先给自己投一票，然后server2和server1进行通信，相互交换选票，此时发现给自有一票，那么进行myid（配置集群时候的写的编号）的比较，2 > 1,server2选举胜出，server1会把票投给server2。这个时候还没有选出leader，票数没有达到半数以上。选举结果任然出于LOCkING。这时候把选票结果恢复到原始状态，server1和server2都有一票 （3） server3 启动，先给自己投票，然后就与server1和server2进行通信，大家交换选票，因为个自都是1票，所以比较myid, 此时server3胜出，server1和server2将自己的选票投给server3，此时server3累计3票，最后判断当前票数知否超过集群的总数的一半。由此就把leader选出了，就是server3。 （4） server4 启动，由于当前集群已经产生了leader,它就不参与选举，自动成为follower （5） server5 启动，由于当前集群已经产生了leader,它就不参与选举，自动成为follower 注意：当启动顺序不确定时，选举结果可能受影响，但是选举额机制原理不变。 2. 集群工作中，leader突然挂了，在当前机器存活数过半以上， 要重新选举出leader。   （1）以上情况出现，会从现有存活的机器中再选出一个leader，此时集群每台机器zxid就不一样，这种情况的选举就以两个条件去投票，就是 （myid,zxid）。此时就会选择当前集群中zxid值最大的为leader。如果极端情况下，zxid的值一样，此时会比较myid。可能会丢失数据，重新选举领导大概是200毫秒，丢失的是毫秒级别的数据 结论：某种意义上，zxid值最大的就可以代表当前集群中数据最完整的一台机器。