Redis OOM 问题排查

QuZero

已于 2023-02-09 16:43:17 修改

阅读量1k

点赞数

CC 4.0 BY-SA版权

分类专栏：工作总结 java 经验总结文章标签： redis java

于 2023-01-19 17:37:47 首次发布

本文链接：https://blog.youkuaiyun.com/quwenqian/article/details/128736631

本文详细介绍了Redis OOM问题导致的服务延迟和硬盘使用率报警，分析了主从切换过程中的超时异常、节点选举时间、异常主从配置以及内存和磁盘波动情况。通过故障排查，揭示了Redis集群在处理故障时的行为和影响，提供了问题的解决方案和参考链接。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

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

由于Redis的一台host出现问题，被健康检测系统用新的host（M5）替换，其连接到Master（M1）之后，触发M1的BGSAVE，但M5同步数据失败，不过由于配置原因(replica-serve-stale-data 为true)，其仍然可以对外提供服务，不过由于其没有完成数据同步，所以无有效数据可以读取，所以traffic会穿透到Sable，从而导致latency增加。
同时这些traffic会触发大量写M1操作，引发大量AOF操作，导致内存使用增加，之后被OOM killer杀掉，多次反复此过程，从而导致内存波动，但由于硬盘数据未清理，故硬盘使用量持续增加，之后进行RDB操作，导致硬盘使用量快速增加，引发RDB进程反复重试报错，但这段时间由于没有AOF操作，所以内存并无变化，之后硬盘被服务器清理后，AOF开始工作，内存开始急剧降低，内存过低引发master连接超时。
由于cluster-node-timeout配置为15000，故超时15s后，会触发Redis节点的选举操作，大概5s左右完成选举；由于在lettuce client中， DEFAULT_REFRESH_PERIOD被配置为60s，所以在60s内，lettuce client会感知到master的选举结果，换句话就是从Redis server超时，选举到client完成更新大概需要1min20s左右，在此过程中这个节点无法对外提供服务，故引发latency的peak。
由于M5一直未成功从master同步数据，