面试系列之-Redis集群脑裂问题

脑裂

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

脑裂发生的原因

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

脑裂会导致数据丢失的原因

• 主从切换后，从库一旦升级为新主库，哨兵就会让原主库执行slave of命令，和新主库重新进行全量同步。而在全量同步执行的最后阶段，原主库需要清空本地的数据，加载新主库发送的RDB文件，这样一来原主库在主从切换期间保存的新写数据就丢失了；
• 在主从切换的过程中，如果原主库只是“假故障”，它会触发哨兵启动主从切换，一旦等它从假故障中恢复后，又开始处理请求，这样一来，就会和新主库同时存在，形成脑裂。等到哨兵让原主库和新主库做全量同步后，原主库在切换期间保存的数据就丢失了；
• 和主库部署在同一台服务器上的其他程序临时占用了大量资源（例如CPU资源），导致主库资源使用受限，短时间内无法响应心跳，其它程序不再使用资源时，主库又恢复正常；
• 脑裂产生问题的本质原因是，Redis主从集群内部没有通过共识算法，来维护多个节点数据的强一致性。它不像Zookeeper那样，每次写请求必须大多数节点写成功后才认为成功。当脑裂发生时Zookeeper主节点被孤立，此时无法写入大多数节点，写请求会直接返回失败，因此它可以保证集群数据的一致性；

脑裂问题解决方案

两个参数

• min-slaves-to-write：设置主库能进行数据同步的最少从库数量；
• min-slaves-max-lag：设置主从库间进行数据复制时，从库给主库发送ACK消息的最大延迟（以秒为单位）；

min-slaves-to-write和min-slaves-max-lag分别给它们设置一定的阈值，假设为N和T；这两个配置项组合后的要求是，主库连接的从库中至少有N个从库，和主库进行数据复制时的ACK消息延迟不能超过T秒，否则主库就不会再接收客户端的请求了；即使原主库是假故障，它在假故障期间也无法响应哨兵心跳，也不能和从库进行同步，自然也就无法和从库进行ACK确认了；这样min-slaves-to-write和min-slaves-max-lag的组合要求就无法得到满足，原主库就会被限制接收客户端请求，客户端也就不能在原主库中写入新数据了；等到新主库上线时，就只有新主库能接收和处理客户端请求，此时新写的数据会被直接写到新主库中，而原主库会被哨兵降为从库，即使它的数据被清空了，也不会有新数据丢失；