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