Redis 内存告警运行手册：从 INFO memory 到淘汰策略和临时止血

Redis 内存告警不要第一时间只盯着“扩容”。更稳的处理方式是先确认告警是否真实、判断增长来源，再决定临时止血还是调整策略。否则很容易在高峰期误删热点数据，或者把一个大 key 问题误判成容量不足。

这篇文章按运维运行手册写：从触发信号开始，给出快速判断命令、处理步骤、回滚路径、告警确认和复盘项，适合值班时直接照着走。

触发信号：什么时候进入 Redis 内存告警流程

建议把 Redis 内存告警拆成三类信号，避免所有情况都按“内存满了”处理：

• 容量信号：used_memory 接近实例上限，或者云监控显示内存使用率超过阈值。
• 淘汰信号：evicted_keys 持续增长，说明 Redis 已经开始主动淘汰 key。
• 业务信号：接口延迟升高、缓存命中率下降、写入失败或热 key 访问异常。

处理流程可以先固定成一张值班图：先确认告警，再判断增长来源，之后才做策略调整或业务降载。

快速判断：先看 INFO memory 和策略配置

值班时先拿三组信息，不要直接改配置：

redis-cli -h 127.0.0.1 -p 6379 INFO memory
redis-cli -h 127.0.0.1 -p 6379 INFO stats
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET maxmemory
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET maxmemory-policy

重点看这些字段：

• used_memory_human：当前 Redis 已使用内存。
• used_memory_peak_human：历史峰值，判断是否是短时突增。
• mem_fragmentation_ratio：碎片率过高时，内存看起来会比数据体积更紧张。
• evicted_keys：如果持续增长，说明已经触发淘汰。
• maxmemory 和 maxmemory-policy：确认是否有上限以及用什么淘汰策略。

一个常见判断是：如果 used_memory 持续增长而 evicted_keys 也增长，说明容量压力已经影响数据保留；如果 used_memory 接近上限但 evicted_keys 不动，要检查策略是否是 noeviction。

处理步骤：找增长来源并做临时止血

确认告警真实后，按风险从低到高处理。

1. 先看 key 数量和过期情况

redis-cli DBSIZE
redis-cli INFO keyspace

如果 key 数量快速上涨，优先怀疑缓存 key 没有设置过期时间、批量任务写入异常，或某个业务前缀爆发。

2. 再查大 key，但要控制扫描影响

redis-cli --bigkeys -i 0.05

--bigkeys 会扫描 key 空间，生产环境建议在低峰期或只读副本上运行，并加 -i 降低连续扫描压力。如果已经知道业务前缀，可以用 SCAN 缩小范围：

redis-cli --scan --pattern 'session:*' | head -100

3. 临时止血先选低风险动作

• 暂停非核心批量写缓存任务。
• 缩短异常前缀的 TTL，先控制新增内存。
• 对确认无用的临时 key 分批删除，避免一次性阻塞。
• 如果业务允许，临时调低缓存写入比例。

不要在没有确认前缀和用途时直接批量删除。Redis 内存告警的目标是恢复稳定，不是制造第二次故障。

回滚路径：避免误删和策略误改

任何止血动作都要留回滚路径，特别是调整 maxmemory-policy 或删除 key 前缀时。

• 配置变更前：记录当前 maxmemory、maxmemory-policy 和实例规格。
• 删除前缀前：确认 key 业务含义、是否可重建、是否会影响登录或订单等核心链路。
• 任务降载前：保留恢复入口，确认负责人和恢复条件。
• 策略调整后：保留原配置，恢复失败时能立即改回。

如果改过淘汰策略，例如从 noeviction 改为某个 LRU/LFU 策略，必须在事故窗口结束后评审是否长期保留。临时策略不应自动变成永久策略。

告警确认：看内存、淘汰和业务错误是否恢复

处理后至少观察三组指标：

redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO commandstats

• used_memory 是否停止上涨或回落到安全水位。
• evicted_keys 是否停止快速增长。
• 业务接口错误率、延迟和缓存命中率是否恢复。
• 批量任务恢复后，内存是否再次上涨。

如果内存回落但业务错误仍在，就不能只关闭 Redis 告警；需要继续查调用方超时、连接池等待或缓存 miss 造成的数据库压力。

复盘项：把一次告警变成容量规则

事故结束后，把这次处理沉淀成下一次更快的判断规则：

• 本次内存增长来自哪个业务前缀，是否缺少 TTL。
• 是否存在大 key，最大 key 属于哪类数据结构。
• 当前 maxmemory 是否合理，淘汰策略是否匹配业务。
• 是否需要给批量任务加写入速率限制。
• 监控是否能提前发现 used_memory 增长斜率。
• 是否需要拆分实例，避免临时缓存和核心会话混在一起。

Redis 内存告警的关键是把“容量压力”拆成可判断的信号：到底是 key 数量增长、大 key 膨胀、TTL 缺失、策略不当，还是业务突增。只要判断链路固定下来，值班处理就会从临场猜测变成可复用的运行手册。