应监控keyspace_hits与keyspace_misses时间序列趋势，结合evicted_keys、used_memory_rss和maxmemory排查内存淘汰：若miss陡增且evicted_keys同步飙升，RSS超maxmemory，则为淘汰导致；若expired_keys增长慢而evicted_keys高，可能是allkeys-lru策略误伤无TTL热key。
直接看 keyspace_hits 和 keyspace_misses 的变化趋势
命中率骤降不是单点数值问题，而是时间序列异常。别只跑一次 redis-cli info stats | grep "keyspace_hits\|keyspace_misses" 算个静态比值——它掩盖了淘汰是否正在高频发生。你应该用监控系统（如 Prometheus + Grafana）或脚本每 10 秒采样一次，画出两条曲线：keyspace_hits 是否平稳上升，keyspace_misses 是否突然陡增且持续不回落。如果后者跳涨的同时 evicted_keys 也在同步飙升，基本可锁定是内存淘汰导致的 miss 激增。
重点核对 evicted_keys 和 maxmemory 配置是否匹配
很多团队设了 maxmemory，但没意识到 Redis 实际内存使用远超这个值：RDB/AOF 缓冲、客户端输出缓冲、Lua 脚本栈等都会额外吃内存。当 used_memory_rss 持续 > maxmemory，淘汰就成常态。排查时必须同时查：
-
redis-cli info memory | grep -E "(used_memory_rss|maxmemory|mem_allocator)"—— 看 RSS 是否已超限 -
redis-cli info stats | grep evicted_keys—— 确认淘汰是否在持续发生（不是历史累计值） -
redis-cli config get maxmemory—— 检查当前生效值（可能被 CONFIG SET 动态改过，但没写入 conf）
常见坑：K8s 中容器内存 limit 设为 2GB，但 maxmemory 也配成 2GB，没给 Redis 自身开销留余量，结果一到流量高峰就触发淘汰。
区分是 allkeys-lru 误伤还是 volatile-lru 策略失效
淘汰策略类型直接影响哪些 key 被干掉。如果你用的是 volatile-lru，但业务里大量缓存根本没设 TTL（即没进过期字典），那这些 key 就完全不会参与淘汰——真正被淘汰的只是少数带过期时间的 key，而 miss 却来自大量无 TTL 的冷 key 被反复查询。此时 keyspace_misses 上升和淘汰无关，而是缓存设计缺陷。验证方法：
-
redis-cli info stats | grep expired_keys—— 如果该值增长缓慢，但evicted_keys很高，说明是allkeys-*类策略在起作用 -
redis-cli --scan --pattern "*"结合TTL命令抽样检查，确认 key 是否普遍带过期时间 - 用
MEMORY USAGE key查几个高频 miss 的 key，看它们是否真在内存里（排除网络或客户端缓存干扰）
警惕 evicted_keys 增长但 keyspace_misses 不同步上涨的假象
淘汰发生 ≠ 立即引发 miss。Redis 淘汰 key 后，如果后续请求没再访问它，就不会体现在 keyspace_misses 里。所以你会看到 evicted_keys 在涨，但 keyspace_misses 平稳——这恰恰说明被淘汰的都是冷数据，不影响业务。真正危险的是：淘汰后立刻有大量请求打到刚被删的 key 上，这时 keyspace_misses 才会跟涨。判断依据是二者增量比值：若 1 分钟内 evicted_keys +1000，keyspace_misses +950，大概率是热点 key 被误杀；若 keyspace_misses 只 +50，那淘汰本身未必是问题根源。
