缓存穿透本质是“查无此物却反复打库”，必须在请求链路前端加布隆过滤器预判存在性；bf.reserve需按全量有效key上限设capacity、error_rate建议0.001～0.005，且不可省略nonscaling参数以防扩容阻塞。
缓存穿透的本质是“查无此物却反复打库”
直接结论：单靠 Redis 自身无法防穿透，必须在请求链路前端加一层“存在性预判”。布隆过滤器不是银弹，但它是目前生产环境最平衡的方案——误判率可控、内存开销低、查询 O(1)。空值缓存能应急，但扛不住恶意随机 key；参数校验只能拦住格式错误，拦不住“合法但不存在”的 ID。
BF.RESERVE 命令参数怎么设才不翻车
RedisBloom 模块的 BF.RESERVE 是初始化布隆过滤器的关键命令，参数配错会导致误判率飙升或内存浪费：
-
capacity必须按「业务全量有效 key 的上限」预估，不是当前数量。比如商品表有 500 万条，未来半年预计新增 200 万，capacity至少设 7000000 -
error_rate默认 0.01（1%），但实际建议设 0.001～0.005。设太小（如 1e-5）会让位数组暴涨，设太大（如 0.1）导致大量误判，查不到就绕过 BF 直接打库，等于白加 - 不要省略
NONSCALING参数。默认开启自动扩容，但扩容时会阻塞写操作，高并发下可能卡住整个过滤器
Java 用 Redisson 调用 BF.ADD 和 BF.EXISTS 的坑
很多团队用 RedissonClient 封装布隆过滤器，但容易忽略三个细节：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 初始化必须在应用启动时完成，不能懒加载。否则第一个请求触发
BF.RESERVE时，若并发高，可能多个线程重复建同名 BF，报ERR key already exists -
bf.add()和bf.contains()都是异步非阻塞调用，但实际底层走的是 Redis pipeline。如果批量写入（比如上线时刷全量 ID），别用 for 循环逐个调add，改用bf.addAsync()批量提交 - Redisson 的
RBatch不支持 BF 命令。想原子性地“查 BF + 查缓存 + 查 DB”，得自己用 Lua 脚本封装，否则存在 BF 说存在、但缓存/DB 实际没数据的窗口期
布隆过滤器重启后数据丢了怎么办
Redis 本身是内存数据库，BF 数据随实例重启清空。这不是 bug，是设计使然——但线上不能接受“重启后穿透恢复”。解决方案只有两个，且必须二选一：
- 冷启动时从 MySQL 或其他持久化源全量重建：
SELECT id FROM product WHERE status = 1，分批调BF.ADD。注意控制 batch size（建议 ≤5000），避免单次命令过大触发 Redis client timeout - 用
BF.MADD替代多次BF.ADD，减少网络往返。但要注意：RedisBloom 6.0+ 才支持BF.MADD，旧版本只能拼 Lua 脚本 - 千万别把 BF 当主存储用。它只负责“快速否定”，所有“BF 说存在”的请求，仍必须走缓存 → DB 的标准链路，否则误判会直接返回脏数据
真正难的不是实现，而是确认哪些 key 该进 BF、什么时候更新它、以及如何验证误判率是否在容忍范围内。这些没法靠代码自动解决，得靠日志采样和线上监控兜底。
