Redisson的RBloomFilter是Spring Boot 3中防御缓存穿透最省事可靠的选择，需Redis启用RedisBloom模块；Guava布隆过滤器仅适用于单机，无法满足分布式场景下共享状态的需求。
直接上结论：用 Redisson 的 RBloomFilter 是 Spring Boot 3 里最省事、最可靠的选择，前提是 Redis 已启用 RedisBloom 模块；别用 Guava 布隆过滤器做分布式场景，它只在单机有效。
为什么必须用 RedisBloom + Redisson，而不是自己手写或用 Guava
缓存穿透防御必须跨进程生效——用户请求可能打到任意一台应用实例，如果每台机器各自维护一个 Guava BloomFilter，那恶意 ID 只需绕过某台机器的本地过滤器就能直达数据库。而 RedisBloom 把位数组存在 Redis 服务端，所有实例共享同一份状态；Redisson 则封装了对 BF.ADD / BF.EXISTS 等命令的线程安全调用，自动处理连接池、重试、序列化。自己用 Jedis 或 StringRedisTemplate 手拼命令，容易漏掉扩容逻辑、误判率校验、或哈希函数实现不一致导致数据错乱。
Redis 服务端必须加载 RedisBloom 模块，否则 RBloomFilter 初始化就失败
RBloomFilter 不是纯客户端逻辑，它依赖 Redis 服务端原生支持 BF.ADD 等指令。如果你没装模块，启动时会抛出 org.redisson.client.RedisException: ERR unknown command `BF.ADD`。Docker 部署推荐用官方镜像加编译参数：
FROM redis:7.2
RUN apt-get update && apt-get install -y git build-essential && \
git clone --depth 1 --branch v2.6.0 https://github.com/RedisBloom/RedisBloom.git && \
cd RedisBloom && make
CMD ["redis-server", "--loadmodule", "/RedisBloom/redisbloom.so"]关键验证点：
- 容器启动后执行
redis-cli MODULE LIST，输出中必须含name:bf version:20600 - 不要用
redis:alpine镜像，缺少build-essential会导致编译失败 - Spring Boot 应用启动时，
redissonClient.getBloomFilter("xxx")不会立即连 Redis，首次tryInit()才触发模块检测
RBloomFilter 初始化参数不能拍脑袋填，capacity 和 error_rate 错配会导致频繁扩容或误判飙升
tryInit(100000L, 0.01) 这类写法看着简单，但隐含风险：如果实际写入量远超 100000，RedisBloom 会自动扩容（靠 expansion 参数，默认 2），但每次扩容要重建位数组、重哈希全部元素，期间 BF.ADD 延迟可能从微秒级升至毫秒级，高并发下直接拖慢接口。更糟的是，若 error_rate=0.01 却只给 capacity=10000，理论误判率会远高于 1%。
正确做法是按业务预估反推：
- 查清未来 6 个月要进过滤器的 ID 总量（比如商品库 500 万 SKU，加上活动页临时 ID 约 600 万）→
n = 6_000_000 - 根据容忍度选
error_rate：电商查不存在商品，1% 误判率可接受 →p = 0.01 - 代入公式算最小位数：
m = -(n * ln(p)) / (ln(2)^2)≈ 41M bit ≈ 5MB - 最终
tryInit(6_000_000L, 0.01)，让 RedisBloom 按需分配，别手动设小
运行中可通过 redis-cli BF.INFO bloomTest 查看当前 Capacity、Size、Number of filters，确认是否已触发扩容。
初始化时机和数据同步是最大隐形坑，漏掉就等于没布防
布隆过滤器不是“一建就灵”，它必须提前把所有合法 ID 加进去，否则新请求进来全被当“不存在”挡掉。常见错误：
- 只在应用启动时查一次数据库全量加载 → 新上架商品永远进不了过滤器
- 用异步线程加载 → 主线程处理请求时过滤器还是空的，第一批请求全穿透
- 没监听商品上下架事件 → 下架商品仍留在过滤器里，导致本该查不到的 ID 被误放行
务实方案：
- 启动时同步加载历史全量 ID（控制在 10 秒内完成，避免阻塞就绪探针）
- 商品服务发 MQ 消息（如
product.status.changed），监听方调用bloomFilter.add(productId)或bloomFilter.delete()（注意：RedisBloom 不支持 delete，得用BF.SCANDUMP+BF.LOADCHUNK手动重建，所以建议改用“标记失效”策略） - 对实时性要求不高的场景，走定时任务每 5 分钟补全一次增量
真正难的从来不是代码怎么写，而是让过滤器里的数据和业务主库的“存在性”始终保持一致——这一步没闭环，前面所有配置都白搭。
