命中率低于75%（即keyspace_hits:keyspace_misses<3:1）时应调整淘汰策略，因缓存已无法有效分担数据库压力；需结合evicted_keys增速与keyspace_misses增速同步上升来确认问题根源。
直接看 INFO 里的 keyspace_hits 和 keyspace_misses，比值低于 4:1 就该调淘汰策略了。 这个比值反映的是缓存是否在“有效工作”——不是单纯看内存满不满，而是看请求到底有多少真被缓存拦住了。很多团队等 OOM 或写入报 OOM command not allowed when used memory > 'maxmemory' 才反应，其实命中率掉到 70% 以下时，数据库压力已经明显上去了。
怎么快速拿到 hit/miss 比率
用 redis-cli 直连后执行：INFO stats，重点找这两行：
keyspace_hits:124890 keyspace_misses:32156
注意：这个统计是自 Redis 启动或上次 CONFIG RESETSTAT 后的累计值，不是实时窗口。如果业务刚上线或刚切流量，数值不准，建议等稳定运行 1–2 小时再采样。
- 不要依赖监控平台的“命中率曲线”做决策——很多平台默认只拉 1 分钟聚合，会掩盖突发 miss 高峰
- 避免在
SAVE或BGSAVE执行期间采样，RDB fork 会导致短时miss上升（尤其是大 key 多时） - 如果用了 Redis Cluster，需分别登录每个 master 节点查，不能只看一个节点
hit/miss 比率低说明什么问题
比值持续低于 3:1（即命中率 < 75%），大概率不是“缓存没设好”，而是淘汰策略和数据访问模式错配。常见对应关系：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
allkeys-lru下 hit 率骤降 → 可能有大量“一次写、多次读、但读完就丢”的数据（比如临时 token），LRU 把刚热起来的键又踢了 -
volatile-lru下 miss 激增 → 说明带 TTL 的 key 占比高，但其中很多是长周期缓存（如用户配置），却被当成短期热点淘汰 -
volatile-ttl下 hit 率尚可但延迟毛刺多 → 该策略会集中清理快过期的 key，触发批量删除，CPU 占用跳升 -
allkeys-random下 hit/miss 波动剧烈 → 说明访问有强局部性（比如某类商品 ID 集中被查），随机淘汰破坏了这种局部性
换策略前必须确认的三件事
改 maxmemory-policy 不是重启服务，但会影响正在淘汰中的 key 选择逻辑，所以得卡准节奏：
- 先确认当前策略：用
CONFIG GET maxmemory-policy，别凭记忆或配置文件判断——线上可能被运维手动改过 - 检查
maxmemory是否已生效：用CONFIG GET maxmemory，返回0表示未限制，此时淘汰策略根本不会触发 - 观察
evicted_keys计数器：在INFO stats里，如果它长期为 0，说明内存根本没触顶，调策略毫无意义
真正要盯的是 evicted_keys 增速 + keyspace_misses 增速是否同步上涨——这才能证明淘汰行为正在恶化缓存效果。
LFU 策略容易被忽略的衰减陷阱
allkeys-lfu 看起来很理想：保留高频访问的 key。但它有个硬伤——计数器会随时间衰减。Redis 默认每分钟对所有计数器右移 1 位（相当于除以 2），且衰减频率由 lfu-decay-time 配置控制（单位：分钟）。
- 如果你的业务有“早晚高峰”，但
lfu-decay-time设成 1，早上的访问计数到下午就被清掉一半，LFU 就退化成近似 LRU - 衰减太慢（比如设成 60）会导致冷数据长期赖着不走，尤其当有突发爬虫刷某类 key 时，后续几小时都难被淘汰
- 验证方式：用
OBJECT FREQ查几个 key 的当前频次，隔 5 分钟再查，看是否明显下降
生产环境调 LFU，lfu-decay-time 建议从 10 开始试，再根据 evicted_keys 类型分布微调——别只盯着 hit/miss 比率，否则可能把真正该留的热 key 给漏掉了。
