分布式爬虫架构 - 网络爬虫-学习笔记-上海佼艾

一、分布式爬虫概述

1.1 为什么需要分布式爬虫

当我们需要采集的数据量达到百万、千万甚至亿级别时，单机爬虫存在明显的瓶颈。首先是带宽限制，单台服务器的网络带宽有限，无法充分利用资源。其次是计算资源限制，CPU和内存的约束导致单机爬虫的处理能力存在上限。最后是时间约束，大规模数据采集如果使用单机爬虫，可能需要数天甚至数周才能完成，这在很多业务场景下是无法接受的。

分布式爬虫通过将任务分发到多台机器上并行执行，可以显著提升数据采集效率。理论上，如果调度得当，N台机器的集群可以实现接近N倍的采集速度提升。同时，分布式系统天然具备高可用性，单台机器的故障不会导致整个采集任务失败。

1.2 分布式爬虫的核心挑战

构建一个健壮的分布式爬虫系统，需要解决以下几个关键问题：

URL去重：多个爬虫节点同时运行，如何确保同一个URL不会被多个节点重复抓取，是分布式爬虫的核心问题之一。去重方案需要兼顾准确性和内存效率。
任务调度：如何将待抓取的URL公平地分配给各个爬虫节点，既要保证负载均衡，又要避免节点之间的资源竞争。
数据汇总：各个节点采集的数据需要统一汇总到中央存储，这个过程中要处理数据冲突、重复和一致性问题。
节点管理：如何动态添加或移除爬虫节点，如何监控各节点的健康状态，如何在节点宕机时进行任务重分配。

1.3 分布式爬虫 vs 单机爬虫

对比维度	单机爬虫	分布式爬虫
抓取速度	受单机资源限制	近乎线性扩展
可扩展性	不可扩展	可动态扩展
容错能力	单点故障	高可用
系统复杂度	低	较高
适用规模	万级以下	百万级及以上
运维成本	低	需要专门维护

二、Scrapy-Redis分布式框架

2.1 Scrapy-Redis的原理

Scrapy-Redis是Scrapy的分布式扩展组件，它将Scrapy原本存储在内存中的请求队列和去重集合转移到Redis中，从而实现多台机器之间的任务协调。每个Scrapy爬虫节点都连接到同一个Redis服务器，从中获取待抓取URL，并将新发现的URL提交到Redis中，所有节点共享同一个任务池和去重集合。

这种架构的核心思想是"去中心化的调度"：每个爬虫节点都是对等的，不存在中心调度节点。Redis作为消息中间件承担了URL队列和去重集合的存储功能，天然支持高并发访问，非常适合作为分布式爬虫的协调枢纽。

2.2 Redis作为请求队列

在Scrapy-Redis中，Redis使用List数据结构来存储待抓取的请求（Request）。爬虫节点通过lpop操作从队列左侧获取请求，爬取新页面发现的新请求则通过rpush操作从右侧入队。这种"左取右放"的模式确保了请求的先进先出（FIFO）顺序，也支持优先级调度。

Scrapy-Redis默认使用scrapy:spider_name:requests作为队列的key。如果配置了SCHEDULER_PERSIST=True，即使爬虫中途停止，队列中的请求也不会丢失，下次启动时可以继续执行。

2.3 Redis去重集合

URL去重是分布式爬虫的关键环节。Scrapy-Redis利用Redis的Set数据结构来实现去重，每个待抓取的URL在经过指纹计算（使用SHA1算法对请求的URL、方法和请求体进行哈希）后，作为Set的一个元素存储。当爬虫发现新的URL时，先检查其指纹是否已存在于Set中，如果存在则跳过，否则加入去重集合并入队。

使用Redis Set去重的优点是实现简单、准确率100%，缺点是当URL数量达到千万级别时，内存消耗会变得非常大。每个URL指纹约为40字节（SHA1十六进制字符串），一亿个URL大约需要4GB内存。

2.4 scrapy_redis配置

在Scrapy项目的settings.py中，通过以下配置启用Scrapy-Redis的分布式调度器：

SCHEDULER = "scrapy_redis.scheduler.Scheduler"
DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"
REDIS_URL = 'redis://localhost:6379/0'
SCHEDULER_PERSIST = True

SCHEDULER指定使用scrapy_redis的调度器替代默认调度器；DUPEFILTER_CLASS指定使用基于Redis的去重过滤器；REDIS_URL配置Redis连接地址；SCHEDULER_PERSIST控制爬虫停止时是否保留Redis中的队列和去重数据。

三、Scrapy-Redis实战

3.1 安装scrapy-redis

安装scrapy-redis非常简单，直接使用pip安装即可：

pip install scrapy-redis

scrapy-redis会自动安装依赖的redis-py库。如果需要在连接Redis时使用密码，可以通过REDIS_URL参数包含密码信息，例如redis://:password@localhost:6379/0。

3.2 settings.py完整配置

一个完整的Scrapy-Redis分布式爬虫配置如下：

# settings.py
SCHEDULER = "scrapy_redis.scheduler.Scheduler"
DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"
SCHEDULER_PERSIST = True

# Redis连接配置
REDIS_URL = 'redis://localhost:6379/0'

# 请求队列模式
SCHEDULER_QUEUE_CLASS = 'scrapy_redis.queue.SpiderPriorityQueue'

# 管道配置（可选，自动将抓取的数据存储到Redis）
ITEM_PIPELINES = {
    'scrapy_redis.pipelines.RedisPipeline': 300,
}

# 并发设置（根据机器性能调整）
CONCURRENT_REQUESTS = 16
DOWNLOAD_DELAY = 0.5

3.3 RedisSpider vs Spider

Scrapy-Redis提供了RedisSpider基类，与Scrapy自带的Spider有以下区别：

起始URL：Spider通过start_urls属性定义起始URL列表，而RedisSpider通过redis_key指定一个Redis key，爬虫启动后会从该key对应的List中获取起始URL。
动态添加URL：RedisSpider运行期间，可以随时向Redis的redis_key中push新的URL，爬虫会自动获取并抓取，无需重启。
共享去重：RedisSpider默认启用基于Redis的全局去重，所有爬虫节点共享去重集合。

使用RedisSpider的示例代码：

from scrapy_redis.spiders import RedisSpider

class MySpider(RedisSpider):
    name = 'myspider'
    redis_key = 'myspider:start_urls'

    def parse(self, response):
        # 解析逻辑
        pass

爬虫启动后，需要向Redis中注入起始URL：

redis-cli lpush myspider:start_urls "http://example.com"

3.4 多爬虫共享去重

在实际项目中，可能多个爬虫需要采集相同的网站，这时候可以配置它们共享同一个去重集合，避免重复抓取。通过在settings.py中设置DUPEFILTER_KEY参数来实现：

DUPEFILTER_KEY = 'shared:dupefilter'

设置了相同的DUPEFILTER_KEY后，多个爬虫实例会使用同一个Redis Set进行去重。这种方式在数据采集量大、爬虫种类多的场景下非常有用，可以避免跨爬虫的重复抓取。

3.5 暂停恢复

分布式爬虫经常需要在维护后继续抓取，Scrapy-Redis通过SCHEDULER_PERSIST配置项支持暂停和恢复：

SCHEDULER_PERSIST = True

当设置为True时，爬虫停止后Redis中的请求队列和去重集合不会被清除。下次启动爬虫时，它会继续处理队列中剩余的请求，实现断点续爬。如果设置为False（默认值），每次爬虫启动都会清空之前的队列和去重数据。

需要注意的是，即使设置了SCHEDULER_PERSIST=True，如果爬虫完成了所有任务后正常退出，队列中已经没有请求，此时启动爬虫会处于等待状态。可以配合IDLE_BEFORE_CLOSE参数设置空闲等待时间。

四、消息队列方案

4.1 Redis List作为任务队列

Redis的List数据结构天然支持队列操作。lpush和rpop组合可以实现先进先出队列，lpush和brpop组合可以实现阻塞式读取。Scrapy-Redis正是利用Redis List实现了请求队列。

Redis List作为队列的优点是部署简单（通常Redis已经作为存储组件存在）、性能高（纯内存操作）、支持阻塞读。缺点是List中的元素没有优先级概念，不支持消息确认机制，消息出队后如果处理失败会丢失。

为了解决消息丢失问题，可以使用RPOPLPUSH命令实现可靠队列：从主队列取出消息的同时，将消息备份到处理中队列，处理成功后从备份队列删除，处理失败则重新入队。

4.2 RabbitMQ消息队列

RabbitMQ是一个成熟的消息中间件，相比Redis List提供了更丰富的功能：

消息确认：消费者处理完消息后发送ACK确认，未确认的消息会重新投递，保证不丢失。
交换机模式：支持Direct、Topic、Fanout等多种路由模式，可以灵活地将消息分发到不同的队列。
优先级队列：可以为URL设置优先级，确保重要页面优先抓取。
持久化：消息可以持久化到磁盘，即使RabbitMQ重启也不会丢失。

在爬虫架构中，RabbitMQ适合对消息可靠性要求高的场景。但需要注意，RabbitMQ的吞吐量（万级/秒）不如Kafka，且运维成本相对较高。

4.3 Kafka高吞吐量消息队列

Kafka是专为高吞吐量设计的分布式消息系统，在爬虫领域的应用越来越广泛：

超高吞吐量：Kafka可以轻松达到每秒数十万甚至百万级消息处理能力，非常适合大规模爬虫任务。
分区机制：Topic可以分成多个Partition，每个Partition可以被不同的消费者并行消费，天然支持并行处理。
消息回溯：Kafka的消息默认持久化，消费者可以重置偏移量重新消费历史消息。
日志式存储：Kafka使用追加日志的方式存储消息，写入性能极高。

Kafka适合爬取速度极快、数据量极大的场景。但Kafka的部署和运维相对复杂，且作为请求队列时延迟比Redis高。

4.4 消息队列方案对比

特性	Redis List	RabbitMQ	Kafka
吞吐量	万级/秒	万级/秒	百万级/秒
消息可靠性	低（无ACK）	高（ACK机制）	高（ISR副本）
延迟	亚毫秒	微秒级	毫秒级
运维复杂度	低	中	高
适用场景	中小规模	需要路由和确认	大规模高吞吐

五、分布式去重方案

5.1 Redis Set去重

这是Scrapy-Redis默认使用的去重方案，将URL的SHA1指纹存储到Redis Set中。实现简单，准确率100%，适合URL数量在千万级以下的场景。当URL数量达到亿级时，内存消耗会非常大。

5.2 Redis HyperLogLog

HyperLogLog是一种概率性数据结构，用于统计基数（即唯一元素的数量）。它使用固定大小的内存（约12KB）就可以统计2^64个不同元素的基数，标准误差约为0.81%。

在爬虫场景中，HyperLogLog可以用于粗略去重，但需要注意它不支持判断某个URL是否已存在（即不能做"是否已抓取"的查询），只能统计"大概有多少不同的URL已抓取"。因此HyperLogLog更适合做抓取进度的估算，而不是精确去重。

5.3 布隆过滤器（Bloom Filter）

布隆过滤器是分布式爬虫中最常用的高性能去重方案，它在内存效率和准确性之间取得了很好的平衡。

5.3.1 原理

布隆过滤器的核心思想是：使用一个很长的二进制位数组和多个独立的哈希函数。当一个URL需要加入过滤器时，用多个哈希函数计算出多个位数组位置，将这些位置的值设为1。判断一个URL是否已存在时，同样计算哈希值，检查对应位置是否全部为1。如果任何一个位置为0，则URL一定不存在；如果全部为1，则URL可能存在（有一定误判率）。

布隆过滤器的特点：

空间效率极高：相比Redis Set可以节省90%以上的内存。
存在误判率：可能把不存在的元素误判为存在（假阳性），但不会把存在的元素误判为不存在（假阴性）。
不支持删除：标准布隆过滤器无法删除元素，因为多个元素可能共享同一个位。

5.3.2 误判率控制

布隆过滤器的误判率与以下参数相关：

位数组大小m：越大误判率越低。
哈希函数数量k：最优的k值约为(m/n)*ln2，其中n是预期元素数量。
已插入元素数量n：插入越多误判率越高。

在分布式爬虫中，通常将误判率控制在1%以下。例如，预计需要去重1亿个URL，将误判率设为0.1%，需要约1.7GB内存（使用Redis Set需要约4GB）。

5.3.3 pybloom_live库

Python中常用的布隆过滤器实现是pybloom_live库：

from pybloom_live import BloomFilter

bf = BloomFilter(capacity=10000000, error_rate=0.001)

bf.add('http://example.com/page1')
print('http://example.com/page1' in bf)  # True
print('http://example.com/page2' in bf)  # False

capacity参数指定预期的最大元素数量，error_rate指定期望的误判率。库会根据这两个参数自动计算最优的位数组大小和哈希函数数量。

5.3.4 Redis布隆过滤器

Redis从4.0版本开始支持模块扩展，RedisBloom模块为Redis提供了原生的布隆过滤器支持：

# 安装RedisBloom
git clone https://github.com/RedisBloom/RedisBloom.git
cd RedisBloom
make

# 启动时加载模块
redis-server --loadmodule /path/to/redisbloom.so

使用Redis布隆过滤器的命令：

BF.RESERVE myfilter 0.001 10000000
BF.ADD myfilter "http://example.com/page1"
BF.EXISTS myfilter "http://example.com/page1"

BF.RESERVE创建布隆过滤器并指定误判率和容量；BF.ADD添加元素；BF.EXISTS判断元素是否存在。所有操作都在Redis服务端完成，客户端只需发送命令，网络开销很小。

5.4 去重方案对比

方案	内存效率	准确率	支持删除	适用规模
Redis Set	低	100%	是	千万级
HyperLogLog	极高	近似	否	任意规模（仅计数）
Bloom Filter	高	可控误判	否	亿级
Redis Bloom	高	可控误判	否	亿级（分布式）

六、分布式爬虫架构设计

6.1 Master-Worker架构

Master-Worker是分布式爬虫中最常见的架构模式。Master节点负责任务调度、URL去重和数据汇总，不参与实际的页面抓取；Worker节点从Master获取任务，执行页面抓取和解析，将结果和新的URL返还给Master。

在Scrapy-Redis的实现中，Redis扮演了"逻辑Master"的角色，没有单独的Master进程。每个Scrapy节点都是Worker，通过Redis协调工作。这种去中心化的设计消除了单点故障，但缺点是缺少统一的任务监控和管理界面。

6.2 URL调度器设计

一个好的URL调度器需要考虑以下因素：

优先级：重要页面（如首页、热门内容）应该优先抓取。可以使用Redis的Sorted Set实现优先级队列，score作为优先级。
爬取频率：对同一个域的请求需要控制频率，避免被反爬。可以在调度器中加入域级别的限流逻辑。
去重检查：每个URL在被放入队列之前都要经过去重过滤器的检查，确保不会重复抓取。
请求去重：除了URL本身，还需要考虑带有不同参数的同一URL是否需要分别抓取。通过定制RequestFingerprinter可以实现灵活的指纹计算策略。

6.3 数据汇总策略

各个Worker节点采集的数据需要汇总到中央存储。常用的汇总策略包括：

直接写入数据库：每个Worker直接连接数据库写入。优点是延迟低，缺点是数据库连接数多，可能成为瓶颈。
通过消息队列汇聚：Worker将数据发送到消息队列，由专门的Consumer写入数据库。优点是解耦、削峰填谷，缺点是需要额外的组件。
Scrapy-Redis的RedisPipeline：将抓取到的Item序列化后存储到Redis中，再由单独的进程批量写入数据库。

6.4 任务监控

分布式爬虫的监控是运维中的重要环节，需要关注以下指标：

爬取速度：每秒抓取的页面数量，反映当前系统的处理能力。
队列长度：Redis中待抓取的请求数量，反映任务的积压情况。
去重数量：已去重的URL总量，反映爬虫的整体进度。
节点状态：各Worker节点的在线状态、CPU和内存使用率。
错误率：抓取失败的请求占比，反映目标网站的反爬强度或系统稳定性。

可以使用redis-cli配合定时脚本实现简单的监控，也可以接入Prometheus + Grafana等专业监控系统。

七、部署与调度

7.1 Docker容器化部署

使用Docker可以快速部署多个爬虫节点，保证环境一致性：

FROM python:3.9-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

CMD ["scrapy", "crawl", "myspider"]

构建镜像并启动多个容器实例：

docker build -t distributed-spider .
docker run -d --name spider-1 distributed-spider
docker run -d --name spider-2 distributed-spider
docker run -d --name spider-3 distributed-spider

7.2 定时任务调度

对于需要定时执行的爬虫任务，可以使用Crontab或APScheduler：

Crontab方案（Linux）：

# 每天凌晨2点执行爬虫
0 2 * * * cd /path/to/project && scrapy crawl myspider

APScheduler方案（Python）：

from apscheduler.schedulers.blocking import BlockingScheduler
import subprocess

def run_spider():
    subprocess.run(['scrapy', 'crawl', 'myspider'])

scheduler = BlockingScheduler()
scheduler.add_job(run_spider, 'cron', hour=2, minute=0)
scheduler.start()

7.3 节点动态扩缩容

分布式爬虫的魅力在于可以根据需求动态调整集群规模。当任务积压时，可以快速增加Worker节点。当负载降低时，可以减少节点节约资源。

使用Docker Compose可以方便地管理多节点：

version: '3'
services:
  spider:
    build: .
    environment:
      - REDIS_URL=redis://redis:6379/0
    deploy:
      replicas: 5
    depends_on:
      - redis

  redis:
    image: redis:7-alpine

通过docker-compose up --scale spider=10可以快速将爬虫节点扩展到10个。

7.4 失败重试与故障转移

分布式环境下，节点故障是常态而非异常。需要设计完善的容错机制：

请求重试：对失败的请求设置重试机制，Scrapy的RETRY_TIMES配置可以控制重试次数。对于分布式环境，建议设置RETRY_HTTP_CODES=[500, 502, 503, 504, 408]。
节点故障检测：通过心跳机制检测节点是否存活。如果节点在超时时间内没有汇报心跳，则认为节点已宕机，将其任务重新分配给其他节点。
任务超时：为每个任务设置超时时间。如果任务在超时时间内没有完成，自动重新入队。
幂等性设计：爬虫的数据处理逻辑应该是幂等的，即同一条数据被处理多次不会产生副作用。这样即使某个请求被多个节点重复处理，也不会造成数据错误。

小结：分布式爬虫是应对大规模数据采集的必备技能。从Scrapy-Redis入门，理解Redis队列和去重的原理，再逐步引入布隆过滤器优化内存，配合消息队列和Docker容器化部署，就可以构建出稳定高效的分布式爬虫系统。在实际项目中，建议从简单的Scrapy-Redis方案入手，随着数据规模的增长，逐步引入更复杂的架构组件。