zookeeper选举机制理解

在理解zookeeper选举机制时需要先了解以下几个概念

1.Sid (又称服务器id,也就是zookeeper中的myid)

2.Zxid 每次znode状态发生改变该值都会受到更新（递增且唯一,唯一是相对于某个zk服务器而言）,每个znode其实都维护了3个zxid

cZxid	该节点创建时的事务id
mZxid	该节点修改时的事务id
pZxid	子节点修改的事务id，子节点创建修改以及删除都会影响该事务id

3.epoch 逻辑时钟,也就是当前投票轮数

4.选举状态

Looking	当前server正在选举，等待leader被选举出来
Leading	当前server为leader
Following	当前server为follower
Observing	跟Follower差不多，就是不参与选票过程

了解了这几个概念就可以讲一讲zk的选举机制。

zk选举机制分为两种，一种是启动时的选举,一种是zk恢复模式选举.

我们先来将一下启动时的选举。

首先我们要明白一个事情zk选出leader的条件必须是leader节点必须获得n/2+1的选票才行，n就是zk集群的server数.

每个zk启动时都会发起新的投票，并在这一轮投票中投票给自己。接收到别的投票时会和自己的投票进行pk。pk规则为 判断sid大小，推荐sid大的那个zk为leader。

那么这样是否代表sid最大的在集群启动时必定为leader吗？答案当然不是。

举个例子，假设我们现在有5台服务器组成的zk集群。

首先server1启动了，此时它投票给自己，但是就他一台server，他的状态自然为Looking。

然后server2启动了，此时他发起了新的投票，他先投票给自己,并且广播。server1接收到了server2的投票信息，发现他的逻辑时钟大于自己，于是自己旧的投票情况作废，重新投票给sid大于自己的server2。此时server2获得两票,但是选票情况未满足n/2+1，所以server2还是Looking。

重头戏来了，此时server3启动了，它发起了新一轮的投票,过程就不说了（大家可以按照server2那样来脑补一下），结果server3获得了3票,此时选票满足了n/2+1，server3成为leader,server1和2为follower。

这个时候就算server4和5启动了，也无济于事了，因为此时leader已经被选举出来了，4和5就不会发起新的投票，直接成为follower。

zk恢复模式选举就是说当leader节点下线或者一半节点下线集群就会进入恢复模式直到选出新的leader，这个时候的选举就会映入Zxid，此时是否选举某个server为leader的依据便是Zxid的大小，当Zxid相同再去判断Sid。

在文章的末尾再聊一天，为什么很多博客都说要zk要两台以上，并不是说两台就不能玩了,两台也是能选举出leader的。只不过两台zk毫无可用性，随便其中一台宕机，集群就不能用了。

另外建议zk节点奇数节点，为什么呢?当个比方吧。

3台节点时我们的集群容错率为1(允许一台非leader节点下线),当我们将集群数提高到4台，此时我们的集群容错率还是1,因为第二台下线的时候也会进入恢复模式。偶数集群并不能带给我们比奇数集群更多的可用性(反而无谓的添加了投票阶段的支出),所以最好还是奇数集群，如果要增加集群的可用性建议还是添加observer节点.