布隆过滤器需与数据库写入强绑定预热，不可依赖定时任务或启动加载；推荐在DAO/Service写操作末尾显式调用put；生产环境优先用RedisBloom而非Guava；误判率应从0.03起步并依监控调优。
布隆过滤器不是“部署完就自动防穿透”的开关，它必须在数据写入数据库的同时或之前，把合法 key 预热进过滤器，否则请求进来时查的还是空的——这是绝大多数人踩坑的第一步。
布隆过滤器预热必须和数据库写入强绑定
缓存穿透防护失效，90% 是因为布隆过滤器没跟上数据变更节奏。比如新增一个商品，只写了 MySQL 和 Redis，却忘了 bloomFilter.put("product:1001")，后续所有对这个 ID 的查询都会穿透到 DB。
- 预热时机只能是：数据落库成功后、且在任何读请求可能到达前完成
- 不能靠定时任务批量同步（有窗口期），也不能只在启动时加载（漏掉运行时新增数据）
- 推荐方案：在 DAO 层或 Service 写操作末尾，显式调用
bloomFilter.put(key)，例如bloomFilter.put("user:" + userId) - 如果用的是 RedisBloom 模块（如
bf.add），确保命令执行成功并捕获异常，失败时要走降级日志告警，不能静默忽略
Guava 布隆过滤器无法热更新，别在单机里硬扛全量数据
Guava 的 BloomFilter 是纯内存、不可变结构，初始化后无法增删元素，也不支持分布式共享。把它放在 Spring Bean 里当全局单例，只适用于 key 总量稳定、变化极少的场景（比如城市编码表）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 电商类业务中，每天新增数万商品 ID，用 Guava 预热会导致内存持续增长、GC 压力大，且重启即丢失
- 真实生产环境应优先选用 RedisBloom 模块（
redisbloom），通过BF.ADD/BF.EXISTS实现服务无状态、过滤器可持久化 - 若必须用 Guava，需配合本地缓存（如 Caffeine）做二级兜底，并设计定期 dump + reload 机制，复杂度陡增
误判率设太低反而会拖垮性能，0.01 不是默认最优解
误判率 fpp=0.01 常被直接复制粘贴，但它和内存占用呈反比：fpp 每降低一个数量级，位数组大小约翻 3–4 倍。1000 万 key 设成 0.001，位图就要近 20MB，而很多微服务堆内存才 512MB。
- 实测建议：从
fpp=0.03起步，在监控中观察bf.exists()返回 true 后实际缓存命中的比例（即“真阳性率”） - 如果命中率低于 60%，说明 fpp 过高，该 key 太多被误放行；如果 Redis 内存上涨过快或 GC 频次明显增加，则该调高 fpp
- 关键点：布隆过滤器只拦“一定不存在”，不保“一定存在”，所以它的价值在于减少无效 DB 查询，而非 100% 精确拦截
真正难的不是加一行 bf.exists()，而是让过滤器的生命周期和业务数据生命周期对齐——数据写哪，过滤器就得跟哪，缺一环，穿透就漏一环。
