用Scrpy配合Redis，爬虫速度能快多少其实挺让人好奇的

开始）

用Scrapy配合Redis，爬虫速度能快多少其实挺让人好奇的，这个问题的答案并不是一个固定的数字，快10倍”或“快50倍”，因为它取决于很多因素，但可以肯定的是，这种组合带来的速度提升是质的飞跃，是从“一个人单干”变成了“一支队伍协同作战”的模式，要理解这一点，我们得先看看一个普通的Scrapy爬虫是怎么工作的,然后再看加入Redis后发生了什么。

一个普通的Scrapy爬虫，我们可以把它想象成一个勤劳的工人，这个工人有一个待办事项清单（也就是爬虫的请求队列），他首先从清单上拿起第一个任务（比如一个网址），跑去处理（下载网页），处理完后，可能从网页里发现一些新的任务（新的链接），他就把这些新任务写在待办事项清单的末尾，他再回过头来，继续处理清单上的下一个任务，这个过程是单线程的，虽然Scrapy内部有异步机制，能让这个工人在等待网络响应时不闲着，可以去干点别的，但归根结底，待办事项清单的维护和任务的获取都是由这个工人自己完成的，如果他发现新任务的速度很快，但处理一个任务（比如解析复杂页面）很慢，那么清单就会越来越长,但处理速度却跟不上。

当我们把Redis引入进来，情况就完全不同了，Redis在这里扮演的是一个中央指挥中心或者共享的待办事项公告板的角色，这时候，我们不再是一个工人在战斗了，我们可以启动多个Scrapy工人（也就是多个爬虫进程，甚至可以分布在不同的机器上），所有这些工人都不再各自维护自己的待办清单,而是全部连接到同一个Redis服务器。

现在的工作流程是这样的：第一个工人从Redis这个中央公告板上取走第一个网址去处理，处理过程中，它发现了十个新的链接，它不会把这十个链接记在自己的小本本上，而是直接汇报给中央公告板（Redis），紧接着，第二个工人、第三个工人……他们可能正处于空闲状态，看到公告板上出现了新的任务，就会立刻抢一个去处理，这样一来，任务的发现和任务的执行被彻底分开了，发现任务的人（爬虫）只管不断往Redis里塞新任务，而执行任务的人（爬虫）只管不断从Redis里取任务来执行，这个过程是并发的,多个爬虫可以同时在不同的网页上忙碌。

这种架构，通常被称为“分布式爬虫”,它的速度优势立刻就体现出来了：

第一，实现了真正的多机协作，如果你的网站允许，你可以轻松地启动10个、50个甚至100个爬虫实例同时运行，它们都不会打架，因为任务来源是统一的Redis，这就好比把一项工程从一个人干，变成了一个施工队一起干，速度自然呈几何级数增长，有开发者分享经验称，在处理海量数据时，这种分布式的架构能够将爬取效率提升数倍乃至数十倍,具体取决于部署的爬虫节点数量。

第二，避免了重复爬取，Redis可以很容易地设置去重功能，当一个爬虫把一个新发现的网址放进Redis时，Redis可以自动检查这个网址是不是已经存在了（无论是已经在队列里，还是已经被处理过了），如果已经存在，就直接过滤掉，这样，所有的爬虫工人都不会做无用功，节省了大量时间和网络资源，而在单机Scrapy中，虽然也有去重机制，但在爬虫重启后，默认情况下可能会丢失状态，而Redis作为外部存储,可以持久化这些状态。

第三，增强了稳定性和容错能力，这也是间接提升平均速度的关键，假设一个爬虫工人因为某种原因崩溃了，没关系，因为它处理的那个任务可能还没有被标记为“完成”，Redis过一段时间后会自动把这个任务重新放回队列，让其他健康的工人去处理，整个爬取任务不会因为一个节点的失败而前功尽弃，而在单机模式下，如果爬虫中途崩溃，重启后可能需要从头开始,或者需要复杂的断点续爬逻辑。

速度能快多少，也受到一些限制。目标网站的反爬虫策略是最主要的瓶颈，即使你有一百个工人，如果网站检测到异常流量把你IP封了，那速度就直接降为零，通常需要配合代理IP池、合理的下载延迟等设置。Redis服务器本身的性能以及网络带宽也是重要的因素，如果Redis成为瓶颈，或者网络出口带宽被占满,增加再多的爬虫工人也无法提升速度。

根据一些技术博客上的非正式测试和分享，在小规模实验中，使用Scrapy-Redis（连接Scrapy和Redis的库）相比单机Scrapy，速度提升两三倍是很容易实现的，而在大规模分布式部署中，面对数千万甚至上亿级别的页面抓取时，其效率提升更是单机模式无法比拟的,可以说是指数级的增长。

用Scrapy配合Redis，爬虫速度的提升潜力是非常巨大的，它最大的价值不在于一个具体的数字，而在于提供了一种可扩展的、稳健的架构，它将爬虫从单兵作战升级为兵团作战，使得快速、高效、大规模地采集网络数据成为了可能，如果你好奇速度能快多少，答案就是：只要你创造好条件（足够的机器、稳定的代理IP、友好的目标网站），它几乎可以快到你想达到的极限。 结束）