布隆过滤器是拦截缓存穿透最直接有效的手段，但本地guava版因多实例状态不一致、无法共享预热结果等缺陷不适用于分布式场景，必须使用redis原生或redisson封装的rbloomfilter以保障跨节点一致性。
布隆过滤器不是万能的，但它是拦截缓存穿透最直接有效的手段——前提是它被正确加载、正确调用、并且不被绕过。
为什么本地 Guava BloomFilter 不能直接用于分布式场景
Guava 的 BloomFilter 是纯内存结构，每个服务实例都持有一份独立副本。在 SpringCloud 多实例部署下，会出现：各节点布隆过滤器状态不一致；新增数据无法实时同步到所有节点；重启后过滤器丢失；无法共享预热结果。
这意味着：哪怕你在启动时从 DB 加载了全部有效 ID，只要请求落到没加载完或刚重启的实例上，bloomFilter.mightContain(id) 就可能返回 false，导致误拦合法请求。
所以生产环境必须用 Redis 原生支持的布隆过滤器（通过 RedisBloom 模块）或 Redisson 封装的 RBloomFilter，它们的数据存在 Redis 中，天然跨节点共享。
Redisson RBloomFilter 初始化与预热时机
Redisson 的 RBloomFilter 必须在 Redis 连接就绪后初始化，且预热逻辑不能放在 Bean 构造方法里——否则可能因依赖未注入或 Redis 还未连上而失败。
- 用
@PostConstruct或实现ApplicationRunner确保 Spring 上下文启动完成后再执行预热 -
tryInit(100000L, 0.003)必须在首次使用前调用，否则后续add()或contains()会抛IllegalStateException - 预热数据量要略大于预期峰值（比如预估 80 万用户，设
expectedInsertions = 1_000_000），否则误判率会陡增 - 避免在预热过程中频繁调用
count()或getFalseProbability()，这些是 O(1) 但会触发额外网络 round-trip
拦截逻辑中容易漏掉的两个关键分支
布隆过滤器只负责“快速否定”，但它不解决“查不到之后该怎么做”。常见疏漏是：没处理空值回写、没防止重复预热、没覆盖异常路径。
- 当
bloomFilter.contains(id)返回false，应直接返回 404 或抛异常，**不要继续查缓存或 DB** - 当
bloomFilter.contains(id)返回true，但缓存和 DB 都查不到，说明这是个新出现的非法 key（比如攻击者爆破），此时应调用bloomFilter.add(id)将其永久加入黑名单（注意：Redisson 的add()是幂等的） - 预热过程若发生数据库查询超时或中断，必须有 fallback 机制（例如记录日志 + 设置一个降级的最小容量布隆过滤器），否则整个拦截链路失效
- 接口参数校验（如 ID 格式、长度）要在进入布隆过滤器判断之前做，否则恶意构造的超长字符串可能引发哈希碰撞激增
性能与误判率的平衡点怎么选
误判率 fpp = 0.001（0.1%）对应约 10 bits/element；设为 0.0001（0.01%）则升至 ~14 bits/element。看似提升小，但对百万级 key 来说，内存占用差 40% 以上。
实际中不需要追求极致低误判：只要保证 false 结果 100% 可信，true 结果只是“值得查一次”，那 0.01 就足够。真正要盯住的是：
-
expectedInsertions是否显著低估——一旦超过，误判率会指数级上升 - Redis 实例的内存是否预留足够（
RBloomFilter占用的是 Redis 内存，不是 JVM） - 高并发下
contains()调用是否被限流——它本质是多次GETBIT，单次延迟虽低，但 QPS 过高仍可能打满 Redis 带宽
上线前务必用真实 key 分布压测，而不是只用 UUID 模拟——哈希分布不均会让误判率虚低，掩盖问题。
