Zookeeper 脑裂问题

什么是脑裂？

脑裂(split-brain)就是“大脑分裂”，也就是本来一个“大脑”被拆分了两个或多个“大脑”，如果一个人有多个大脑，并且相互独立的话，那么会导致人体“手舞足蹈”，“不听使唤”。
脑裂通常会出现在集群环境中，比如ElasticSearch、Zookeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如ElasticSearch集群中有Master节点，Zookeeper集群中有Leader节点。
**官方定义：**当一个集群的不同部分在同一时间都认为自己是活动的时候，我们就可以将这个现象称为脑裂症状。通俗的说，就是比如当你的 cluster 里面有两个结点，它们都知道在这个 cluster 里需要选举出一个 master。那么当它们两之间的通信完全没有问题的时候，就会达成共识，选出其中一个作为 master。但是如果它们之间的通信出了问题，那么两个结点都会觉得现在没有 master，所以每个都把自己选举成 master。于是 cluster 里面就会有两个 master。
在脑裂发生时，集群中的每个子集可能都会继续工作，执行读取和写入操作。这可能会导致数据冲突和不一致性。例如，如果一个数据库集群发生脑裂，不同的子集可能会同时接收写入请求，导致数据在不同子集中不同步。当脑裂问题解决后，这些不同的数据可能会导致数据合并困难，进而导致数据损坏或数据丢失。

集群脑裂产生的原因？

一般集群脑裂都是由以下三个原因产生的

1. 网络分区： 当集群中的节点之间的网络连接出现问题，导致某些节点无法与其他节点通信。例如高可用服务器各节点之间心跳线链路发生故障，高可用服务器上开启了iptables防火墙阻挡了心跳消息传输等等
2. 节点故障： 集群中的某些节点可能因为硬件故障、操作系统问题或其他原因而失去响应，导致其他节点认为它们已经不再可用。例如网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）因心跳线间连接的设备故障（网卡及交换机）
3. 通信问题： 由于通信协议、时钟同步等问题，节点可能无法准确地识别其他节点的状态，从而导致混淆。

那么如何判断集群是否发生了脑裂？

在分布式系统中这些都是有监控者来判断判断一个节点是否down 掉的，但是监控者也很难判定其他的节点的状态，唯一一个可靠的途径就是心跳，Zookeeper也是使用心跳来判断客户端是否仍然活着。
整体运转流程如下

1. 每个节点都尝试注册一个象征leader的临时节点，其他没有注册成功的则成为follower，并且通过watch机制监控着leader所创建的临时节点
2. Zookeeper通过内部心跳机制来确定leader的状态，一旦leader出现意外Zookeeper能很快获悉并且通知其他的follower，其他flower在之后作出相关反应，这样就完成了一个切换，这种模式也是比较通用的模式，基本大部分都是这样实现的。
3. 但是这里面有个很严重的问题，如果注意不到会导致短暂的时间内系统出现脑裂，因为心跳出现超时可能是leader挂了，但是也可能是zookeeper节点之间网络出现了问题，导致leader假死的情况，leader其实并未死掉，但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了，然后通知其他节点进行切换。
4. 这样follower中就有一个成为了leader，但是原本的leader并未死掉，这时候client也获得leader切换的消息，但是仍然会有一些延时，zookeeper需要通讯需要一个一个通知，这时候整个系统就很混乱可能有一部分client已经通知到了连接到新的leader上去了，有的client仍然连接在老的leader上
5. 如果同时有两个client需要对leader的同一个数据更新，并且刚好这两个client此刻分别连接在新老的leader上，就会出现很严重问题。

这里做下小总结：
假死：由于心跳超时（网络原因导致的）认为leader死了，但其实leader还存活着。
脑裂：由于假死会发起新的leader选举，选举出一个新的leader，但旧的leader网络又通了，导致出现了两个leader ，有的客户端连接到老的leader，而有的客户端则连接到新的leader。

如何解决脑裂问题？

过半机制

在领导者选举的过程中，如果某台zkServer获得了超过半数的选票，则此zkServer就可以成为Leader了。举个简单的例子：如果现在集群中有5台zkServer，那么half=5/2=2，那么也就是说，领导者选举的过程中至少要有三台zkServer投了同一个zkServer，才会符合过半机制，才能选出来一个Leader。

那zookeeper过半机制中为什么是大于，而不是大于等于？
这是为了减少脑裂的概率，假设现在有一个由6台zkServer所组成的一个集群，部署在了两个机房，每个机房都有3台zkServer，那么如果机房之间的网络断了之后，两个机房内的zkServer还是可以相互通信的，如果不考虑过半机制，那么就会出现每个机房内部都将选出一个Leader。

Quornums机制

即只有集群中超过半数节点投票才能选举出Leader。这样的方式可以确保leader的唯一性,要么选出唯一的一个leader, 要么选举失败。这是zookeeper防止"脑裂"默认采用的方法。
在ZooKeeper中Quorums有2个作用：

• 集群中最少的节点数用来选举Leader保证集群可用：通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据，客户端将被通知已经安全保存了，可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据。
• 假设某个leader假死，其余的followers选举出了一个新的leader。这时，旧的leader复活并且仍然认为自己是leader，这个时候它向其他followers发出写请求也是会被拒绝的。因为每当新leader产生时，会生成一个epoch，这个epoch是递增的，followers如果确认了新的leader存在，知道其epoch，就会拒绝epoch小于现任leader epoch的所有请求。 那有没有follower不知道新的leader存在呢，有可能，但肯定不是大多数，否则新leader无法产生。Zookeeper的写也遵循quorum机制，因此，得不到大多数支持的写是无效的，旧leader即使各种认为自己是leader，依然没有什么作用。

通过Quorums机制来防止脑裂和假死，当leader挂掉之后，可以重新选举出新的leader节点使整个集群达成一致；当出现假死现象时，通过epoch大小来拒绝旧的leader发起的请求，在前面也已经讲到过，这个时候，重新恢复通信的老的leader节点会进入恢复模式，与新的leader节点做数据同步。不过这个如果旧的leader处理了数据，就会出现数据丢失的情况。

适当的超时设置

ZooKeeper 使用会话（Session）来管理客户端和服务器之间的连接，设置适当的会话超时时间可以减少脑裂的影响。较短的会话超时时间可以更快地检测到节点失效，从而减少不一致性。

采用Redundant communications (冗余通信)方式

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

网络配置优化

确保集群中的节点之间的网络连接稳定，避免分区和网络延迟。优化网络配置可以减少网络问题引发的脑裂。

启用磁盘锁

在 ZooKeeper 中，磁盘锁（Disk Lock）是一种额外的安全措施，用于防止脑裂问题。磁盘锁可以在主节点选举时帮助确保只有一个节点被选为主节点，从而降低脑裂风险。启用磁盘锁需要进行一些特定的配置和步骤。
以下是启用磁盘锁的一般步骤：

1. 配置数据目录： 首先，您需要为每个 ZooKeeper 节点配置一个数据目录（dataDir）。数据目录是节点用于存储数据和元数据的位置。确保您的配置文件中已经正确设置了数据目录。
2. 配置磁盘锁目录： 在 ZooKeeper 配置文件中，设置一个磁盘锁目录（dataLogDir）。这个目录将用于存储磁盘锁的文件。
3. 启用磁盘锁： 在 ZooKeeper 的配置文件中，设置 syncEnabled 选项为 true。这将启用磁盘锁机制。
4. 配置自动清理： 您还可以配置自动清理磁盘锁的选项，以便在主节点意外失效时，其他节点能够顺利选出新的主节点。具体配置可能因 ZooKeeper 版本而异，但通常会涉及到设置一些时间间隔。
5. 重启 ZooKeeper 节点： 在配置文件修改完成后，您需要重启所有的 ZooKeeper 节点，以使配置生效。

磁盘锁的原理是通过将选举过程的相关信息写入磁盘锁文件，其他节点可以检查这些文件以决定是否进行选举。这在一定程度上增加了选举的稳定性，从而降低了脑裂风险。
请注意，虽然启用磁盘锁可以增加系统的稳定性，但它也会引入一些额外的磁盘 I/O 操作，可能会对性能产生一些影响。因此，在启用磁盘锁之前，建议您仔细评估您的系统需求和性能预期。
尽管磁盘锁可以确保选举信息写入磁盘，但如果出现写入延迟或错误，节点之间的信息同步可能会受到影响，可能导致脑裂。

参考文章

HA高可用集群中”脑裂”问题解决 - 运维总结 - 散尽浮华 - 博客园
Zookeeper集群”脑裂”问题 - 运维总结 - 散尽浮华 - 博客园