Redis内存暴涨导致服务雪崩的排查与解决

问题现象

凌晨三点，告警声像闹钟一样准时响起。Redis 集群里某个节点，内存使用率从 45% 一路飙升到 95%，几乎涨了一倍。紧接着，多个核心服务的请求开始大面积超时——P99 从原本的 5ms 直接跳到 3000ms 以上。用户侧那边，反馈已经炸了：页面打不开、登录失败……一句话，典型的雪崩前兆。

• 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 检测”脚本

复盘总结

快速复盘一下，这次事故其实给我们敲了三记警钟：

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