布隆过滤器容量必须根据预期数据量、可接受误判率和内存预算反推，不能随意设定；容量过小导致误判率飙升、合法请求被拦截，过大则浪费内存甚至分配失败；其capacity应为预估最大元素数，需用公式capacity = -(expected_elements × ln(epsilon)) / (ln(2)²)计算，并通过BF.RESERVE严格设置，不支持自动扩容，超限后BF.ADD静默失败引发缓存穿透。
布隆过滤器容量不能靠拍脑袋定，必须结合预期数据量、可接受误判率、内存预算三者反推——直接设成 100 万或 1 亿都大概率出问题。
为什么容量错了会导致穿透防护失效
容量过小，插入少量 key 就会让位数组快速饱和，false positive rate（误判率）飙升到 10% 甚至更高，大量合法请求被拦截；容量过大，浪费 Redis 内存，且 BF.RESERVE 分配时可能触发 (error) ERR not enough memory。关键点在于：布隆过滤器的容量是「预估最大元素数」，不是当前已有数量，也不是 QPS。
怎么算出合理容量值
用公式反推：capacity = - (expected_elements * ln(epsilon)) / (ln(2)^2)，其中 epsilon 是你容忍的误判率（比如 0.01 表示 1%）。实际操作建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先统计业务侧未来 3–6 个月预计会写入过滤器的唯一 key 总数（比如订单 ID、商品 SKU），记为
N - 设定误判率目标：线上一般取
0.001（0.1%），对一致性要求极高的场景可压到0.0001 - 用在线计算器或 Python 快速估算：
import math; capacity = int(-N * math.log(0.001) / (math.log(2)**2)) - Redis 的
BF.RESERVE命令中capacity参数必须 ≥ 这个值，否则扩容只能重建，无法原地增长
Redis 布隆过滤器的容量限制与实操陷阱
RedisBloom 模块的 BF.RESERVE 不支持自动扩容，一旦写满，后续 BF.ADD 会静默失败（不报错但返回 0），导致漏判 → 穿透发生。常见踩坑点：
-
BF.RESERVE myFilter 1000000 0.01中的1000000是硬上限，超了就不再生效 - 不要复用同一个 key 存不同业务的过滤器（比如把用户 ID 和商品 ID 全塞进
user_bf），哈希冲突会互相污染 - 冷启动时别一次性
BF.ADD几百万 key，容易阻塞主线程；改用BF.MADD批量 + 分片写入 - 监控
BF.EXISTS返回0的比例，持续高于 5%，说明容量不足或误判率设置过松
真正难的不是算出那个数字，而是让业务方给出相对靠谱的 expected_elements —— 很多团队拿日活当基数，结果发现订单号、设备指纹等衍生 key 量级高出一个数量级。上线前务必用真实采样数据跑一遍压测验证误判率。
