需监控evicted_keys每秒增量（>200/sec）、redis-cli --stat中evicted列跳变+mem列逼近上限+cmd列骤降，及latency中eviction P99延迟突增（如超8ms），三者同步出现方可确认高频淘汰。
怎么确认Redis正在高频淘汰key
光看 INFO memory 里的 used_memory_human 和 maxmemory 比值不够。比值长期 >95% 只说明压力大，不能证明淘汰在发生。真正要盯的是 evicted_keys 的增量变化：
- 用脚本每 2 秒执行一次
redis-cli INFO memory，提取evicted_keys字段做差值计算 - 如果每秒增量稳定在 200+，基本可断定主线程正频繁执行淘汰逻辑
- 搭配
redis-cli --stat观察：evicted列跳变 +mem列逼近上限 +cmd列数值骤降（比如掉到平时的 60% 以下），三者同步出现就是典型信号
为什么只看 expired_keys 容易误判
expired_keys 统计的是“因过期而被删”的 key 数量，和内存淘汰是两套机制。混淆它会导致错误归因：
- 如果
expired_keys增速快但evicted_keys几乎不动，大概率是淘汰策略配成了noeviction，而不是“没努力删” - 反过来，
evicted_keys涨得猛但expired_keys平稳，说明淘汰策略生效了（比如allkeys-lru），且大量被淘汰的 key 根本没设 TTL - volatile-* 类策略下，如果业务里大部分 key 都没设过期时间，
evicted_keys就会一直为 0，哪怕内存早已爆满——这时写入直接报错，但监控上看不到淘汰动作
如何抓到淘汰导致的延迟尖峰
--stat 只暴露吞吐下降，不反映真实耗时。要定位淘汰是否抢了 CPU 时间片，必须看延迟分类数据：
- 运行
redis-cli --latency-history -i 1持续采样至少 5 分钟 - 再执行
redis-cli --latency-dist或查INFO latency，重点关注eviction行的 P99 值 - 若
evictionP99 从 0.2ms 突增到 8ms 以上，且时间点与evicted_keys增速吻合，就能确认淘汰循环正在阻塞命令处理 - 注意：
CONFIG GET active-expire-effort设太高（比如 10）反而可能加剧这种尖峰，尤其碎片率mem_fragmentation_ratio > 1.5时
容易被忽略的碎片率陷阱
很多人以为 evicted_keys 在涨、used_memory 却不降，就是淘汰失效了。其实更可能是内存碎片在作祟：
- 检查
mem_fragmentation_ratio = used_memory_rss / used_memory，>1.5 就说明 jemalloc 分配器已严重碎片化 - 此时即使淘汰了 key，释放的内存 OS 不回收，
used_memory_rss居高不下，Redis 还会继续触发淘汰 - 这种情况不能只调淘汰策略，得配合
activedefrag yes或计划性重启，否则监控指标永远“看起来在拼命干活，实际腾不出空间”
