Redis是大厂核心，下面我详解Redis内存突然暴涨？大厂如何排查@mikechen
第一层：确认是否有发布或变更
优先检查最近 30 分钟到 24 小时内是否有：
- 应用发布；
- 配置变更；
- 定时任务变更；
- Redis 参数变更；
- 数据结构升级；
很多内存问题都与变更强相关，尤其是新版本引入了缓存粒度变细、key 数量暴涨、TTL 取消等问题。
第二层：看监控曲线
要同时看：
- 内存曲线；
- QPS 曲线；
- 写命令比例；
- key 数量变化；
- 过期和淘汰数量；
- 慢查询和阻塞情况；
因此，首先要看几个核心指标：
| 指标 | 含义 | 常见判断 |
|---|---|---|
used_memory |
Redis 分配器已使用内存 | 是否实际持续增长 |
used_memory_rss |
OS 实际驻留内存 | 明显高于 used_memory 时，可能是碎片、写时复制或内存未归还 |
mem_fragmentation_ratio |
RSS / Redis 使用内存 | 长期明显大于 1.5 需关注碎片；突发升高还要排查 fork/COW |
used_memory_dataset |
数据集本体内存 | 数据本身变大，通常是新写入、大 Key、TTL 失效 |
used_memory_overhead |
元数据、客户端、复制缓冲等开销 | 连接/缓冲区/过期字典等非数据部分异常 |
mem_clients_normal |
普通客户端缓冲区内存 | 高说明客户端读慢或连接堆积 |
mem_clients_slaves |
副本客户端缓冲区内存 | 高说明副本延迟、全量同步或复制链路问题 |
evicted_keys |
被驱逐 Key 数 | 增长说明已触及 maxmemory 并开始牺牲缓存 |
expired_keys |
过期 Key 数 | TTL 是否在正常工作 |
total_connections_received |
累计连接数 | 突增常见于连接泄漏、连接池失效或流量异常 |
如果 used_memory 持续上涨，说明确实有数据增长；
如果 used_memory 平稳但 rss 飙升，则更可能是内存碎片或进程层面的峰值问题。
第三层：抽样分析 key
在不影响线上稳定性的前提下，抽样查看：
- 大 key；
- 热 key；
- 同前缀 key 数量；
- value 类型分布；
大厂会特别关注“结构性问题”，例如：
- hash 里字段数过多
- set 中元素无限增长
- list 作为消息队列却未消费完
- zset 排行榜长期不裁剪
这些问题表面上是 Redis 内存问题，本质上是业务模型设计问题。
第四层：应急处理：先止血，再优化
当内存已经逼近上限，必须先止血。
可采取的应急手段包括：
- 临时限流写入流量
- 下线异常任务或异常版本
- 调整 TTL，减少新写入压力
- 删除明显异常的大 key
- 扩容 Redis 实例或迁移集群
- 必要时重启实例，缓解碎片问题
但删除 key 要非常谨慎，不能只看大就删，必须确认业务可恢复性，否则可能引发更大范围故障。
总之，大厂的排查方式，核心不是“盯住一个指标”，而是通过监控、发布、日志、key 分布和配置五位一体地定位根因。
只有做到先判断现象、再锁定范围、最后验证假设，才能在最短时间内完成止血，并从根本上避免同类问题再次发生。