一、缓存基础与命中率定义

大家好，我是你们的老朋友。今天咱们聊聊缓存命中率这个话题。

说实话，我见过太多团队在缓存上栽跟头了。有的系统明明上了缓存，性能反而更差。有的缓存命中率只有20%，还以为是正常的。嗯，这其实都是基础没打牢。

缓存，说白了就是把数据放在一个更快的地方。你想想看，每次查数据库都要走磁盘IO，慢得很。缓存就是把热点数据放到内存里，下次直接取。

我习惯把缓存比作「便签纸」。你记不住所有电话号码，就把常用的写在便签纸上。查的时候先看便签纸，找不到再去翻通讯录。这个「便签纸」就是缓存。

核心要点：缓存是介于应用和慢速存储之间的高速存储层。它的存在就是为了「快」。

这两个概念其实很简单：

我在项目中遇到过一种情况：明明缓存里有数据，但每次请求都穿透到数据库。后来发现是缓存key设计有问题，每次生成的key都不一样。你说冤不冤？

这个公式必须刻在脑子里：

缓存命中率 = 缓存命中次数 / (缓存命中次数 + 缓存未命中次数) × 100%

举个例子：

我的经验：命中率低于80%就要警惕了。低于50%？那缓存基本白上了。我曾经接手过一个项目，命中率只有12%，查了半天发现是缓存过期时间设得太短，数据刚存进去就过期了。

这三个概念经常有人搞混。我画了一张图，一看就明白：

说白了就是请求的数据在缓存和数据库里都不存在。每次请求都穿过缓存，直接打到数据库。我见过最夸张的一次，有人用随机ID疯狂请求，数据库直接挂了。

避坑指南：我曾经在项目中没做空值缓存，结果恶意请求用不存在的ID刷接口，数据库CPU直接飙到100%。后来加了布隆过滤器，问题才解决。

这个特指某个热点key过期。比如微博热搜第一的key突然过期了，瞬间几万个请求同时去数据库查。你想想看，数据库扛得住吗？

我习惯的做法是：热点key永不过期，或者用互斥锁保证只有一个请求去查数据库。

这个更狠。大量key在同一时间过期，缓存层集体失效。就像多米诺骨牌一样，数据库瞬间被压垮。

为什么会这样？很多新手喜欢把所有key设成相同的过期时间。比如统一设成1小时，那每到整点，缓存就集体失效一次。

我的建议：过期时间加个随机偏移量。比如基础时间1小时，再随机加1-10分钟。这样就不会集体过期了。

缓存这东西，用好了是神器，用不好是灾难。我见过太多人上来就上缓存，结果问题更多。记住：先理解基础，再动手实践。

这三个概念的区别，我再用一句话总结：

嗯，基础就讲到这里。下一节咱们聊聊怎么监控和排查命中率问题。到时候我会分享一些实战中的骚操作。