Redis集群脑裂导致数据丢失问题处理

什么是Redis的集群脑裂：

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

脑裂现象发生原因：

网络问题：导致Redis Master节点跟Redis Slave节点和哨兵Sentinel集群处于不同的网络分区，此时因为Sentinel集群无法感知到master的存在，所以将Slave节点提升为Master节点。此时就存在两个不同的Master节点，就像一个大脑分裂成了两个。

主机资源问题：redis Master节点所在的服务器上的其他程序临时占用了大量资源（例如 CPU 资源），导致主库资源使用受限，短时间内无法响应心跳，于是Sentinel集群重新选举了新的Master，当其它程序不再使用资源时，旧Master节点又恢复正常，同一集群下出现两个Master。

Redis 主节点阻塞：主库自身遇到了阻塞的情况，例如，处理 bigkey 或是发生内存 swap，短时间内无法响应心跳，还是会触发Sentinel机制，等主库阻塞解除后，又恢复正常的请求处理了。

step1：在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。如果主节点A的网络突然发生问题，与所有的从节点都失联，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据，此时这些数据被旧主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。

step2：这时，哨兵也发现主节点失联，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在「从节点」中选举出一个 leeder 作为主节点，这时集群就有两个主节点了 —— 脑裂出现了。

step3：然后，网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题。

脑裂问题处理

在redis的配置文件中有两个参数我们可以设置：

min-slaves-to-write  N min-slaves-max-lag N

min-slaves-to-write默认配置为0，这个配置表示master至少有N个slave节点才进行工作。当出现Redis集群脑裂时，其中一个出问题的master此时就少于N的slave连接，此master就拒绝写请求。

min-slaves-max-lag默认配置为10，这个配置表示slave和master之间只能落后N ms的数据。超过了该值就拒绝写请求，就不会往master中写入数据。

假设从库有K个，可将：

min-slaves-to-write设置为K/2+1（如果K等于1，就设为1）
min-slaves-max-lag设置为十几秒（例如10～20s）

这个配置下，如果有一半以上的从库和主库进行的ACK消息延迟超过十几s，我们就禁止主库接收客户端写请求。

这样一来，我们可以避免脑裂带来数据丢失的情况，而且，也不会因为只有少数几个从库因为网络阻塞连不上主库，就禁止主库接收请求，增加了系统的鲁棒性。