Redis 内存打满与淘汰：判断是策略、热键还是数据生命周期

适用范围与前提

适用于 Redis 缓存或数据服务；ACL 或托管服务策略可能禁止 CONFIG 等诊断命令。

先确认是否含权威数据，使用已配置的 TLS/认证连接执行只读诊断，不把密码写入命令。

常见症状

• 写入报 OOM command not allowed
• 命中率下降或 evicted_keys 持续增长
• 内存 RSS 显著大于 used_memory

1. 查看内存和淘汰的实际状态

收集 used_memory、maxmemory、mem_fragmentation_ratio、keyspace 和 eviction 指标。确认实例是缓存还是兼任持久化数据；两者的可接受淘汰策略完全不同。

redis-cli INFO memory
redis-cli INFO stats | grep -E "evicted|keyspace"
redis-cli CONFIG GET maxmemory-policy

2. 找出增长来源

先按业务前缀抽样，再检查无 TTL 的键与大值。生产环境避免对极大实例无节制执行 KEYS；使用 SCAN 分批采样，必要时在副本上分析。

redis-cli --scan --pattern "*" | head -n 50
redis-cli INFO keyspace

3. 选择可回滚的缓解动作

缓存场景可临时限制写入、缩短明确可过期数据的 TTL 或扩容分片；持久化数据场景应先停止错误写入并评估迁移。变更 maxmemory-policy 前，确认应用是否能正确处理 cache miss。

redis-cli SLOWLOG GET 20
redis-cli INFO commandstats

解读证据

说明性诊断案例

以下假设案例用于解释推理，并非客户真实事故，也不代表已在你的技术环境中测试。

使用 volatile 淘汰策略时写入失败，但大多数键没有 TTL，可能没有可淘汰的键。结合 INFO keyspace 与限定前缀的抽样检查；修复写入生命周期或规划容量。直接改成 allkeys 可能静默删除不应丢弃的数据。

验证恢复

• 在正常流量下验证写入、命中率与延迟，并确认没有意外键丢失。
• 同时观察内存、淘汰与到期速率，并为复制和持久化开销保留进程内存。

回滚与停止条件

记录原策略和限制；回退淘汰策略无法找回已被淘汰的键，允许删除前先确认可重建或有备份。