缓存命中率的计算与观测

缓存命中率衡量的是"请求来了，缓存能不能接得住"。它不直接写在监控大盘上，需要用 Redis 自己上报的两个计数器算出来，算出来之后再谈优化。 一、公式与读取 命中率 = keyspace_hits ÷ (keyspace_hits + keyspace_misses)，两个值都来自 info stats： redis-cli info stats | grep keyspace 输出类似 keyspace_hits:95213 和 keyspace_misses:4987，代入公式约等于 95%。看趋势比看单点更有用，命中率应该是一条长期平稳的线，突然掉下去就说明有什么东西变了。要注意这两个计数器从启动起累计，中途重启会清零，刚重启不久的实例命中率偏低属于正常，别急着下结论。 二、命中率过低时的排查面 第一个面是业务写入方式。大量 key 属于一次性使用、写进去不会被读第二次，命中率天生就低，这不是缓存的问题。第二个面是过期时间。大量 key 设成同一时刻过期，到期瞬间请求全部穿透到数据库，命中率会周期性跳水，常见做法是给过期时间加随机偏移，比如 3600 秒上下浮动 300 秒。第三个面是容量。跑 redis-cli info memory | grep -E 'used_memory_human|maxmemory_human' 看内存水位，用 dbsize 看 key 总量，再查 evicted_keys 是否持续增长——这个数一直涨，说明内存不够、老 key 被挤掉，缓存等于被反复清空。 三、观测怎么落地 最省事的办法是定时任务每分钟采一次： * * * * * redis-cli info stats | grep keyspace >> /var/log/redis-hit.log 或者接进现有监控系统，对命中率低于某个阈值设告警。阈值没有统一标准，以自己业务平时的水位为基准，比如平时稳定在 95%，跌破 90% 就值得看一眼。顺带一提，命中率要和请求量一起看：同样是 80%，每秒十次请求和每秒一百万次请求，穿透到数据库的量天差地别。曲线陡降时先对照两件事：当天有没有发布改动 key 的结构，有没有人执行过 FLUSHDB 之类的清空操作，多数异变都能对上其中一个。 命中率掉下来，页面变慢往往要隔几分钟才显现，等用户反馈就晚了。采样脚本之外，可以用 awk 把两个计数器直接算成百分数再落盘，监控图上就是现成的点位，不用人工换算。把它变成一条每天扫一眼的曲线，是成本很低的保险，数值本身不贵重，贵重的是它突变的那一刻你能第一时间知道。