上周线上出了个事故，凌晨 2 点被告警电话叫醒。打开 Grafana 一看，MySQL 的 QPS 从平时的 200 飙到了 8000+，CPU 直接打满。排查下来原因很离谱------有人拿一批根本不存在的用户 ID 疯狂请求我们的用户详情接口。
这些 ID 在 Redis 里查不到（因为压根不存在），于是每次请求都穿透到了 MySQL。Redis 形同虚设，MySQL 被打成了筛子。
这就是经典的缓存穿透问题。说实话这个概念面试背了无数遍，真到线上出事才发现自己只会嘴上说说。花了两天把几种方案都跑了一遍，把实操过程和踩的坑全记下来。
先搞清楚：穿透、击穿、雪崩，别搞混了
面试时这三个总被放一起问，但它们是完全不同的场景：
| 问题类型 | 触发条件 | 本质原因 | 危害程度 |
|---|---|---|---|
| 缓存穿透 | 查询的数据在 DB 中也不存在 | 恶意攻击 / 业务 bug | ⭐⭐⭐⭐⭐ |
| 缓存击穿 | 热点 key 过期瞬间被大量并发请求 | 热点数据过期 | ⭐⭐⭐ |
| 缓存雪崩 | 大量 key 同时过期 / Redis 宕机 | 过期时间设置不当 | ⭐⭐⭐⭐ |
这篇只聊穿透。击穿和雪崩改天再写。
缓存穿透的请求链路
正常情况下，一个查询请求的链路是这样的：
问题出在最后那个环节：DB 也没数据时，什么都没往 Redis 写，下次同样的请求还是会打到 DB。攻击者用大量不存在的 key 来请求，Redis 就成了摆设。
方案一：缓存空值（最简单，但有坑）
最直觉的方案------DB 查不到数据时，也往 Redis 里写一个空值，下次就能被缓存拦住了。
java
public User getUserById(Long userId) {
String key = "user:" + userId;
// 1. 先查 Redis
String cached = redisTemplate.opsForValue().get(key);
// 注意：这里要区分 "key不存在" 和 "key存在但值为空标记"
if (cached != null) {
if ("NULL".equals(cached)) {
return null; // 命中空值缓存，直接返回
}
return JSON.parseObject(cached, User.class);
}
// 2. 查 MySQL
User user = userMapper.selectById(userId);
if (user != null) {
// 正常数据，缓存 30 分钟
redisTemplate.opsForValue().set(key, JSON.toJSONString(user), 30, TimeUnit.MINUTES);
} else {
// 关键：空值也缓存，但过期时间要短！
redisTemplate.opsForValue().set(key, "NULL", 2, TimeUnit.MINUTES);
}
return user;
}踩坑记录
坑 1：空值的过期时间不能太长。 我一开始图省事设了 30 分钟，结果业务那边新注册了一个用户，发现 30 分钟内怎么查都查不到。因为这个 ID 之前被缓存了空值，新数据进 DB 后缓存还没过期。最后改成了 2 分钟，算是在防护效果和数据一致性之间找了个平衡。
坑 2：攻击者如果每次用不同的随机 ID，这方案就废了。 假设攻击者每次请求都用一个新的随机 UUID，Redis 里会被灌入海量的空值 key，内存很快就爆了，而且每个新 ID 第一次还是会穿透到 DB。
所以缓存空值只能防「用少量固定 ID 反复请求」的场景，对随机 ID 攻击基本没用。
方案二：布隆过滤器（真正的银弹）
布隆过滤器的思路完全不同：在 Redis 前面再加一层，预先把所有合法的 ID 存进去。请求进来先问布隆过滤器「这个 ID 存在吗」，如果回答不存在，直接拒绝，连 Redis 都不用查。
Redis 4.0 之后可以用 RedisBloom 模块，操作起来很简单：
python
import redis
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
# 创建布隆过滤器，预计 100 万个元素，误判率 0.01%
r.execute_command('BF.RESERVE', 'user_filter', 0.0001, 1000000)
# 初始化：把所有已有用户 ID 灌进去
# 实际项目中这步一般在数据初始化脚本或定时任务里做
def init_bloom_filter():
# 假设从 DB 批量拉取所有用户 ID
all_user_ids = fetch_all_user_ids_from_db()
pipe = r.pipeline()
for uid in all_user_ids:
pipe.execute_command('BF.ADD', 'user_filter', str(uid))
pipe.execute()
print(f"布隆过滤器初始化完成，共 {len(all_user_ids)} 个 ID")
# 查询时先过布隆过滤器
def get_user(user_id):
# 第一关：布隆过滤器
exists = r.execute_command('BF.EXISTS', 'user_filter', str(user_id))
if not exists:
# 布隆过滤器说不存在，那就一定不存在
return None
# 第二关：查 Redis 缓存
cache_key = f"user:{user_id}"
cached = r.get(cache_key)
if cached:
return json.loads(cached)
# 第三关：查 DB
user = db.query_user(user_id)
if user:
r.setex(cache_key, 1800, json.dumps(user))
return user布隆过滤器参数怎么选
这个我纠结了挺久，最后总结了一个参考表：
| 数据规模 | 误判率 | 占用内存（约） | 适用场景 |
|---|---|---|---|
| 10 万 | 1% | ~120 KB | 小项目、内部系统 |
| 100 万 | 0.1% | ~2.4 MB | 中型业务 |
| 100 万 | 0.01% | ~3.2 MB | 对准确度要求高 |
| 1000 万 | 0.1% | ~24 MB | 大型业务 |
| 1 亿 | 0.01% | ~320 MB | 超大规模 |
误判率设太低会占更多内存，但布隆过滤器本身就很省内存。1 亿条数据 0.01% 误判率才 320MB，比把 1 亿个完整 ID 存 Redis 省太多了。
踩坑记录
坑 1：布隆过滤器不支持删除。 用户注销、数据删除后，这个 ID 在布隆过滤器里还是「存在」的。如果业务有删除需求，要么用 Cuckoo Filter（CF.RESERVE），要么定期重建布隆过滤器。我选了后者，每天凌晨跑个定时任务重建一次。
坑 2：新增数据别忘了同步加进去。 新用户注册后，除了写 DB，还得 BF.ADD 到布隆过滤器。我一开始漏了这步，导致新注册用户查自己信息时被布隆过滤器拦掉了，debug 了半天才想起来。
python
# 新用户注册时的完整流程
def register_user(user_data):
# 1. 写入数据库
user_id = db.insert_user(user_data)
# 2. 同步写入布隆过滤器（别漏了！）
r.execute_command('BF.ADD', 'user_filter', str(user_id))
# 3. 预热缓存（可选）
r.setex(f"user:{user_id}", 1800, json.dumps(user_data))
return user_id坑 3：Redis 重启后布隆过滤器数据会丢。 用 RedisBloom 模块的话，布隆过滤器的数据跟普通 key 一样会持久化到 RDB/AOF，没问题。但如果用的是内存实现的布隆过滤器（比如 Guava 的 BloomFilter），进程重启就没了，必须重新构建。
方案三：接口层限流 + 参数校验（别忘了最基本的）
前两个方案都是在缓存层做防御，但最容易被忽略的往往是最前面的入口层。
java
@RestController
public class UserController {
@GetMapping("/api/user/{id}")
public Result<User> getUser(@PathVariable("id") Long id) {
// 1. 参数合法性校验 ------ 最基本但很多人不做
if (id == null || id <= 0 || id > 999999999L) {
return Result.fail("参数非法");
}
// 2. 限流：同一个 IP 每秒最多 10 次请求
// 这里用 Guava 的 RateLimiter 或者 Redis + Lua 实现都行
// 3. 走正常的缓存查询逻辑
User user = userService.getUserById(id);
return Result.success(user);
}
}我们的用户 ID 是自增的 Long 类型，合法范围很明确。攻击者用的那批 ID 里有负数、有超大数、甚至有带字母的字符串（被框架自动转换失败后报了一堆 400）。如果一开始就做了参数校验，至少能挡掉一大半无效请求。
三种方案怎么选
| 维度 | 缓存空值 | 布隆过滤器 | 接口层校验 + 限流 |
|---|---|---|---|
| 实现难度 | ⭐ | ⭐⭐⭐ | ⭐⭐ |
| 防随机 ID 攻击 | ❌ | ✅ | 部分 ✅ |
| 内存开销 | 可能很大 | 很小 | 无 |
| 数据一致性 | 有短暂不一致 | 不支持删除 | 无影响 |
| 适用场景 | key 空间有限 | key 空间极大 | 所有场景 |
最终方案是三层都上：
- 最外层做参数校验和 IP 限流，挡掉明显的垃圾请求
- 中间用布隆过滤器，拦截不存在的 ID
- 最后缓存空值兜底，处理布隆过滤器的误判漏网
三层加上之后，同样的攻击流量再来，MySQL 的 QPS 基本没波动。
小结
缓存穿透这个问题，面试题和实战差距挺大。面试时说一句「用布隆过滤器」就过了，实际上布隆过滤器的初始化、新数据同步、重启恢复、参数调优全是坑。
我现在的实践是：防御要做多层，别指望一招鲜。参数校验是第一道防线但很多人懒得写，布隆过滤器是核心防御但运维成本不低，缓存空值是兜底但不能单独用。三层叠起来才靠谱。
对了，如果你还在用 Redis 6 以下的版本，RedisBloom 模块装起来比较折腾。Redis 7 之后模块管理好了很多，建议直接上 Redis 7 + RedisBloom 的组合，省不少事。