如何处理Python爬虫抓取到的重复URL链接_使用布隆过滤器BloomFilter高效去重-Python教程-PHP中文网

布隆过滤器内存暴增主因是error_rate过低与capacity虚高，应设error_rate≥0.001、按实际增量估算capacity、强制URL归一化、避免多进程共享、上线前必须实测误判率。

如何处理python爬虫抓取到的重复url链接_使用布隆过滤器bloomfilter高效去重

pybloom_live 初始化时内存暴增，怎么算才不炸？

直接写 capacity=10000000 + error_rate=0.0001，十有八九 OOM。这不是代码写错了，是参数组合没算清——capacity 和 error_rate 共同决定位数组长度，而后者才是吃内存的真凶。

error_rate 别设低于 0.001：每降一个数量级（比如从 0.001 → 0.0001），内存约增 4.8 倍；对 URL 去重，0.01（1% 误判）已足够，爬虫本身就有丢页风险，没必要追求“零误判”
按实际增量估算 capacity：不是总 URL 数，而是「峰值并发 URL 数 × 爬取周期内新增量」；例如每天新增 500 万、保留最近 7 天，就设 capacity=35000000，别拍脑袋填 1 亿
初始化后立刻检查：bf.bitarray.length() 返回位数，除以 8 / 1024 / 1024 换算成 MB，确认是否超过机器可用内存的 60%

URL 字符串不标准化，布隆过滤器等于摆设

布隆过滤器对输入极其敏感。https://a.com/?x=1&y=2 和 https://a.com/?y=2&x=1 在它眼里是两个完全不同的 key，查重必然失效——这不是 bug，是你没做归一化。

必须用 urllib.parse.urlparse + urllib.parse.urlunparse 统一 scheme/netloc/path，小写 host、去掉末尾斜杠
query 部分不能直接拼字符串：要用 urllib.parse.parse_qs 解析，按 key 字典序重组，再 urlencode；空参数（如 ?ref=）要剔除，重复参数（a=1&a=2）只留一个
所有 bf.add() 调用前，必须过一层 normalize_url() 封装；否则后期排查漏重，你会怀疑人生

多进程下共享 BloomFilter，为什么一跑就段错误？

pybloom_live.BloomFilter 既不线程安全，也不进程安全。用 multiprocessing.Manager 包一层或塞进 Redis，运行时大概率报 AttributeError: 'BloomFilter' object has no attribute '_bitarray' 或直接段错误。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

放弃「单实例多进程共用一个 BF」的想法：它的 bitarray 是 Python 对象，无法跨进程共享；pybloom_live 也没暴露 mmap 接口
改用「每个 worker 独立 BF + 定期合并」：每小时把各进程的 bf.bitarray.tobytes() 发到 Redis，主进程用 bitwise OR 合并，再广播回 worker
更稳的选择是换 pyreBloom（Redis 后端）或直接用 redis-py 调 BFAADD：牺牲几毫秒延迟，换来确定性

误判率测试没做，上线后才发现漏重严重

布隆过滤器的 error_rate 是理论值，实际误判受 URL 分布、哈希函数质量、标准化程度影响很大。不测，你永远不知道真实漏重率是多少。

上线前，用历史 URL 样本做离线测试：先全量 bf.add()，再逐个 bf.contains()，统计误判次数 / 总数
重点关注「关键 URL」二次校验：比如种子页、高权重域名首页，哪怕 bf.contains() 返回 True，也强制查一次持久化存储（如 SQLite 或 Redis Set）
监控 bf.count（如果支持）或定期 dump bf.bitarray 的置位密度；当密度 > 90%，说明位数组快饱和，误判率会指数上升，该扩容或重建了

布隆过滤器不是黑盒开关，它对输入格式、参数配比、部署方式都极度敏感；最容易被忽略的，是标准化和误判率实测——这两步跳过，前面所有优化都白搭。