直接用set()处理亿级URL会爆内存，因每个URL字符串在Python中至少占几十字节，1亿个平均50字符的URL常驻内存达8–12GB；布隆过滤器仅需约120MB（误判率0.1%），适合URL去重场景。
为什么直接用 set() 处理亿级 URL 会爆内存？
因为每个 URL 字符串在 Python 中至少占用几十字节（含对象头、引用、编码开销），1 亿个平均长度 50 的 URL，set 实际常驻内存轻松突破 8–12 GB。这不是算法问题，是数据结构本身的存储密度瓶颈。
布隆过滤器用固定大小的位数组 + 多个哈希函数模拟“存在性集合”，1 亿 URL 只需约 120 MB 内存（误判率 ~0.1%），代价是「可能误判存在，但绝不会漏判不存在」——这恰好契合 URL 去重场景：宁可让极少数新 URL 被误认为已存在（后续业务层可二次校验），也不能漏掉重复项。
用 pybloom_live 还是手写 mmh3 + bitarray？
生产环境优先选 pybloom_live：它封装了容量预估、自动扩容、序列化支持，且底层用 C 优化哈希计算；手写容易踩坑——比如哈希分布不均导致实际误判率远高于理论值，或忘记对哈希结果取模时处理负数。
安装与基础用法：
立即学习“Python免费学习笔记（深入）”；
pip install pybloom-live
pybloom_live 初始化关键参数：
-
capacity：预估最大元素数（不能动态增长，设小了后期误判率飙升） -
error_rate：目标误判率（越低，位数组越大，哈希函数越多） - 实际内存 ≈
-capacity * math.log(error_rate) / (math.log(2) ** 2)比特
示例：
from pybloom_live import ScalableBloomFilter<br><br># 自动扩容版，适合不确定总量的流式场景<br>bloom = ScalableBloomFilter(initial_capacity=1000000, error_rate=0.001)<br><br># 判断并添加<br>url = "https://example.com/path?id=123"<br>if url not in bloom:<br> bloom.add(url)<br> # 处理新 URL<br>else:<br> # 跳过（或触发二次精确去重）
URL 去重时，hash(url) 和 mmh3.hash_bytes(url.encode()) 差在哪？
Python 内置 hash() 在不同进程/重启后结果不一致（启用了 hash 随机化），且对长字符串性能差；而 mmh3（MurmurHash3）是确定性、高速、均匀分布的工业级哈希，布隆过滤器必须依赖确定性哈希。
如果你用 bitarray 手写，必须：
- 用
mmh3.hash(url.encode(), seed)生成多个独立哈希值（seed 每次不同） - 对每个哈希结果做
hash_val & (bitarray_length - 1)（位运算取模，比%快，但要求位数组长度为 2 的幂） - 避免直接用
hash(url) % size—— 它在 Python 3.3+ 默认随机化，会导致布隆过滤器序列化后失效
误判率不是越低越好，要平衡内存和业务容忍度
把 error_rate 设成 1e-6 看似很美，但内存翻 3 倍，而实际业务中：若每天新增 500 万 URL，误判率 0.1% 意味着约 5000 个 URL 被误拦，这些可由下游数据库唯一索引或 Redis SETNX 二次兜底；但若为压这 5000 个而多占 300 MB 内存，就本末倒置了。
真实建议：
- 日增千万级 URL →
error_rate=0.001（0.1%），capacity设为预估峰值的 1.2 倍 - 需要持久化 → 用
ScalableBloomFilter的tofile()/fromfile()，别用pickle - 注意：布隆过滤器本身不存原始 URL，所以无法反查「哪些 URL 被判重了」——这是设计使然，不是 bug
真正难的是容量预估和长期误判率漂移监测，上线后得定期用测试集抽样统计真实误判率，而不是只信理论公式。
