从脑裂问题剖析Nacos&Eureka&Zookeeper架构异同_eureka 脑裂

一、Zookepper简介

1.1 Zookeeper的主从机制

Leader等价于Master，Follower等价于Slaver。集群中的各个节点都会尝试注册为leader节点，其他没有注册成功的则成为follower从节点。

这些follower节点通过watcher观察者监控着leader节点：

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

1.2 脑裂现象的表现

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

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

1.3 为什么会出现脑裂

1. 集群中网络通信不好，导致心跳检测超时--follower认为leader节点由于某种原因挂掉了，可其实leader节点并未真正挂掉，这就是假死现象。

2. leader节点假死后，zookeeper通知所有follower节点进行选举-->某个follower节点升级为新的leader，此时集群中存在2个leader节点。

3. 此时zookeeper需要将新的leader节点的信息通知给所有的follower节点，还要通知到所有的client，而这个过程由于网络等环境的影响，消息到达就会存在快慢之分。

4. 如果部分client获得了新的leader节点的信息，而部分没有获得，而此时client向zookeeper发起读写请求，zookeeper内部的不一致就会导致：部分client连接到了新的leader节点上，而部分client连接到了旧的leader节点上--服务中出现了2个leader，client不知道听谁的好，就像1个大脑被分裂成2个。

1.4 zookeeper如何解决脑裂

ZooKeeper默认采用了Quorums(法定人数)的方式: 只有获得超过半数节点的投票, 才能选举出leader，这种方式可以确保要么选出唯一的leader，要么选举失败。

ZooKeeper中Quorums的作用:

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

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

1.5 zookeeper的具体解决思路

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

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

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

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

二、脑裂问题剖析

对于zookeeper，它是一个主从架构，而像Eureka它是一个点对点的架构，对于脑裂问题，一般都是发生在主从架构，它是怎么发生的呢？比如，现在我们有一个zookeeper集群，它有三个节点，当主节点与其它节点发生了网络故障分区了，正常情况下，主节点与从节点会有数据同步的。

以zookeeper这种cp模式的集群架构来说，cp模式，写数据只能写主节点，从节点只能查数据，假如往从节点写数据，它会帮我们转移到主节点，主节点才提供写，其他节点只能提供读。如果主节点写一条数据，发现网络分区了，主节点数据不能同步到其他从节点，这里面会有一个问题，由于网络不通了，zookeeper集群被分为了两个小的集群，但是，小的集群没有leader了，不能提供写服务了，zookeeper底层会发起一个集群leader选举，这样就会产生两个leader，每个小集群都能接受客户端发来的请求。如果网络恢复了，新的leader是不会动的，旧的leader会同步新的leader的所有数据，那问题就来了，在分区的时候，往久的leader写的数据都会丢失，这就是脑裂。

zookeeper是不会有脑裂问题

它底层实现了ZAB协议，只有半数以上的节点同意，才会写入成功，否则报错。比如，现在我们三个点，那半数以上也就是有两个节点同意。对于新leader刚好两个(算是它自己)，而对于久leader的，就只有一个节点，所以，它是不会写入成功的。

三、根据nacos源码分析

nacos即支持AP模式又支持CP模式，它底层实现了Raft协议，下面从源码来看，它是如何解决脑裂问题的

以上，就是nacos源码，对应的Raft协议的实现，来解决脑裂问题。

参考1，参考2，参考3，参考4