Redisson BloomFilter：分布式位图实现、误判率调优与缓存穿透三级防护的 Spring Boot 生产级实战

注：

博客：

https://blog.csdn.net/badao_liumang_qizhi

一、布隆过滤器原理速览

1.1 为什么需要布隆过滤器

在缓存穿透场景中，恶意请求携带大量不存在的 ID（如 surveyId=-1、surveyId=99999999）持续访问，这些请求在 Redis 中必然 miss，然后全部涌向数据库。数据库的查询能力远低于 Redis，瞬间就会被拖垮。

布隆过滤器用一个极小的固定内存 ，在请求到达 Redis 之前就判断出"这个 ID 一定不存在"，从而在网关层或 Service 层直接拒绝，请求甚至碰不到 Redis 的门。

类比讲解 ：布隆过滤器就像小区门口的保安。他手里有一份"业主名单"，但这份名单不是名字列表，而是一张经过特殊处理的指纹图。你报一个门牌号，他用几个不同的规则（哈希函数）在指纹图上查对应位置，如果有一个位置是空的，你肯定不是业主（100% 准确）；如果所有位置都有标记，你可能是业主（有小概率是保安把别人的标记错认成了你的）。

1.2 核心特性：单向误判

布隆过滤器最关键的语义是：

查询结果	含义	是否可以信任
`contains(key) == false`	该 key 一定不存在	✅ 可以放心拦截
`contains(key) == true`	该 key 可能存在	⚠️ 仍需查 Redis / DB

永远不会出现"假阴性" ------已加入过滤器的元素，查询时必然返回 true。但允许存在可调的假阳性率（False Positive Probability, FPP）------从未加入的元素，偶尔会被误判为存在。

生产铁律 ：只有 contains() 返回 false 时才能直接拒绝请求。返回 true 只意味着"值得继续查"，绝不能当作"确认存在"的凭据。

1.3 标准布隆过滤器的位数组与哈希

标准布隆过滤器的底层是一个很长的二进制位数组（Bit Array）和一组（通常 k 个）独立的哈希函数。插入元素时，元素经过 k 个哈希函数映射到位数组中的 k 个位置，将这些位置置为 1。查询时检查这些位置是否全为 1。

Redisson 的 RedissonBloomFilter 实现基于 Highway 128-bit hash，位数组大小和哈希函数数量由 Guava 风格的经典公式推导得出：

java 复制代码

// RedissonBloomFilter.java 中的最优参数推导
private int optimalNumOfHashFunctions(long n, long m) {
    return Math.max(1, (int) Math.round((double) m / n * Math.log(2)));
}

private long optimalNumOfBits(long n, double p) {
    if (p == 0) p = Double.MIN_VALUE;
    return (long) (-n * Math.log(p) / (Math.log(2) * Math.log(2)));
}

你只需提供预期插入数量 n 和可接受的误判率 p，Redisson 自动计算出位数组大小和哈希轮数。

二、Redisson RBloomFilter 快速上手

2.1 Maven 依赖

xml 复制代码

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.27.0</version>
</dependency>

2.2 Redisson 客户端配置

java 复制代码

@Configuration
public class RedissonConfig {

    @Bean(destroyMethod = "shutdown")
    public RedissonClient redissonClient() {
        Config config = new Config();
        config.useSingleServer()
              .setAddress("redis://127.0.0.1:6379")
              .setPassword("your-password")
              .setConnectionMinimumIdleSize(10)
              .setConnectionPoolSize(64);
        return Redisson.create(config);
    }
}

2.3 初始化与预热（关键步骤）

RBloomFilter 必须在应用启动时一次性初始化并完成预热，否则首波请求会全部被误拦为"不存在"。

java 复制代码

@Slf4j
@Service
@RequiredArgsConstructor
public class BloomFilterInitializer {

    private final RedissonClient redissonClient;
    private final SurveyRepository surveyRepository;

    private static final String BLOOM_KEY = "survey:bloom";

    @PostConstruct
    public void initBloomFilter() {
        RBloomFilter<Long> bloomFilter =
                redissonClient.getBloomFilter(BLOOM_KEY);

        // tryInit：仅在 Redis 中该 key 不存在时真正创建
        // expectedInsertions 按全量上限设置，不要按日活估算
        bloomFilter.tryInit(10_000_000L, 0.03);
        // 参数含义：预期最多 1000 万个 ID，误判率 3%

        // 预热：将数据库中所有有效 ID 批量加入
        List<Long> allIds = surveyRepository.findAllPublishedIds();
        for (Long id : allIds) {
            bloomFilter.add(id);
        }
        log.info("布隆过滤器初始化完成，已预热 {} 个 ID，当前计数={}",
                allIds.size(), bloomFilter.count());
    }
}

关键参数说明：

参数	建议值	说明
`expectedInsertions`	全量合法 key 的上限	不要填日活或缓存预估量。设小了误判率飙升，设大了浪费内存
`falseProbability`	0.03 ~ 0.05	生产推荐区间。设 0.01 内存翻倍，但误判率下降不明显

内存参考：误判率 0.01% 时，千万级数据约占用 20MB，亿级数据约占用 200MB。

2.4 查询与拦截

java 复制代码

public Survey getSurveyWithBloomProtection(Long surveyId) {
    RBloomFilter<Long> bloomFilter =
            redissonClient.getBloomFilter(BLOOM_KEY);

    // 第一级：布隆过滤器拦截
    if (!bloomFilter.contains(surveyId)) {
        log.warn("布隆过滤器拦截非法请求: surveyId={}", surveyId);
        throw new RuntimeException("问卷不存在");
    }

    // 第二级：查 Redis 缓存
    String cacheKey = "survey:cache:" + surveyId;
    Survey cached = (Survey) redisTemplate.opsForValue().get(cacheKey);
    if (cached != null) return cached;

    // 第三级：查数据库
    Survey survey = surveyRepository.findById(surveyId).orElse(null);
    if (survey == null) {
        // 空值缓存兜底，防止布隆误判导致的穿透
        redisTemplate.opsForValue().set(cacheKey, "NULL",
                Duration.ofMinutes(5));
        return null;
    }

    redisTemplate.opsForValue().set(cacheKey, survey,
            Duration.ofSeconds(3600 + ThreadLocalRandom.current().nextInt(3600)));
    return survey;
}

拦截逻辑必须写成 if (!contains()) { 拒绝 }，而不是 if (contains()) { 放行 } 。返回 true 只代表"可能有"，仍需走后续缓存和数据库流程。

三、参数调优与容量规划

3.1 误判率与内存的权衡

误判率并非越低越好。每降低一个数量级，位数组大小约增加 40%~50%。生产环境需要在内存成本 和穿透风险之间找到平衡点。

场景	推荐误判率	预期数据量	大致内存
用户 ID 查询	0.01	50 万	~8 MB
URL 去重	0.03	1000 万	~30 MB
问卷 ID 防护	0.03	1000 万	~30 MB
亿级商品 ID	0.01	1 亿	~200 MB

3.2 容量不足的后果

当实际插入的元素数量逐渐逼近 expectedInsertions 时，位数组的"饱和程度"上升，误判率会急剧攀升 。Redisson 提供了 count() 方法返回当前已加入的元素估算数量，可用于监控：

java 复制代码

long currentCount = bloomFilter.count();
long expected = bloomFilter.getExpectedInsertions();
double usageRate = (double) currentCount / expected;
if (usageRate > 0.8) {
    log.warn("布隆过滤器使用率 {}%，误判率可能已显著上升", usageRate * 100);
    // 触发告警或重建流程
}

生产建议 ：expectedInsertions 按未来 6~12 个月的预期峰值设置，并监控使用率。超过 80% 时启动重建流程。

四、生产级关键问题与解决方案

4.1 布隆过滤器不支持删除

标准布隆过滤器一旦加入元素就无法删除。删除一个位会影响所有映射到该位的其他元素，产生"假阴性"------这是布隆过滤器设计所不允许的。

类比讲解：就像一本多人合用的打卡本，每个人上班时在对应格子里打勾。你不能擦掉某个人的勾，因为那个格子可能也被另一个人打了勾------擦掉后另一个人就被误判为"没来过"。

解决方案：

方案	适用场景	实现方式
重建过滤器	删除不频繁	定期从 DB 重新加载全量 ID 构建新过滤器，原子替换旧 key
Cuckoo Filter	需要删除且数据量中等	Redisson 提供 `RCuckooFilter`，支持删除，但内存占用略高
计数布隆过滤器	需要精确删除计数	将每个 bit 升级为计数器，实现复杂，Redis 原生不支持

Redisson 的 RCuckooFilter 是支持删除的替代方案，底层使用 RedisBloom 模块的 CF.* 命令，但需要 Redis 服务端加载 RedisBloom 模块。

4.2 主从延迟导致误判

在 Redis 主从架构中，布隆过滤器的写入在主节点完成，但从节点存在复制延迟。如果查询请求被路由到从节点，可能读到尚未同步的位数组状态，导致 contains() 返回 false，造成假阴性（已存在的元素被误判为不存在）。

解决方案：配置 Redisson 的读取模式，强制从主节点读取：

java 复制代码

config.useSingleServer()
      .setReadMode(ReadMode.MASTER);  // 布隆过滤器查询强制走主节点

4.3 数据对齐：add() 只能来自 DB 确认的数据

绝不能让用户输入、参数拼接、日志提取等不可信来源触发 add()。一旦非法 key 被写入过滤器，后续所有同名请求都会被误判为"可能存在"，穿透风险反而被放大。

正确做法：

java 复制代码

@Transactional
public Survey publishSurvey(Long surveyId) {
    Survey survey = surveyRepository.findById(surveyId)
            .orElseThrow(() -> new RuntimeException("问卷不存在"));

    survey.setStatus(Survey.SurveyStatus.PUBLISHED);
    surveyRepository.save(survey);

    // 仅在 DB 写入成功后，同步更新布隆过滤器
    RBloomFilter<Long> bloomFilter =
            redissonClient.getBloomFilter(BLOOM_KEY);
    bloomFilter.add(surveyId);

    return survey;
}

4.4 布隆过滤器 + 空值缓存协同

布隆过滤器无法 100% 拦住穿透（存在误判）。必须配合短时空值缓存 兜底。当 contains() 返回 true 但 DB 查询为空时，写入 "NULL" 标记并设置 5~300 秒的 TTL。

java 复制代码

// 空值缓存：存字符串标记，不能存 null
redisTemplate.opsForValue().set(cacheKey, "NULL",
        Duration.ofSeconds(300));

4.5 多实例一致性

不要使用 Guava 的本地布隆过滤器 。多实例部署时，每个实例的本地过滤器状态不同步，会导致同一 ID 在 A 实例被拦截、在 B 实例被放行。Redisson 的 RBloomFilter 将位数组存储在 Redis 中，天然支持跨节点共享。

五、完整生产级封装

java 复制代码

@Slf4j
@Component
@RequiredArgsConstructor
public class DistributedBloomFilter {

    private final RedissonClient redissonClient;
    private RBloomFilter<Long> bloomFilter;

    private static final String KEY = "app:bloom:ids";
    private static final long EXPECTED = 10_000_000L;
    private static final double FPP = 0.03;

    @PostConstruct
    public void init() {
        bloomFilter = redissonClient.getBloomFilter(KEY);
        bloomFilter.tryInit(EXPECTED, FPP);
    }

    /** 判断 ID 是否一定不存在 */
    public boolean definitelyNotExists(Long id) {
        return !bloomFilter.contains(id);
    }

    /** DB 确认存在后调用 */
    public void markExists(Long id) {
        bloomFilter.add(id);
    }

    /** 监控使用率 */
    public double usageRate() {
        return (double) bloomFilter.count() / bloomFilter.getExpectedInsertions();
    }

    /** 重建：删除旧 key，用新 ID 集合重新构建 */
    public void rebuild(Collection<Long> allValidIds) {
        RBloomFilter<Long> newFilter =
                redissonClient.getBloomFilter(KEY + ":rebuild");
        newFilter.tryInit(EXPECTED, FPP);
        newFilter.add(allValidIds);

        // 原子替换（实际生产中建议用 Lua 脚本或双 key 切换）
        redissonClient.getKeys().rename(KEY + ":rebuild", KEY);
        this.bloomFilter = redissonClient.getBloomFilter(KEY);
        log.info("布隆过滤器重建完成，新计数={}", bloomFilter.count());
    }
}

六、总结

Redisson RBloomFilter 是在 Java 分布式系统中实现缓存穿透防护的首选方案。它的核心价值在于：用极小的内存代价，在请求到达 Redis 和数据库之前就拦截掉大量非法查询。

维度	要点
初始化	启动时 `tryInit` + 全量预热，`expectedInsertions` 按上限设置
误判语义	`false` = 一定不存在（可拦截），`true` = 可能存在（需继续查）
add 来源	仅限 DB 确认存在的数据，禁止不可信输入触发
协同防护	布隆过滤器 + 空值缓存 + 随机 TTL 形成三级防护
删除限制	不支持删除，需重建或改用 Cuckoo Filter
监控	通过 `count() / getExpectedInsertions()` 监控使用率，超 80% 告警

类比总结 ：布隆过滤器不是"数据库的替代品"，而是一道前置漏斗 。它不存储数据本身，只存储"数据存在性的概率摘要"。把它放在请求链路的最前端，配合空值缓存和随机 TTL，就形成了一套低成本、高吞吐的缓存穿透防护体系。