脑裂：在主从集群中，同时有两个主节点他们都能接收写请求。而脑裂最直接影响的就是客户端不知道往哪个主节点写入数据，结果就是不同的客户端往不同的主节点写入数据。而且严重的会导致数据丢失。
为什么会发生脑裂？
1.确认是不是数据同步出了问题：主库的数据还未同步到从库，结果主库发生了故障，等到从库升级为主库后，未同步的数据就发生了缺失。
这种情况我们可以通过计算master_repl_offset和slave_repl_offset的差值，如果大于0就可以认定为是由于数据同步未完成导致的。
2.排查客户端的操作日志，发生脑裂现象
在排查操作日志时，我们发现在主从切换的过程中仍然有一个客户端和原主库通信，并没有和新升级的主库进行交互。这相当于主从集群中同时有两个主库。但是按道理来说，不同的客户端给两个主库发送数据写操作，只会导致新数据会分配到不同的数据库上，不会导致数据丢失。
为什么脑裂会导致数据丢失？
主从切换后，从库一旦升级为新主库，哨兵就会让原主库执行slave of命令，和新主库进行全量同步，而在全量同步的最后阶段，原数据库需要清空本地信息，加载新主库发送的RDB文件，这样原主库在数据同步后数据就丢失了。
如何应对脑裂？
既然问题出现在原主库发生故障后仍然能接收请求上，我们就开始在主从集群机制的配置项中查找是否有限制主库接收请求的设置。
redis提供了两个配置项来限制主库的请求处理，分别是min-slaves-to-write 和 min-slaves-max-lag
min-slaves-to-write：这个配置项设置了主库能进行数据同步的最少从库数量
min-slaves-max-lag：这个配置项设置了主从库间进行数据复制时，从库给主库发送的ACK消息的最大延迟。
有了这两个配置就可以轻松解决脑裂问题了，首先既然原主库是假故障，它在假故障期间是无法响应哨兵心跳的，也不能和从库进行同步，自然也就无法和从库进行 ACK 确认了。这样一来，min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，原主库就会被限制接收客户端请求，客户端也就不能在原主库中写入新数据了。等到新主库上线时，就只有新主库能接收和处理客户端请求，此时，新写的数据会被直接写到新主库中。而原主库会被哨兵降为从库，即使它的数据被清空了，也不会有新数据丢失。