Redis重新选举导致数据丢失问题分析

一、数据丢失的情况

1. 异步复制同步丢失
2. 集群产生脑裂数据丢失

1、异步复制丢失

对于Redis主节点与从节点之间的数据复制，是异步复制的，当客户端发送写请求给master节点的时候，客户端会返回OK，然后同步到各个slave节点中。

如果此时master还没来得及同步给slave节点时发生宕机，那么master内存中的数据会丢失；

要是master中开启持久化设置数据可不可以保证不丢失呢？答案是否定的。在master 发生宕机后，sentinel集群检测到master发生故障，重新选举新的master，如果旧的master在故障恢复后重启，那么此时它需要同步新master的数据，此时新的master的数据是空的（假设这段时间中没有数据写入）。那么旧master中的数据就会被刷新掉，此时数据还是会丢失。

2、集群产生脑裂

首先我们需要理解集群的脑裂现象，这就好比一个人有两个大脑，那么到底受谁来控制呢？在分布式集群中，分布式协作框架zookeeper很好的解决了这个问题，通过控制半数以上的机器来解决。

那么在Redis中，集群脑裂产生数据丢失的现象是怎么样的呢？

假设我们有一个redis集群，正常情况下client会向master发送请求，然后同步到salve，sentinel集群监控着集群，在集群发生故障时进行自动故障转移。

此时，由于某种原因，比如网络原因，集群出现了分区，master与slave节点之间断开了联系，sentinel监控到一段时间没有联系认为master故障，然后重新选举，将slave切换为新的master。但是master可能并没有发生故障，只是网络产生分区，此时client任然在旧的master上写数据，而新的master中没有数据，如果不及时发现问题进行处理可能旧的master中堆积大量数据。在发现问题之后，旧的master降为slave同步新的master数据，那么之前的数据被刷新掉，大量数据丢失。

在了解了上面的两种数据丢失场景后，我们如何保证数据可以不丢失呢？在分布式系统中，衡量一个系统的可用性，我们一般情况下会说4个9,5个9的系统达到了高可用（99.99%，99.999%，据说淘宝是5个9）。对于redis集群，我们不可能保证数据完全不丢失，只能做到使得尽量少的数据丢失。

二、如何保证尽量少的数据丢失？

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

min-slaves-to-write 1
min-slaves-max-lag 10

min-slaves-to-write默认情况下是0，min-slaves-max-lag默认情况下是10。
以上面配置为例，这两个参数表示至少有1个salve的与master的同步复制延迟不能超过10s，一旦所有的slave复制和同步的延迟达到了10s，那么此时master就不会接受任何请求。

我们可以减小min-slaves-max-lag参数的值，这样就可以避免在发生故障时大量的数据丢失，一旦发现延迟超过了该值就不会往master中写入数据。

那么对于client，我们可以采取降级措施，将数据暂时写入本地缓存和磁盘中，在一段时间后重新写入master来保证数据不丢失；也可以将数据写入kafka消息队列，隔一段时间去消费kafka中的数据。

通过上面两个参数的设置我们尽可能的减少数据的丢失，具体的值还需要在特定的环境下进行测试设置。