缓存穿透与布隆过滤器：原理、选型与落地实践

这是一个很典型的“看着简单、调好难”的缓存优化点。很多团队在缓存穿透这个问题上，第一反应就是“加布隆过滤器”，但真正落地的过程中，从原理理解、工具选型到参数配置，每一步都藏着不少坑。我结合自己的实际经验，把缓存穿透的排查思路、布隆过滤器的原理，以及Guava和RedisBloom这两种主流实现从选型到落地写了一份完整的复盘，希望能帮你少走弯路。

1. 先搞清楚你的系统到底是不是缓存穿透

在动手引入布隆过滤器之前，我建议你先花半天时间把问题的性质确认清楚。很多人一看到数据库压力大，就急着上布隆过滤器，结果搞了半天发现根本不是缓存穿透，而是缓存击穿或者缓存雪崩，方案完全用错了。

1.1 穿透、击穿、雪崩，很多人分不清

这三个概念在日常沟通里经常被混着说，但它们的成因、现象和解决方案截然不同。

缓存穿透：查询一个根本不存在的数据。比如查一个不存在的商品ID，缓存里没有，数据库里也没有。如果这个请求量大，每次都会打到数据库，而数据库每次也都是白查一遍。因为数据不存在，缓存永远没法生效，请求会全部漏到存储层。这就像有人拿着假门票反复闯闸机，闸机每次都认真检查，但每次放行的都是空气。

缓存击穿：一个热点key在缓存过期的瞬间，大量请求同时涌入，全部打到数据库。注意这里的数据是真实存在的，只是因为缓存恰好失效了，导致并发都穿透到DB。这就像演唱会散场时，所有人都挤同一个出口，平时没问题，那一刻就堵死了。

缓存雪崩：一大批key在同一时间段集中过期，或者Redis实例宕机，导致大量请求直接打到数据库，数据库瞬间扛不住。这跟击穿的区别在于，击穿是单个热点key，雪崩是一大片key同时失效。

这三种问题的应对策略也完全不同：穿透靠布隆过滤器或者缓存空值，击穿靠互斥锁或者逻辑过期时间，雪崩靠过期时间抖动、多级缓存或者高可用架构。

1.2 怎么确认线上就是穿透问题

诊断穿透问题，我的排查路径一般是这样的：

1. 看Redis监控，如果get请求的QPS很高，但是hit rate（命中率）突然掉得很厉害，说明大量请求在缓存里没找到数据。
2. 看数据库监控，如果select的QPS和Redis的miss量基本持平，而且查询的都是同一个范围的不存在ID，那穿透基本坐实。
3. 看应用日志，如果出现大量“查询结果为空”的记录，而且请求参数集中在某些非法或者异常的ID段，比如负数、超大数、随机字符串，那就更确定了。

我遇到过最典型的场景就是：某个对外开放的API接口，调用方因为代码bug，把一个ID字段传成了随机数。结果就是Redis的QPS很高但全部miss，数据库的QPS直接被打满，慢查询日志里全是那种花费几秒钟的无效查询。后来排查下来，就是典型的缓存穿透，而不是什么高并发问题。

1.3 穿透问题的排查链路与数据收集

先通过观测工具把数据收集起来。命令示例如下（以Redis和MySQL为例）：

bash复制# Redis上查看key的命中情况
redis-cli INFO stats | grep keyspace_

# 如果是Redis 4.0以上，可以用latency监控查看延迟
redis-cli --latency-history

# 通过slowlog查看慢查询，确认是否有大量空查
redis-cli SLOWLOG GET 50

通过观察expired_keys和keyspace_hits、keyspace_misses三个指标，可以比较清晰地看到缓存命中的全貌。如果是穿透，keyspace_misses会显著高于正常水平，同时数据库的Com_select会同步飙升。

核心结论：穿透的本质是请求了不存在的数据，解决思路要么是让不存在的数据在缓存层“留下痕迹”（缓存空值），要么是在缓存层之前就“拦截非法请求”（布隆过滤器）。布隆过滤器就是后一种思路的经典方案。

2. 布隆过滤器原理：一个位数组和k个哈希函数的故事

布隆过滤器（Bloom Filter）是1970年由Burton Howard Bloom提出的，用于判断一个元素是否在一个集合中。它的核心特点是：如果它说一个元素“不存在”，那这个元素一定不存在；如果它说“存在”，那可能是误判。

2.1 为什么不直接用Set或者Hash

很多人会问：我在Redis里直接Set一个所有合法ID的集合，查的时候直接用SISMEMBER判断不就行了吗？为什么非要用布隆过滤器？

你用Set当然可以，但如果合法ID有几千万甚至上亿个，这个Set占用的内存会非常可观。以亿级数据为例，每个ID如果是long类型8字节，加上Redis的dictEntry开销（约60-100字节），一亿个ID可能要占用6-10GB内存。这还只是一个业务场景。布隆过滤器的核心价值在于：用极小的内存空间表示海量元素的集合，代价是牺牲一定的准确性（存在误判率）。

以布隆过滤器为例，一亿个元素，误判率控制在1%，只需要大约120MB的内存。如果是Set结构，这个量级通常在几个GB以上。这就是布隆过滤器的空间优势来源：它不需要存储元素本身，只存储元素的“指纹信息”，而指纹存储在固定大小的位数组里。

2.2 原理拆解：写入和查询两个阶段

布隆过滤器底层是一个bit数组（每个位置只有0和1两种状态），加上k个独立的哈希函数。

写入过程（add）：

1. 元素通过k个哈希函数计算出k个位置。
2. 把这k个位置的值都置为1。

举例，假设位数组长度是16，哈希函数有3个（记为h1、h2、h3）。元素“商品ID:1001”经过三个哈希函数计算后，得到位置2、7、14，那么就把bit[2]、bit[7]、bit[14]置1。

查询过程（mightContain）：

1. 元素通过同样的k个哈希函数计算出k个位置。
2. 检查这k个位置。如果任何一个位置是0，说明这个元素一定不在集合中，返回“不存在”；如果所有位置都是1，返回“可能存在”。

这就是误判的来源：元素A和元素B虽然本身不同，但它们的哈希结果可能在某些位上发生重叠，导致一个不存在的元素，其k个位置恰好都被其他元素置为1了。

2.3 误判率怎么来的，怎么算

有两个参数直接影响误判率：

• n：预期元素数量（你要存多少个元素）
• m：位数组的长度（多少个bit位）
• k：哈希函数的个数

位数组长度m的计算公式（n为预期元素数量，p为期望误判率）：

code复制m = - (n * ln(p)) / (ln(2)^2)

哈希函数个数k的计算公式：

code复制k = (m / n) * ln(2)

简单推算一下：n=1亿，p=1%，代入公式得m≈95.8千万bit，也就是约114MB，k≈6.69，取整为7个哈希函数。

结论是：误判率p越低，m越大，需要的哈希函数k也越多。Guava的BloomFilter类在创建时，你只需要传入expectedInsertions（预期插入数量）和fpp（误判率），它内部会自动计算m和k，不需要你手动算。

2.4 两个容易被忽视的边界条件

布隆过滤器不支持删除元素。因为一个bit可能被多个元素共享，你如果把这个bit置为0，可能导致其他元素查询时被误判为“不存在”。如果需要支持删除，就得用Counting Bloom Filter（计数布隆过滤器），每个位置用一个计数器替代bit，删除时计数器减一。但代价是空间占用成倍增加。

布隆过滤器无法枚举集合中的元素。它只回答“在不在”，不回答“有哪些”。如果需要遍历所有ID，还是得靠原始数据源。

3. Guava版布隆过滤器：从引入依赖到生产级配置

Guava是Google开源的Java工具库，内部提供了BloomFilter实现，也是很多Java团队的第一站。它的优点是零外部依赖、使用简单，缺点是只能在单机内存中使用，无法跨进程共享。

3.1 引入依赖与基本用法

在Maven项目中引入Guava：

xml复制<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>33.0.0-jre</version>
</dependency>

核心示例代码：

java复制import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;
import java.nio.charset.StandardCharsets;

public class BloomFilterDemo {
    public static void main(String[] args) {
        // 预期插入10万个元素，误判率设置为1%
        BloomFilter<String> bloomFilter = BloomFilter.create(
                Funnels.stringFunnel(StandardCharsets.UTF_8),
                100000,
                0.01);

        // 批量初始化数据
        for (int i = 0; i < 100000; i++) {
            bloomFilter.put("product:" + i);
        }

        // 查询存在的元素
        System.out.println(bloomFilter.mightContain("product:99999")); // true

        // 查询不存在的元素
        System.out.println(bloomFilter.mightContain("product:200000")); // 大概率false，也可能true（误判）
    }
}

值得注意的是，Guava的BloomFilter.create()有多个重载方法。最常用的就是传入Funnel、expectedInsertions和fpp。Funnel的作用是把对象转换为字节流，对于字符串类型，直接使用Funnels.stringFunnel()即可。

3.2 参数怎么定：别拍脑袋，要算

很多人在这一步会犯一个“差不多就行”的错误。实际上，expectedInsertions和fpp直接决定了位数组占用多少内存。

我来做一组对比实验（同样是100万个元素，不同误判率）：

可以看到，误判率从10%降到0.1%，内存只增加了三倍左右，但误判率却下降了两个数量级。因此，在内存可接受的前提下，我建议误判率往低设置，一般推荐0.01到0.001之间。

expectedInsertions的预估更关键。如果设置得太小，当实际插入数量超过预期后，误判率会急剧上升；如果设置得太大，则浪费内存。我的经验是，如果业务量增长较快，按当前量级的5到10倍预估比较稳妥。

3.3 线程安全和使用边界

Guava的BloomFilter是线程不安全的。多线程环境下做put操作，需要自行加锁，或者使用Striped锁机制。

另一个边界是：它是JVM内存级别的。如果应用是多节点部署，每个节点都要单独维护一份布隆过滤器。这就带来两个问题：

1. 数据一致性：如果某个节点只初始化了部分数据，它查漏的请求就会被误判为“不存在”，直接打到数据库。
2. 内存浪费：每个节点都要存一份同样的位数组，节点越多浪费越大。

所以Guava的布隆过滤器适合单机应用、数据量可控、初始化数据基本固定不变的场景。如果你的服务是多节点部署，数据还在持续增长，就应该考虑RedisBloom这种集中式方案。

3.4 一种典型的错误用法

我在代码评审中见过这种写法：每次请求来了，都去数据库全量加载商品ID列表，再重新构建布隆过滤器，然后判断。这个做法有两个致命问题：

• 每次请求都重建过滤器，性能和直接查数据库没有本质区别，过滤器完全白做了。
• 如果构建过程中其他线程读到了半初始化的过滤器，可能产生严重误判。

正确做法是：在应用启动时，把数据库中的合法ID列表一次性加载并构建到布隆过滤器中，构建完成后再对外提供服务。后期数据增量变化时，通过定时任务或监听消息队列的方式，增量补充到过滤器中。

4. RedisBloom落地：模块化安装与命令实操

如果说Guava是Java生态的解决方案，那么RedisBloom就是Redis生态的官方模块。RedisBloom从Redis 4.0开始可以作为模块加载，提供了布隆过滤器、Cuckoo Filter等高级数据结构。它的核心优势是集中式存储，多节点共享同一份过滤器数据，不存在“每个节点各存一份”的问题。

4.1 安装方式对比

源码方式下载编译：

bash复制git clone --recursive https://github.com/RedisBloom/RedisBloom.git
cd RedisBloom
make
# 在redis.conf中加入 loadmodule /path/to/redisbloom.so
# 重启Redis

Docker方式启动：

bash复制docker run -d -p 6379:6379 redis/redis-stack-server:latest

如果公司用的是云Redis（如阿里云、腾讯云），控制台上一般都有“模块管理”或者“扩展数据结构”入口，直接开通RedisBloom即可，不需要自己维护模块文件。

4.2 核心命令实操

RedisBloom提供了四个核心命令：BF.RESERVE（创建过滤器）、BF.ADD（添加元素）、BF.MADD（批量添加）、BF.EXISTS（查询元素）。

bash复制# 创建一个名为 product_filter 的布隆过滤器
# 预期元素数量 1000000，误判率 0.01
BF.RESERVE product_filter 0.01 1000000

# 添加单个元素
BF.ADD product_filter product:1001

# 批量添加元素
BF.MADD product_filter product:1002 product:1003 product:1004

# 查询元素是否存在
BF.EXISTS product_filter product:1001
# 返回 (integer) 1，表示可能存在

BF.EXISTS product_filter product:9999
# 返回 (integer) 0，表示一定不存在

BF.RESERVE如果不执行，直接调用BF.ADD，RedisBloom会以默认参数（误判率0.01，预期容量100）自动创建过滤器。但这样会导致容量太小，后续误判率飙升。所以生产环境建议先执行BF.RESERVE指定容量和误判率，再执行添加操作。

还有一个值得注意的命令是BF.INFO，可以查看当前过滤器的容量、元素数量、位数组大小等统计信息：

bash复制BF.INFO product_filter

4.3 Java侧如何调用RedisBloom

Java侧通常通过Lettuce或者Redisson客户端来操作。

Lettuce示例：

java复制RedisClient redisClient = RedisClient.create("redis://localhost:6379");
StatefulRedisConnection<String, String> connection = redisClient.connect();
RedisCommands<String, String> commands = connection.sync();

// 创建布隆过滤器
commands.execute("BF.RESERVE", "product_filter", "0.01", "1000000");

// 添加元素
Boolean added = commands.execute("BF.ADD", "product_filter", "product:1001");

// 判断元素是否存在
Boolean exists = commands.execute("BF.EXISTS", "product_filter", "product:1001");

Redisson更简洁，它封装了布隆过滤器的客户端接口：

java复制RBloomFilter<String> bloomFilter = redisson.getBloomFilter("product_filter");
bloomFilter.tryInit(1000000L, 0.01);
bloomFilter.add("product:1001");
boolean exists = bloomFilter.contains("product:1001");

4.4 RedisBloom的高可用注意事项

RedisBloom虽然解决了多节点共享问题，但也带来一个新的关注点：如果Redis集群中的某个节点挂了，或者发生了主从切换，布隆过滤器的数据是否完整。

在生产环境中，我强烈建议：

• 使用Redis Sentinel或者Cluster模式部署，保证Redis本身的高可用。
• 定期对包含布隆过滤器key的实例做RDB备份。
• 如果业务允许，在应用启动时对布隆过滤器做一次“幂等性”校验，例如对比数据库中的ID总数和BF.INFO中统计的元素数量，不一致则重建过滤器。

RedisBloom本身不支持直接导出或导入过滤器，备份只能依赖Redis自身的持久化机制。这也是一个需要提前规划好的运维点。

5. Guava还是RedisBloom：选型决策点逐条拆解

这两套方案没有绝对的好坏，关键看你的架构形态和业务特征。我从以下几个维度做了对比，你可以直接套用这个框架来做决策。

5.1 什么时候无脑选Guava就够了

如果满足以下条件，Guava的BloomFilter完全可以满足需求：

• 应用只有单节点，或者多节点但每个节点的数据量一样且独立。
• 过滤器的数据集在启动时就能确定，后续变化很少。
• 过滤器的数据量在百万级别以内，内存可接受。
• 不想为这个功能引入额外的Redis运维成本。

典型场景：某个内部管理系统的用户ID合法性校验，用户总量几十万，变化频率低，单机部署就够。

5.2 什么时候必须上RedisBloom

• 应用多节点部署，且各节点收到的请求不均衡，无法确定“哪个节点该存哪部分数据”。
• 过滤器的数据是动态增长的，比如每天新增几十万个商品ID，期望在启动时全量加载已经不现实。
• 过滤器数据量达到千万级以上，单机内存已经吃紧，需要集中在Redis中管理。
• 多个服务共用同一份ID合法性判断，比如订单服务和商品服务都要判断商品ID是否存在。

这类场景下，RedisBloom的集中式存储能避免每个节点各自维护一份数据带来的不一致问题。

5.3 我的经验：初期用Guava，规模上来再迁移

我给团队的建议常常是：不要一开始就在Guava和RedisBloom之间纠结。业务初期，数据量小，用Guava快速落地，成本最低。当监控指标显示误判率肉眼可见地上升，或者应用节点数扩展到3个以上，再平滑迁移到RedisBloom。迁移的成本并没有想象中高，因为核心代码逻辑是一样的——初始化过滤器、写入数据、查询数据——只是把数据存储层从堆内换到了Redis。

6. 布隆过滤器不是银弹：这几种场景别硬上

布隆过滤器解决缓存穿透的能力很强，但它并非万能。以下这几种场景，布隆过滤器的效果会大打折扣，甚至完全不适用。我逐一说明。

6.1 数据频繁删除的场景

前面提到过，布隆过滤器不支持删除元素。如果业务上允许ID被删除（比如商品下架后ID就不能再查询），那布隆过滤器里这个ID依然存在，查询时依然会通过过滤器的校验，然后打到数据库找到空结果，再走一遍缓存空值的逻辑。

这种情况下，你可以考虑两种处理方式：

1. 定时重建布隆过滤器，把已删除的ID剔除。但重建期间要保证过滤器的一致性，不能边重建边使用。
2. 使用Cuckoo Filter（布谷鸟过滤器），它支持删除操作。RedisBloom也提供了CF命令系列，包括CF.ADDNX和CF.DEL。但注意，Cuckoo Filter在删除时如果删除不存在的元素，可能导致数据损坏，需要谨慎使用。

6.2 查询参数高度随机的场景

布隆过滤器适用于“合法ID集合可枚举”的场景。但如果你的查询参数是随机的、无规律的字符串，比如搜索关键词或者日志ID，那布隆过滤器能发挥的作用就非常有限了。因为合法集合本身就是全量的、无限增长的，没有固定的“合法”边界。

这种场景下，更合适的方案是缓存空值：当数据库查到空结果时，也在缓存里写一个特殊的空值标记（比如存入一个固定的字符串__EMPTY__，并设置较短的过期时间，如5分钟），防止缓存穿透反复打库。

6.3 对误判零容忍的业务

虽然布隆过滤器的误判率可以调低，但永远不可能降到0。如果业务上绝不允许“误判一个不存在的ID存在”，那布隆过滤器就不适合作为唯一防线。

举个例子，如果查询ID不存在，结果会带来法律风险或者资金风险，那过滤器一旦误判，就会放行一个非法请求。此时应该采用其他方案，比如直接查数据库，或者用精确的数据结构（如Redis的Set）做判断。

6.4 布隆过滤器和缓存空值该怎么配合

一个比较完善的穿透防护方案是布隆过滤器 + 缓存空值组合使用：

1. 请求先经过布隆过滤器，如果过滤器判断“不存在”，直接返回空，不查缓存也不查数据库。
2. 如果过滤器判断“可能存在”，则查缓存。
3. 缓存miss后查数据库，如果数据库查到数据，回填缓存；如果数据库也查不到，写一个短TTL的空值到缓存，防止下一次穿透。

这样双保险的效果是：布隆过滤器拦截了绝大多数不存在的数据请求，缓存空值兜底了布隆过滤器误判以及数据被删除后的场景。我比较推荐这个组合，因为它把两种方案的优点都利用了。

7. 生产环境踩过的三个坑：误判率、容量预估、数据预热

最后这部分，我复盘几个自己实际踩过的坑，算是给后来者的参考。

7.1 误判率设置得“过于乐观”，导致穿透流量漏了

我第一次给订单系统加布隆过滤器时，把误判率设成了0.1（10%），觉得“反正就算误判了也只是多查一次数据库”。结果在高峰期，100%的请求都会经过过滤器，10%的请求都会漏过去，数据库还是每秒多了几千次无效查询。

后来我把误判率调到0.001，内存只增加了不到两倍，但漏过的流量直接降了两个数量级。结论：在内存允许的情况下，误判率宁可设低一点。0.01是底线，0.001是比较推荐的值。

7.2 容量预估不足，导致误判率指数级上升

这个坑更隐蔽。布隆过滤器的误判率只有在“实际插入元素数量小于等于预期容量”时才成立。如果实际插入数量超过了expectedInsertions，误判率会呈指数级上升。

举个例子，你创建过滤器时设了expectedInsertions=100万，fpp=0.01。实际运行半年后，插入数据达到了1000万，这个时候误判率可能会飙升到20%-40%。不存在的ID里，有将近一半会被误判为“存在”，全部漏到数据库。

解决这个问题的方法是：容量预估时留足余量，按当前量级的5到10倍设置。同时，对过滤器做存量监控。Guava没有直接提供查看当前插入量的方法，但你可以维护一个计数器的字段；RedisBloom则可以直接用BF.INFO查看当前元素个数。

7.3 数据预热时机不对，服务刚启动就误判大量合法请求

还有一个很常见的问题：应用启动时，一边加载布隆过滤器，一边开始接收线上流量。如果你还没有把数据库的全部合法ID加载完，就有请求进来查询，那很可能会被刚初始化的过滤器误判为“不存在”。

我见过一次线上事故，服务在启动时异步加载布隆过滤器，结果加载到一半，来自上游的重试流量进来了，导致大量合法请求直接被过滤器拦截，业务方反馈“订单查不到了”。

解决方式：

1. 同步加载：应用启动时阻塞等待布隆过滤器初始化完成，再对外提供服务。对于数据量大的场景，这个过程可能耗时较长，但安全性最高。
2. 加载完成后设置一个“过滤器就绪”的标记，未就绪时请求直接走缓存+数据库查询，不经过过滤器判断。
3. RedisBloom方案中可以提前把数据预热到Redis，应用启动时只检查过滤器是否已存在，而不是等待数据加载完成。

7.4 一个小技巧：用Counting Bloom Filter思路做“有限删除”

虽然标准布隆过滤器不支持删除，但有些场景下确实面临“ID被删除后仍被误判存在”的问题。我实践过一个折中方案：在过滤器外层维护一个“已删除ID”的短TTL黑名单（可以放到Redis的Set里，TTL设置为5分钟）。查询时先查黑名单，如果命中则不继续；否则再去查布隆过滤器。这个方案虽然额外占用了一些内存，但能有效解决“删除后短期内仍被放行”的问题，比定时重建过滤器要简单得多。

写在最后

缓存穿透的治理，本质上是一个“用空间换准确率，用方案组合换稳定性”的工程问题。布隆过滤器作为第一道防线，价值在于用极低的内存成本拦截绝大多数“不存在”的请求。但无论用Guava还是RedisBloom，都要在原理理解的前提下，把参数算清楚、把数据预热节奏调好、把兜底方案备好。希望这篇复盘对你有参考价值，也欢迎在实践中多踩几次坑，有些教训真的得亲身经历一遍才有体感。