Zookeeper Leader选举机制

勿以浮沙筑高台

---

基础知识

1.服务器的几种状态（Status）

1.1 Looking：寻找状态，当整个集群当中没有Leader的时候，需要进行选举的过程则为Looking

1.2 Leader：领导者，所有的请求都会来到Leader进行处理，处理的内容主要是事务，所有请求到Leader的好处就是Leader的数据永远是最新的数据

1.3 Follower：跟随者，即copyLeader中的数据，复制节点。

2.服务器ID(ServiceId)
在我们配置zoo.cfg时，会去定义Service.xx，这个xx即服务器ID，另外我们在dataDir这个属性当中配置的myid也是当前的服务器ID。ID越大即权重占比越大。

3.ZXID
ZXID由世纪数据（epoch）和事务ID（XID）构成


什么是世纪数据（epoch）
每个leader都会具有不同的epoch值，表示一个纪元/朝代，用来标识 leader 周期。每个新的选举开启时都会生成一个新的epoch，新的leader产生的话epoch会自增，会将该值更新到所有的zkServer的zxid和epoch，当发生一次选举时世纪数据就会发生一次改变

什么是事务ID(XID)
当数据发生更改操作时，xid会加1，xid数值越大代表越新。事务ID也预防了更新的失败的操作，即当事务paper过程完成，并超半数主机paper完成才开始执行更新操作。

Lerader选举过程

Leader选举又分启动选举和运行时选举

启动选举

第一步：首先启动的机器投自己一票

比如SID：1先启动，先投自己一票，进入Looking状态，此时SID1拥有1票

第二步：第二台的机子会和之前的机子进行比较

S1和S2进行比较，如果S2的serverID比S1的值高，就会投票给S2。这个时候S2就有2票，S1，0票。S2和S1都保持为Looking状态

第三步：循环进行第二步，当选举超过半数时，SID最大的则为Leader

当项目启动的时候，我们就配置了主机数量，
依次比较，当选举超过半数时，SID最大的主机更改为状态为Leader，其他的机子为Follower状态。

运行时选举

当Leader宕机了，这时follower需要重新进行选举，会经历2次选举，第一次，从各个服务器拿一票，这个时候各个服务器的票数是相同的，然后进行第二次选举，谁的事务xid大谁当leader，当事务ID一样时，谁的serverid大谁是leader，

如图实例：

选举遇见的几个问题

1.当其中一台服务器例SID3，zid为17最大时宕机了一段时间，其他服务器选举成功新Leader，SID3会进行回滚

2.倘若选举跨过了一个纪元epoch后重新恢复了，不会重新挡下来，因为纪元不一样了。

3.脑裂

什么是脑裂：指在网络某一网段不通，多个集群之间，进行了独立选举，比如6台机子，发生了脑裂,3:3的分开，这个时候就发生了2个Leader的选举，倘若是4台机子，2:2分开，就无法保证对外始终有一个Leader的存在，整个系统就发生了宕机。因此服务器集群要求2N+1的要求是选举需要也是为了保证对外始终存在Leader避免宕机的要求。

必须保证每个网段的服务器的梳理为2N+1台。避免脑裂线性发生。
比如：
A：2个节点，B：2个节点
如果这时候A网段发生了宕机则B无法完成超过半数的机制，就会发生宕机
A：1个节点，B：3个节点
A发生宕机，B能即使选举出新的Leader
A：2个节点，B：3个节点
A宕机了,B也会有Leader