布隆过滤器误判率由初始capacity决定，超载会导致误判率飙升；应按峰值数据×1.3～1.5设capacity，bf.info中items/capacity>0.8需重建；扩容优先增capacity而非k，批量插入必用bf.madd。
布隆过滤器的误判率不是缺陷，而是空间换时间的必然代价；它直接决定缓存穿透防护是否“形同虚设”——误判率设高了，大量无效请求仍会打到 DB；设低了，内存暴涨、Redis 内存碎片加剧，甚至触发 OOM。
误判率从哪来？本质是哈希碰撞的数学累积
布隆过滤器不存原始数据，只靠 k 个哈希函数把元素映射到位数组的 k 个位置。当不同元素的哈希结果撞到同一组位置时，查询就会“误以为存在”。这不是实现 bug，而是概率模型的固有属性。
- 插入
n个元素后，某一位仍是 0 的概率是(1 - 1/m)^(k*n)，约等于e^(-kn/m) - 查询时所有
k位都为 1 的概率（即误判率）≈(1 - e^(-kn/m))^k - 这个公式里没有“随机误差”，只有确定性的数学关系：只要
m/n小于 10，误判率就大概率超过 1.5%；m/n = 13.8才压到 0.1%
BF.RESERVE 命令必须显式调用，否则 RedisBloom 用默认参数硬扛
很多人在 Redis CLI 里直接 BF.ADD，结果发现刚插几万条，误判率就飙到 5% 以上——因为没执行 BF.RESERVE，RedisBloom 自动 fallback 到保守默认值：capacity=100, error_rate=0.01，根本撑不住真实业务量。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 正确初始化姿势：
BF.RESERVE myFilter 0.001 10000000（先定误判率0.001，再定容量10000000） - 注意顺序：
error_rate必须在capacity前，参数颠倒会报错ERR wrong number of arguments for 'bf.reserve' command - RedisBloom 实际分配的位数组大小会向上取整到最近的 2 的幂次方，比如理论需 71,862,143 bits，它会分配 2^26 = 67,108,864 bits？不对——是 2^27 = 134,217,728 bits，多占近一倍内存
误判率设多少才不翻车？看场景，别拍脑袋
0.01（1%）不是金标准，它只在“日增百万、允许少量漏防”的场景下成立。一旦业务变化，这个值就可能让缓存穿透防护失效。
- 爬虫 URL 去重：可接受
0.0001（0.01%），因为重复抓取成本远低于漏判导致的全站扫描 - 用户 ID 缓存穿透防护：建议
0.001（0.1%），实测 1 亿用户下对应约 8.5MB 内存，DB 压力下降 92% - 商品详情页兜底：慎用
，位数组超 22MB，Redis 大 key 风险上升，且 <code>BF.MADD批量写入延迟明显增加 - 关键点：误判率每降一个数量级，内存增长约 1.4–1.5 倍，不是线性
容量预估不准怎么办？别重建，用 BF.SCANDUMP + BF.LOADCHUNK 迁移
业务增长快，初始 capacity=500w 很快插满，继续 BF.ADD 不报错但误判率失控——这时不能删掉重建，否则出现“防护空窗期”，新老请求同时绕过过滤器直击 DB。
- 安全扩容流程：先
BF.SCANDUMP myFilter 0拉出全部 chunk，再新建myFilter_v2并BF.RESERVE更大容量，最后用BF.LOADCHUNK把旧数据流式导入 - RedisBloom v2.4+ 支持该方式，全程无停服，但要求客户端能串行执行 dump/load，不能并发写入
- 如果用的是 Redisson，它的
RBloomFilter.tryInit()底层其实也走这套逻辑，但会自动重试——前提是你的 Redis 节点没启maxmemory-policy noeviction，否则LOADCHUNK可能因内存不足失败
真正容易被忽略的不是公式怎么算，而是误判率数字背后对应的 **真实请求放大系数**：误判率 0.01 意味着每 100 个“不存在”请求，就有 1 个会穿透到 DB；如果你每秒收到 10 万非法 ID 查询，那就是每秒 1000 次无效 DB 查询——这个量级足以拖垮中小规模 MySQL 实例。
