Redis数据丢失问题

主备切换的过程中( 异步复制，脑裂 )，可能会导致数据丢失

因为 master ->slave的复制是异步 的（客户端发送给redis，主节点数据同步到内存中后就返回成功了）

所以可能有部分数据还没复制到slave，master就宕机了，此时master内存中的数据也没了，这些部分数据就丢失了。

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着（这种分布式中间件脑裂是常规 *** 作,类似的，比如 rabiitmq脑裂 ）

此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master

这个时候，集群里就会有两个master，也就是所谓的脑裂

此时虽然某个slave被切换成了master，但是可能client还没来得及切换游贺到新的master，还继续写向旧master的数据，然后旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据，就导致了我们之前在脑裂时候向旧master写的数据全部都丢失了。

解决以上两种情况redis数据丢失的问题 都是靠 以下两个参数配置将数据损失降到最低。

min-slaves-to-write x

min-slaves-max-lag y

(要求y秒内至少有x个slave同步接收到这个数据,比如x=1，y=10)

有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数简肢据和ack延时太长，就 认为 可能master宕机后 损失 的数据 太多 了，那么就 拒绝 新的 写 请求，这样可以把master 宕机时 由于部分数据未同步到slave导致的数据丢失的损失 降低的可控范围内 ，但是 仅有一个从库要谨慎设置1,只有一个从库且要去维护的时候,请先设置 最少写从库的个数为0,再去维护从库

如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求

这样脑裂后的 旧master就不拦磨世会接受client的新数据 ，也就避免了更多的数据丢失

上面的配置就确保了，如果跟任何一个slave（配置的x为所有从结点的数量）丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求

大致总结一下redis丢失键值的情况一般为以下几种情况：

1. 是否有大量过期key被清理

分析：

原因：这种情况并不是真正的“丢失”键值，只是达到了设置的key的过期值

应对方案：根据项目情况设芦尺敏置合理的键值过期时间，或者设置为不过期，对不使用的key进行删除

2. 是否maxmemory不足导致redis自动清理部分key以节省空间

分析：

原因：redis内存使用达到设置的可用内存的上限，redis自动清理部分key已节省空间给新的key使用

应对方案：适当的调大maxmemory

3. 主库故障后自动重启

分析：

原因：主库由于某种原因挂掉，但是在redis哨兵发现并启动切换之前被监控程序重启，如果主库有完整的备份策略，则丢失重启之前的一小段时间的数据，如果主库为了性能没有设置备份策略，则可能重启之后成为一个空的库，一段时间后，从库发现主库的runid发生变化，自动同陪枝步主库，导致数据丢失严重

应对方案：

4. 网络分区的问题，可能导致短时间的写入数据丢失

分析：

原因：网络不稳定导致的短时写入失败或触发哨兵的自动切换（单独的主备方案触发切换期间会有数据丢失）

应对方案：保障网络环境稳定可达

ps：故障的排查更多的靠监控的精细度，如困历内存使用百分比的监控，对删除命令的监控，过期key的数量监控，slowlog的监控（大量key的查找和删除会被记录）等等

---