Redis集群模式下的脑裂问题及如何解决

Redis脑裂现象

什么是Redis的脑裂现象

当Redis主从集群环境出现两个主节点为客户端提供服务，这时客户端请求命令可能会发生数据丢失的情况。

脑裂出现的场景

场景一

主从哨兵集群中如果当发生主从集群切换时，那么一定是超过预设quorum数量的哨兵和主库连接超时了，这时哨兵集群才会将主库判断为主观下线，然后哨兵开始选举新的主节点，进行故障转移，转移完毕后客户端和新的主节点通信恢复正常请求。

如果在哨兵进行选举，故障转移的过程中原主节点恢复和客户端的通信，那么证明原主节点没有真正的故障，这时客户端依旧可以向原主节点正常通信，这就是脑裂产生的第一个场景，示意图如下

假故障：

1、同服务器其它进程占用大量CPU资源，导致主节点短时间无法响应心跳，CPU资源空闲后恢复正常。

2、主库自身阻塞，如处理bigkey或者发生内存swap时，短时间无法响应心跳，阻塞解决后心跳恢复正常。

真故障：

1、服务器宕机。

2、实例进程挂了。

场景二 

网络分区，主节点和客户端，哨兵和从库分割为了两个网络，主库和客户端处在一个网络中，从库和哨兵在另外一个网络中，此时哨兵也会发起主从切换，出现两个主节点的情况。

脑裂带来的影响 

脑裂出现后带来最严重的后果就是数据丢失，为什么会出现数据丢失的问题呢，主要原因是新主库确定后会向所有的实例发送slave of命令，让所有实例重新进行全量同步，而全量同步首先就会将实例上的数据先清空，所以在主从同步期间在原主库执行的命令将会被清空（上面场景二是同样的道理，在网络分区恢复后原主节点将被降级为从节点，并且执行全量同步导致数据丢失），所以这就是数据丢失的具体原因。

如何应对脑裂 

脑裂的主要原因其实就是哨兵集群认为主节点已经出现故障了，重新选举其它从节点作为主节点，而原主节点其实是假故障，从而导致短暂的出现两个主节点，那么在主从切换期间客户端一旦给原主节点发送命令，就会造成数据丢失。

所以应对脑裂的解决办法应该是去限制原主库接收请求，Redis提供了两个配置项。

• min-slaves-to-write：与主节点通信的从节点数量必须大于等于该值主节点，否则主节点拒绝写入。

• min-slaves-max-lag：主节点与从节点通信的ACK消息延迟必须小于该值，否则主节点拒绝写入。

这两个配置项必须同时满足，不然主节点拒绝写入。

在假故障期间满足min-slaves-to-write和min-slaves-max-lag的要求，那么主节点就会被禁止写入，脑裂造成的数据丢失情况自然也就解决了。

解决脑裂出现的问题

添加冗余的心跳线，尽量减少“脑裂”的机会

启用磁盘锁：在发生脑裂的时候可以协调控制对资源的访问设置仲裁机制

实际的生产环境中，我们可以从以下几个方面来防止裂脑的发生：

1. 同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个线路还是好的，依然能传送消息（推荐的）

2. 检测到裂脑的时候强行的关闭一个心跳节点（需要特殊的节点支持，如stonith，fence），相当于程序上备节点发现心跳线故障，发送关机命令到主节点。

3. 多节点集群中，可以通过增加仲裁的机制，确定谁该获得资源，这里面有几个参考的思路：

   1. 增加一个仲裁机制。例如设置参考的IP，当心跳完全断开的时候，2个节点各自都ping一下参考的IP，不同则表明断点就出现在本段，这样就主动放弃竞争，让能够ping通参考IP的一端去接管服务。

   2. 通过第三方软件仲裁谁该获得资源，这个在阿里有类似的软件应用

4. 做好对裂脑的监控报警（如邮件以及手机短信等），在问题发生的时候能够人为的介入到仲裁，降低损失。当然，在实施高可用方案的时候，要根据业务的实际需求确定是否能够容忍这样的损失。对于一般的网站业务，这个损失是可控的（公司使用）

5. 启用磁盘锁。正在服务一方锁住共享磁盘，脑裂发生的时候，让对方完全抢不走共享的磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的乙方不主动解锁，另一方就永远得不到共享磁盘。现实中介入服务节点突然死机或者崩溃，另一方就永远不可能执行解锁命令。后备节点也就截关不了共享的资源和应用服务。于是有人在HA中涉及了“智能”锁，正在服务的一方只在发现心跳线全部断开时才启用磁盘锁，平时就不上锁了

总结梳理解决方案

如何解决脑裂

设置每个master限制slave的数量

redis的配置文件中，存在两个参数

min-slaves-to-write 3

min-slaves-max-lag 1

• 第一个参数表示连接到master的最少slave数量

• 第二个参数表示slave连接到master的最大延迟时间

按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。

注意：较新版本的redis.conf文件中的参数变成了

min-replicas-to-write 3

min-replicas-max-lag 10

 redis中的异步复制情况下的数据丢失问题也能使用这两个参数

总结

官方文档所言，redis并不能保证强一致性（Redis Cluster is not able to guarantee strong consistency. / In general Redis + Sentinel as a whole are a an eventually consistent system) 对于要求强一致性的应用，更应该倾向于相信RDBMS(传统关系型数据库）。