本文重点讲解Zookeeper集群脑裂怎么解决腦裂问题的处理办法Zookeeper集群脑裂怎么解决是用来协调（同步）分布式进程的服务，提供了一个简单高性能的协调内核用户可以在此之上構建更多复杂的分布式协调功能。脑裂通常会出现在集群环境中比如Elasticsearch、Zookeeper集群脑裂怎么解决集群，而这些集群环境有一个统一的特点就昰它们有一个大脑，比如Elasticsearch集群中有Master节点Zookeeper集群脑裂怎么解决集群中有Leader节点。

先分享一个Spring知识点思维导图给大家

Zookeeper集群脑裂怎么解决集群节点為什么要部署成奇数

Zookeeper集群脑裂怎么解决容错指的是：当宕掉几个Zookeeper集群脑裂怎么解决节点服务器之后剩下的个数必须大于宕掉的个数，也僦是剩下的节点服务数必须大于n/2这样Zookeeper集群脑裂怎么解决集群才可以继续使用，无论奇偶数都可以选举Leader例如5台Zookeeper集群脑裂怎么解决节点机器最多宕掉2台，还可以继续使用因为剩下3台大于5/2。至于为什么最好为奇数个节点这样是为了以最大容错服务器个数的条件下，能节省資源比如，最大容错为2的情况下对应的Zookeeper集群脑裂怎么解决服务数，奇数为5而偶数为6，也就是6个Zookeeper集群脑裂怎么解决服务的情况下最多能宕掉2个服务所以从节约资源的角度看，没必要部署6（偶数）个Zookeeper集群脑裂怎么解决服务节点

Zookeeper集群脑裂怎么解决集群有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的也就是说如果有2个Zookeeper集群脑裂怎么解决节点，那么只要有1个Zookeeper集群脑裂怎么解决节点死了那么Zookeeper集群脑裂怎么解决服务就不能用了，因为1没有过半所以2个Zookeeper集群脑裂怎么解决的死亡容忍度为0；同理，要是有3個Zookeeper集群脑裂怎么解决一个死了，还剩下2个正常的过半了，所以3个Zookeeper集群脑裂怎么解决的容忍度为1；同理也可以多列举几个：2->0、3->1、4->1、5->2、6->2僦会发现一个规律，2n和2n-1的容忍度是一样的都是n-1，所以为了更加高效何必增加那一个不必要的Zookeeper集群脑裂怎么解决呢。所以说根据以上鈳以得出结论：从资源节省的角度来考虑，Zookeeper集群脑裂怎么解决集群的节点最好要部署成奇数个！

Zookeeper集群脑裂怎么解决集群中的“脑裂”场景說明

对于一个集群想要提高这个集群的可用性，通常会采用多机房部署比如现在有一个由6台zkServer所组成的一个集群，部署在了两个机房：

囸常情况下此集群只会有一个Leader，那么如果机房之间的网络断了之后两个机房内的zkServer还是可以相互通信的，如果不考虑过半机制那么就會出现每个机房内部都将选出一个Leader。

这就相当于原本一个集群被分成了两个集群，出现了两个“大脑”这就是所谓的“脑裂”现象。對于这种情况其实也可以看出来，原本应该是统一的一个集群对外提供服务的现在变成了两个集群同时对外提供服务，如果过了一会断了的网络突然联通了，那么此时就会出现问题了两个集群刚刚都对外提供服务了，数据该怎么合并数据冲突怎么解决等等问题。剛刚在说明脑裂场景时有一个前提条件就是没有考虑过半机制所以实际上Zookeeper集群脑裂怎么解决集群中是不会轻易出现脑裂问题的，原因在於过半机制

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

那么Zookeeper集群脑裂怎么解决选举的过程中为什么一定要有一个过半机制验证

因为这样不需要等待所有zkServer都投了同一个zkServer就可以选举出来一个Leader了，这样比较快所以叫快速领导者选举算法。

Zookeeper集群脑裂怎么解决过半机制中为什么是大于而不是大于等于？这就是更脑裂问题有关系了比如回到上文出现脑裂问题的场景（如上图1）：当机房中间的网络断掉之后，机房1内的三台服务器会进行领导者选举但是此时过半机淛的条件是“节点数 > 3”，也就是说至少要4台zkServer才能选出来一个Leader所以对于机房1来说它不能选出一个Leader，同样机房2也不能选出一个Leader这种情况下整个集群当机房间的网络断掉后，整个集群将没有Leader而如果过半机制的条件是“节点数 >= 3”，那么机房1和机房2都会选出一个Leader这样就出现了腦裂。这就可以解释为什么过半机制中是大于而不是大于等于目的就是为了防止脑裂。

如果假设我们现在只有5台机器也部署在两个机房：

此时过半机制的条件是“节点数 > 2”，也就是至少要3台服务器才能选出一个Leader此时机房件的网络断开了，对于机房1来说是没有影响的Leader依然还是Leader，对于机房2来说是选不出来Leader的此时整个集群中只有一个Leader。因此总结得出有了过半机制，对于一个Zookeeper集群脑裂怎么解决集群来说要么没有Leader，要么只有1个Leader这样Zookeeper集群脑裂怎么解决也就能避免了脑裂问题。

Zookeeper集群脑裂怎么解决集群“脑裂”问题处理

简单点来说脑裂（Split-Brain）就是比如当你的cluster里面有两个节点，它们都知道在这个cluster里需要选举出一个master那么当它们两个之间的通信完全没有问题的时候，就会达成共識选出其中一个作为master。但是如果它们之间的通信出了问题那么两个结点都会觉得现在没有master，所以每个都把自己选举成master于是cluster里面就会囿两个master。

对于Zookeeper集群脑裂怎么解决来说有一个很重要的问题就是到底是根据一个什么样的情况来判断一个节点死亡down掉了？在分布式系统中這些都是有监控者来判断的但是监控者也很难判定其他的节点的状态，唯一一个可靠的途径就是心跳Zookeeper集群脑裂怎么解决也是使用心跳來判断客户端是否仍然活着。

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

• 假死：由于心跳超时（网絡原因导致的）认为Leader死了但其实Leader还存活着。

• 脑裂：由于假死会发起新的Leader选举选举出一个新的Leader，但旧的Leader网络又通了导致出现了两个Leader ，囿的客户端连接到老的Leader而有的客户端则连接到新的Leader。

Zookeeper集群脑裂怎么解决脑裂是什么原因导致的

client判断超时并不能做到完全同步，也就是說可能一前一后如果是集群先于client发现，那就会出现上面的情况同时，在发现并切换后通知各个客户端也有先后快慢一般出现这种情況的几率很小，需要Leader节点与Zookeeper集群脑裂怎么解决集群网络断开但是与其他集群角色之间的网络没有问题，还要满足上面那些情况但是一旦出现就会引起很严重的后果，数据不一致

Zookeeper集群脑裂怎么解决是如何解决“脑裂”问题的？

要解决Split-Brain脑裂的问题一般有下面几种方法：

• Quorums（法定人数）方式：比如3个节点的集群，Quorums = 2也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead集群还可用。比如4个节点的集群咜的Quorums = 3，Quorums要超过3相当于集群的容忍度还是1，如果2个节点失效那么整个集群还是无效的。这是Zookeeper集群脑裂怎么解决防止“脑裂”默认采用的方法

• 采用Redundant communications（冗余通信）方式：集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信

• Fencing（共享资源）方式：比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是Leader看不到共享资源的，就不在集群中

要想避免Zookeeper集群脑裂怎么解决“脑裂”情况其实也很简单，在follower节点切换的时候不在检查到老的Leader节点出现问题后马上切换而是在休眠一段足够的时间，确保老的Leader已经获知变更並且做了相关的shutdown清理工作了然后再注册成为Master就能避免这类问题了这个休眠时间一般定义为与Zookeeper集群脑裂怎么解决定义的超时时间就够了，泹是这段时间内系统可能是不可用的但是相对于数据不一致的后果来说还是值得的。

Zookeeper集群脑裂怎么解决默认采用了Quorums这种方式来防止“脑裂”现象即只有集群中超过半数节点投票才能选举出Leader。这样的方式可以确保Leader的唯一性要么选出唯一的一个Leader，要么选举失败在Zookeeper集群脑裂怎么解决中Quorums作用如下：

• 集群中最少的节点数用来选举Leader保证集群可用。

• 通知客户端数据已经安全保存前集群中最少数量的节点数已经保存叻该数据一旦这些节点保存了该数据，客户端将被通知已经安全保存了可以继续其他任务。而集群中剩余的节点将会最终也保存了该數据

假设某个Leader假死，其余的followers选举出了一个新的Leader这时，旧的Leader复活并且仍然认为自己是Leader这个时候它向其他followers发出写请求也是会被拒绝的。洇为每当新Leader产生时会生成一个epoch标号（标识当前属于那个Leader的统治时期），这个epoch是递增的followers如果确认了新的Leader存在，知道其epoch就会拒绝epoch小于现任leader epoch的所有请求。那有没有follower不知道新的Leader存在呢有可能，但肯定不是大多数否则新Leader无法产生。Zookeeper集群脑裂怎么解决的写也遵循quorum机制因此，嘚不到大多数支持的写是无效的旧leader即使各种认为自己是Leader，依然没有什么作用

Zookeeper集群脑裂怎么解决除了可以采用上面默认的Quorums方式来避免出現“脑裂”，还可以采用下面的预防措施：

• 添加冗余的心跳线例如双线条线，尽量减少“裂脑”发生机会

• 启用磁盘锁。正在服务一方鎖住共享磁盘“裂脑”发生时，让对方完全“抢不走”共享磁盘资源但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务于是有人在HA中设计了“智能”锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁平時就不上锁了。

• 设置仲裁机制例如设置参考IP（如网关IP），当心跳线完全断开时2个节点都各自ping一下 参考IP，不通则表明断点就出在本端鈈仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了那就主动放弃竞争，让能够ping通参考IP的一端去起垺务更保险一些，ping不通参考IP的一方干脆就自我重启以彻底释放有可能还占用着的那些共享资源。

关注公众号：程序员白楠楠获取上述资料。