简介这是一套面向Python爬虫开发者的Scrapy-Redis分布式爬虫案例包适合已掌握Scrapy基础、希望系统学习分布式抓取的初中级读者用于解决跨机器任务调度、请求队列共享、结果集中存储与反爬应对等核心问题。压缩包共15个文件以8个py源码文件为主辅以6个pyc编译文件和scrapy.cfg工程配置覆盖爬虫入口脚本、settings配置、中间件、管道、items数据模型及spiders目录pyc文件可辅助验证运行结果cfg则定义项目基础参数结构清晰紧凑可直接对照运行与修改。已有1449人学习浏览。案例从环境版本对齐、Redis启动与队列设定讲起完整演示如何将Scrapy改造为分布式任务模式把请求调度从本地内存移到Redis并通过不同启动参数让各节点消费同一URL队列同时明确中间件启用、REDIS_URL等关键配置项给出MySQL结果存储Pipeline的实现思路针对IP封禁、重复抓取、节点同步等实战难点提出代理IP池、去重机制、分布式锁等应对方案。整体来看这是一份能帮助快速理解分布式爬虫原理、搭建可运行原型的实用参考便于按需裁剪和二次开发。1. 单机爬虫的瓶颈我为什么会转向scrapy-redis这套方案先说一个我自己踩过的坑。去年接了一个公开数据采集的需求数据量大概在百万级目标网站的页面结构不复杂但翻页特别深。我一开始用单机Scrapy写了个爬虫跑在本地一台服务器上前三天一切正常日志干干净净下载速度稳定在每秒几十个页面。结果第四天早上起来一看任务挂了而且不是被封IP那种挂——是我手动重启服务器之后整个队列全部丢了。Scrapy默认的调度器是跑在内存里的去重集合也是内存里的任务一停所有状态归零。我当时的爬虫没有加断点续跑于是只能从头再来。那种明明已经爬了60%却要全部重来的感觉我相信做过爬虫的人都懂。后来我花了几天时间把项目改造成scrapy-redis也就是用Redis来统一管理调度队列和去重集合把单个Scrapy实例变成可以横向扩展的分布式爬虫。改造完之后我可以在任意多台机器上同时启动爬虫进程它们消费同一个Redis队列互不重复地抓取任务任何一台机器挂了其他节点会接着把任务跑完重启之后也不需要重新爬一遍。这篇文章就把完整的实现过程拆开讲讲包括scrapy-redis的调度原理、代码改造步骤、多节点部署方案以及我实测过程中遇到的各种问题和对应的排查思路。如果你正在做的项目满足两个条件——任务量大到单机跑不完或者你对任务的稳定性有要求那这套方案大概率能帮到你。1.1 先认清分布式不是多开几个进程这么简单很多人一听说分布式第一反应是那我多开几个Scrapy进程不就行了。这个想法我一开始也有实际操作之后才发现根本不成立。你在一台机器上开三个scrapy crawl进程它们只是各自独立地在跑每个进程都有自己的队列和去重集合任务并不会自动分到三个进程上反而是同一个URL可能被三个进程各爬一遍。你真正需要的是一个共享的任务队列和一套全集群统一的去重机制让每个请求只被消费一次不重复也不遗漏。Redis在这里扮演的就是中央调度器的角色。scrapy-redis这个库做的事情非常清晰把Scrapy默认的Scheduler调度器和DupeFilter去重过滤器替换成基于Redis的实现。这样所有爬虫节点——不管它们在哪台机器上——看到的都是同一个队列、同一个去重集合配合自然就产生了。1.2 scrapy-redis帮我解决的核心问题把问题拆开来看scrapy-redis主要干了四件事统一调度所有待爬取的Request不再存在本地内存而是push到Redis的List结构中任何节点都能从这个List里pop任务。统一去重Request指纹存放在Redis的Set结构中所有节点共享同一份去重数据不会重复抓取。状态持久化队列和解重数据都落在Redis里爬虫进程挂了、服务器重启了任务状态还在重启后能继续消费。数据汇总爬取结果可以通过Item Pipeline写入Redis也可以直接把item交给数据库层统一落库相当于给多节点找了一个共同的数据出口。这套组合拳打下来单机爬虫的三大痛点——不可横向扩展、任务易丢失、去重不共享——全部解决了。当然它也有自己的局限性后文我会单独讲它不适合什么样的场景。2. 分布式调度的执行原理先弄懂两个Redis数据结构在用scrapy-redis之前我建议你先花二十分钟把它的源码翻一下。这个库整体代码量不大核心就几个文件核心逻辑比我预想的简单得多。我把它拆成两个部分来理解队列和去重。2.1 调度队列为什么是Redis的List而不是消息队列scrapy-redis默认的调度队列是基于Redis的List实现的。爬虫请求从左边push进去节点从右边pop出来一个标准的FIFO队列对应Redis的lpush和rpop两个操作时间复杂度都是O(1)。有人会问既然要处理大量异步任务为什么不用Kafka或者RabbitMQ这种成熟的消息队列我的理解是爬虫任务的调度和通用消息队列的诉求不太一样。爬虫更看重的是去重、优先级控制、断点续爬这些能力而不是吞吐量和广播模式。而且单独为了爬虫去维护一套Kafka集群运维成本直接拉高一个量级。Redis部署简单、天然支持持久化、操作命令直观对爬虫这种任务重、消息量中等、要求去重精准的场景来说是性价比最高的选择。2.2 去重集合基于Redis Set的指纹去重机制Scrapy内置的去重逻辑是把每一个Request对象生成一个指纹然后丢到一个集合里新来的Request指纹如果在集合里已经存在就直接丢弃。这个指纹由scrapy.utils.request.request_fingerprint函数生成对Request的url、method、body、headers等信息做一次SHA1加密得到一个40位的十六进制字符串。单机版本里这个集合存在内存中scrapy-redis把它搬到了Redis的Set结构里。每次请求到达调度器的第一步是先检查指纹是否存在于Set中如果存在就跳过不存在就加入Set并进入队列。这里有一个设计上的细节值得注意入队的时机是在指纹检查之后。也就是说去重发生在请求进入队列之前而不是消费时候才检测。这样保证同一个URL即使被多个节点同时推送也只有一个能进队列后面的都会被Set拦截。多节点环境下同时推送同一个URL这种情况很常见靠这个机制天然规避了重复抓取。2.3 多节点之间靠什么保持共同认知分布式系统里最怕的就是各个节点各干各的相互不知道对方做了什么。scrapy-redis解决这个问题的方式很朴素——所有关键状态都只存在Redis里节点本身不保留状态。举个例子当两个节点同时执行scrapy crawl myspider它们的Spider名字一样从Scrapy的角度看是两个完全独立的爬虫实例。但它们都连同一个Redis用的是同一个队列key默认是spidername:requests和同一个去重集合key默认是spidername:dupefilter所以在调度的视角里它们就是同一个任务的两个worker只是分别从队列两侧取活干而已。理解了这个机制分布式三个字在你心里就不会那么神秘了——本质上就是多个无状态进程共享一组有状态的外部存储。3. 动手改造从单机Scrapy到分布式可扩展的完整过程理论部分差不多了下面进入实操环节。我用一个具体的改造过程来说明假设你现在有一个单机版的Scrapy爬虫要把它改成scrapy-redis分布式版本。3.1 环境准备与依赖安装前提是你已经装好了Scrapy并且爬虫能在单机跑通。在此基础上只需要额外安装一个库pip install scrapy-redis装完之后检查一下版本。scrapy-redis停更比较早现在常用的版本是0.7.2它和较新版本的Scrapy之间偶尔会有兼容性小问题我用的是Scrapy 2.5.1配scrapy-redis 0.7.2没有遇到问题但你如果用的是Scrapy 2.8以上建议先装完跑一个最小demo验证一下再动正式代码。同时确保你的机器能连上Redis本地开发就先不用密码生产环境务必设置密码和限制IP访问。3.2 settings.py里的配置项逐个说清楚改造的核心配置都在settings.py里我贴一份完整配置然后逐项解释# 调度器改为scrapy-redis的实现 SCHEDULER scrapy_redis.scheduler.Scheduler # 使用scrapy-redis的去重组件 DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter # 是否在爬虫结束时保留Redis中的调度队列和去重指纹 SCHEDULER_PERSIST True # 队列类型FifoQueue即先进先出的普通队列 SCHEDULER_QUEUE_CLASS scrapy_redis.queue.FifoQueue # Redis连接配置 REDIS_URL redis://:yourpassword127.0.0.1:6379/0SCHEDULER这一行是最关键的它告诉Scrapy不要用默认的调度器改用scrapy-redis提供的调度器。DUPEFILTER_CLASS同理把默认的内存去重换成了Redis版本的RFPDupeFilter。SCHEDULER_PERSIST设置为True的意义在于爬虫结束之后Redis队列和去重集合不自动清空。如果设置成False爬虫关闭时调度器会把队列和去重数据都flush掉断点续跑就会失效所以这个选项要想清楚再改。SCHEDULER_QUEUE_CLASS可以选三种队列类型队列类底层结构适用场景FifoQueueRedis List普通爬取先进先出PriorityQueueRedis ZSet需要给任务设置优先级LifoQueueRedis List后进先出的栈式策略一般先用FifoQueue后面要优化了再考虑PriorityQueue。3.3 Spider代码的改造套路Spider方面的改动很小但有一个关键点。原来的写法是import scrapy class MySpider(scrapy.Spider): name myspider start_urls [http://example.com/page/1]改成scrapy-redis的写法from scrapy_redis.spiders import RedisSpider class MySpider(RedisSpider): name myspider redis_key myspider:start_urls def parse(self, response): # 这里的内容保持不变 pass继承的类从scrapy.Spider换成了RedisSpiderstart_urls不用写了改成了一个redis_key字符串。这个改动意味着什么请求的入口从代码里写死的URL列表变成了Redis里的一个队列。你需要单独往Redis里推送初始URL方式很简单redis-cli lpush myspider:start_urls http://example.com/page/1 redis-cli lpush myspider:start_urls http://example.com/page/2一旦RedisSpider启动后检测到myspider:start_urls队列里有URL就会马上消费这些URL之后在parse方法里yield scrapy.Request()出来的新请求就会自动进入调度队列等待分配。这里我遇到过一个有意思的坑如果你什么URL都不往Redis里推爬虫进程启动后会一直处于等待状态日志停在Spider opened那一行看起来像卡住了。不要慌这只是它在等任务——往Redis里push URL进去它就会开始跑。3.4 初始化URL的三种写入方式对比start_urls的写入方式直接影响你整个流程的效率。我试过三种方法对比一下手动用redis-cli敲命令适合调试阶段快速验证爬虫能不能跑通缺点是URL多的时候不现实。写一个独立的Python脚本从数据库或者文件里读出URL列表批量lpush到Redis。这是我最常用的方式适合启动任务前一次性灌入大量入口URL。爬虫内部自触发在parse里定期往redis_key所在的队列push新的URL实现类似持续发现新入口的效果。适合那种入口列表本身会不断增长的场景比如根据数据库里的新记录去抓取。实际项目里我通常是第二种和第三种混用启动前批量灌入一批初始URL运行过程中根据解析结果动态补充。4. 多节点部署的正确姿势Master-Worker架构怎么搭分布式爬虫的部署方式和前面代码改造同样重要。如果你把所有爬虫节点都跑在同一台机器上那Redis也在这台机器上一旦宕机所有节点都失去调度中心照样全部停摆。所以部署架构要清晰。4.1 部署架构与节点分工我的推荐做法是经典的Master-Worker架构Master节点只跑Redis服务不跑爬虫进程。它的职责是接收所有节点写入的Request、存储去重指纹、输出爬取结果。Worker节点可以是一台机器也可以是几十台。每台上只安装Scrapy环境运行相同的爬虫代码启动scrapy crawl myspider。Worker节点之间完全平级没有主从之分任何一个节点宕机都不影响整体任务剩下的节点会继续从Redis队列里消费任务。等宕机的节点恢复之后重新启动爬虫进程它会继续从断点接着干不会重复爬取。如果只有一台服务器也可以在这台机器上同时跑Redis和多进程爬虫但要做好内存规划。Redis本身占用内存不大主要是爬虫进程和请求缓存占资源。4.2 Worker节点的并发参数控制分布式环境下并发参数的设置有讲究。每个Worker节点上的CONCURRENT_REQUESTS不能设置得太高否则所有节点叠加在一起对目标网站的压力会成倍放大导致被封IP。以我的经验单节点建议初始设置为16到32之间根据目标网站的响应速度和自身机器性能逐步调。另外DOWNLOAD_DELAY一定要设置哪怕只有0.5秒能显著降低被封风险。多节点环境下更要注意这一点因为很多反爬策略是按IP维度统计请求频率的你10个节点如果每个都1秒并发几十个请求同一个IP每秒几百个请求过去不封你封谁。如果目标网站要求高并发可以考虑让不同Worker节点走不同的代理出口IP或者用代理池轮换。4.3 数据落库的收敛策略分布式环境下多个节点同时跑每个节点都会单独执行自己的Item Pipeline。如果Pipeline是直接写MySQL或者写文件的每个节点都会打开自己的数据库连接、写自己的文件数据就是分散的。我之前遇到的一个问题是10个节点同时写同一个MySQL表连接数暴增数据库负载飙高。改进的方式是让所有节点把Item写到Redis里一个单独的队列然后由一个独立的落库进程负责消费这个队列统一写入数据库。scrapy-redis本身就提供了一个RedisPipeline作用就是把Item序列化后扔进Redis队列。你要做的就是在ITEM_PIPELINES里加上它ITEM_PIPELINES { scrapy_redis.pipelines.RedisPipeline: 300, }然后自己写一个消费者脚本从Redis里取出Item批量写入数据库。这样既减少了数据库连接压力又可以做批量插入优化整体吞吐量反而更高。5. 实测中的几个深坑与完整排查链路scrapy-redis整个框架本身不复杂但把它放到生产环境跑起来各种问题就冒出来了。下面这几个坑是我真实踩过的每个都附上我的排查过程希望能帮你节省排查时间。5.1 爬虫节点假死日志停滞但Redis队列还有大量任务现象某个Worker节点运行了几个小时后日志停止输出新请求既不报错也不崩溃Redis队列的剩余长度却在持续下降——说明其他节点在正常消费只有这一个节点在摸鱼。排查过程我先看这个节点的CPU和内存发现CPU很低内存正常排除资源耗尽。然后看Redis连接数发现这个节点占用的连接比预期多很多。接着查看scrapy-redis的日志发现它一直在重试同一个请求。最后定位到原因这个节点上有一个请求因为目标网站返回了超时Scrapy会根据RETRY_TIMES设置重试而重试操作需要把Request重新放回调度队列。问题出在重试频率太高节点的大部分时间都花在处理重试上新请求的消费反而被阻塞了。解决方案把RETRY_TIMES从默认的2次降为1次同时设置RETRY_HTTP_CODECS只针对特定状态码重试避免所有超时都进入重试循环。另外把DOWNLOAD_TIMEOUT从默认的180秒降到了30秒无效请求快速失败不再长时间占用线程。5.2 Redis内存暴涨去重集合撑爆了内存现象爬虫跑了两天后检查Redis内存使用量发现已经占用了好几个GB而且还在持续增长。用redis-cli info memory查看used_memory高得吓人。排查过程先查看key的分布情况redis-cli --bigkeys扫了一遍发现最大的key就是去重集合里面有上亿个指纹。每个SHA1指纹是40字节加上Redis Set的存储开销上亿条数据占几个GB完全不奇怪。解决方案如果你的URL量级预估在千万以下直接用Set去重没问题。但如果超过亿级就要考虑用Bloom Filter替换精确去重。Bloom Filter用很小的内存代价换取了极低概率的误判能在一个亿级URL场景下把内存占用降到几百MB。scrapy-redis生态里有现成的scrapy-redis-bloomfilter项目改一个配置就能切换。还有一个优化手段是定期清理过期指纹。如果你的爬虫是周期性抓取每次任务结束后把旧的去重集合重命名保留最近几次的指纹做增量去重能有效控制集合增长。5.3 任务消费完毕但数据对不上Redis队列已空数据库却少了记录现象爬虫跑完后检查Redis队列llen已经是0所有请求都被消费了。但核对数据库里的记录数发现比预期少了10%左右。排查过程最开始怀疑是解析逻辑漏了抓了部分页面重新分析发现页面内容正常解析代码也没有疏漏。接着怀疑是Item Pipeline丢弃了数据查看日志发现确实有若干条警告提示某些Item写入失败。进一步查原因发现失败的Item都卡在同一个字段上网络波动导致某些请求返回了空页面或错误页面这部分页面被Parser正常解析但字段缺失Pipeline在写入数据库时因为非空约束直接把整条数据丢弃了。解决方案这种静默丢弃比报错更可怕因为你不看日志完全发现不了。我的做法是在Pipeline里加了一层校验和告警解析结果为空或者关键字段缺失时不仅不丢弃还把原始页面快照和请求信息写入一个专门的异常表。后续可以针对这些异常URL重新发起抓取形成一条补爬链路。5.4 节点重启后重复爬取断点续爬失效了现象一个节点挂了重启之后我发现它又重新爬了一部分之前已经爬过的URL去重好像没生效。排查过程先检查SCHEDULER_PERSIST配置确认是True。然后看Redis里的去重集合发现集合确实还在。最后看了下重启时的启动日志发现报了一个警告Duplicate request的过滤日志消失了某些Request没经过去重直接放进了队列。最终原因很微妙节点重启后爬虫内部有些Request是在parse过程中临时生成的这些Request的指纹在生成时依赖了当时的内存状态。如果爬虫代码里用了不稳定的数据比如时间戳、随机数拼接URL参数同一个逻辑URL每次生成的指纹都会不一样去重自然失效。解决方案检查所有scrapy.Request的构造参数确保URL中的参数顺序固定不能使用每次运行都会变化的动态值。对于确实需要动态参数的请求考虑重写request_fingerprint函数只针对URL的核心部分计算指纹。5.5 Redis连接池撑爆爬虫数量一多就报连接错误现象把Worker节点从3个扩展到10个之后Redis频繁报连接错误日志显示ConnectionError: Error while reading from socket。排查过程先看Redis的maxclients配置默认是10000按理说10个节点不会超过。再看Redis的CPU发现已经接近100%单实例Redis处理不过来了。解决方案第一步调大Redis的timeout和tcp-keepalive配置让空闲连接尽快释放。第二步给每台Worker节点设置合理的REDIS_CONNECTION_POOL_SIZEscrapy-redis用的是Redis-py的默认连接池不要在每毫秒级操作里都新建连接。第三步如果节点数超过20个单Redis实例确实是瓶颈需要考虑改用Redis Cluster或者给不同爬虫任务分开Redis实例。6. 进一步的进阶玩法增量爬取、优先级调度与大规模去重优化基础的分布式爬虫跑通之后你会发现这套框架还有很大的延伸空间。这几个方向是我在实际项目中陆续摸索出来的可以帮你把scrapy-redis用得更顺手。6.1 基于Redis的增量爬取方案周期性任务比如每天早上抓一次竞品价格如果用朴素的方式跑每次都会从start_urls重新开始之前抓过的页面会全部重新抓一遍。虽然去重能保证不重复入库但浪费了大量的请求和带宽。和去重指纹配合的增量思路是每次任务结束后把这次请求过的URL指纹临时保存到另一个集合比如myspider:seen_today下次任务启动时在middleware里检查当前请求的指纹是否在这个临时集合里如果在就直接跳过。这样周期性任务只抓新增或变化的页面大幅度缩短耗时。对于入口URL本身就动态增长的站点更推荐在启动时只push新增的URL进redis_key然后配合SPIDER_MIDDLEWARES做增量逻辑判断避免把整个历史URL列表重新灌进去。6.2 用PriorityQueue实现任务优先级调度默认的FifoQueue对所有请求一视同仁但实际业务中往往有优先级差异。比如你现在既要抓商详页又要抓列表页商详页的新鲜度直接影响用户体验那应该让商详页请求插队。scrapy-redis提供了基于Redis ZSet的PriorityQueue使用方式很简单SCHEDULER_QUEUE_CLASS scrapy_redis.queue.PriorityQueue然后在生成Request时用priority参数控制优先级yield scrapy.Request(url, callbackself.parse_detail, priority10)priority值越大出队越早。我一般约定默认请求priority0重要页面priority10低优先级数据补量请求priority-5。使用PriorityQueue后有个明显变化Redis里存储的不再是简单的List而是一个ZSet分数就是priority值。这样你可以直接在redis-cli里查看当前队列里各个优先级的任务分布方便观察任务进度。6.3 大规模场景下的去重优化Bloom Filter实战前面提过Bloom Filter应对亿级URL去重的方案这里展开说说具体怎么做。传统Set精确去重在URL数量超过一亿之后内存占用轻松超过10GB很多服务器根本扛不住。Bloom Filter的核心原理是把每个URL通过多个哈希函数映射到bit数组的多个位置把这些位置置为1。判断某个URL是否存在时看它映射的t个位置是否都为1只要有一个为0就确定不存在。它的代价是存在一定的误判率——可能把没访问过的URL误判为已访问造成少量漏爬但换来的内存节省非常可观。有一个开源项目scrapy-redis-bloomfilter用法和scrapy-redis几乎一样只需要改一行配置DUPEFILTER_CLASS scrapy_redis_bloomfilter.dupefilter.RFPDupeFilter配置完再设置一个误判率参数即可。我实测在千万级URL的场景下Bloom Filter版本的内存占用是精确去重版本的十分之一左右漏爬率控制在千分之一以内对于大多数爬虫场景完全可接受。6.4 其他值得尝试的优化方向除了上面几个方向还有一些小技巧性价比很高请求指纹自定义如果你的URL参数顺序不固定比如?a1b2和?b2a1是同一个页面默认的指纹会把它们当成两个不同请求。重写request_fingerprint方法把URL参数排序后再生成指纹可以让去重更精准。动态配置Redis地址区分开发和生产环境的Redis实例用一个环境变量控制REDIS_URL避免本地调试时误连生产Redis把任务队列搞乱。监控和告警写一个简单的巡检脚本定时检查Redis队列长度、去重集合大小、各Worker节点的在线状态和各自的消费速率异常时发告警通知。分布式环境下的排障效率很大程度上取决于你对线上状态的可见性。最后说几句实在话scrapy-redis这套方案我从第一次接触到现在用了很久最大的感受是它把分布式这个词从概念层面落到了工程层面没有引入太多复杂概念一个Redis就搞定了调度、去重、持久化三件大事。但我也要说清楚它的适用边界。如果你的任务量级只有几万条URL一台机器跑单机Scrapy完全够用引入Redis反而多了一个维护点没必要为了分布式而分布式。如果你要抓取的是实时性要求极高、需要毫秒级调度的场景scrapy-redis这种基于队列的批量消费模型可能不是最佳选择更应该去看看真正的任务调度系统。我个人的经验是判断一个项目要不要用scrapy-redis就看两点——第一任务量是否大到单机跑不完第二你的业务是否能容忍少量任务可能被延迟处理但不会丢失。这两个条件都满足那scrapy-redis就是非常靠谱的选择。如果你的情况介于边界之间我建议你从最小配置开始跑先把单节点调通、队列落好再逐步加节点不要一上来就铺开10台机器那样一旦出了问题排查成本比省下的时间还高。本文还有配套的精品资源点击获取
简介这是一套面向Python爬虫开发者的Scrapy-Redis分布式爬虫案例包适合已掌握Scrapy基础、希望系统学习分布式抓取的初中级读者用于解决跨机器任务调度、请求队列共享、结果集中存储与反爬应对等核心问题。压缩包共15个文件以8个py源码文件为主辅以6个pyc编译文件和scrapy.cfg工程配置覆盖爬虫入口脚本、settings配置、中间件、管道、items数据模型及spiders目录pyc文件可辅助验证运行结果cfg则定义项目基础参数结构清晰紧凑可直接对照运行与修改。已有1449人学习浏览。案例从环境版本对齐、Redis启动与队列设定讲起完整演示如何将Scrapy改造为分布式任务模式把请求调度从本地内存移到Redis并通过不同启动参数让各节点消费同一URL队列同时明确中间件启用、REDIS_URL等关键配置项给出MySQL结果存储Pipeline的实现思路针对IP封禁、重复抓取、节点同步等实战难点提出代理IP池、去重机制、分布式锁等应对方案。整体来看这是一份能帮助快速理解分布式爬虫原理、搭建可运行原型的实用参考便于按需裁剪和二次开发。1. 单机爬虫的瓶颈我为什么会转向scrapy-redis这套方案先说一个我自己踩过的坑。去年接了一个公开数据采集的需求数据量大概在百万级目标网站的页面结构不复杂但翻页特别深。我一开始用单机Scrapy写了个爬虫跑在本地一台服务器上前三天一切正常日志干干净净下载速度稳定在每秒几十个页面。结果第四天早上起来一看任务挂了而且不是被封IP那种挂——是我手动重启服务器之后整个队列全部丢了。Scrapy默认的调度器是跑在内存里的去重集合也是内存里的任务一停所有状态归零。我当时的爬虫没有加断点续跑于是只能从头再来。那种明明已经爬了60%却要全部重来的感觉我相信做过爬虫的人都懂。后来我花了几天时间把项目改造成scrapy-redis也就是用Redis来统一管理调度队列和去重集合把单个Scrapy实例变成可以横向扩展的分布式爬虫。改造完之后我可以在任意多台机器上同时启动爬虫进程它们消费同一个Redis队列互不重复地抓取任务任何一台机器挂了其他节点会接着把任务跑完重启之后也不需要重新爬一遍。这篇文章就把完整的实现过程拆开讲讲包括scrapy-redis的调度原理、代码改造步骤、多节点部署方案以及我实测过程中遇到的各种问题和对应的排查思路。如果你正在做的项目满足两个条件——任务量大到单机跑不完或者你对任务的稳定性有要求那这套方案大概率能帮到你。1.1 先认清分布式不是多开几个进程这么简单很多人一听说分布式第一反应是那我多开几个Scrapy进程不就行了。这个想法我一开始也有实际操作之后才发现根本不成立。你在一台机器上开三个scrapy crawl进程它们只是各自独立地在跑每个进程都有自己的队列和去重集合任务并不会自动分到三个进程上反而是同一个URL可能被三个进程各爬一遍。你真正需要的是一个共享的任务队列和一套全集群统一的去重机制让每个请求只被消费一次不重复也不遗漏。Redis在这里扮演的就是中央调度器的角色。scrapy-redis这个库做的事情非常清晰把Scrapy默认的Scheduler调度器和DupeFilter去重过滤器替换成基于Redis的实现。这样所有爬虫节点——不管它们在哪台机器上——看到的都是同一个队列、同一个去重集合配合自然就产生了。1.2 scrapy-redis帮我解决的核心问题把问题拆开来看scrapy-redis主要干了四件事统一调度所有待爬取的Request不再存在本地内存而是push到Redis的List结构中任何节点都能从这个List里pop任务。统一去重Request指纹存放在Redis的Set结构中所有节点共享同一份去重数据不会重复抓取。状态持久化队列和解重数据都落在Redis里爬虫进程挂了、服务器重启了任务状态还在重启后能继续消费。数据汇总爬取结果可以通过Item Pipeline写入Redis也可以直接把item交给数据库层统一落库相当于给多节点找了一个共同的数据出口。这套组合拳打下来单机爬虫的三大痛点——不可横向扩展、任务易丢失、去重不共享——全部解决了。当然它也有自己的局限性后文我会单独讲它不适合什么样的场景。2. 分布式调度的执行原理先弄懂两个Redis数据结构在用scrapy-redis之前我建议你先花二十分钟把它的源码翻一下。这个库整体代码量不大核心就几个文件核心逻辑比我预想的简单得多。我把它拆成两个部分来理解队列和去重。2.1 调度队列为什么是Redis的List而不是消息队列scrapy-redis默认的调度队列是基于Redis的List实现的。爬虫请求从左边push进去节点从右边pop出来一个标准的FIFO队列对应Redis的lpush和rpop两个操作时间复杂度都是O(1)。有人会问既然要处理大量异步任务为什么不用Kafka或者RabbitMQ这种成熟的消息队列我的理解是爬虫任务的调度和通用消息队列的诉求不太一样。爬虫更看重的是去重、优先级控制、断点续爬这些能力而不是吞吐量和广播模式。而且单独为了爬虫去维护一套Kafka集群运维成本直接拉高一个量级。Redis部署简单、天然支持持久化、操作命令直观对爬虫这种任务重、消息量中等、要求去重精准的场景来说是性价比最高的选择。2.2 去重集合基于Redis Set的指纹去重机制Scrapy内置的去重逻辑是把每一个Request对象生成一个指纹然后丢到一个集合里新来的Request指纹如果在集合里已经存在就直接丢弃。这个指纹由scrapy.utils.request.request_fingerprint函数生成对Request的url、method、body、headers等信息做一次SHA1加密得到一个40位的十六进制字符串。单机版本里这个集合存在内存中scrapy-redis把它搬到了Redis的Set结构里。每次请求到达调度器的第一步是先检查指纹是否存在于Set中如果存在就跳过不存在就加入Set并进入队列。这里有一个设计上的细节值得注意入队的时机是在指纹检查之后。也就是说去重发生在请求进入队列之前而不是消费时候才检测。这样保证同一个URL即使被多个节点同时推送也只有一个能进队列后面的都会被Set拦截。多节点环境下同时推送同一个URL这种情况很常见靠这个机制天然规避了重复抓取。2.3 多节点之间靠什么保持共同认知分布式系统里最怕的就是各个节点各干各的相互不知道对方做了什么。scrapy-redis解决这个问题的方式很朴素——所有关键状态都只存在Redis里节点本身不保留状态。举个例子当两个节点同时执行scrapy crawl myspider它们的Spider名字一样从Scrapy的角度看是两个完全独立的爬虫实例。但它们都连同一个Redis用的是同一个队列key默认是spidername:requests和同一个去重集合key默认是spidername:dupefilter所以在调度的视角里它们就是同一个任务的两个worker只是分别从队列两侧取活干而已。理解了这个机制分布式三个字在你心里就不会那么神秘了——本质上就是多个无状态进程共享一组有状态的外部存储。3. 动手改造从单机Scrapy到分布式可扩展的完整过程理论部分差不多了下面进入实操环节。我用一个具体的改造过程来说明假设你现在有一个单机版的Scrapy爬虫要把它改成scrapy-redis分布式版本。3.1 环境准备与依赖安装前提是你已经装好了Scrapy并且爬虫能在单机跑通。在此基础上只需要额外安装一个库pip install scrapy-redis装完之后检查一下版本。scrapy-redis停更比较早现在常用的版本是0.7.2它和较新版本的Scrapy之间偶尔会有兼容性小问题我用的是Scrapy 2.5.1配scrapy-redis 0.7.2没有遇到问题但你如果用的是Scrapy 2.8以上建议先装完跑一个最小demo验证一下再动正式代码。同时确保你的机器能连上Redis本地开发就先不用密码生产环境务必设置密码和限制IP访问。3.2 settings.py里的配置项逐个说清楚改造的核心配置都在settings.py里我贴一份完整配置然后逐项解释# 调度器改为scrapy-redis的实现 SCHEDULER scrapy_redis.scheduler.Scheduler # 使用scrapy-redis的去重组件 DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter # 是否在爬虫结束时保留Redis中的调度队列和去重指纹 SCHEDULER_PERSIST True # 队列类型FifoQueue即先进先出的普通队列 SCHEDULER_QUEUE_CLASS scrapy_redis.queue.FifoQueue # Redis连接配置 REDIS_URL redis://:yourpassword127.0.0.1:6379/0SCHEDULER这一行是最关键的它告诉Scrapy不要用默认的调度器改用scrapy-redis提供的调度器。DUPEFILTER_CLASS同理把默认的内存去重换成了Redis版本的RFPDupeFilter。SCHEDULER_PERSIST设置为True的意义在于爬虫结束之后Redis队列和去重集合不自动清空。如果设置成False爬虫关闭时调度器会把队列和去重数据都flush掉断点续跑就会失效所以这个选项要想清楚再改。SCHEDULER_QUEUE_CLASS可以选三种队列类型队列类底层结构适用场景FifoQueueRedis List普通爬取先进先出PriorityQueueRedis ZSet需要给任务设置优先级LifoQueueRedis List后进先出的栈式策略一般先用FifoQueue后面要优化了再考虑PriorityQueue。3.3 Spider代码的改造套路Spider方面的改动很小但有一个关键点。原来的写法是import scrapy class MySpider(scrapy.Spider): name myspider start_urls [http://example.com/page/1]改成scrapy-redis的写法from scrapy_redis.spiders import RedisSpider class MySpider(RedisSpider): name myspider redis_key myspider:start_urls def parse(self, response): # 这里的内容保持不变 pass继承的类从scrapy.Spider换成了RedisSpiderstart_urls不用写了改成了一个redis_key字符串。这个改动意味着什么请求的入口从代码里写死的URL列表变成了Redis里的一个队列。你需要单独往Redis里推送初始URL方式很简单redis-cli lpush myspider:start_urls http://example.com/page/1 redis-cli lpush myspider:start_urls http://example.com/page/2一旦RedisSpider启动后检测到myspider:start_urls队列里有URL就会马上消费这些URL之后在parse方法里yield scrapy.Request()出来的新请求就会自动进入调度队列等待分配。这里我遇到过一个有意思的坑如果你什么URL都不往Redis里推爬虫进程启动后会一直处于等待状态日志停在Spider opened那一行看起来像卡住了。不要慌这只是它在等任务——往Redis里push URL进去它就会开始跑。3.4 初始化URL的三种写入方式对比start_urls的写入方式直接影响你整个流程的效率。我试过三种方法对比一下手动用redis-cli敲命令适合调试阶段快速验证爬虫能不能跑通缺点是URL多的时候不现实。写一个独立的Python脚本从数据库或者文件里读出URL列表批量lpush到Redis。这是我最常用的方式适合启动任务前一次性灌入大量入口URL。爬虫内部自触发在parse里定期往redis_key所在的队列push新的URL实现类似持续发现新入口的效果。适合那种入口列表本身会不断增长的场景比如根据数据库里的新记录去抓取。实际项目里我通常是第二种和第三种混用启动前批量灌入一批初始URL运行过程中根据解析结果动态补充。4. 多节点部署的正确姿势Master-Worker架构怎么搭分布式爬虫的部署方式和前面代码改造同样重要。如果你把所有爬虫节点都跑在同一台机器上那Redis也在这台机器上一旦宕机所有节点都失去调度中心照样全部停摆。所以部署架构要清晰。4.1 部署架构与节点分工我的推荐做法是经典的Master-Worker架构Master节点只跑Redis服务不跑爬虫进程。它的职责是接收所有节点写入的Request、存储去重指纹、输出爬取结果。Worker节点可以是一台机器也可以是几十台。每台上只安装Scrapy环境运行相同的爬虫代码启动scrapy crawl myspider。Worker节点之间完全平级没有主从之分任何一个节点宕机都不影响整体任务剩下的节点会继续从Redis队列里消费任务。等宕机的节点恢复之后重新启动爬虫进程它会继续从断点接着干不会重复爬取。如果只有一台服务器也可以在这台机器上同时跑Redis和多进程爬虫但要做好内存规划。Redis本身占用内存不大主要是爬虫进程和请求缓存占资源。4.2 Worker节点的并发参数控制分布式环境下并发参数的设置有讲究。每个Worker节点上的CONCURRENT_REQUESTS不能设置得太高否则所有节点叠加在一起对目标网站的压力会成倍放大导致被封IP。以我的经验单节点建议初始设置为16到32之间根据目标网站的响应速度和自身机器性能逐步调。另外DOWNLOAD_DELAY一定要设置哪怕只有0.5秒能显著降低被封风险。多节点环境下更要注意这一点因为很多反爬策略是按IP维度统计请求频率的你10个节点如果每个都1秒并发几十个请求同一个IP每秒几百个请求过去不封你封谁。如果目标网站要求高并发可以考虑让不同Worker节点走不同的代理出口IP或者用代理池轮换。4.3 数据落库的收敛策略分布式环境下多个节点同时跑每个节点都会单独执行自己的Item Pipeline。如果Pipeline是直接写MySQL或者写文件的每个节点都会打开自己的数据库连接、写自己的文件数据就是分散的。我之前遇到的一个问题是10个节点同时写同一个MySQL表连接数暴增数据库负载飙高。改进的方式是让所有节点把Item写到Redis里一个单独的队列然后由一个独立的落库进程负责消费这个队列统一写入数据库。scrapy-redis本身就提供了一个RedisPipeline作用就是把Item序列化后扔进Redis队列。你要做的就是在ITEM_PIPELINES里加上它ITEM_PIPELINES { scrapy_redis.pipelines.RedisPipeline: 300, }然后自己写一个消费者脚本从Redis里取出Item批量写入数据库。这样既减少了数据库连接压力又可以做批量插入优化整体吞吐量反而更高。5. 实测中的几个深坑与完整排查链路scrapy-redis整个框架本身不复杂但把它放到生产环境跑起来各种问题就冒出来了。下面这几个坑是我真实踩过的每个都附上我的排查过程希望能帮你节省排查时间。5.1 爬虫节点假死日志停滞但Redis队列还有大量任务现象某个Worker节点运行了几个小时后日志停止输出新请求既不报错也不崩溃Redis队列的剩余长度却在持续下降——说明其他节点在正常消费只有这一个节点在摸鱼。排查过程我先看这个节点的CPU和内存发现CPU很低内存正常排除资源耗尽。然后看Redis连接数发现这个节点占用的连接比预期多很多。接着查看scrapy-redis的日志发现它一直在重试同一个请求。最后定位到原因这个节点上有一个请求因为目标网站返回了超时Scrapy会根据RETRY_TIMES设置重试而重试操作需要把Request重新放回调度队列。问题出在重试频率太高节点的大部分时间都花在处理重试上新请求的消费反而被阻塞了。解决方案把RETRY_TIMES从默认的2次降为1次同时设置RETRY_HTTP_CODECS只针对特定状态码重试避免所有超时都进入重试循环。另外把DOWNLOAD_TIMEOUT从默认的180秒降到了30秒无效请求快速失败不再长时间占用线程。5.2 Redis内存暴涨去重集合撑爆了内存现象爬虫跑了两天后检查Redis内存使用量发现已经占用了好几个GB而且还在持续增长。用redis-cli info memory查看used_memory高得吓人。排查过程先查看key的分布情况redis-cli --bigkeys扫了一遍发现最大的key就是去重集合里面有上亿个指纹。每个SHA1指纹是40字节加上Redis Set的存储开销上亿条数据占几个GB完全不奇怪。解决方案如果你的URL量级预估在千万以下直接用Set去重没问题。但如果超过亿级就要考虑用Bloom Filter替换精确去重。Bloom Filter用很小的内存代价换取了极低概率的误判能在一个亿级URL场景下把内存占用降到几百MB。scrapy-redis生态里有现成的scrapy-redis-bloomfilter项目改一个配置就能切换。还有一个优化手段是定期清理过期指纹。如果你的爬虫是周期性抓取每次任务结束后把旧的去重集合重命名保留最近几次的指纹做增量去重能有效控制集合增长。5.3 任务消费完毕但数据对不上Redis队列已空数据库却少了记录现象爬虫跑完后检查Redis队列llen已经是0所有请求都被消费了。但核对数据库里的记录数发现比预期少了10%左右。排查过程最开始怀疑是解析逻辑漏了抓了部分页面重新分析发现页面内容正常解析代码也没有疏漏。接着怀疑是Item Pipeline丢弃了数据查看日志发现确实有若干条警告提示某些Item写入失败。进一步查原因发现失败的Item都卡在同一个字段上网络波动导致某些请求返回了空页面或错误页面这部分页面被Parser正常解析但字段缺失Pipeline在写入数据库时因为非空约束直接把整条数据丢弃了。解决方案这种静默丢弃比报错更可怕因为你不看日志完全发现不了。我的做法是在Pipeline里加了一层校验和告警解析结果为空或者关键字段缺失时不仅不丢弃还把原始页面快照和请求信息写入一个专门的异常表。后续可以针对这些异常URL重新发起抓取形成一条补爬链路。5.4 节点重启后重复爬取断点续爬失效了现象一个节点挂了重启之后我发现它又重新爬了一部分之前已经爬过的URL去重好像没生效。排查过程先检查SCHEDULER_PERSIST配置确认是True。然后看Redis里的去重集合发现集合确实还在。最后看了下重启时的启动日志发现报了一个警告Duplicate request的过滤日志消失了某些Request没经过去重直接放进了队列。最终原因很微妙节点重启后爬虫内部有些Request是在parse过程中临时生成的这些Request的指纹在生成时依赖了当时的内存状态。如果爬虫代码里用了不稳定的数据比如时间戳、随机数拼接URL参数同一个逻辑URL每次生成的指纹都会不一样去重自然失效。解决方案检查所有scrapy.Request的构造参数确保URL中的参数顺序固定不能使用每次运行都会变化的动态值。对于确实需要动态参数的请求考虑重写request_fingerprint函数只针对URL的核心部分计算指纹。5.5 Redis连接池撑爆爬虫数量一多就报连接错误现象把Worker节点从3个扩展到10个之后Redis频繁报连接错误日志显示ConnectionError: Error while reading from socket。排查过程先看Redis的maxclients配置默认是10000按理说10个节点不会超过。再看Redis的CPU发现已经接近100%单实例Redis处理不过来了。解决方案第一步调大Redis的timeout和tcp-keepalive配置让空闲连接尽快释放。第二步给每台Worker节点设置合理的REDIS_CONNECTION_POOL_SIZEscrapy-redis用的是Redis-py的默认连接池不要在每毫秒级操作里都新建连接。第三步如果节点数超过20个单Redis实例确实是瓶颈需要考虑改用Redis Cluster或者给不同爬虫任务分开Redis实例。6. 进一步的进阶玩法增量爬取、优先级调度与大规模去重优化基础的分布式爬虫跑通之后你会发现这套框架还有很大的延伸空间。这几个方向是我在实际项目中陆续摸索出来的可以帮你把scrapy-redis用得更顺手。6.1 基于Redis的增量爬取方案周期性任务比如每天早上抓一次竞品价格如果用朴素的方式跑每次都会从start_urls重新开始之前抓过的页面会全部重新抓一遍。虽然去重能保证不重复入库但浪费了大量的请求和带宽。和去重指纹配合的增量思路是每次任务结束后把这次请求过的URL指纹临时保存到另一个集合比如myspider:seen_today下次任务启动时在middleware里检查当前请求的指纹是否在这个临时集合里如果在就直接跳过。这样周期性任务只抓新增或变化的页面大幅度缩短耗时。对于入口URL本身就动态增长的站点更推荐在启动时只push新增的URL进redis_key然后配合SPIDER_MIDDLEWARES做增量逻辑判断避免把整个历史URL列表重新灌进去。6.2 用PriorityQueue实现任务优先级调度默认的FifoQueue对所有请求一视同仁但实际业务中往往有优先级差异。比如你现在既要抓商详页又要抓列表页商详页的新鲜度直接影响用户体验那应该让商详页请求插队。scrapy-redis提供了基于Redis ZSet的PriorityQueue使用方式很简单SCHEDULER_QUEUE_CLASS scrapy_redis.queue.PriorityQueue然后在生成Request时用priority参数控制优先级yield scrapy.Request(url, callbackself.parse_detail, priority10)priority值越大出队越早。我一般约定默认请求priority0重要页面priority10低优先级数据补量请求priority-5。使用PriorityQueue后有个明显变化Redis里存储的不再是简单的List而是一个ZSet分数就是priority值。这样你可以直接在redis-cli里查看当前队列里各个优先级的任务分布方便观察任务进度。6.3 大规模场景下的去重优化Bloom Filter实战前面提过Bloom Filter应对亿级URL去重的方案这里展开说说具体怎么做。传统Set精确去重在URL数量超过一亿之后内存占用轻松超过10GB很多服务器根本扛不住。Bloom Filter的核心原理是把每个URL通过多个哈希函数映射到bit数组的多个位置把这些位置置为1。判断某个URL是否存在时看它映射的t个位置是否都为1只要有一个为0就确定不存在。它的代价是存在一定的误判率——可能把没访问过的URL误判为已访问造成少量漏爬但换来的内存节省非常可观。有一个开源项目scrapy-redis-bloomfilter用法和scrapy-redis几乎一样只需要改一行配置DUPEFILTER_CLASS scrapy_redis_bloomfilter.dupefilter.RFPDupeFilter配置完再设置一个误判率参数即可。我实测在千万级URL的场景下Bloom Filter版本的内存占用是精确去重版本的十分之一左右漏爬率控制在千分之一以内对于大多数爬虫场景完全可接受。6.4 其他值得尝试的优化方向除了上面几个方向还有一些小技巧性价比很高请求指纹自定义如果你的URL参数顺序不固定比如?a1b2和?b2a1是同一个页面默认的指纹会把它们当成两个不同请求。重写request_fingerprint方法把URL参数排序后再生成指纹可以让去重更精准。动态配置Redis地址区分开发和生产环境的Redis实例用一个环境变量控制REDIS_URL避免本地调试时误连生产Redis把任务队列搞乱。监控和告警写一个简单的巡检脚本定时检查Redis队列长度、去重集合大小、各Worker节点的在线状态和各自的消费速率异常时发告警通知。分布式环境下的排障效率很大程度上取决于你对线上状态的可见性。最后说几句实在话scrapy-redis这套方案我从第一次接触到现在用了很久最大的感受是它把分布式这个词从概念层面落到了工程层面没有引入太多复杂概念一个Redis就搞定了调度、去重、持久化三件大事。但我也要说清楚它的适用边界。如果你的任务量级只有几万条URL一台机器跑单机Scrapy完全够用引入Redis反而多了一个维护点没必要为了分布式而分布式。如果你要抓取的是实时性要求极高、需要毫秒级调度的场景scrapy-redis这种基于队列的批量消费模型可能不是最佳选择更应该去看看真正的任务调度系统。我个人的经验是判断一个项目要不要用scrapy-redis就看两点——第一任务量是否大到单机跑不完第二你的业务是否能容忍少量任务可能被延迟处理但不会丢失。这两个条件都满足那scrapy-redis就是非常靠谱的选择。如果你的情况介于边界之间我建议你从最小配置开始跑先把单节点调通、队列落好再逐步加节点不要一上来就铺开10台机器那样一旦出了问题排查成本比省下的时间还高。本文还有配套的精品资源点击获取
