Zookeeper 选举机制和脑裂问题

Zookeeper 选举机制和脑裂问题

之前刚接触的时候对这两个概念有所了解，因为用不到，隔一段时间就忘了。网上的解答又鱼龙混杂，由于各人理解不同，工作/学习环境不同，结果良莠不齐。每次搜索回忆都需要很长时间。在此特地将我个人的理解记录下来。

如果文章内容有问题，欢迎评论或与我进行讨论（请注明原因）：

mail: wgh0807@qq.com
微信: hello-wgh0807
qq: 490536401

zookeeper选举

1. zookeeper 集群中包含的角色：

   • leader，领导人，负责投票发起和决议；更新系统状态；分配用户请求到跟随者；不实际处理业务。在集群中也被称为master。

   • follower，跟随者，接收客户请求，想客户返回结果，在集群中也被称为slave。选举时参与投票。

   • observe，观察者，将请求转发给leader，不参与投票。

   tip: 只要有leader 存在，就不进行选举

2. 核心：ZAB (Zookeeper Atomic Broadcast, zookeeper原子广播，用于保证server同步)

   ZAB的两种工作模式：

   • 恢复模式（选主）
   • 广播模式（同步）

3. zookeeper集群的配置：提前在其配置文件中配置集群中机器的ip和端口 (这点很重要，不是自主发现，未配置的zk无法混入集群中)

4. 选举前提：

   1. 半数可用机制（半数以上个zk服务器可用才执行选举，不然无法满足条件3）
   2. no leader（无领导情况下才能选举）
   3. 半数选举机制（某一个leader必须获取半数以上张选票才能成为leader。用于防止脑裂问题）

5. 选举流程（以五台服务器为例）：

   Note: 在注册时，每台server会获得一个ID(配置文件可以指定ID)。除人工指定外，ID是递增的 。在无leader情况下，ID较低的zk服从ID较高的zk。以下zk服务器的ID等于其编号。

   Note 2: Leader不负责实际处理用户请求。故单台ZK Server不会成为leader。

   1. Server 1启动，先投自己，获得的票数是1/5，未超过半数，选举无效。
   2. Server 2启动，先投自己，Server 1 跟从Server 2 投票给2，Server 2获得票数为2/5，未超过半数，选举无效。
   3. Server 3启动，先投自己，Server 1 和 2 跟从Server 3 投票给 3 ，Server 3 获得票数为 3/5，超过半数，选举生效，server 3 成为集群中的leader。
   4. Server 4启动，此时已经不满足选举条件，无选举行为。
   5. Server 5启动，同样不满足选举条件，无选举行为。

6. 时间轴如下（丑是丑了点，将就看吧）：

   

7. 结果：此时Server 3 成为集群的leader，其他的server成为follower。

脑裂问题

脑裂，即有两个大脑。在集群中表现为两个leader(master)。容易导致同步问题、资源抢占和死锁问题。

产生环境事例和解决方案：

tip：此处举例使用了六台服务器，会发现不符合推荐的奇数个服务器。因为6台服务器和7台服务器需要经过的选举次数相同（都是至少获得4票），但是处理能力却不如7台服务器。故推荐选择奇数个服务器。

1. 网络环境变化（常见）：假设之前Server 1 为leader，其他的为slave，若没有半数选举机制，遇到网线（或心跳线）断开的情况，则网络环境B会选举一台新的leader。当网线/心跳线恢复后，这一集群合二为一后，将有两个leader。
   

解决方案：引入半数选举机制，必须获得半数以上票数选举生效，可以有效避免这种情况下的脑裂问题。

2. 在上图网络环境中，假设server 1 是leader，某一时刻突然宕机，其他机器开始选举leader。但是server 1 宕机恢复了，则出现了新选举的leader和旧leader 并存的情况。

   解决方案：先入为主（具体名字我忘记了，这里是按照我的印象完成的，若有问题请评论或联系我）原则，若旧leader恢复在选举完成之前，则停止选举，使用旧leader。若恢复时选举已经完成，则采用新的leader。

参考资料：

zookeeper的选举机制 - HandsomeEric - cnblogs

《分布式数据库架构与企业实践-基于Mycat中间件》周继峰，冯钻优，陈胜尊，左越宗著

部分资料源于我的leader - @李诗明

如有问题，欢迎评论或联系我讨论。