Redis OOM 问题排查

背景

多个服务同时出现latency SEV2问题，这些服务都依赖远程缓存Redis存储的数据，而且Redis硬盘使用率也出现报警，经过排查发现Redis有4台host停止对外服务，另外其中一个node变成1主11从配置，而非默认的1主4从。

客户影响

1. 大概有0.1%的traffic在30min超过latency阈值，会导致上游服务部分请求超时。
2. 一个节点大部分数据丢失，会增加部分访问的latency。

分析&结论

1. 由于Redis的一台host出现问题，被健康检测系统用新的host（M5）替换，其连接到Master（M1）之后，触发M1的BGSAVE，但M5同步数据失败，不过由于配置原因(replica-serve-stale-data 为true)，其仍然可以对外提供服务，不过由于其没有完成数据同步，所以无有效数据可以读取，所以traffic会穿透到Sable，从而导致latency增加。
2. 同时这些traffic会触发大量写M1操作，引发大量AOF操作，导致内存使用增加，之后被OOM killer杀掉，多次反复此过程，从而导致内存波动，但由于硬盘数据未清理，故硬盘使用量持续增加，之后进行RDB操作，导致硬盘使用量快速增加，引发RDB进程反复重试报错，但这段时间由于没有AOF操作，所以内存并无变化，之后硬盘被服务器清理后，AOF开始工作，内存开始急剧降低，内存过低引发master连接超时。
3. 由于cluster-node-timeo