内存告急的处置顺序
内存告急时按顺序处理：先确认影响面与错误形态（写被拒、还是淘汰加剧），再按内存构成定位增长源（客户端缓冲、大键、写入暴增、复制缓冲），然后止血（限流、清理可再生成的数据、处理异常连接），最后才谈扩容与结构优化。顺序颠倒容易在没看清原因时就把现场破坏掉。
基本信息
| 第一步 | 确认影响面：读写可用性、错误形态、受影响的业务 |
|---|---|
| 第二步 | 按内存构成定位增长源 |
| 第三步 | 止血：限流、清理可再生成数据、处理异常客户端 |
| 第四步 | 扩容或结构优化，并留下时间线记录 |
| 原则 | 止血动作要可回退、可评估数据影响 |
内存构成排查点
| 占用来源 | 查看方式 | 典型表现 |
|---|---|---|
| 数据集本身 | INFO memory 的 used_memory_dataset | 随写入量线性增长 |
| 客户端缓冲 | CLIENT LIST 的缓冲字段 | 少数连接占用明显突出 |
| 复制缓冲 | CLIENT LIST 中复制连接的缓冲字段 | 从库重连或大批量写入时突增 |
| 内存碎片 | mem_fragmentation_ratio | rss 明显高于 used_memory |
| 大键 | MEMORY USAGE 与 --bigkeys | 单个键占用异常突出 |
取证命令
取证命令
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_dataset|mem_fragmentation_ratio'
redis-cli MEMORY DOCTOR
redis-cli CLIENT LIST | head -10 # 找出占用突出的连接
redis-cli --bigkeys # 找异常大的键
redis-cli INFO replication # 复制侧是否在堆积缓冲典型使用场景
- 生产内存告警：先降影响再找原因
- 写入被拒的紧急响应：确认是硬上限还是策略配置问题
- 大促前巡检：提前确认水位与可再生成数据的清理路径
- 复盘准备：记录每一步动作与当时的指标
- 容器触顶：内存上限由运行时控制时的处置差异
止血动作（清理键、断开连接）会直接影响业务与数据；执行前确认这些数据是否可再生成，并把动作与时间记录下来供复盘。
如果实例内存只是略高于可用物理内存，可以先导出或迁移一部分可再生成的数据，而不是立即重启；重启会丢失未持久化的写入。