缓存穿透、击穿与雪崩：布隆过滤器原理与实战解析

前几天有个同事在群里发了一条报警：商品详情接口P99延迟从40ms飙到了4s，数据库CPU打到90%，Redis的QPS肉眼可见往下掉。等他打开慢查询一看，清一色都是同一批热门SKU查缓存为空的SQL。当时第一反应是“缓存穿透”，后来我们检查Redis的key分布和发版记录才发现，其实是这批热门商品key集中过期，在过期瞬间正好撞上流量高峰——从根源上讲，这是一次缓存击穿和雪崩叠加的混合事故。

这类事故很多开发都遇到过，但追问下去，不少人连穿透、击穿、雪崩三个词之间的区别都说不清楚，更别说怎么用布隆过滤器去拦截那些根本不存在的key了。这篇文章不打算只背书上的定义，我按实际排查的思路把“三兄弟”拆开，再把布隆过滤器从原理到参数、再到落地的坑一次讲完。适合正在做缓存改造、准备面试系统设计、或者线上已经出现频繁告警但还不知道从哪下手的同学。

1. 一次线上事故的拆解：穿透、击穿与雪崩真的分得清吗

1.1 缓存穿透：查一个根本不存在的数据

缓存穿透最核心的特征是：请求的目标在缓存和数据库里都不存在。正常流程大家都很熟——先查Redis，没命中再查DB，然后把结果写回缓存。但一个key如果是用户输入并且可被伪造的，比如查 uid=-1、skuId=99999999、一串随机生成的订单号，DB查不到自然也就没有东西可以写回缓存。于是同一个不存在的key每一次都完整穿过缓存、打到数据库上。

穿透真正的威胁不是慢，而是“每一次空查询都是有效查询”。如果这个查询背后是一个多表Join或者几个索引联合过滤的重SQL，那每次都会让数据库把磁盘IO、临时表、排序全部走一遍。攻击者根本不需要多复杂的手段，只要用脚本持续生成统计上不会重复的随机ID，数据库就会一直忙在做无用功。某些极端案例里，一个不存在的整数ID能拖垮一个订单服务，就是因为业务代码在DB返回空之后还在继续做二次查询、消息推送之类的附加动作。

那“缓存空值”能不能解决？能，但这是后面要讲的代价问题——空值也会占内存。换句话说，穿透问题本质上是一个“不存在路径上没有缓存落点”的问题，需要一套专门机制来挡住。

1.2 缓存击穿：热点key失效的一瞬间

击穿和穿透就差一个字，很多人混着用，但它们成因完全不同。击穿的前提是数据本身存在，只是由于缓存过期或被人为删除，在某一个极短的时间窗口里，缓存里没有这个key。如果这个key恰好是热点，所有请求在同一瞬间发现缓存为空，就会一起冲向数据库。

典型场景是秒杀。某爆款SKU被放到首页，活动开始前几秒大量用户开始点击。假设这个SKU的详情数据需要聚合库存、价格、优惠券等一堆外部数据，重建缓存要20到50毫秒。一旦key过期时间和流量洪峰撞上，第一波几万个请求在缓存里全部落空，数据库收到的并发量会瞬间放大几十倍，而这种流量通常不是业务真实请求量，是缓存失效导致的“重复回源”。

击穿和穿透的关键差异在于：击穿恢复后缓存就能继续工作，所以我们的防御目标不是“永久拦截”，而是把并发回源压缩到少数几个线程。只要保证同时只有一个线程去重建key，其他线程等一等或者拿旧值，数据库压力就完全可控。

1.3 缓存雪崩：大面积失效引发的连锁反应

雪崩可以理解为击穿的“扩大版”，但也包含一类击穿不会涉及的情况。第一种常见触发点是大量key设置了相近的过期时间。很多业务写缓存时喜欢用同一个基准时间，比如当天零点生成的数据，有效期都设成第二天的零点，或者脚本批量刷缓存时统一用24小时。结果就是某一秒内几千上万个key一起过期，数据库瞬间被这些“同时醒来”的请求淹没。

第二种触发点是Redis实例本身不可用。比如主从切换、网络分区、内存淘汰导致大面积key被逐出，或者某一台Redis节点发生了长时间阻塞。这时候业务层如果完全依赖Redis、没有降级动作，所有请求会直接穿透到数据库，然后数据库跟着被打挂，所谓“缓存雪崩”的本质就是故障在下游存储之间传导。

击穿是“单点key的失效”，雪崩是“一批key或者整层缓存的失效”。生产环境里最要警惕的是它们的复合形态：先有一个热点key击穿导致数据库负载升高，接着其他key因为慢查询影响也开始超时、被逐出，最后演变成大面积雪崩。所以排查线上问题时，不要只看单个现象。

1.4 三者对比与常见误区

要特别注意一个误区：很多人以为“缓存穿透”指的就是所有缓存未命中请求，这不对。未命中但数据存在于DB，这种场景属于普通缓存加载；只有DB也没有数据，才会形成穿透。理解这个区别很重要，因为后面用布隆过滤器时，它只能解决“DB里一定不存在”的那部分请求，对“DB里存在但还没缓存”的请求是不能拦截的。

2. 三个缓存问题的防御方案：哪种手段治哪个病

2.1 防穿透三板斧：参数校验、空值缓存与非法流量拦截

防穿透不是一个方案包打天下，最好分层来做。第一层是参数校验，请求进来先判断ID符不符合业务规则，比如负数、超长字符串、非数字字符，直接返回参数错误。这一层成本最低，能挡掉大部分误操作和初级扫描，但它挡不住“合法格式但实际不存在”的key，比如一个随机生成的18位数字订单号，格式完全正确，就是没这个单。

第二层是空值缓存。DB查到空结果时，把空标记也写进Redis，TTL设短一些，通常30到60秒。伪代码思路如下：

java复制Object value = redis.get(key);
if (value != null) {
    if ("EMPTY".equals(value)) {
        return Result.empty();  // 命中缓存空值，直接返回
    }
    return Result.success(value);
}

Object dbValue = dao.query(key);
if (dbValue == null) {
    redis.set(key, "EMPTY", Duration.ofSeconds(30));
    return Result.empty();
}

redis.set(key, dbValue, ttl);
return Result.success(dbValue);

这里有个容易被忽视的问题：空值标记的TTL不能太长，因为真实数据可能在几秒后就创建了，如果缓存里长期存着一个过期的“空”，新数据就会一直读不到。另外空值value本身也需要精简，不要存一个大对象进去。

第三层是布隆过滤器。当非法key的数量级很大、空值缓存也扛不住内存压力时，就轮到布隆过滤器上场了。它能在请求打到DB之前，先用极低的内存成本判断“这个key一定不存在”。如果一个key被判定为不存在，直接return，连Redis都不查，更不用说DB。这一层是后面要重点展开的内容。

2.2 防击穿：缓存重建锁该怎么加

防击穿的核心思路是给“重建缓存”这个动作加互斥控制。业界最经典的是分布式锁方案：缓存没有命中时，先尝试获取一把key维度的锁，只有拿到锁的线程才允许查DB并写缓存，其他线程要么短暂等待、要么先用旧值兜底。

Redis实现互斥锁时，一定要注意命令的原子性，最稳妥的是SET命令配合NX和EX参数：

bash复制SET lock:sku_detail:1001 1 EX 5 NX

如果返回OK，说明当前线程拿到了锁，可以查DB、写缓存，最后用Lua脚本或者del删除锁。如果返回空，说明其他线程正在重建，当前线程可以选择sleep几十毫秒后重试，也可以直接把旧值返回给调用方。用SETNX单命令再加EXPIRE两步操作是新手最容易踩的坑，两步之间进程崩溃会导致锁没有过期时间，直接死锁。

这个方案理解起来简单，实战里却有一个很关键的粒度问题。锁的key不能做得太粗，比如一个“商品详情缓存锁”如果只用了固定的 lock:sku，那么一个SKU的失效会让所有SKU的详情重建全部排队，系统吞吐量直线下降。正确做法是把锁的粒度细化到业务实体维度，例如 lock:sku:skuId、lock:order:orderId，这样才能保证不同key之间的重建能并行。

除了加锁，还有一套更平滑的“逻辑过期”方案：不给Redis key设置物理TTL，而是在value里存一个过期时间戳，比如：

json复制{"data": "...", "expireAt": 1700000000000}

每次读取时判断如果当前时间超过expireAt，则先返回旧值给调用方，同时异步发起一个后台任务去刷新缓存。这种方案的好处是请求永远不会阻塞，用户体验上不会出现超时，代价是可能存在几百毫秒到几秒的旧数据窗口。对于那些允许短暂读到旧版本数据的业务（比如商品介绍页、资讯列表），逻辑过期比互斥锁更实用。

2.3 防雪崩：过期时间打散、缓存预热与多级容灾

雪崩第一类成因是批量过期，解法也最直接：把固定的过期时间改成“基础时间+随机偏移”。比如原来所有key都是24小时过期，改成都是一天的同时加一个0到300秒的随机值：

java复制long baseTtl = Duration.ofHours(24).getSeconds();
long random = ThreadLocalRandom.current().nextLong(300);
redis.setex(key, baseTtl + random, value);

这个随机偏移的幅度要看业务容忍度。缓存有效期越短，随机值相对越要大一些，避免数据在同一分钟内成片失效。对于批量定时任务生成的缓存，还要额外做预热：在数据快过期之前，用后台任务主动把热点key刷新一遍，而不是等请求来了再重建。

雪崩第二类成因是Redis不可用，这一层防护逻辑就复杂了。我在生产环境里习惯按三级来设计：

• 一级是本地缓存兜底，比如Caffeine，把最热门的几百个key在JVM内再放一份，即使Redis故障，本地缓存还能挡掉一部分流量；
• 二级是回源限流，对打到DB的查询做并发控制和速率限制，宁可丢弃少量请求，也不能让DB被击穿；
• 三级是熔断降级，当Redis连续不可用超过阈值时，直接关闭依赖缓存的非核心功能，把资源留给核心链路。

这套组合不能省。只做过期时间打散，解决的是“热闹”的场景，一旦Redis节点真挂了，该崩还是会崩。本地缓存从30%到50%的命中率里挤出来的空间，往往就是数据库活下来的关键。

2.4 防御方案总表

这张表可以作为复盘时的检查清单。每次线上缓存出问题，先对着表判断自己属于哪一类、现有防护覆盖了哪一层，再动手改代码，比临时拍脑袋加逻辑靠谱得多。

3. 布隆过滤器原理：为什么它的“不存在”结论可以信

3.1 适合用布隆过滤器的场景盘点

布隆过滤器不是新东西，但很多同学第一次接触是在缓存穿透的文章里，容易误以为它只能用在Redis前面。实际上它解决的是一个很通用的问题：用很小的内存开销判断一个元素“是否在集合中”。

适合布隆过滤器的场景有几个特征。第一，集合元素总量可控，可以全量加载；第二，可以容忍极低概率的“误判为存在”；第三，绝对不能容忍“漏判为不存在”，也就是说，如果系统判断“不在集合”，那它必须真的不在。满足这三个特征的业务场景非常多，比如判断一个手机号是否注册过、一个订单号是否在本批次中、一个URL是否已经被爬虫处理过、一个用户ID是否存在。

缓存穿透拦截自然也适用。我们的目标是要拦截掉那些“永远不会出现在DB”的key，比如随机生成的ID。布隆过滤器可以把所有历史合法ID放进去，查询时如果过滤器说“不存在”，那基本可以确定DB里也没有，直接返回空即可；如果过滤器说“存在”，则继续查Redis，反正Redis里没有再去查DB。注意这里没有业务正确性问题——因为判定为“存在”的请求最后还是会走一次DB，顶多损失一点性能。

3.2 位数组与多个哈希函数如何标记一个key

布隆过滤器的底层数据结构是一个很长的位数组（bit数组），每个位置只有0和1两个状态。插入一个key时，先用k个不同的哈希函数分别计算出k个位置，然后把这k个位全部置为1。查询key是否在集合中时，同样计算这k个位置，如果有一个位置是0，就说明这个key一定不在集合里；如果k个位置全是1，那这个key大概率在集合里，但也可能只是其他key的哈希结果碰巧把这些位置全部占用。

我习惯用一个生活场景来解释：假设餐厅门口有一块巨大的签到黑板，每个来过的人都会把自己的指纹按在几个随机的格子上。新来一个人想知道自己是否来过，就去比对同样几个格子；只要有一个格子是空的，就能确定自己没来过。但反过来，如果格子全脏了，也不能完全证明自己来过，因为可能是好几个人凑巧把格子都踩脏了。

这里有两个结论很关键：

• 布隆过滤器对“不存在”的判断是严格正确的，不会漏判。
• 布隆过滤器对“存在”的判断是有误差的，可能误判。

正是基于这个语义，使用它时才不能问“它说有，那一定会有吗”，而要问“它说没有，那还需要继续查吗”。

3.3 不可删除与误判带来的应用红线

布隆过滤器一个被反复踩坑的特性是：标准版本不支持删除。因为一个位可能同时被多个key标记，你无法安全地只把某一个key对应的位置回0，那会影响到其他key的判断。时间一长，随着插入的key越来越多，位数组里1的密度越来越大，误判率会逐渐上升。

所以布隆过滤器适合两种数据：一种是只增不改的集合，比如订单号、历史ID；另一种是允许定期重建的集合，比如每天凌晨把当天的有效用户全量重建一次。如果业务里元素频繁增加和删除，标准布隆过滤器就需要谨慎评估了。

另一个红线是：误判会带来“误杀”。假设我们用它判断用户是否注册，过滤器误判一个未注册用户“已存在”，用户只是多走一次查库流程，没影响正确性；但如果反过来把判断结果当作最终结论，比如“过滤器说不存在就拒绝请求”，一旦出现误判（过滤器对存在的key判断为不存在不会发生，这里指的是对不存在的正常key判断误杀？）——其实这里容易绕晕，我再更正一下：布隆只说“可能存在”或“一定不存在”，不会把真实存在的key判定为不存在。它真正的风险是会把不存在的key判定为“可能存在”，导致拦截失效，也就是让一部分穿透流量漏过去。正因为这一点，我常说布隆过滤器是“降低穿透概率、提高攻击成本”，不是“彻底消灭穿透”。实战中往往要叠加空值缓存和限流才能做到多层兜底。

4. 工程落地：布隆过滤器的选型、参数计算与示例

4.1 四种接法：本地、Redis、Module与自研

布隆过滤器在工程里常见的接入方式有四类，各有各的长短。

第一种是Google Guava的BloomFilter。它跑在JVM进程内，使用简单、性能极高，适合单机应用或者本地缓存防穿透。但它的数据不跨节点共享，在微服务多实例部署时需要每个实例都加载一份全量数据，如果集合有几百万上千万元素，启动时初始化会有内存和耗时开销。

第二种是用Redis的bitmap自研。思路是用SETBIT和GETBIT命令自己管理位数组，通过Lua脚本保证多个哈希位置的原子性。这个方案的优点是不需要额外组件，适合团队不想引入新依赖的情况；缺点是所有逻辑都要自己写，包括哈希函数、key分布、位上越界处理，要小心定位偏移超过bitmap上限的问题。

第三种是成熟客户端Redisson的RBloomFilter。它内部也是基于Redis，但封装了扩容、比较完整的API，分布式场景下多个服务可以共用同一个布隆过滤器，是目前Java生态比较主流的选择。

第四种是RedisBloom模块。它提供了BF.RESERVE、BF.ADD、BF.EXISTS等命令，是官方生态推荐的方向。生产环境需要在Redis服务端安装模块，多了一步运维成本，但性能和语义最完备。

4.2 参数确定：根据数据量和误判率反推内存

很多人用布隆过滤器时直接抄网上配置，比如容量填10000、误判率填0.01，这个习惯很危险。布隆过滤器的内存占用和哈希函数数量直接由两个数据决定：预估的元素数量n和能容忍的误判率p。

基本公式是这样的：

• 位数组长度：m = - n * ln(p) / (ln(2))^2
• 哈希函数个数：k = (m / n) * ln(2)
• 实际误判率：(1 - e^(-k*n/m))^k

举例来说，如果预估元素数量是1000万，能容忍的误判率是1%，代入公式后需要约9585万个bit，也就是大约11.4MB内存；哈希函数个数取整约等于7。如果误判率收紧到0.1%，位数组长度会变成约1.44亿个bit，也就是大约17MB左右，哈希函数个数约10个。

从表中能看到一个很重要的现象：误判率从1%降到0.1%，内存并不会呈十倍增长，只增加了50%左右。所以项目里如果内存不是极端紧张，更建议把误判率设置到0.1%或者更低，没有必要为了省几MB内存去忍受更高的误判。真正需要小心的是n，如果预估错误——比如估了100万但实际涨到1000万——误判率会迅速恶化，所以上线后一定要监控布隆过滤器的实际误判情况。

4.3 一套可落地的Java示例

用Redisson落地是最快的，代码大概长这样：

java复制// 初始化Redisson客户端
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient redisson = Redisson.create(config);

// 创建布隆过滤器，名称 biz:sku:catalog
// expectedInsertions=1000万，falseProbability=0.001
RBloomFilter<String> skuFilter = redisson.getBloomFilter("biz:sku:catalog");
if (!skuFilter.isExists()) {
    skuFilter.tryInit(10_000_000L, 0.001);
}

// 系统初始化时把DB存在的skuId全量写入
for (String skuId : skuIdFromDb) {
    skuFilter.add(skuId);
}

// 请求入口处判断
if (!skuFilter.contains(requestSkuId)) {
    return Result.empty(); // 过滤器认为肯定不存在，直接返回
}
// 否则继续走缓存

注意这段代码里的isExists()和tryInit()非常关键。如果每次都直接调用tryInit，它会覆盖掉原有配置，导致过滤器内容被清空重新初始化。上线初期最典型的故障就出在这里——每次应用启动都重建过滤器，构建期间所有合法请求全部被拦截或全部穿透到DB。

对于数据量特别大、初始化耗时很长的情况，我推荐一个重建设计：先创建新名字的过滤器，比如biz:sku:catalog:v2，通过后台任务全量加载并预热，等预热完成后再在代码里切换查询入口。整个过程业务无感，也规避了“删除重建”窗口期的空档问题。

4.4 顺带聊聊布谷鸟过滤器

搜索热度里经常能看到“布谷鸟布隆过滤器”，这里先澄清一个说法：布谷鸟过滤器不是布隆过滤器的升级版实现，而是一种完全不同的过滤器结构。它的核心设计是每个元素在数组中有两个候选桶，插入时如果两个桶都满了，就随机把一个旧元素的指纹踢出去，被踢的元素再去找自己的另一个候选桶，有点像布谷鸟把自己的蛋挤走其他鸟蛋的巢穴。这也是它名称的由来。

布谷鸟过滤器最大的优势是支持删除操作，同时内存占用在低误判率下比布隆过滤器更省。这对某些“集合元素会过期、需要动态删除”的业务场景很有吸引力。但它也有自己的短板：实现复杂，存在插入失败后无限撞桶的问题，需要额外的退化重哈希机制；重复插入和删除频繁时，可能导致循环踢出。所以生产环境如果团队没有充分压测，我不建议一上来就替换成熟的布隆过滤器方案。布隆过滤器生态成熟、可观测性好、文档案例多，稳定性在工程里往往比那点内存优势更重要。

5. 实践中的“坑位”记录与排查思路

5.1 坑一：空值缓存把防穿透层变成了垃圾场

有一年我们给某个用户查询接口加了空值缓存来防穿透，上线后数据库压力确实降了，但Redis内存开始以肉眼可见的速度上涨，三天内涨了快两个G。当时很多人第一反应是“是不是缓存key没设过期时间”，排查后发现大部分key都正常设置了短TTL。后来看监控里的键空间分布，罪魁祸首是攻击者根本没有停手，而是不断生成新的合法格式但实际不存在的用户ID，每个ID都触发一次DB空查并写入空值缓存。

这个问题的本质是：空值缓存只是把“DB的压力”转移到了“Redis的内存压力”上，如果恶意请求的量足够大，它依然会被打爆。这次的修复方案分了两步：先把布隆过滤器加在空值写入逻辑之前，让过滤器认为“肯定不存在”的key不写入任何缓存；再把大范围的非法请求做了实时限流，对单位时间内空结果占比超过阈值的IP直接拒绝服务。经过这轮改造之后，内存曲线很快就平了。

5.2 坑二：击穿锁粒度太大，全库热点互相排队

另一个印象很深的故障是服务整体响应变慢，但数据库负载并不高。排查应用日志时发现大量线程阻塞在“lock wait”阶段，好几百个请求排队等着同一个锁。问题就出在加锁代码的写法上，同事把锁key定义为常量lock:detail，没有拼接业务ID。结果一个热点商品过期后，线程拿到了锁开始重建，其他所有商品的详情请求也都在等同一把锁。

这种锁的正确姿势必须是业务ID级别，甚至更细到“某次重建动作”级别。锁key设计为lock:detail:{skuId}之后，不同SKU的重建就互不影响了。我后来又顺手加了一个带超时保护的重试，防止极端情况下线程等锁时间太长导致调用链超时。这个坑的教训是：防击穿的锁和普通分布式锁一样，锁的粒度直接决定了并发上限，一定要根据业务访问模型去设计，而不是随手用一个固定字符串。

5.3 坑三：布隆过滤器数据同步不及时，正常用户被误杀

布隆过滤器应用中最危险的问题不是误判率翻车，而是新数据同步不及时导致合法key被当成“不存在”。我们有一次上线了订单号布隆过滤器，历史订单全量导入后一切正常，但几个小时后业务方反馈新创建的订单在查询时大面积报“订单不存在”。排查链路走了一遍：从网关日志看到请求确实到达了服务，结果却在布隆过滤器判断时被拦截了。因为新订单落库后，触发器把订单ID写入布隆过滤器的逻辑还没有来得及执行，查询请求已经先到了，过滤器一看“不存在的语义为真”，直接返回了空。

修复方案是调整数据同步顺序：新增数据先写DB，然后立刻同步写布隆过滤器，最后再让外部查询可见。另外在并发量允许的范围内，对过滤结果加了降级策略——过滤器判定不存在时，不直接返回失败，而是带着告警标记把这个请求降级成“查一次DB再做最终判断”，同时记录一条WARN日志。等确认过滤器数据跟上了，再把降级开关关闭。这套“先兜底、再告警、最后拦截”的上线方式，几乎适用于所有引入布隆过滤器的业务。

5.4 写在这里的体会

这几年的缓存治理经验里，我最大的体会是：缓存三兄弟很少单打独斗地出现，往往是先被穿透打出一个缺口，接着热点key被击穿，最后演变成整层雪崩。布隆过滤器也好、分布式锁也好、过期时间随机化也好，都不是一个“装了就免疫”的插件，而是一套需要根据业务数据特征、访问模型、故障容忍度去逐层设计的防御体系。

如果你现在正准备给系统加缓存治理，建议先从压测开始。压出一个热点key失效时数据库能承受的最大并发，再决定门禁阈值设多少；先弄清楚业务集合的真实数量级，再代入布隆公式去算内存。很多看起来合理的高大上方案，只要数据量一放大就会露馅，这一点是光看文章学不来的，真的要落到自己的监控面板上跑一遍才知道。