写在前面很多爬虫工程师在数据量突破百万级后都会遇到同一个瓶颈写入速度跟不上采集速度去重逻辑拖慢整体吞吐重启任务后大量重复请求浪费资源。问题的根源往往不是爬虫框架本身而是存储层设计不合理。本文不讲理论只分享一套在生产环境中稳定运行、日均处理2000万条数据的MongoDBRedis双引擎存储方案。所有代码和配置均来自真实项目脱敏后的实践重点解决三个核心痛点高速写入不丢数据、精准去重不耗内存、断点续爬不重复。一、 为什么是MongoDBRedis不是MySQL不是Elasticsearch在选型之前先明确爬虫数据存储的三个刚性需求Schema灵活性不同站点字段差异大且同一站点字段可能随版本迭代变化固定表结构维护成本极高写入吞吐优先爬虫是典型写密集型场景读取多为批量导出或增量同步对实时查询要求不高去重与状态管理URL去重、任务队列、断点记录需要毫秒级读写且数据具有时效性。基于这三点我们对比了主流方案方案Schema灵活写入性能去重/队列能力运维复杂度适用场景MySQL❌⭐⭐⭐⭐⭐⭐结构化报表、强事务Elasticsearch✅⭐⭐⭐⭐⭐⭐⭐⭐全文检索、复杂聚合MongoDB✅⭐⭐⭐⭐⭐⭐⭐⭐⭐文档型爬虫数据Redis✅⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐去重/队列/缓存MongoDBRedis✅⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐大规模爬虫生产环境结论MongoDB负责持久化存储原始数据与清洗结果Redis负责URL去重、任务调度、热点缓存。两者职责清晰互为补充而非互相替代。⚠️ 常见误区试图用Redis做持久化存储AOF/RDB有丢失风险或用MongoDB做高频去重$in查询随集合增大急剧变慢。让专业组件做专业的事。二、 架构总览数据流与组件分工1. 检查去重未见过已存在2. 解析数据是否3. 批量刷盘4. 更新状态5. 获取新任务6. 分发爬虫WorkerRedis Set/BloomFilter抓取页面跳过数据有效?写入Buffer记录日志MongoDBRedis Hash调度器Redis List/ZSetRedis承担“快”角色——URL去重Set/Bloom Filter、任务队列List/ZSet、断点状态Hash、热点数据缓存MongoDB承担“稳”角色——原始HTML/JSON存储、结构化数据落盘、索引支持增量查询Buffer层爬虫Worker不直接写MongoDB而是攒批后批量插入将单次IO开销摊薄到百条级别。三、 Redis层设计去重、队列、状态三位一体3.1 URL去重从Set到Bloom Filter的演进阶段一Redis Set500万URLimportredis rredis.Redis(hostlocalhost,port6379,db0)defis_duplicate(url:str)-bool:SISMEMBER O(1)但内存占用高returnr.sismember(spider:url_seen,url)defmark_seen(url:str):r.sadd(spider:url_seen,url)问题500万URL约消耗800MB内存1亿URL需16GB且无法设置过期时间Set不支持TTL per member。阶段二Bloom Filter500万URL使用redisbloom模块或Python端pybloom_liveRedis String模拟frompybloom_liveimportScalableBloomFilterimporthashlib,redisclassRedisBloomFilter:def__init__(self,redis_client,key,capacity10_000_000,error_rate0.001):self.rredis_client self.keykey# 本地构建BF序列化存Redis或直接使用RedisBloom模块self.bfScalableBloomFilter(initial_capacitycapacity,error_rateerror_rate)self._load_from_redis()def_load_from_redis(self):dataself.r.get(self.key)ifdata:self.bfScalableBloomFilter.from_bytes(data)defadd(self,url:str):url_hashhashlib.md5(url.encode()).hexdigest()# 压缩key节省内存ifurl_hashnotinself.bf:self.bf.add(url_hash)self.r.set(self.key,self.bf.to_bytes())# 定期持久化defcontains(self,url:str)-bool:url_hashhashlib.md5(url.encode()).hexdigest()returnurl_hashinself.bf生产建议若Redis版本≥4.0直接使用BF.ADD/BF.EXISTS命令RedisBloom模块性能比Python端高一个数量级且支持集群。 关键细节URL先做MD5/SHA1哈希再存入BF可将平均key长度从120字节压缩到32字节内存节省70%以上。误判率设为0.001时1亿URL仅需约140MB内存。3.2 任务队列优先级与公平性兼顾# 高优先级任务如首页、列表页用LPUSH/RPOP实现FIFOr.lpush(spider:queue:high,json.dumps(task))# 普通任务用ZSet按优先级时间戳排序r.zadd(spider:queue:normal,{json.dumps(task):priority_score})# 调度器取任务先high后normaldefget_next_task():taskr.rpop(spider:queue:high)iftask:returnjson.loads(task)# ZPOPMIN返回最低分值最高优先级成员resultr.zpopmin(spider:queue:normal)ifresult:returnjson.loads(result[0][0])returnNone防积压设计为每个队列设置MAXLEN超限时丢弃最低优先级任务并告警避免内存无限增长。3.3 断点状态Hash记录进度# 记录每个站点的爬取进度state_keyspider:state:example_comr.hset(state_key,mapping{last_page:156,last_timestamp:2024-05-20T10:30:00,total_items:48230,status:running})r.expire(state_key,86400*7)# 7天过期防止僵尸状态重启任务时读取该Hash从last_page1继续无需重新扫描已处理数据。四、 MongoDB层设计写入优化与索引策略4.1 批量写入Buffer bulk_write绝对禁止逐条insert。实测单条insert TPS约800bulk_write(500条) TPS可达12000。frompymongoimportMongoClient,InsertOne,UpdateOnefromdatetimeimportdatetimeimportthreading,timeclassMongoBuffer:def__init__(self,collection,batch_size500,flush_interval3):self.collectioncollection self.batch_sizebatch_size self.flush_intervalflush_interval self.buffer[]self.lockthreading.Lock()self._start_auto_flush()defadd(self,doc:dict):withself.lock:self.buffer.append(InsertOne(doc))iflen(self.buffer)self.batch_size:self._flush()def_flush(self):ifnotself.buffer:returntry:self.collection.bulk_write(self.buffer,orderedFalse)exceptExceptionase:# 记录失败批次后续重试或落盘log.error(fBulk write failed:{e}, count{len(self.buffer)})finally:self.buffer.clear()def_start_auto_flush(self):定时刷新防止低流量时数据滞留defloop():whileTrue:time.sleep(self.flush_interval)withself.lock:self._flush()tthreading.Thread(targetloop,daemonTrue)t.start()⚠️orderedFalse是关键允许部分成功避免因单条文档校验失败导致整批回滚。配合应用层重试机制保证最终一致性。4.2 文档结构设计原始数据与清洗数据分离// 原始数据集合保留完整响应用于回溯与重新解析db.raw_pages.insertOne({url:https://example.com/item/123,html:html.../html,// 或压缩后的binaryheaders:{Content-Type:text/html},crawled_at:ISODate(2024-05-20T10:30:00Z),spider_name:product_v2,checksum:a1b2c3d4...// 内容指纹用于变更检测})// 清洗后数据集合业务字段供下游消费db.products.insertOne({source_url:https://example.com/item/123,title:无线蓝牙耳机,price:299.00,sku:BT-2024-001,crawled_at:ISODate(2024-05-20T10:30:00Z),updated_at:ISODate(2024-05-20T10:30:05Z),_raw_id:ObjectId(...)// 关联原始文档})优势解析逻辑变更时可从raw_pages重新提取无需重爬清洗数据集合保持精简查询更快。4.3 索引策略只为必要查询建索引爬虫MongoDB的索引原则写入优先按需建索引。// 必建索引db.raw_pages.createIndex({url:1},{unique:true})// 原始数据去重db.raw_pages.createIndex({crawled_at:-1})// 按时间范围查询db.products.createIndex({sku:1},{unique:true})// 业务唯一键db.products.createIndex({updated_at:-1})// 增量同步// 禁止行为// ❌ 对html/content等大字段建索引// ❌ 对频繁更新的字段建复合索引写入放大// ❌ 未使用的索引不及时删除 监控指标通过db.collection.stats().indexSizes定期检查索引大小单个索引超过集合数据量30%时需评估必要性。写入密集期可临时禁用非关键索引空闲期重建。五、 缓存层减少重复解析与外部调用并非所有数据都需要走MongoDB。以下场景应优先用Redis缓存缓存对象TTLRedis类型说明站点配置robots.txt/sitemap1hString避免每次请求都解析用户代理池永久List/Set轮询使用无需持久化热门商品详情15minHash短时间内多次访问同一页面API Token/OAuth凭证按有效期String避免重复认证解析规则版本永久String规则变更时主动失效# 示例带缓存的页面解析defparse_product(url:str)-dict:cache_keyfcache:product:{md5(url)}cachedr.hgetall(cache_key)ifcached:return{k.decode():v.decode()fork,vincached.items()}# 未命中正常抓取解析datafetch_and_parse(url)# 写入缓存r.hset(cache_key,mappingdata)r.expire(cache_key,900)# 15分钟returndata六、 生产环境避坑清单6.1 Redis相关禁止KEYS *用SCAN游标遍历或在设计时用TagList替代模糊搜索大Key预警单个Set/ZSet超过10万元素即视为大Key拆分为多个slot或使用BF持久化策略爬虫Redis以性能优先推荐save 关闭RDB仅开启AOF everysec连接池复用每个Worker进程独立连接池避免多线程竞争socket。6.2 MongoDB相关WiredTiger缓存设置为物理内存的50%-60%预留足够给OS文件缓存Journal提交间隔写入密集时可设为commitIntervalMs: 200默认100牺牲少量耐久性换吞吐分片时机单集合超过5000万文档或100GB时考虑分片提前规划shard key推荐url_hash或site_idcrawled_at备份策略使用mongodump --oplog保证时间点一致性备份期间避开写入高峰。6.3 通用原则监控先行部署PrometheusGrafana监控Redis内存/命中率、MongoDB opcounters/wt_cache、爬虫QPS/错误率优雅降级Redis不可用时自动切换为内存Set去重限流保护MongoDB写入失败时暂存本地SQLite数据生命周期raw_pages保留30天后归档至对象存储products永久保留但冷数据迁移至低频存储权限最小化爬虫账号仅有readWrite权限禁止drop/createCollection等DDL操作。七、 性能基准参考单机16C32G NVMe SSD指标数值备注Redis SISMEMBER QPS120,000单线程网络带宽未饱和Redis BF.EXISTS QPS85,000RedisBloom模块MongoDB bulk_write TPS12,000500条/批orderedFalseMongoDB 单条insert TPS800对比基准端到端延迟去重写入5msP99不含网络RTT内存占用1亿URL去重~180MBBloom Filter Redis元数据八、 总结存储设计的本质是权衡MongoDBRedis方案并非银弹它的核心价值在于将爬虫存储的复杂性分解为两个可独立优化的子问题Redis解决“快”与“临时”去重、队列、缓存容忍一定数据丢失MongoDB解决“稳”与“持久”原始数据、结构化结果保证最终一致性。在实际落地中请记住三条铁律永远批量写入永远不要逐条insertURL去重尽早压缩内存是爬虫最贵的资源原始数据与业务数据分离为未来留后悔药。技术选型没有最优解只有最适合当前规模与团队能力的解。当你的爬虫从十万级迈向亿级时这套双引擎架构能为你提供足够的扩展空间而不是成为瓶颈。本文所述方案已在电商、资讯、招聘等多个爬虫项目中验证代码片段已脱敏。转载或引用请注明出处。