ZooKeeper 03 - ZooKeeper集群的脑裂问题 (Split Brain问题)

目录

• 1 ZooKeeper的主从机制
• 2 什么是ZooKeeper的脑裂
  • 2.1 脑裂现象的表现
  • 2.2 为什么会出现脑裂
• 3 ZooKeeper如何解决"脑裂"
  • 3.1 3种可行的思路
  • 3.2 ZooKeeper采用的方法
  • 3.3 ZooKeeper的具体解决思路

1 ZooKeeper的主从机制

Leader == Master, Follower == Slaver.

集群中的各个节点都会尝试注册为leader节点, 其他没有注册成功的则成为follower(随从)节点.

这些follower节点通过watcher(观察者)监控着leader节点:

—— ZooKeeper内部通过心跳机制来确定leader的状态, 一旦leader节点出现问题, : 就能很快获悉并迅速通知其他follower节点, 这些follower节点得知消息之后将及时采取相关操作.

2 什么是ZooKeeper的脑裂

2.1 脑裂现象的表现

ZooKeeper集群中, 各个节点间的网络通信不良时, 容易出现脑裂(split-brain)现象:

集群中的节点监听不到leader节点的心跳, 就会认为leader节点出了问题, 此时集群将分裂为不同的小集群, 这些小集群会各自选举出自己的leader节点, 导致原有的集群中出现多个leader节点.

—— 这就是脑裂现象.

2.2 为什么会出现脑裂

设想这样一种情况:

① 集群中网络通信不好, 导致心跳监测超时 —— follower认为leader节点由于某种原因挂掉了, 可其实leader节点并未真正挂掉 —— 这就是假死现象.
② leader节点假死后, ZooKeeper通知所有follower节点进行选举 ==> 某个follower节点升级为新的leader. —— 此时集群中存在2个leader节点.
③ 此时ZooKeeper需要将新leader节点的信息通知给所有的follower节点, 还要通知到所有的client(比如通过: 搭建的Solr集群中的Solr实例就是一个client), 而这个过程由于网络等环境的影响, 消息到达就会存在快慢之分.
④ 如果部分client获得了新leader节点的信息, 而部分没有获得, 而此时client向ZooKeeper发起读写请求, ZooKeeper内部的不一致就会导致: 部分client连接到了新的leader节点上, 而部分client连接到了旧的leader节点上 —— 服务中出现了2个leader, client不知道听谁的好, 就像1个大脑被分裂成2个, 很形象吧O(∩_∩)O

3 ZooKeeper如何解决"脑裂"

3.1 3种可行的思路

(1) Quorums(ˈkwɔrəm, 法定人数)法:

通过设置法定人数, 进而确定集群的容忍度, 当集群中存活的节点少于法定人数, 集群将不可用. 比如:

3个节点的集群中, Quorums = 2 —— 集群可以容忍 (3 - 2 = 1) 个节点失败, 这时候还能选举出leader, 集群仍然可用;
4个节点的集群中, Quorums = 3 —— 集群同样可以容忍 1 个节点失败, 如果2个节点失败, 那整个集群就不可用了.

(2) Redundant communications(冗余通信):

集群中采用多种通信方式, 防止一种通信方式失效导致集群中的节点无法通信.

(3) Fencing(共享资源):

通过共享资源的方式, 将所有共享资源添加到集群中, 能对共享资源进行写操作(即加锁)的节点就是leader节点.

3.2 ZooKeeper采用的方法

ZooKeeper默认采用了Quorums(法定人数)的方式: 只有获得超过半数节点的投票, 才能选举出leader.

这种方式可以确保要么选出唯一的leader, 要么选举失败.

ZooKeeper中Quorums的作用:

① 指定集群中选举leader所需的最少节点数, 保证集群可用;
② client的数据被安全保存到集群中所需的最少节点数, 一旦这些节点保存了数据, 客户端将被通知数据已经安全保存, 可以继续其他任务 —— 基于最终一致性, 集群中剩余的节点最终也会保存相关的数据.

ZooKeeper的写也遵循quorum机制, 因此得不到大多数支持的写是无效的.

3.3 ZooKeeper的具体解决思路

假设: leader发生了假死, followers选举出了一个新的leader.

当旧的leader复活并认为自己仍然是leader, 它向其他followers发出写请求时, 会被拒绝.

—— 因为ZooKeeper维护了一个叫epoch的变量, 每当新leader产生时, epoch都会递增, followers如果确认了新的leader存在, 同时也会知道其epoch的值 —— 它们会拒绝epoch小于现任leader的epoch的所有旧leader的任何请求.

注意: 仍然会存在有部分followers不知道新leader的存在, 但肯定不是大多数, 否则新leader将无法产生.

参考资料

zookeeper（二）常见问题汇总

Zookeeper集群节点数量为什么要是奇数个？

版权声明

作者: 马瘦风

出处: 博客园 马瘦风的博客

您的支持是对博主的极大鼓励, 感谢您的阅读.

本文版权归博主所有, 欢迎转载, 但请保留此段声明, 并在文章页面明显位置给出原文链接, 否则博主保留追究相关人员法律责任的权利.