浅谈分布式系统脑裂现象与ZK、HDFS的避免方案

"split brain"原本是指医学中的“ 裂脑综合征 ”，即连接大脑左右半球的胼胝体受损到一定程度后发生的症状。左右脑分离后，会分别处理知觉、形成概念和对刺激产生反应，相当于有两个脑在一个身体运作，会造成患者行为的冲突。例如：

split brain这个词也被计算机科学引入，指 采用主从（master-slave）架构的分布式系统中，出现了多个活动的主节点的情况 。但正常情况下，集群中应该只有一个活动主节点。

造成脑裂的原因主要是 网络分区 （这个词之前在 讲CAP理论 时就已经出现过了）。由于网络故障或者集群节点之间的通信链路有问题，导致原本的一个集群被物理分割成为两个甚至多个小的、独立运作的集群，这些小集群各自会选举出自己的主节点，并同时对外提供服务。网络分区恢复后，这些小集群再度合并为一个集群，就出现了多个活动的主节点。

另外，主节点 假死 也有可能造成脑裂。由于当前主节点暂时无响应（如负载过高、频繁GC等）导致其向其他节点发送心跳信号不及时，其他节点认为它已经宕机，就触发主节点的重新选举。新的主节点选举出来后，假死的主节点又复活，就出现了两个主节点。

脑裂的危害非常大，会破坏集群数据和对外服务的一致性，所以在各分布式系统的设计中，都会千方百计地避免产生脑裂。下面举两个例子说说。

一般有以下三种思路来避免脑裂：

Quorum一词的含义是“法定人数”，在ZooKeeper的环境中，指的是ZK集群 能够正常对外提供服务所需要的最少有效节点数 。也就是说，如果n个节点的ZK集群有少于m个节点是up的，那么整个集群就down了。m就是所谓Quorum size，并且：

为什么是这个数呢？

考虑一个n = 5的ZK集群，并且它按3:2分布在两个机房中。

假设m = 2（即n / 2），当两个机房之间的网络中断时，Server 1~3和Server 4~5将分别形成独立的集群，并且都能对外提供服务——也就意味着都能重新选举出各自的Leader，即产生了脑裂。当网络恢复，两个集群合并时，它们的数据就会不一致。

但是，若m = 3（即n / 2 + 1），那么网络中断后，DC2上的两个节点不满足Quorum要求的数量，故只有DC1上的三个节点能选举出Leader并提供服务，DC2上的两个节点不能提供服务，当然也就不会破坏数据一致性了。

由上可知，ZK的Quorum机制其实就是要求集群中 过半 的节点是正常的，所以ZK集群包含奇数个节点比偶数个节点要更好。显然，如果集群有6个节点的话，Quorum size是4，即能够容忍2个节点失败，而5个节点的集群同样能容忍2个节点失败，所以可靠性是相同的。偶数节点还需要额外多管理一个节点，不划算。

上面说的是网络分区的情况，如果是Leader假死呢？

之前某篇文章中其实说过了，集群每次选举出一个Leader时，都会自增纪元值（epoch），也就是Leader的代数。所以，就算原来的Leader复活，它的纪元值已经小于新选举出来的现任Leader的纪元值，Follower就会拒绝所有旧Leader发来的请求，所以不会产生脑裂。当然，有一部分Follower可能对新选举出的Leader没有感知，但由于上述Quorum机制的保证，这部分肯定不会占多数，故集群能够正常运转。除ZK外，Kafka集群的Controller也是靠纪元值防止脑裂的。

下面先贴出HDFS高可用的官方经典架构图。

HDFS NameNode高可用需要两个NN节点，一个处于活动状态，另一个处于热备状态，由ZKFailoverController组件借助外部ZK集群提供主备切换支持。

当活动NN假死时，ZK集群长时间收不到心跳信号，就会触发热备NN提升为活动NN，之前的NN复活就造成脑裂。如何解决呢？答案就是隔离，即 将原来那个假死又复活的NN限制起来 （就像用篱笆围起来一样）， 使其无法对外提供服务 。具体来讲涉及到三方面。

为了实现Fencing，成为活动NN的节点会在ZK中创建一个路径为 /hadoop-ha/${dfsnameservices}/ActiveBreadCrumb 的持久znode。当正常发生主备切换时，ZK Session正常关闭的同时会一起删除上述znode。但是，如果NN假死，ZK Session异常关闭， /hadoop-ha/${dfsnameservices}/ActiveBreadCrumb 这个znode就会残留下来。由热备升格为活动的NN会检测到这个节点，并执行Fencing逻辑：

只有Fencing执行完毕之后，新的NN才会真正转换成活动状态并提供服务，所以能够避免脑裂。

最后废话一句，JournalNode集群区分新旧NN同样是靠纪元值，而它的可用性也是靠Quorum机制——即如果JournalNode集群有2N + 1个节点的话，最多可以容忍N个节点失败。

冗余通信机制没有提到，其实就是在节点之间添加额外的心跳线，防止一个心跳路径断开导致误判。

帝都疫情开始反d，还是老实在家待着吧。

民那周末快乐，晚安。

概述：

一个正常es集群中只有一个主节点，主节点负责管理整个集群，集群的所有节点都会选择同一个节点作为主节点所以无论访问那个节点都可以查看集群的状态信息。 而脑裂问题的出现就是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点从而使集群分裂，使得集群处于异常状态。

原因：

1：网络原因

        内网一般不会出现此问题，可以监控内网流量状态。外网的网络出现问题的可能性大些。

2：节点负载

         主节点即负责管理集群又要存储数据，当访问量大时可能会导致es实例反应不过来而停止响应，此时其他节点在向主节点发送消息时得不到主节点的响应就会认为主节点挂了，从而重新选择主节点。

3：回收内存

         大规模回收内存时也会导致es集群失去响应。

所以内网负载的可能性大，外网网络的可能性大。

再来看看ES（Elastic Search）主动选举机制：

elasticsearch集群一旦建立起来以后，会选举出一个master，其他都为slave节点。但是具体 *** 作的时候，每个节点都提供写和读的 *** 作。就是说，你不论往哪个节点中做写 *** 作，这个数据也会分配到集群上的所有节点中。

这里有某个节点挂掉的情况，如果是slave节点挂掉了，那么首先关心，数据会不会丢呢？不会。如果你开启了replicate，那么这个数据一定在别的机器上是有备份的。别的节点上的备份分片会自动升格为这份分片数据的主分片。这里要注意的是这里会有一小段时间的yellow状态时间。

如果是主节点挂掉怎么办呢？当从节点们发现和主节点连接不上了，那么他们会自己决定再选举出一个节点为主节点。但是这里有个脑裂的问题，假设有5台机器，3台在一个机房，2台在另一个机房，当两个机房之间的联系断了之后，每个机房的节点会自己聚会，推举出一个主节点。这个时候就有两个主节点存在了，当机房之间的联系恢复了之后，这个时候就会出现数据冲突了。

预防方案：

1：角色分离

         在es集群中配置2到3个主节点并且让它们只负责管理不负责存储，从节点只负责存储。另外从节点禁用自动发现机制并为其指定主节点，在elasticsearchyml文件中。

主节点：nodemaster =true   nodedata=false

从节点：nodemaster =false   nodedata=ture

discoveryzenpingmulticastenabled:false

discoveryzenpingunicasthosts:["host1", "host2:port"]

2：参数配置

discoveryzenping_timeout:3

       此参数指定从节点访问主节点后如果3秒之内没有回复则默认主节点挂了，我们可以适当的把它改大，这样可以减少出现脑裂的概率。

       discoveryzenminimum_master_nodes:1

       该参数的意思是，当具备成为主节点的从节点的个数满足这个数字且都认为主节点挂了则会进行选举产生新的主节点。

       例如：es集群有三个从节点有资格成为主节点，这时这三个节点都认为主节点挂了则会进行选举，此时如果这个参数的值是4则不会进行选举。

       我们可以适当的把这个值改大，减少出现脑裂的概率，官方给出的建议是(n/2)+1,n为有资格成为主节点的节点数nodemaster=true。

所谓的脑裂，就是指在主从集群中，同时有两个主节点，它们都能接收写请求。而脑裂最直接的影响，就是客户端不知道应该往哪个主节点写入数据，结果就是不同的客户端会往不同的主节点上写入数据。而且，严重的话，脑裂会进一步导致数据丢失。

主库是由于某些原因无法处理请求，也没有响应哨兵的心跳，才被哨兵错误地判断为客观下线的。结果，在被判断下线之后，原主库又重新开始处理请求了，而此时，哨兵还没有完成主从切换，客户端仍然可以和原主库通信，客户端发送的写 *** 作就会在原主库上写入数据了。下图展示了脑裂的发生过程。

Redis 提供了两个配置项来限制主库的请求处理，分别是 min-slaves-to-write 和 min-slaves-max-lag。

这两个配置项组合后的要求是， 主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的请求了 。

假设我们将 min-slaves-to-write 设置为 1，把 min-slaves-max-lag 设置为 12s，把哨兵的 down-after-milliseconds 设置为 10s，主库因为某些原因卡住了 15s，导致哨兵判断主库客观下线，开始进行主从切换。同时，因为原主库卡住了 15s，没有一个从库能和原主库在 12s 内进行数据复制，原主库也无法接收客户端请求了。这样一来，主从切换完成后，也只有新主库能接收请求，不会发生脑裂，也就不会发生数据丢失的问题了。

主从数据不一致，就是指客户端从从库中读取到的值和主库中的最新值并不一致。举个例子，假设主从库之前保存的用户年龄值是 19，但是主库接收到了修改命令，已经把这个数据更新为 20 了，但是，从库中的值仍然是 19。那么，如果客户端从从库中读取用户年龄值，就会读到旧值。

出现主从数据不一致的主要原因是 主从库间的命令复制是异步进行的。 从库会滞后执行数据同步命令的原因主要有两个

应对主从数据不一致的解决方案：

我们可以开发一个监控程序，先用 INFO replication 命令查到主、从库的进度，然后，我们用 master_repl_offset 减去 slave_repl_offset，这样就能得到从库和主库间的复制进度差值了。 如果某个从库的进度差值大于我们预设的阈值，我们可以让客户端不再和这个从库连接进行数据读取，这样就可以减少读到不一致数据的情况 。不过，为了避免出现客户端和所有从库都不能连接的情况，我们需要把复制进度差值的阈值设置得大一些。可以周期性地运行这个流程来监测主从库间的不一致情况。

Redis 同时使用了两种策略来删除过期的数据，分别是 惰性删除策略和定期删除策略 。关于删除策略可以参考： >