Redis内存暴涨导致服务雪崩的问题解决

问题现象

线上突然收到一连串告警：

• Redis Cluster 某节点内存使用率从 45% 飙到 95%
• 多个核心服务的 Redis 请求大量超时（P99 从 5ms → 3000ms+）
• 用户侧反馈"页面打不开"、“登录失败”

排查过程

罪魁祸首浮出水面：新上线的 session 缓存逻辑。

根因

新功能的伪代码：

redis.set("session:" + userId, sessionData)

忘了写 EX（过期时间）。

加上当天正好有一波运营活动流量，短短 3 天积累了近 8000 万个永久有效的 session key。Redis 的 maxmemory-policy 配置的是 noeviction（不淘汰），内存满了之后直接拒绝所有写请求 → 连锁反应导致读也阻塞 → 服务超时 → 雪崩。

一句话总结：忘记设置 TTL 的缓存 = 内存泄露炸弹。

解决方案

止血（5分钟内）

• Lua 脚本批量扫描 session key，对 idletime > 1800 的 key 执行 UNLINK 异步删除
• 内存迅速回落至 55%

短期修复（当天）

• 紧急 hotfix：所有 session 写入加上 EX 3600（1小时 TTL）
• 临时调大 maxmemory 预留缓冲

长期加固

1. Redis 使用规范加入 deploy checklist：所有 cache key 必须设置 TTL，否则 CR 拒绝
2. 新增监控：keyspace 每分钟 key 数量增长率，超过 5%/min 触发告警
3. maxmemory-policy 从 noeviction 改为 allkeys-lru，极端情况自动淘汰而非拒绝写入
4. 集成测试增加"无 TTL key 检测"脚本

复盘总结

Redis 的内存问题极少来自一个"超级大 key"，更多是"千万个小 key 的沉默堆积"。

三个核心教训：

1. 缓存的本质是"临时" —— 不设 TTL 的缓存不是缓存，是定时炸弹
2. 监控要盯增长趋势，而不只是绝对值：80M key 不是一秒爆的，是 3 天慢慢涨上去的，早该发现
3. maxmemory-policy noeviction 在生产环境极其危险，除非你对每条数据都精确控制了容量，否则请用 allkeys-lru 或 volatile-lru

到此这篇关于Redis内存暴涨导致服务雪崩的问题解决的文章就介绍到这了,更多相关Redis内存暴涨导致雪崩内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论