布隆过滤器适合拦截缓存穿透因其仅判断“key是否可能存在”，查询o(1)、内存占用低，不存真实数据，可快速拦截非法请求。
为什么布隆过滤器适合拦截缓存穿透
因为布隆过滤器只判断“key是否可能存在”，且查询是 O(1)、内存占用极低，不会把真实数据存下来，天然适合作为缓存前的第一道轻量级守门员。它不解决“查得对不对”，只解决“值根本不可能存在，别往下传了”。只要攻击者用 id=-1、id=999999999 这类数据库里压根没有的值刷请求，布隆过滤器就能在毫秒内返回“不存在”，直接拦住，连 Redis 都不用碰。
怎么初始化布隆过滤器并同步数据库全量 ID
布隆过滤器必须提前加载“所有合法 key”的集合，否则就是摆设。常见错误是只加载部分热 key 或漏掉新插入的数据。
- 初始化阶段：启动时从数据库全量扫描主键（如
user.id），逐个调用bloomFilter.put(id)；不要用分页查再合并，避免漏数据 - 增量更新：对新增/删除操作，需同步调用
bloomFilter.put()或bloomFilter.mightContain()配合业务逻辑兜底（注意：Guava 的BloomFilter不支持删除，慎用于高频删场景） - 分布式一致性：单机
BloomFilter无法共享，必须用 Redis + Bitmap 或专用服务（如 RedisBloom 模块）；若用 Guava，每个节点要独立加载全量，且需保证加载时机一致（例如监听 binlog 同步）
请求链路中布隆过滤器该放在哪一级
位置错了等于没加。它必须在缓存查询之前、且尽可能靠近入口，否则无效请求仍会打到 Redis 或 DB。
- 推荐位置：
Gateway层或Service入口方法最开头，比如 Spring Boot 的@ControllerAdvice或自定义Filter - 绝对不能放的位置：在
Redis.get()之后——此时穿透已经发生；也不能放在 DAO 层，太晚了 - 配合空值缓存用：布隆过滤器说“可能存在” → 查 Redis → Miss → 查 DB → 再按需缓存空值；两者是互补，不是二选一
误判率控制与实际参数设置
误判率（false positive rate）不是越低越好，它和内存、哈希次数强相关。设得太严会导致位数组爆炸，设得太松又失去拦截意义。
- 典型参数（以 1 亿用户 ID 为例）：
expectedInsertions = 100_000_000，fpp = 0.01（1%误判率），Guava 会自动算出最优位数组长度和哈希个数 - 生产建议：
fpp控制在0.01～0.03之间；低于 0.001 时内存增长非线性，不划算 - 验证方式：上线前用离线脚本生成一批非法
id（如随机负数、超大数），跑 10 万次bloomFilter.mightContain()，统计返回true的比例
真正难的是长期维护——布隆过滤器一旦部署，就和数据库主键生命周期绑定。ID 删除、分库分表、归档策略变更，都会让过滤器逐渐失准。别只盯着第一次上线，得有持续校验和重建机制。
