排查 Redis 缓存命中率偏低时，应重点监控 keyspace_hits 与 keyspace_misses 的变化速率，而不是只盯着累计绝对值；同时结合 expired_keys、evicted_keys、instantaneous_ops_per_sec 等监控指标做交叉分析：如果 miss 突然增加而 hit 基本停滞，且 evicted_keys 同步暴涨、used_memory_rss 超过 maxmemory，通常说明是内存淘汰导致；如果 expired_keys 增长过快，多半是 TTL 设置过短；如果两项都偏高，则可能是缓存预热不足，或遭遇恶意请求、异常流量冲击。
直接看 INFO stats 里的两个核心指标
Redis 缓存命中率不是凭感觉判断的，而是通过 keyspace_hits 和 keyspace_misses 这两个关键统计值计算出来的。只要这两个数字持续增长，就说明 Redis 正在真实处理缓存请求。如果 keyspace_misses 明显飙升，而 keyspace_hits 几乎没有同步增长，那么基本可以判断缓存层已经失去应有作用。
需要特别注意的是：这两个计数器都是从 Redis 实例启动后开始累计的，因此不能只看绝对值，更要关注单位时间内的增长率。举例来说，如果每分钟新增的 keyspace_misses 达到之前的 3 倍，而 keyspace_hits 基本没有变化，那就意味着新进入的请求大多没有命中缓存，这往往是 Redis 命中率下降的直接信号。
别忽略 expired_keys 和 evicted_keys
很多时候，Redis 命中率低并不代表“没有做缓存”，而是数据虽然进入了缓存，却很快失效或被淘汰。排查 INFO stats 时，建议顺带关注以下两个指标：
• expired_keys 高 → 通常表示过期时间设置过短，尤其是冷热数据混用同一套 TTL 策略时，更容易导致大量缓存刚写入就失效
• evicted_keys 非零 → 说明 Redis 内存达到上限后发生了淘汰，这意味着 maxmemory 配置不足，或者淘汰策略（如 volatile-lru）误删了本应保留的热点 key
• 两者同时偏高 → 往往意味着缓存预热不到位，或者系统上线后瞬间涌入大量带随机 key 的请求，例如爬虫抓取、恶意扫描等，导致 Redis 一边过期一边淘汰，缓存效果持续变差
用 redis-cli --hotkeys 看谁在“假活跃”
这个命令只有在 maxmemory-policy 设置为 allkeys-lfu 或 volatile-lfu 时才有效。它可以帮助你发现一个非常常见的 Redis 缓存问题：表面上 keyspace_hits 不算低，但命中几乎都集中在极少数热点 key 上，其他大量 key 却持续未命中，这就是典型的“长尾请求击穿缓存”。
常见场景包括：
• URL 路径中包含用户 ID、时间戳等动态参数，从而生成海量唯一 key
• 接口参数没有做归一化处理（例如 ?sort=asc 和 ?sort=ASC 被当成两个不同 key）
• 分页参数缺乏限制（如 page=9999 这类无效分页不断触发数据库查询）
在这种情况下，单纯提升整体缓存命中率意义并不大，真正要做的是从业务上游收敛 key 设计与请求模式，减少无意义的长尾 key。
结合 instantaneous_ops_per_sec 看流量结构是否异常
只看 Redis 命中率，往往会漏掉更关键的性能线索。比如命中率从 95% 下降到 85%，表面上只是小幅波动；但如果同期 instantaneous_ops_per_sec 从 200 飙升到 2000，就说明整体请求量发生了剧烈增长，缓存层已经承压。这时候，真正的问题未必是缓存策略本身，而可能是连接池耗尽、慢查询堆积，或者客户端没有正确复用连接。
建议继续做交叉验证：
• instantaneous_read_ops_per_sec 和 instantaneous_other_ops_per_sec 是否同时上升？如果是，很可能存在大量无效请求，例如探测类 ping、空参数调用等
• total_commands_processed 的增长速度是否远高于业务 QPS？如果明显偏高，说明某些 Redis 命令正在被高频重试，例如客户端没有正确处理 NOAUTH 或 READONLY 错误，导致请求不断重发
• rejected_connections > 0？如果出现这种情况，那已经不只是缓存命中率低的问题，而是 Redis 开始拒绝新连接，服务可用性本身正在下降
真正困难的，从来不是算出 Redis 缓存命中率，而是判断“哪些 miss 属于正常范围，哪些 miss 已经失控”。例如，新上线功能在首次访问时出现 miss 是正常现象，但这类 miss 应该随着访问增加而逐步衰减；如果 miss 长时间维持在高位，背后通常隐藏的是 key 设计不合理、异常流量来源，或客户端重试机制有问题——这些根因不会直接写在 INFO 输出中，必须通过监控数据和多项指标交叉分析才能定位。
