Redis 内存暴涨导致服务雪崩------技术复盘
问题现象
线上突然收到一连串告警：
- Redis Cluster 某节点内存使用率从 45% 飙到 95%
- 多个核心服务的 Redis 请求大量超时（P99 从 5ms → 3000ms+）
- 用户侧反馈"页面打不开"、"登录失败"
排查过程
| 步骤 | 操作 | 发现 |
|---|---|---|
| 1 | redis-cli INFO memory | used_memory_rss 从 12GB 跳到了 28GB |
| 2 | MEMORY STATS | volatile-ttl 类内存占比极低，说明大部分 key 没有设置过期时间 |
| 3 | SLOWLOG GET 100 | 大量 KEYS session 和 HGETALL 大 key 操作 |
| 4 | INFO keyspace | 某个 db 里 key 数量 8000万+，几乎是上周的 10 倍 |
| 5 | 查发布记录 | 3 天前新上线了一个功能，把用户 session 缓存到了 Redis |
罪魁祸首浮出水面：新上线的 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 预留缓冲
长期加固
- Redis 使用规范加入 deploy checklist：所有 cache key 必须设置 TTL，否则 CR 拒绝
- 新增监控：keyspace 每分钟 key 数量增长率，超过 5%/min 触发告警
- maxmemory-policy 从 noeviction 改为 allkeys-lru，极端情况自动淘汰而非拒绝写入
- 集成测试增加"无 TTL key 检测"脚本
复盘总结
Redis 的内存问题极少来自一个"超级大 key"，更多是"千万个小 key 的沉默堆积"。
三个核心教训：
- 缓存的本质是"临时" ------ 不设 TTL 的缓存不是缓存，是定时炸弹
- 监控要盯增长趋势，而不只是绝对值：80M key 不是一秒爆的，是 3 天慢慢涨上去的，早该发现
- maxmemory-policy noeviction 在生产环境极其危险，除非你对每条数据都精确控制了容量，否则请用 allkeys-lru 或 volatile-lru
坚持每天一个知识点，365 天就是 365 次成长
#Redis #技术复盘 #内存泄漏 #后端 #中间件 #故障排查