所谓脑裂，就如同它的名字一样，大脑裂开了，一般来说是指一个分布式系统中有两个子集，然后每个子集都有一个自己的大脑（Leader/Master）。那么整个分布式系统就会存在多个大脑了，而且每个都认为自己是正常的，这就会导致数据不一致或重复写入的问题。

在Redis集群中，每个节点的部署方式一般都是【一主多从】，主节点提供写操作，从节点提供读操作。如果主节点此时发生网络故障，与从节点断开连接了，但主节点与客户端是正常的，客户端依旧向主节点写入数据。

这时哨兵节点发现主节点有故障失联了，于是哨兵节点就会从 从节点选出一个leader作为新主节点，这时脑裂就出现了。

突然这时原主节点网络好了，然而此时故障转移已完毕，已经有新主节点了，那么原主节点就会降级为新主节点的从节点，新主节点会向所有实例发送slave of命令，让所有实例重新全量同步，在全量同步之前，从节点会先清空自己的数据，那么客户端在原主节点故障期间写入的数据就丢失了。

Redis的脑裂问题可能发生在网络分区或者主节点出现问题的时候：

从上面图中可以清楚地看到脑裂的危害，这里再总结一下：

脑裂的主要原因其实就是哨兵集群认为主节点出现"假故障"了，于是开始主从切换，选举出了新的主节点，这就导致短暂的出现了两个主节点。

所以应对脑裂的解决办法应该是取限制原主库接收请求，Redis提供了两个配置项（已翻译）： 

再解释下：

这两项必须同时满足，不然主节点会禁止写入操作，这就解决了因脑裂导致数据丢失的问题。

举个例子，我们把min-slaves-to-write设置为1，把min-slaves-max-lag设置为10。

如果Master节点因为某些原因挂了12s，导致哨兵判断主节点客观下线，开始主从切换。

同时，因为原Master宕机了12s，没有一个（min-slaves-to-write）从节点与主节点之间的数据复制在10s（min-slaves-max-lag）内，不满足配置要求，原Master就无法执行写操作了。

我们来看一个场景：

我们把min-slaves-to-write设置为1，把min-slaves-max-lag设置为10，同时把down-after-milliseconds设置为8s，也就是如果8秒连不上主节点，哨兵就会进行主从切换。

假设Matser节点宕机8s，哨兵会判为客观下线，开始主从切换，但是这个过程一共需要5秒。那如果主从切换过程中，主节点在第9秒恢复运行了，而min-slaves-max-lag 10s那么主节点还是可以写的。

那么在9s~12秒期间原主节点还是可以接收客户端传的写命令并且执行，新主节点执行slave of命令后，这个期间写的数据就会丢失。

所以Redis脑裂可以采用min-slaves-to-write和min-slaves-max-lag合理配置尽量规避，但无法彻底解决。

End：希望对大家有所帮助，如果有纰漏或者更好的想法，请您一定不要吝啬你的赐教🙋。