布隆过滤器的关键在于“快速否定”：只要确认请求一定未出现就立即拦截，若判断可能存在则交由后续校验；其通过位数组+多哈希函数以极小空间成本实现毫秒级存在性判断，支撑10万+ qps。
布隆过滤器实现高效拦截重复请求，关键不在“存数据”，而在“快速否定”——只要能第一时间确认某个请求**一定没出现过**，就直接放行；若判断为“可能存在”，再走后续校验。这种“先筛后查”的策略，让它在高并发防重场景中极轻量、极快。
位数组 + 多哈希函数：最小成本标记存在性
布隆过滤器不存原始请求参数（比如订单号、扫码ID），只用一个大位数组（如 1 亿 bit ≈ 12.5MB）和 3–7 个独立哈希函数。每次收到请求时：
- 对请求标识（如 barcode_12345）运行 k 个哈希函数，得到 k 个数组下标；
- 检查这 k 个位置是否全为 1：只要有一个是 0，说明该请求**绝对没来过**，可立即拦截或拒绝；
- 若全为 1，则标记为“可能存在”，进入下一步（如查 Redis 或数据库）做精确判定。
这个过程只有几次哈希计算 + k 次内存读取，耗时通常低于 0.1ms，轻松支撑 10 万+ QPS。
参数要提前算准：容量和误差率决定实效
误判率（假阳性）不是随机的，它由位数组长度 m 和哈希函数个数 k 共同决定。实际部署前必须按预期数据量预估：
- 假设日均新增 500 万请求，保留 90 天 → 总量约 4.5 亿；
- 设允许误判率 0.1%（即千分之一），用公式 m = −n × ln(ε) / (ln2)² 可算出所需位数 ≈ 64 亿 bit（约 780MB）；
- 最优哈希个数 k = m/n × ln2 ≈ 5，选 5 个高质量哈希函数（如 MurmurHash3 + CityHash 组合）效果更稳。
参数设小了，误判飙升；设大了，浪费内存。Redis 的 BF.RESERVE key 0.001 5000000 就是典型初始化命令。
落地时绕不开的三个实操要点
纯理论能跑通，但工程中得处理真实约束：
- 不支持删除：基础版无法清除已过期请求（如 30 分钟前的扫码 ID）。解法是定期重建新过滤器，或改用支持计数的变种（如 Counting Bloom Filter）；
- 哈希函数必须独立均匀：避免多个函数输出集中在某段区间。实践中常用“双重哈希法”——用一个哈希值生成多个偏移，比调用 5 个不同库更可控；
- 务必搭配二级校验：布隆说“可能存在”，不代表真存在。例如扫码场景，BF 返回 1 后，必须查一次 Redis 订单状态或 DB 主键，才能最终决定是否拒单。
为什么比 Redis Set 更适合防重？
存 1 亿个字符串 ID：
- Redis Set 至少占 1GB+ 内存（每个字符串带额外元信息）；
- 布隆过滤器仅需 ~120MB（0.1% 误判率），内存降 90%，且查询不依赖网络往返；
- Set 查是否存在是 O(1) 但有内存分配开销；BF 是纯 CPU + cache 访问，延迟更稳、更可预测。
它不是替代精确存储，而是做最外层的“智能门卫”——挡掉 99% 的无效穿透，让后端真正聚焦在有价值的请求上。
