必须用 RedissonClient.getBloomFilter() 创建并初始化，误判率和容量需在首次 tryInit() 时定死；@Bean 注册无效，因 RBloomFilter 是按 name 绑定 key 的动态代理，不自动初始化，未调用 tryInit() 会导致静默失败或异常。
直接用 RedissonClient.getBloomFilter() 创建并初始化，别自己封装 Bean；误判率和容量必须在首次 tryInit() 时定死，后续改配置无效。
为什么不能靠 @Bean 注册 RBloomFilter？
Redisson 的 RBloomFilter 是按 name 绑定 Redis key 的动态代理对象，不是普通 Spring Bean。你写一个 @Bean 方法返回 RBloomFilter<string></string>，看似注入成功，但实际每次调用 add() 或 contains() 前，它不会自动检查底层 Redis 结构是否已初始化——而未初始化的布隆过滤器会静默失败或抛 IllegalStateException。
正确做法是：在服务类构造或 @PostConstruct 中显式调用 tryInit(expectedInsertions, falseProbability)。这个方法只在 Redis 中对应 key 不存在时才真正创建结构，且一旦创建，参数就固化在 Redis 的元数据里（存于 bloom:{name}:config hash）。
- 如果
tryInit()被跳过（比如已存在），改application.yml里的false-probability完全没用 - 强行重复调用
tryInit()不会覆盖，只会返回false - 想换参数？只能删 Redis 里
bloom:xxx*相关 key，或换新 name
expectedInsertions 和 falseProbability 怎么选？
这两个值决定布隆过滤器底层位数组大小和哈希轮数，直接影响内存占用与误判率。Redisson 不支持运行时扩容，填错会导致后期误判飙升或浪费大量内存。
常见误配：
- 把
expectedInsertions设成“当前已有数据量”，而不是“未来 6–12 个月预计新增总量”——结果很快打满，误判率从 3% 涨到 15%+ - 设
falseProbability=0.001（0.1%）却只给 10 万预期量，Redisson 会算出约 2MB 位数组；若实际塞入 500 万，同样误判率可能翻倍 - 高并发写场景下，
expectedInsertions建议上浮 20–30%，避免因瞬时写入抖动提前饱和
参考值（使用 RBloomFilter<string></string>）：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
100 万 → falseProbability=0.03 → 实际 Redis 内存 ≈ 1.2MB 500 万 → falseProbability=0.01 → 实际 Redis 内存 ≈ 8.5MB 1000 万 → falseProbability=0.005 → 实际 Redis 内存 ≈ 22MB
contains() 返回 true 后，还必须查数据库吗？
必须。这是布隆过滤器的固有缺陷：contains() 返回 true 表示“可能存在”，返回 false 才表示“一定不存在”。缓存穿透防护的核心逻辑不是靠它 100% 拦住，而是靠它低成本筛掉 99% 的非法请求。
典型流程：
- 请求来，先
bloomFilter.contains(userId) - 返回
false→ 直接拒掉，不查缓存、不查 DB - 返回
true→ 正常走缓存 → 缓存 miss → 查 DB → DB 无结果 → 写空值缓存（防穿透）
漏掉这步 DB 校验，等于把布隆过滤器当确定性集合用了，一旦误判，就会把错误数据返回给前端。
生产环境必须关注的三个 Redis 键
Redisson 把布隆过滤器拆成 3 类 key 存在 Redis 里，运维和排查时得认得：
-
bloom:{name}：主位图，type = string，实际存储所有 bit -
bloom:{name}:config：hash 结构，存expectedInsertions、falseProbability、hashIterations等元信息 -
bloom:{name}:counter：string，记录当前已插入元素个数（非精确，是估算值）
如果发现误判率异常高，先 hgetall bloom:myfilter:config 确认参数是否符合预期；再 get bloom:myfilter:counter 看是否远超 expectedInsertions——超了就得重建。
参数定死、key 可查、DB 必校——这三件事漏掉任何一环，布隆过滤器在生产环境就只是个心理安慰。
