应监控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 里的两个关键数字
命中率低不是靠猜，而是靠 keyspace_hits 和 keyspace_misses 这俩数算出来的。只要这两个值在增长，就说明 Redis 正在真实响应请求；如果 keyspace_misses 暴涨而 keyspace_hits 几乎不动，基本可以锁定是缓存层“形同虚设”。
注意：这两个计数器是自实例启动以来的累计值，不能只看绝对值，要对比单位时间内的变化率——比如每分钟新增 keyspace_misses 是之前的 3 倍，但 keyspace_hits 没变，问题就出在“新请求几乎全没命中”。
别忽略 expired_keys 和 evicted_keys
命中率低常被误认为是“数据没缓存”，其实是缓存了但活不过几秒。查 INFO stats 时顺手扫一眼：
• expired_keys 高 → 过期时间设得太短，尤其对冷热不均的数据用了统一 TTL
• evicted_keys 非零 → 内存满被迫淘汰，说明 maxmemory 不够或淘汰策略（如 volatile-lru）把本该留下的热点 key 清掉了
• 两者同时高 → 很可能是缓存预热没做，或上线后瞬间涌入大量带随机 key 的请求（比如爬虫、恶意扫描），Redis 被迫边过期边淘汰
用 redis-cli --hotkeys 看谁在“假装活跃”
这个命令只有在 maxmemory-policy 设为 allkeys-lfu 或 volatile-lfu 时才有效。它能暴露一个典型陷阱：表面看 keyspace_hits 不低，但 hit 都集中在几个 key 上，其余 key 全是 miss —— 也就是“长尾请求打穿缓存”。
常见场景：
• URL 路径含用户 ID 或时间戳，生成海量唯一 key
• 接口参数未归一化（如 ?sort=asc 和 ?sort=ASC 被当成两个 key）
• 分页参数无限制（page=9999 这种无效分页反复触发 DB 查询）
这种情况下，光调高整体命中率没意义，得从上游收敛 key 模式
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
结合 instantaneous_ops_per_sec 看流量结构是否异常
单看命中率会漏掉关键线索。比如命中率从 95% 降到 85%，看似小跌，但如果同期 instantaneous_ops_per_sec 从 200 涨到 2000，说明请求量激增，而缓存层吞不下——这时真正的问题可能是连接池打满、慢查询堆积，或客户端没走连接复用。
要交叉验证：
• instantaneous_read_ops_per_sec 和 instantaneous_other_ops_per_sec 是否同步飙升？如果是，大概率是无效请求（如探测类 ping、空参数调用）
• total_commands_processed 增速是否远高于业务 QPS？说明有命令被高频重试（比如 client 侧没处理 NOAUTH 或 READONLY 错误，反复重发）
• rejected_connections > 0？那根本不是命中率问题，是 Redis 已经拒绝新连接了
真正难的不是算出命中率，而是判断“哪个 miss 是合理的，哪个是失控的”。比如一个新上线功能的首次访问必然 miss，但它的 miss 应该随时间衰减；而持续稳定的高 miss 率，往往藏在 key 设计、流量来源或客户端重试逻辑里——这些不会直接写在 INFO 输出里，得靠交叉指标倒推。
