一个数字概括体系
前十六篇铺了满地的机制——穿透、击穿、雪崩、一致性、淘汰、多级——评价这套体系运转得好不好，最浓缩的指标就是缓存命中率：
命中率 = keyspace_hits / (keyspace_hits + keyspace_misses)分子是缓存里直接取走的请求，分母里多出来的那一截是白跑一趟去回源的。每个未命中都是一次 DB 查询、一段更长的 RT、一份更大的开销——命中率每掉一个点，底下 DB 的压力就多涨一片。多少算好？没有绝对线，读多写少的经典场景 90% 是及格线，95%~99% 是常态标杆；而写多读少、数据天然冷门的场景，命中率天然上不去，硬拉反而有害。
命中率低的三条病根
命中率偏低，按三条线排查。第一条：容量不够——内存满了开始淘汰，淘汰策略篇讲的 evicted_keys 持续增长，说明热数据还没来得及被再读就被挤走了，典型症状是命中率曲线跟着内存水位一起跳水；第二条：TTL 失配——过期太频繁，数据还没被读几次就没了，或者反过来 TTL 太长、脏数据引发业务问题被迫频繁手动清；第三条：访问模式本身冷——缓存的 key 里有大量长尾冷数据占着内存，真正的热点反而分不到预算，或者穿透污染（不存在的 key 被空值缓存占坑，穿透篇的空值缓存要配短 TTL 就是这个道理）。
看盘：别只盯一个总分
只看全局命中率会漏掉关键细节，几个配套指标要摆在一起看：命中率曲线——突变比数值更有信息量，发布时间点上的跳水十有八九是新版本改了 key 规则或 TTL；内存水位与 evicted_keys——判断是不是容量瓶颈；expire 与淘汰的比值——判断 key 是「自然过气」还是「被逼下岗」；分业务的命中率——全局 95% 可能掩盖了某个核心业务只有 70% 的事实，按业务前缀拆开统计（客户端埋点或 key 前缀聚合）才看清谁在拖后腿：
# Redis 侧的原始数据
INFO stats
# keyspace_hits:1234567 keyspace_misses:23456 evicted_keys:789
# 按业务前缀拆分的命中率（客户端埋点聚合）
item:detail --> 98.2% 核心业务，健康
user:feed --> 61.5% 拖后腿，重点排查养命中率：四件常规武器
对症下药的四板斧，全是前文的老朋友：预热（第 8 篇）——上线与大促前把热点灌进去，冷启动的空窗期不拉低曲线；合理的 TTL 加打散（第 5 篇）——按数据的更新节奏定 TTL，随机抖动防雪崩；容量规划——按热点数据规模定内存，maxmemory 留余量，淘汰策略选对；穿透防线（第 3 篇）——布隆过滤器与短 TTL 空值缓存，别让不存在的 key 污染统计与内存。四板斧之外还有一招兜底：命中率告警——跌破基线告到值班群里，缓存体系的故障大多先在命中率上显形，比 RT 报警更早。
命中率是果不是因——养它的手段，全是前十六篇的功夫。至此，应用层的读写姿势、Redis 自身的机制、监控的指标都已备齐，下一篇把整个体系画成一张全景图，合流收官。
评论 (0)