Scrapy分布式爬虫改造实战：从单机到Redis集群的架构与踩坑-代码聚汇网

Scrapy分布式爬虫改造实战：从单机到Redis集群的架构与踩坑

Scrapy分布式爬虫scrapy-redis

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

做过爬虫的人大概都经历过这样一个阶段：单机Scrapy跑得好好的，协程并发调到32，请求间隔压到0.1秒，带宽跑满，硬盘一天写几GB数据，当时觉得"这不挺快吗"。直到某天接到一个需要抓取千万级数据量的需求，跑了一周才完成20%，这时候才发现，Scrapy单机的性能天花板不是CPU也不是带宽，而是调度模型本身。我这篇文章就想聊聊，怎么用Scrapy把单机爬虫改造成一套真正可横向扩展的分布式爬虫，包括核心架构、实操步骤，以及我在真实环境里踩过的坑。

1. 当单机Scrapy撞上性能天花板：先搞清楚瓶颈在哪

1.1 我遇到的那个"跑不完"的爬虫

先交代背景。去年我做了一个电商比价项目，需要采集某个垂直品类下所有商品的SKU信息。数据量大概800万条，商品详情页还要解析变体、规格、库存状态。单机Scrapy怎么跑都不太对劲：请求协程从16调到40，稳定跑了三天，Redis里存了多少条数据呢？120万。照这速度，跑完全量数据要20天，而且中间还得处理IP封禁、登录失效、详情页结构改版这些幺蛾子。更尴尬的是，这台机器如果夜里死机了，前面所有断点续传全靠MySQL里job_id维度的状态标记去拼。

当时我第一反应是"加机器"，但很快意识到，无脑加机器是没用的。因为Scrapy默认的去重是基于内存中的RFPDupeFilter，每一台机器都有自己独立的去重集合和调度队列。你就算起10台机器，它们也会各自为政，抓取任务大量重复，甚至可能同时抓同一个URL。真正的解法是先让"调度"这件事从单机进程里解耦出来，让所有机器共享同一个任务队列、同一个去重集合，然后才有资格谈扩展。

1.2 单机瓶颈到底卡在哪：CPU、带宽还是调度逻辑？

很多人以为瓶颈在网络带宽，但我在实际压测中发现，对于中等规模页面（50KB到200KB），瓶颈通常在任务调度和网络等待的权衡逻辑上。

Scrapy的调度器是进程内的，它负责从优先队列里拿出Request，交给下载器执行。单机模式下，一个Request从入队到出队、到发送、到处理响应，整个生命周期都在同一个进程里，协程切换开销再小，它也是单点调度。而且当爬虫需要处理多种类型的URL（比如列表页和详情页优先级不同），或者遇到下载超时要重试时，调度器就开始变得力不从心。

另外一个隐藏瓶颈是去重集合的内存占用。Scrapy默认的指纹集合就是一个不断增长的Python set。如果你跑了千万级URL，这个set占用的内存会轻松超过2GB。关键问题是，这个set没法持久化，进程一重启就没了，你还得靠JOBDIR去延续。这是一种非常脆弱的单机状态。

所以单机Scrapy的问题，不是"不够快"，而是没法在故障恢复、任务分发、去重共享三个维度上做到协作。你需要的是一个能够横跨多台机器的调度中心，而不是一台一台地堆爬虫实例。

1.3 分布式不是银弹：它解决什么，不解决什么

这里我先泼一盆冷水。分布式爬虫解决的是吞吐量和容错问题，它不解决目标网站反爬策略问题。如果你单机跑都被封IP，那分布式只会更惨——因为多台机器同时访问，被封的维度更多，暴露得更快。所以决定上分布式之前，先确认你的目标网站允许一定频率的访问策略（或者说，你有充分的合规理由和合适的限速方案），再考虑架构改造。

分布式真正解决的问题有三个：

任务队列共享，多个worker节点从同一个队列取任务，天然避免了重复分配。
去重集合共享，URL指纹只需判断一次，不需要每台机器各维护一个。
调度状态持久化，队列和指纹都存在Redis里，单台worker宕机不影响整个集群的任务流转。

这套思路其实非常成熟，早些年大家用Celery做分布式任务队列，后来Scrapy生态里冒出了scrapy-redis这个库，把Scrapy的调度器、去重器用Redis重写了一遍，整个接入成本就低了很多。下面我详细拆解它的工作机制。

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

2. 分布式爬虫的核心机制：从进程内调度到跨机器协作

2.1 关键组件的外部化：调度器、去重器、数据管道

要理解scrapy-redis的原理，首先要理解Scrapy在单机模式下哪些东西是"进程内私有"的。

调度器（Scheduler）：Scrapy默认的Scheduler维护一个优先队列（默认是内存队列），负责管理待爬取的Request。
去重器（Dupefilter）：一个基于内存set的指纹过滤器。每当一个Request到达调度器之前，先去这个set里查指纹是否已存在。
爬虫队列逻辑：start_requests生成的第一批URL，会直接进入调度器。

这三样东西在单机模式下全都在内存里，进程死了就全没了。scrapy-redis做的事，就是把这三样东西全部搬到一个所有机器都能访问的Redis里去。

听起来好像是"用Redis存队列"这么简单，但细节比这个多。在scrapy-redis里，调度器不再读取进程内的start_requests，而是读取Redis里的一个List类型key（默认是spider_name:start_urls）。worker节点通过RedisSpider或者手动把起始URL推送到这个key里，所有机器就能从这个共享队列里抢占任务。谁来抢？谁先执行lpop或者brpop，谁就拿到这个Request。

2.2 scrapy-redis 到底做了什么

具体来说，scrapy-redis做了四件关键的事：

替换Scheduler：把原来的PriorityScheduler替换为基于Redis的调度器。所有待抓取的Request都被序列化以后扔进Redis的List或者ZSet（如果你启用了优先级，可以用ZSet实现按优先级调度）。
替换Dupefilter：把原来的内存set替换成Redis的SET数据结构。指纹判断变成SISMEMBER + SADD两个操作。去重集合可以跨进程共享，并且可以通过Redis的持久化机制保留下来。
提供Spider基类：RedisSpider和RedisCrawlSpider。它们不读取start_urls属性，而是从Redis里读取起始URL。
实现数据管道：scrapy-redis还提供了一个把Item推入Redis List的Pipeline。通常不用它存最终数据，而是用它把Item暂存到Redis，再通过另一个消费者进程写入MySQL或HBase。这样爬虫进程本身不直连数据库，IO压力也不会阻塞抓取循环。

这四件事联动起来的效果是：你可以把任意数量的worker节点挂在同一个Redis上，它们共享队列、共享去重指纹、共享调度状态。任何一个节点宕机，其他节点会自动继续消费队列里的任务，不需要人工干预。

2.3 请求指纹与去重：为什么分布式下同一URL不会被重复抓取

很多刚接触分布式的朋友最容易问：多台机器同时跑，真的不会重复抓同一个URL吗？

答案是：不会，但也可能——这取决于你的指纹生成逻辑。

Scrapy的默认指纹算法是基于url、method、body、headers中的关键字段做SHA1哈希。相同的Request在两个worker上算出来的指纹是一样的。当两个worker同时从Redis队列里取任务时，逻辑是这样的：先lpop取出一个Request，然后执行SISMEMBER判断指纹是否在集合中，不在就SADD加入集合，然后开始抓取。这个判断和加入的过程本身是原子的吗？其实涉及两步操作，在极端并发下存在一个竞态条件：两个worker同时查指纹，都没查到，然后同时加入集合，结果两个都开始抓取。

不过在实际运行中，这种竞态发生的概率非常低，因为队列消费是lpop，同一个Request只会被一个worker取走。真正容易出问题的是你自己手动往队列里推了重复URL，或者调度器重试逻辑里产生了重复的Request。对于后者，DUPEFILTER_CLASS配合SCHEDULER_FLUSH_ON_START这些配置需要仔细调，下文实操部分我会细讲。

3. 实操：手把手把一个Scrapy项目改造成分布式集群

3.1 环境准备：版本兼容这件"小"事

先列一下我这次改造用的环境，方便你对照：

Python 3.9
Scrapy 2.9.0
scrapy-redis 0.7.3
Redis 6.2

需要特别注意，scrapy-redis这个库很久没更新了，0.7.3版本对Scrapy 2.x的兼容性还不错，但对Scrapy 2.10以上版本有概率出现from scrapy.utils.reqser import request_to_dict导入报错的问题。这是因为新版本Scrapy移除了scrapy.utils.reqser这个模块。如果遇到这问题，解决方案是手动给scrapy-redis打补丁，或者把Scrapy锁定在2.9.x/2.11.x这些验证过的版本上。我在项目里用的就是Scrapy 2.9.0，稳定跑了一个多月没出过幺蛾子。

安装依赖：

bash复制pip install scrapy==2.9.0 scrapy-redis==0.7.3 redis

Redis服务端如果是云端托管，注意网络延迟和连接数上限。每台worker节点的连接池默认是10个左右，集群规模大了以后，Redis的连接数会飙升。建议在settings.py里显式配置连接池参数，后面会提到。

3.2 settings.py 里需要改的四个核心配置

我见过很多新手在网上找"分布式爬虫配置模板"，复制几个配置一改就完事，结果跑起来全是bug。其实核心配置就四个，搞懂每个配置的意义比抄配置重要得多。

在settings.py里加这样一段：

python复制# 使用scrapy-redis的调度器
SCHEDULER = "scrapy_redis.scheduler.Scheduler"

# 使用scrapy-redis的去重过滤器
DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"

# Redis连接地址
REDIS_URL = 'redis://your-redis-host:6379'

# 调度器持久化开关
SCHEDULER_PERSIST = True

一个一个解释。

SCHEDULER：替换Scrapy默认的调度器。这是最核心的一行配置，等于告诉Scrapy"你别自己管任务队列了，去Redis里拿任务"。

DUPEFILTER_CLASS：替换去重过滤器。RFPDupeFilter通过Redis的SET结构实现URL去重指纹的跨进程共享。如果不配这个，每台worker还是各自为政，就会重复抓取。

REDIS_URL：Redis的连接地址。在实际生产环境，我建议不要用单机Redis，最好用有主从切换的Redis实例。因为一旦Redis挂了，整个分布式爬虫集群就瘫痪了。

SCHEDULER_PERSIST：这个配置非常关键。设为True时，worker进程关闭或崩溃后，Redis队列里的任务不会清空，下次启动可以接着跑。设为False时，每次启动都会清空任务队列。我建议在生产环境设为True，配合定时任务做断点续爬。

还有一个比较容易忽略的配置是去重集合的过期策略。如果你跑的是一个长期任务，指纹集合会越来越大，Redis内存迟早撑不住。可以在Redis端做定期清理：每天凌晨删除一定时间以外的指纹，或者用单独的Redis实例跑去重指纹，方便定期切换。

3.3 爬虫类该用RedisSpider还是普通Spider

这是很多教程没讲清楚的地方。RedisSpider和普通Spider最大的区别在起始URL的读取方式上：

普通Spider读取start_urls属性。
RedisSpider不读属性，它从Redis的spider_name:start_urls这个列表key里读取起始URL。

具体代码写法：

python复制import scrapy
from scrapy_redis.spiders import RedisSpider

class ProductSpider(RedisSpider):
    name = "product_spider"

    def parse(self, response):
        # 解析列表页
        item_links = response.css("a.item-link::attr(href)").extract()
        for link in item_links:
            yield scrapy.Request(url=response.urljoin(link), callback=self.parse_detail)

        # 翻页
        next_page = response.css("a.next::attr(href)").extract_first()
        if next_page:
            yield scrapy.Request(url=response.urljoin(next_page), callback=self.parse)

    def parse_detail(self, response):
        yield {
            "title": response.css("h1::text").get(),
            "price": response.css(".price::text").get(),
            "sku": response.css(".sku::attr(data-sku)").get(),
        }

然后，你不要在代码里初始化start_urls，而是在启动worker之前，手动往Redis里推起始URL：

bash复制redis-cli lpush product_spider:start_urls "https://example.com/category/shoes"

为什么用lpush而不是set？因为RedisSpider在启动时会用lpop之类的操作从列表左侧消费起始URL。多条起始URL可以依次lpush进去，worker启动之后就能立即消费。

实际运行中，我习惯把起始URL的推送写成一个小脚本，统一管理，比如一次性推入多个分类页URL：

python复制import redis

r = redis.Redis.from_url('redis://your-redis-host:6379')
urls = [
    "https://example.com/category/shoes",
    "https://example.com/category/bags",
    "https://example.com/category/accessories",
]
for url in urls:
    r.lpush("product_spider:start_urls", url)

使用RedisCrawlSpider的场景：如果你要抓取整个站点，需要基于CrawlSpider的Rule机制做自动链接发现，那你就应该继承RedisCrawlSpider。它保留了Rule驱动的爬取逻辑，同时起始URL从Redis读取。比如：

python复制from scrapy_redis.spiders import RedisCrawlSpider
from scrapy.spiders import Rule
from scrapy.linkextractors import LinkExtractor

class SiteSpider(RedisCrawlSpider):
    name = "site_spider"
    rules = (
        Rule(LinkExtractor(allow=r"/product/\d+"), callback="parse_item", follow=False),
        Rule(LinkExtractor(allow=r"/category/"), follow=True),
    )

    def parse_item(self, response):
        yield {"title": response.css("h1::text").get()}

3.4 启动与投喂：master和worker的正确打开方式

很多人对"分布式爬虫"有个误解，以为需要一台专门的master机器来分配任务。实际上在scrapy-redis这套架构里，没有主从之分，所有机器都是worker，Redis扮演了master的角色。你可以在任意一台worker上推送起始URL，也可以通过一个独立的管理脚本推送起始URL。

启动方式也很统一，在所有机器上进入同一个爬虫目录，执行：

bash复制scrapy crawl product_spider

然后，任选一台机器往Redis里推送起始URL：

bash复制redis-cli lpush product_spider:start_urls "https://example.com/category/shoes"

此时你会看到，所有worker几乎同时开始消费这个URL队列。由于RFPDupeFilter是共享的，同一条URL只会被一台worker的parse方法处理一次。

实际运行中有一个细节要提醒：worker的数量和Redis队列消费速率是有关联的。如果你有10台worker，但队列里只有几十个列表页URL，大部分worker会进入"空转等待"状态，不断执行brpop阻塞等待新任务。这是正常的。真正需要的是保证队列里有足够的待解析任务供worker消费，否则加再多worker也提升不了吞吐量。

数据管道的建议：scrapy-redis自带了一个把Item推入Redis List的Pipeline，不过我个人不建议直接用这个Pipeline作为最终落库方案。理由是：Redis存储大量原始Item会占内存，而且后续清洗还得再读一遍，多一跳。我通常的做法是让各worker直连MySQL或MongoDB写入，或者用Kafka做削峰缓冲。只有遇到数据库写入压力过大时，才会引入Redis作为暂存缓冲，再由一个独立的消费者异步批量写入。

4. 真实运行中踩过的坑：从Redis失联到重复抓取的完整排障过程

理论讲完，下面这部分才是真正的实战价值。分布式爬虫和单机爬虫有个本质区别：系统复杂度上了一个台阶，故障排查的维度也从"看日志"变成了"看Redis、看网络、看各节点日志"。我把我实际踩过的坑和排查链路完整写出来，希望你能少走点弯路。

4.1 坑一：所有worker同时抢占导致Redis连接风暴

第一次把集群扩容到5台worker时，发现Redis CPU飙到90%，还有大量MISCONF Errors writing to the AOF的错误报警，紧接着就有worker开始报：

text复制redis.exceptions.ConnectionError: Error while reading from socket: Connection reset by peer

排障链路：

先看Redis日志，发现大量连接从不同IP涌入，并发连接数一度超过500。
再看worker日志，发现每个worker在启动时都会实例化若干个Redis连接，而且scrapy-redis内部对同一个Redis会创建多个连接池。
进一步定位，问题出在REDIS_URL未指定连接池参数，所有worker都用默认的redis.ConnectionPool配置，导致每个进程创建的连接数远超预期。

解决方案是在settings.py里显式配置连接池：

python复制REDIS_PARAMS = {
    "socket_timeout": 30,
    "socket_connect_timeout": 30,
    "retry_on_timeout": True,
    "max_connections": 30,
}

max_connections设成30之后，每个worker对Redis的连接数被限制住了，问题解决。另外，Redis侧的timeout建议设置成300（秒），避免空闲连接被回收导致worker端报错。

4.2 坑二：运行一段时间后，任务重复率飙升

集群连续运行48小时后，我在数据库里做唯一键校验，发现有的URL被抓了两次甚至三次。这个问题如果不排查清楚，分布式爬虫就白做了——因为你牺牲了那么多机器，结果大量请求是白费的。

排障链路：

首先在Scrapy日志里搜索同一个URL的抓取记录，确认它确实被多个worker分别抓取过。
检查指纹生成逻辑。Scrapy的默认指纹包含了url、method、body和关键headers。如果两个worker上Scrapy版本一致，指纹应该完全一致。
再查调度器重试逻辑。我配置了RETRY_TIMES = 3，下载超时后会重试。每个worker在重试时，会重新生成Request。问题出在重试的Request在入队前会再次执行DUPEFILTER判断。理论上指纹是同一个，不会重新加入队列，但此时我发现了一个细节：指纹集合在Redis里用的是SET类型，如果两个worker同时判断同一个请求的指纹，其中一个会SISMEMBER返回False，然后SADD成功，另一个也是同样的流程。这个"判断+写入"的操作不是一个原子操作，极端情况下会放行重复请求。

这个问题怎么解决？最可靠的方案是把指纹判断写成一个Lua脚本，在Redis端原子执行：

lua复制-- 原子化检查并添加指纹
if redis.call('SISMEMBER', KEYS[1], ARGV[1]) == 1 then
    return 0
else
    redis.call('SADD', KEYS[1], ARGV[1])
    return 1
end

不过这需要改RFPDupeFilter的源码，维护成本比较高。我在实际项目中用的替代方案是：接受极低概率的重复请求，但在解析阶段用数据库的唯一索引兜底。也就是：即使Request重复了，解析出来的Item在写入数据库时，MySQL的唯一键会拦下重复数据。这个方案工程上最简单，而且能保证最终数据不重复，我认为是性价比最高的选择。

4.3 坑三：某一台worker宕机，任务队列里的任务会丢吗？

这个问题我专门做了个实验。在我的一台worker上直接kill -9干掉进程，观察Redis队列里的任务变化。

结论是：不会丢。

因为scrapy-redis的调度器在取出Request之后，并不会立即从Redis队列中删除。它的逻辑是：lpop取出一个Request，但与此同时，它会复制一份放入“内存处理中”状态。如果worker崩溃，这个Request就还留在Redis的另一个队列里（在scrapy-redis的实现里，它用一个临时集合记录在途请求）。重启worker后，可以从Redis里恢复这些在途请求，重新入队。

当然，这个机制不是绝对完美的。如果你的worker在处理Request的过程中已经发出了HTTP请求、并且下载器已经返回了Response，这时候进程崩溃，这个Request会因为指纹已经存在于去重集合中，导致重启后不再处理。结果是：这个页面最终没有入库。 这也是需要数据库唯一索引兜底的原因——你没法保证分布式环境下的"至少一次处理"语义，只能用幂等写入来凑合"最终一致性"。

4.4 坑四：断点续爬的正确姿势：SCHEDULER_PERSIST到底该怎么配

SCHEDULER_PERSIST = True，听上去很美好。但它有个副作用：每次你修改了爬虫代码，想重新跑一遍，Redis里的去重指纹还在，新的请求会被挡掉。

所以实际使用的时候，我的习惯是这样：

开发调试阶段：设置SCHEDULER_PERSIST = False，每次启动都清空队列和去重集合，避免旧的调试数据影响新代码。
稳定生产阶段：设置SCHEDULER_PERSIST = True，配合每日监控，确保队列不丢。
如果你要强制重置某个爬虫的状态，在Redis里执行：

bash复制redis-cli del product_spider:requests
redis-cli del product_spider:dupefilter

注意，requests是队列key的名字，dupefilter是去重集合的key名，实际前缀取决于SCHEDULER_QUEUE_KEY和DUPEFILTER_KEY配置。在scrapy-redis里，默认配置下dupefilter的key是spider_name:dupefilter，队列key是spider_name:requests。

4.5 另一个隐藏坑：Scrapy版本升级带来的`request_to_dict`兼容性

前面提到过，scrapy-redis 0.7.3依赖Scrapy内部的一些序列化函数，这些函数在Scrapy 2.10之后被移除。如果你在升级Scrapy版本后发现调度器报错：

text复制ModuleNotFoundError: No module named 'scrapy.utils.reqser'

最简单的方案是固定Scrapy版本到2.9.x。如果你必须用新版Scrapy，就得自己实现Request的序列化。scrapy-redis里大量使用了request_to_dict和request_from_dict，你需要在打补丁时用scrapy.utils.request.request_to_dict替换旧函数，并处理callback名字序列化逻辑。这个补丁写起来不难，但需要对Scrapy的Request对象结构有足够理解。我在另一个项目里做过一次，大概花了半天时间，主要是调试cb_kwargs和meta字段的兼容性。

5. 进阶：当目标页面动态渲染，分布式爬虫该怎么玩

前面讲的都是静态页面的情况。然而现在很多网站都是前端Ajax渲染的，甚至整个页面内容都在iframe里。这也引出了热词里的“scrapy playwright 动态 iframe”——分布式爬虫遇到动态页面，到底该怎么处理。

5.1 动态渲染和分布式架构其实是两件独立的事

首先要理清一个概念：动态页面渲染是"请求阶段"的问题，分布式是"调度阶段"的问题。 两者并不冲突，你可以在调度层保持scrapy-redis做分布式，在下载层把普通的下载器替换成支持执行JavaScript的下载器。

Scrapy官方不推荐直接在Scrapy里跑Playwright，因为两者的事件循环模型有冲突。Scrapy基于Twisted的异步模型，Playwright用的是Python asyncio，两者硬缝合会出现奇怪的问题。更干净的做法是把Playwright独立成一个渲染服务，Scrapy的下载中间件通过HTTP接口调用这个服务，让服务返回渲染后的HTML。

我用的是这个架构：

code复制Scrapy worker（分布式调度） → HTTP调用 → Playwright渲染服务（独立部署）

渲染服务的核心代码如下，基于FastAPI + Playwright：

python复制from fastapi import FastAPI
from playwright.async_api import async_playwright
import asyncio

app = FastAPI()

async def render_page(url: str):
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        page = await browser.new_page()
        await page.goto(url, wait_until="networkidle", timeout=30000)
        content = await page.content()
        await browser.close()
        return content

@app.get("/render")
async def render(url: str):
    try:
        html = await asyncio.wait_for(render_page(url), timeout=45)
        return {"html": html, "status": "success"}
    except Exception as e:
        return {"html": "", "status": "error", "message": str(e)}

Scrapy侧，写一个自定义下载中间件，把Request的URL透传给渲染服务：

python复制import requests

class PlaywrightRenderMiddleware:
    def process_request(self, request, spider):
        if request.meta.get("render_js"):
            render_url = f"http://render-service:8000/render?url={request.url}"
            resp = requests.get(render_url, timeout=50)
            if resp.status_code == 200 and resp.json().get("status") == "success":
                html = resp.json()["html"]
                # 用Response替换原响应
                from scrapy.http import HtmlResponse
                return HtmlResponse(url=request.url, body=html, encoding="utf-8", request=request)
        return None

这样一来，分布式队列里调度的是每一个需要JS渲染的任务，而实际的渲染动作由一个独立的渲染服务池完成。这个服务池也可以横向扩展——多个渲染服务实例挂在同一个负载均衡后面，Scrapy的请求随机分发到任意实例。

5.2 处理iframe和嵌套页面的思路

很多动态页面里，数据被嵌在<iframe>中。Playwright的page.content()拿到的HTML可能不包含iframe的内部内容。处理方法是先遍历所有iframe，获取它们的src，然后用Playwright切换到对应frame上下文：

python复制page = await browser.new_page()
await page.goto(url, wait_until="networkidle", timeout=30000)
frames = page.frames
for frame in frames:
    # frame 的 url 如果是具体的数据页，可以单独渲染
    inner_html = await frame.content()
    # 把 inner_html 和主html一起返回

注意，如果iframe是从不同域加载的，跨域限制下Playwright可能无法访问其内容。这种情况下，你只能从iframe的src属性里提取目标URL，然后重新作为新任务放入分布式队列。

这套思路有一个非常好的优势：你不必专门为动态页面单独写一套爬虫，只需要在Request的meta里加上render_js=True标记，中间件自动走Playwright渲染流程。需要动态渲染的URL和普通URL可以在同一个分布式队列里共存。

5.3 进阶调度策略：让整个集群处于"可控"状态

当系统跑了一段时间后，你会发现真正重要的已经不是"怎么抓"，而是"怎么控制"。

我最后会分享几个关键的监控指标和调优方向，这些对分布式爬虫的稳定运行至关重要：

Redis队列长度监控。如果队列堆积超过阈值，说明worker消费能力跟不上生产速度，需要增加worker或者优化下载速度；如果队列一直为空，说明起始URL投喂策略有问题，或者爬虫逻辑已经跑完了。
去重集合增长速度。如果增长太快，说明URL模式太多，可能爬虫逻辑里有动态参数没有处理干净（比如时间戳、随机数），这时候你得回溯代码，把动态参数从URL里去掉。
单worker的抓取速率。在监控面板上对比每个worker的每分钟请求数。如果某台worker速率远低于其他机器，可能是它的网络环境、IP被封禁程度或者其他环境问题导致的，需要单独排查。
重复率监控。在数据库端做唯一键约束后，通过捕获IntegrityError统计重复写入的数量，以此评估整个集群的"有效率"。我目前线上集群的重复率控制在0.02%以下，这个数值是可以接受的。

工具层面，我用的是Prometheus + Grafana做监控。scrapy-redis没有内置metrics，但你可以写一个Scrapy扩展，在spider_opened和spider_idle时采集统计数据，比如每个spider的item_scraped_count、request_bytes，然后暴露给Prometheus采集。这个扩展写起来大概80行代码，网上也有很多现成实现可以参考。

写在最后：分布式爬虫的最佳实践，不是技术炫技

回到开头那句话，分布式爬虫看上去是一个技术方案，但实际项目中它更是一个工程权衡。我在做完这个项目之后的体会是：如果你的抓取量只有几十万级别，单机Scrapy加一个靠谱的去重和断点续传机制完全够用，没必要引入Redis，更不需要多台worker。分布式带来的收益，只有在数据量足够大、任务队列足够深、worker足够多的时候才会体现出来。

如果让我给一个参考阈值的话，我个人认为：80万到100万以上的页面总量、单位天维度的连续抓取任务，才开始有上分布式的必要。在这个阈值以下，单机的可维护性远高于分布式。

最后再分享一个小技巧。scrapy-redis的官方文档里没有特别强调，但我实际测试下来：队列key和去重key的前缀最好包含爬虫名称和任务批次，比如product_spider:20240501:requests。这样你可以在一个Redis实例里同时运行多个爬虫项目而不冲突，同时还能按批次回滚、按批次清理数据。这一点在我同时维护三个不同爬虫项目时帮了大忙。

分布式爬虫没有银弹，scrapy-redis也只是把调度和去重这两个问题交给了Redis而已。真正的稳定性还是靠监控、告警和日志分析一点点磨出来的。希望这篇文章能帮你少踩一些我踩过的坑，如果你在改造过程中遇到什么奇怪的问题，欢迎在评论区聊聊，说不定恰好是我之前趟过的某条河。