scrapy和scrapy_redis的理解

一、scrapy和scrapy_redis的区别：

scrapy 是一个通用的爬虫框架，其功能比较完善，可以迅速的写一个简单爬虫，并且跑起来。scrapy-redis是为了更方便地实现scrapy分布式爬取，而提供了一些以redis为基础的组件（注意：scrapy-redis只是一些组件，而不是一个完整的框架）。假如scrapy是一工厂，能够出产你要的spider。而scrapy-redis是其他厂商为了帮助scrapy工厂更好的实现某些功能而制造了一些设备，用于替换scrapy工厂的原设备。所以要想跑分布式，先让scrapy工厂搭建起来，再用scrapy-redis设备去更换scrapy的某些设备。

二、scrapy-redis提供了哪些组件？
Scheduler、Dupefilter、Pipeline、Spider
提供了哪些组件具体见darkrho/scrapy-redis · GitHub。

三、为什么要提供这些组件？
这要从哪哪哪说起（喝口水，默默地望着远方......）

我们先从scrapy的“待爬队列”和“Scheduler”入手：
咱们玩过爬虫（什么玩过，是学习过，研究过，爱过也被虐过）的同学都多多少少有些了解，在爬虫爬取过程当中，有一个主要的数据结构是“待爬队列”，以及能够操作这个队列的调度器（也就是Scheduler啦）。scrapy官方文档对这二者的描述不多，基本上没提。

scrapy使用什么样的数据结构来存放待爬取的request呢？
其实没用高大上的数据结构，就是python自带的collection.deque，不过当然是改造过后的啦（后面所说到的deque均是指scrapy改造之后的队列，至于如何改造的，就去看代码吧）。
详见源代码queuelib/queue.py at master · scrapy/queuelib · GitHub
不过咱们用一用deque就会意识到，该怎么让两个以上的Spider共用这个deque呢？答案是，我水平不够，不知道。那分布式怎么实现呢，待爬队列都不能共享，还玩个泥巴呀。scrapy-redis提供了一个解决方法，把deque换成redis数据库，我们从同一个redis服务器存放要爬取的request，这样就能让多个spider去同一个数据库里读取，这样分布式的主要问题就解决了嘛。

---------------------------------------------------分割线的随地大小便--------------------------------------------
那么问题又来了，我们换了redis来存放队列，哪scrapy就能直接分布式了么？（当初天真的我呀~
当然不能。我们接着往下说。scrapy中跟“待爬队列”直接相关的就是调度器“Scheduler”：scrapy/scheduler.py at master · scrapy/scrapy · GitHub，它负责对新的request进行入列操作（加入deque），取出下一个要爬取的request（从deque中取出）等操作。
在scrapy中，Scheduler并不是直接就把deque拿来就粗暴的使用了，而且提供了一个比较高级的组织方法，它把待爬队列按照优先级建立了一个字典结构，比如：
{
priority0:队列0
priority1:队列2
priority2:队列2
}
然后根据request中的priority属性，来决定该入哪个队列。而出列时，则按priority较小的优先出列。为了管理这个比较高级的队列字典，Scheduler需要提供一系列的方法。说这么多有什么意义呢？最主要的指导意义就是：你要是换了redis做队列，这个scrapy下的Scheduler就用不了，所以自己写一个吧。

于是就出现了scrapy-redis的专用scheduler：scrapy-redis/scheduler.py at master · darkrho/scrapy-redis · GitHub，其实可以对比一下看，操作什么的都差不太多。主要是操作的数据结构变了。