千万级电商数据爬取系统设计与MongoDB优化实践-代码聚汇网

千万级电商数据爬取系统设计与MongoDB优化实践

分布式爬虫Scrapy-RedisMongoDB分片

|难度：普通|阅读约 20 分钟

1. 项目概述：千万级电商数据爬取系统设计

这个爬虫项目源自去年我们团队接到的电商价格监控需求，客户需要实时追踪15个主流电商平台的3C类目商品数据，日均数据量在300万条左右。传统单机爬虫在测试阶段就暴露出明显的性能瓶颈——完成一次全量抓取需要近40小时，且频繁遭遇IP封禁。这迫使我们转向分布式架构，最终实现的系统可以稳定维持每秒200+的请求量，数据入库延迟控制在3秒内。

系统核心由四部分组成：(1)基于Scrapy-Redis的任务调度层，实现请求的分布式分配；(2)动态代理池和请求指纹去重机制，保证高可用性；(3)MongoDB分片集群存储，支持水平扩展；(4)可视化监控看板，实时展示爬虫状态和数据质量。特别要说明的是，我们放弃了常见的MySQL方案，因为测试中发现当单表超过500万条记录时，即便加了索引，查询性能也会急剧下降，而MongoDB的文档模型和分片能力完美适配了商品数据半结构化的特性。

重要提示：商业爬虫必须严格遵守robots.txt协议，我们的实践是在代码中集成RobotsParser模块，自动识别并遵守目标网站的爬取限制，同时将请求频率控制在人类浏览的合理范围内（通常每秒不超过2次请求）。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术架构深度解析

2.1 分布式爬虫核心组件

Scrapy-Redis构成了系统的骨架，其工作原理值得深入剖析。主节点运行的Redis服务器存储着三类关键数据：

待爬队列（spider:requests）：采用优先级队列存储Request对象
请求指纹（spider:dupefilter）：Bloom过滤器实现，占用空间仅为传统哈希表的1/8
项目缓存（spider:items）：临时存储爬取结果，等待持久化

我们在原生架构上做了两处关键改进：

动态权重调度算法：根据URL域名自动调整优先级，对反爬严格的网站降低请求密度
心跳检测机制：每30秒检查各工作节点状态，自动重启僵死的爬虫进程

配置示例（scrapy_redis默认配置增强版）：

python复制# settings.py
SCHEDULER = "scrapy_redis.scheduler.Scheduler"
DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"
REDIS_URL = 'redis://:password@master-node:6379/0'

# 自定义配置
SCHEDULER_QUEUE_CLASS = 'project.queue.PriorityQueue'
SCHEDULER_SERIALIZER = "project.picklecompat.PickleSerializer"
STATS_CLASS = "scrapy_redis.stats.RedisStatsCollector"

2.2 MongoDB集群优化实践

面对日均300GB的原始数据，我们设计了如下分片策略：

按电商平台分片（shard key=platform）
3个配置服务器 + 2个mongos路由 + 6个分片节点（3副本集×2）
WiredTiger存储引擎，配置snappy压缩

关键参数调优记录：

yaml复制# mongod.conf
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 12 # 建议不超过物理内存60%
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy
    indexConfig:
      prefixCompression: true

写入性能对比测试结果（单位：ops/sec）：

并发线程数	无索引	单字段索引	复合索引
10	8,742	7,105	6,883
50	9,156	8,927	8,674
100	9,203	9,018	8,905

经验之谈：MongoDB 4.0+版本的事务功能在爬虫场景要慎用，我们的测试显示开启事务后写入吞吐量下降达40%。对于商品数据这种独立文档，其实不需要强一致性保证。

3. 反爬对抗体系构建

3.1 动态代理池实现

市面上90%的代理服务商我们都有测试，最终选型方案是：

国内站点：混用芝麻代理和快代理的独享IP套餐
国际站点：Luminati的住宅IP+自建AWS出口IP轮询

代理健康检查算法（Python实现核心逻辑）：

python复制def check_proxy(proxy):
    try:
        start = time.time()
        resp = requests.get('https://httpbin.org/ip', 
                          proxies={"http": proxy, "https": proxy},
                          timeout=10)
        latency = time.time() - start
        if resp.json().get('origin') in proxy:
            return {
                'valid': True,
                'latency': latency,
                'stable': latency < 2.0
            }
    except Exception:
        pass
    return {'valid': False}

3.2 请求特征伪装技术

浏览器的真实请求包含上百个特征头，我们通过实测总结了关键参数：

User-Agent轮频：准备120个常见UA，按权重分配使用频率
TLS指纹伪装：使用pycurl模拟Chrome的TLS握手特征
鼠标轨迹模拟：对关键操作生成贝塞尔曲线轨迹坐标

请求头优化示例：

http复制GET /product/12345 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
Referer: https://www.example.com/category/electronics
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 118.122.123.124

4. 数据存储与处理流水线

4.1 MongoDB Schema设计

商品数据采用灵活但有约束的混合Schema：

python复制{
    "_id": ObjectId("5f8d8a7b8c3a1b2c3d4e5f6g"),
    "platform": "jd",  # 平台标识
    "item_id": "100003456789",
    "crawl_time": ISODate("2023-05-20T14:32:45Z"),
    "basic_info": {
        "title": "Apple iPhone 14 Pro Max 256GB",
        "price": 9999.00,
        "original_price": 10999.00,
        "sales": 25000,
        "shop": {"name": "Apple官方旗舰店", "type": "self"}
    },
    "specs": [
        {"name": "颜色", "value": "深空黑"},
        {"name": "版本", "value": "5G全网通"}
    ],
    "extras": {}  # 预留扩展字段
}

索引策略：

必须创建：platform+item_id唯一索引
推荐创建：basic_info.price范围索引、crawl_time时间索引
避免创建：specs数组字段的全索引

4.2 数据清洗流程

原始数据需要经过五步标准化处理：

字符编码统一转UTF-8
价格字段提取（处理¥1,299.00等格式）
规格参数结构化（将"颜色:黑色;内存:256GB"拆解）
图片URL规范化（相对路径转绝对URL）
敏感信息脱敏（商家联系方式等）

价格清洗正则示例：

python复制import re
def extract_price(text):
    pattern = r'[¥￥]?\s*(\d{1,3}(?:,\d{3})*(?:\.\d{2})?)'
    match = re.search(pattern, text)
    if match:
        return float(match.group(1).replace(',', ''))
    return None

5. 可视化监控系统实现

5.1 实时看板技术栈

采用Grafana+Prometheus+自定义Exporter方案：

爬虫节点通过statsd上报指标
Prometheus每15秒抓取一次数据
Grafana配置关键仪表盘：
- 请求成功率/失败率
- 代理IP健康状态
- MongoDB集群负载
- 数据增长趋势

核心监控指标示例：

python复制# 在Spider中埋点
class MySpider(scrapy.Spider):
    def __init__(self):
        self.stats = statsd.StatsClient('monitor-host', 8125)
        
    def parse(self, response):
        self.stats.incr('request.count')
        if response.status != 200:
            self.stats.incr('request.error')
            return
            
        # 解析逻辑...
        self.stats.timing('parse.time', time.time() - start_time)

5.2 数据分析案例

价格波动分析SQL（在MongoDB Shell中执行）：

javascript复制db.products.aggregate([
    {
        $match: {
            "basic_info.title": /iPhone 14 Pro Max 256GB/,
            "crawl_time": {
                $gte: ISODate("2023-05-01"),
                $lte: ISODate("2023-05-31")
            }
        }
    },
    {
        $group: {
            _id: {
                platform: "$platform",
                date: { $dateToString: { format: "%Y-%m-%d", date: "$crawl_time" } }
            },
            avgPrice: { $avg: "$basic_info.price" },
            minPrice: { $min: "$basic_info.price" },
            maxPrice: { $max: "$basic_info.price" }
        }
    },
    { $sort: { "_id.date": 1 } }
])

6. 性能调优实战记录

6.1 爬虫节点优化

通过cProfile发现的性能瓶颈及解决方案：

XPath解析耗时：改用PyQuery后解析速度提升3倍
重复DNS查询：启用dnscache模块，缓存时间设为300秒
日志I/O阻塞：改用异步日志库logzero，写入吞吐量提升50%

内存优化配置示例：

python复制# settings.py
import gc
gc.set_threshold(700, 10, 10)  # 调高GC阈值

# 禁用不需要的中间件
DOWNLOADER_MIDDLEWARES = {
    'scrapy.downloadermiddlewares.robotstxt.RobotsTxtMiddleware': 100,
    # 其他中间件...
}

6.2 MongoDB写入优化

批量插入的黄金法则：

理想批次大小：100-500个文档/次
使用unordered_insert提升吞吐量
合理利用bulk_write操作

实测写入速度对比（单位：万条/分钟）：

写入方式	无索引	有索引
单条插入	1.2	0.8
批量插入(100)	8.7	6.5
bulk_write	12.4	9.1

7. 踩坑经验与故障排查

7.1 典型问题速查表

故障现象	可能原因	解决方案
Redis连接数暴涨	爬虫异常退出未释放连接	增加连接池回收超时设置
MongoDB查询超时	未设置最大执行时间	添加maxTimeMS参数
代理IP大量失效	目标网站更新了IP检测策略	切换代理供应商或调整轮频策略
数据重复率超过5%	Bloom过滤器内存不足	扩大redis内存并重置过滤器
爬虫节点CPU持续100%	解析回调陷入死循环	添加递归深度保护机制

7.2 血泪教训

不要相信任何免费代理IP池，我们曾因使用某个知名免费服务导致所有爬虫IP被目标网站批量封禁
MongoDB的_id默认生成方式（时间戳+机器标识）在分布式环境下可能导致冲突，建议改用UUID
永远为每个Request设置errback回调，我们曾因未处理503错误导致丢失重要数据
爬虫日志一定要包含完整上下文信息（至少包含URL和时间戳），否则排查问题如同大海捞针

8. 法律合规与道德考量

虽然技术实现很吸引人，但必须强调合规底线：

严格遵守目标网站的robots.txt协议
设置合理的爬取间隔（建议≥2秒/请求）
禁止爬取用户个人信息等敏感数据
数据使用范围需获得授权
商业用途前务必咨询法律顾问

我们在项目中采取的合规措施：

自动识别并遵守robots.txt
请求头包含明确的Contact信息
数据存储加密处理
设置严格的访问权限控制

最后分享一个实用技巧：在开发阶段，可以先用https://httpbin.org/这个服务测试爬虫的各种行为，它能回显所有请求细节，非常适合调试请求头、代理等设置。