误判率由bf.reserve初始化时capacity与error_rate共同决定位数组大小和哈希函数个数，不可运行时调整；需按历史峰值×1.3～1.5设capacity、error_rate建议0.01，超载时须del后重建并用bf.madd批量插入。
误判率不是运行时可调的开关，它在 BF.RESERVE 执行那一刻就基本锁死了——后续所有优化都得围绕“别让它超载”展开。
BF.RESERVE 初始化时 capacity 和 error_rate 怎么填
真正影响误判率的不是 error_rate 这个数字本身，而是它和你填的 capacity 共同决定的位数组大小 m 和哈希函数个数 k。Redis 不会动态扩缩，所以填错就等于埋雷。
- 先看历史数据：查最近 7 天缓存 miss 的 key 峰值，乘以 1.3～1.5 得到保守
capacity（比如日 peak miss 是 80 万，就设1200000） -
error_rate直接填0.01，这是缓存穿透场景下最务实的起点；填0.001会让位数组翻倍、BF.EXISTS耗时多 2–3 倍，但误判率只从 1% 降到约 0.8%，业务几乎感知不到 - 命令示例：
BF.RESERVE user_id_bf 0.01 1200000，别写0.001或硬套预估量不加冗余的1000000
误判率突然升高？先执行 BF.INFO 看过载没
90% 以上的误判率飙升，不是参数设错了，而是实际插入量远超 capacity。RedisBloom 不提供运行时调参接口，error_rate 只参与初始化计算，不参与后续校准。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 执行
BF.INFO user_id_bf，重点看items和capacity字段 - 若
items/capacity > 0.8，说明已过载，误判率会明显偏离设定值，重建是唯一解 - 不要用
BF.RESERVE覆盖同名 key——Redis 会报(error) BUSYKEY；得先DEL user_id_bf再重设，且确保迁移期间无写入 - 重建时新
capacity至少 = 当前items× 1.5，error_rate仍建议保持0.01
批量插入必须用 BF.MADD，别循环调 BF.ADD
BF.ADD 单条插入在接近容量上限时容易掩盖扩容失效：当触发扩容，旧数据可能未完整迁移，部分哈希位未刷新，误判率悄然升高；而 BF.MADD 对扩容过程有更好协同。
- 批量写入一律走
BF.MADD key item1 item2，哪怕只有 2 个元素也建议用它 - 避免混用：
BF.ADD和BF.MADD在同一个 key 上交替使用，尤其在items/capacity > 0.7时行为不可预测 - 如果必须单条插入（如流式写入），务必监控
BF.INFO key中的size字段：它应始终 ≥ 预期m/8，否则说明扩容没生效
布隆过滤器不是 set 的替代品，它是前置守门员——它的价值不在 100% 准确，而在用极小代价挡住绝大多数无效请求。真正难的不是算公式，而是把 capacity 估准、把 BF.MADD 用稳、把 BF.INFO 当成日常巡检项。漏掉任意一环，误判率都会悄悄失控。
