查内存暴增先运行redis-cli info memory，重点关注used_memory_human、used_memory_peak_human、mem_fragmentation_ratio和maxmemory_human四个字段。
查内存暴增的第一手证据：用 info memory 看真实水位
别急着翻日志或猜业务，先连上 Redis 实例跑一句：redis-cli info memory。重点盯这四个字段：used_memory_human（当前用了多少）、used_memory_peak_human（历史峰值）、mem_fragmentation_ratio（碎片率）、maxmemory_human（硬上限）。如果 used_memory_human 在 5 分钟内翻了 3 倍，而 used_memory_peak_human 同步飙升，基本可锁定是写入突增而非缓存“老化”；若 mem_fragmentation_ratio > 1.5，说明不是数据多了，是内存“散架”了——这时候淘汰策略再好也救不了带宽和延迟。
确认驱逐是否真在发生：看 evicted_keys 和淘汰策略配置
info stats 里的 evicted_keys 是唯一能证明“Redis 正在主动踢人”的指标。它归零？那内存暴增根本没触发淘汰，问题出在别处（比如客户端堆积输入缓冲区）；它持续上涨？再立刻查 config get maxmemory-policy。常见坑：volatile-lru 配了但 90% 的 Key 没设 TTL，等于实际退化成 noeviction，一到内存满就报 OOM command not allowed when used memory > 'maxmemory'；allkeys-lfu 虽稳，但 Redis 3.2 以下不支持，升级前别乱配。
定位谁在“吃内存”：用 --bigkeys 和 memory usage 锁定元凶
大 Key 是最隐蔽的暴增源。运行 redis-cli --bigkeys --memtier 1024 扫描，重点关注 Hash、ZSet 类型中单个超过 1MB 的 Key。扫出来后，对可疑 Key 执行 memory usage 看真实开销——注意，hgetall 返回的字节数 ≠ 内存占用，Redis 的 dict 结构、编码转换（如 ziplist 升级为 hashtable）都会额外吃内存。容易踩的坑：用 keys * 查大 Key，会阻塞主线程；用 scan + memory usage 分批查更安全，但得自己写脚本。
验证淘汰是否生效：模拟写压测 + 观察 keyspace_hits/misses
光看配置没用，得验证策略真在干活。用 redis-benchmark -n 100000 -t set,get 压测，同时监控 info stats 中的 keyspace_hits 和 keyspace_misses。如果 keyspace_misses 暴涨但 evicted_keys 几乎不动，说明淘汰太慢或样本数太少（maxmemory-samples 默认是 5，调到 20 能提升 LFU/LRU 精度）；如果 keyspace_hits 断崖下跌，大概率是驱逐误杀了热点 Key——这时换 allkeys-lfu 比 allkeys-lru 更抗突发流量。
真正难的不是发现大 Key 或调参数，而是区分“内存暴增”到底是数据本身膨胀、还是 Redis 自身管理失灵（比如碎片卡死、AOF 重写时的临时内存尖峰）。一次排查里，有 70% 的 case 最终指向定时任务批量写入 + 未设 TTL 的组合拳，而不是配置错了什么高级策略。
