布隆过滤器在大规模爬虫中以极低内存（1亿URL仅23MB）和微秒级查询实现高效去重，替代HashSet、数据库、Redis Set等高成本方案，成为事实标准。
在大规模网络爬虫系统中，用布隆过滤器做循环查重，核心不是“防止所有重复”，而是以极低成本拦截绝大多数重复 URL，避免陷入无限爬取循环。它不保证 100% 精确，但能用不到传统方案 1% 的内存，把去重判断压到微秒级——这才是实战价值所在。
为什么必须用布隆过滤器替代传统去重
当爬取目标扩展到千万级 URL 时，传统方式会迅速失效：
- 用 HashSet 存 URL 字符串：1 亿条约占 3.2GB 内存，且随字符串长度增长而膨胀；
- 用数据库唯一索引：单次查询动辄百毫秒，QPS 卡在 5000 以下，根本扛不住并发调度；
- 用 Redis Set：虽快于数据库，但 1 亿数据仍需近 2.8GB 内存，集群扩容成本高。
布隆过滤器把 1 亿 URL 的内存开销压缩到约 23MB，查询延迟稳定在 0.1ms 以内，且天然适配分布式部署——这是它成为爬虫去重事实标准的根本原因。
关键参数设置要匹配真实爬取规模
误判率不是越低越好，而是要在内存、速度和精度之间找平衡点。对典型爬虫场景（如日增 500 万新 URL，历史总量 5000 万），推荐这样设：
- 预估总容量 n = 5000 万；
- 接受误判率 ε = 0.1%（即 0.001）；
- 位数组长度 m ≈ −n × ln(ε) / (ln2)² ≈ 479MB / 8 ≈ 60MB 位空间 → 实际取 2³² 位（512MB）更稳妥；
- 哈希函数个数 k = (m/n) × ln2 ≈ 8~10 个，C# 或 Python 中常用 7 或 9 个高质量哈希（如 Murmur3、xxHash）。
参数定死前，务必用真实 URL 样本跑一轮误判测试——短域名、含参数的长 URL、带 hash 片段的链接，哈希分布差异很大，不能只看理论公式。
嵌入爬虫流程的三步落地法
布隆过滤器不是独立模块，必须无缝接入爬取生命周期：
-
调度前过滤：URL 管理器从待抓队列取出一个 URL，先调
contains()；返回 false 才入下载队列，true 则直接丢弃； -
下载后注册：HTTP 下载器成功拿到响应后，立即对原始 URL 调
add()，确保后续同 URL 请求被拦截； -
解析时二次过滤：HTML 解析器提取出新链接后，逐条过布隆过滤器，仅将
contains() == false的 URL 推入待抓队列。
注意：所有环节都只读不写（除注册外），无锁设计；若用 Redis Bloom 模块，直接用 BF.ADD 和 BF.EXISTS，天然支持多进程/多机共享状态。
必须规避的四个实战陷阱
很多团队上线后才发现效果打折，问题往往出在细节：
- URL 规范化缺失：`https://a.com/`、`https://a.com/index.html`、`https://A.COM/` 应统一转为小写 + 去默认路径 + 去冗余参数（如 utm_、?ref=），否则等价 URL 被判为不同项；
- 未区分协议与子域：爬取 `http://news.site.com` 时，不应因 `https://site.com` 已存在就跳过，需按 host+scheme 组合建多个过滤器，或加前缀隔离；
-
位数组爆满不扩容：当插入量接近预设容量的 80%，误判率会陡升；Redis Bloom 支持自动扩容（
BF.RESERVE配EXPANSION），本地实现需监控bitArray.cardinality() / m比值； - 忽略冷热分离：高频站点（如首页、列表页）可单独缓存最近 1 小时 URL 布隆过滤器，避免全量位图频繁刷新，提升局部命中率。
不复杂但容易忽略
