分布式爬虫

三种分布式爬虫策略：

1.Slaver 端从 Master 端拿任务（Request/url/ID）进行数据抓取，在抓取数据的同时也 生成新任务，并将任务抛给 Master。Master 端只有一个 Redis 数据库，负责对 Slaver 提交的任务进行去重、加入待爬队列。

优点：

scrapy-redis 默认使用的就是这种策略，我们实现起来很简单，因为任务调度 等工作 scrapy-redis 都已经帮我们做好了，我们只需要继承 RedisSpider、指定 redis_key 就 行了。

缺点：

scrapy-redis 调度的任务是 Request 对象，里面信息量比较大（不仅包含 url， 还有 callback 函数、headers 等信息），导致的结果就是会降低爬虫速度、而且会占用 Redis 大量的存储空间。当然我们可以重写方法实现调度 url 或者用户 ID。

2.Master 端跑一个程序去生成任务（Request/url/ID）。Master 端负责的是生产任务， 并把任务去重、加入到待爬队列。Slaver 只管从 Master 端拿任务去爬。

优点：

将生成任务和抓取数据分开，分工明确，减少了 Master 和 Slaver 之间的数据 交流；Master 端生成任务还有一个好处就是：可以很方便地重写判重策略（当数据量大时 优化判重的性能和速度还是很重要的）。

缺点：

像 QQ 或者新浪微博这种网站，发送一个请求，返回的内容里面可能包含几十 个待爬的用户 ID，即几十个新爬虫任务。但有些网站一个请求只能得到一两个新任务，并 且返回的内容里也包含爬虫要抓取的目标信息，如果将生成任务和抓取任务分开反而会降 低爬虫抓取效率。毕竟带宽也是爬虫的一个瓶颈问题，我们要秉着发送尽量少的请求为原 则，同时也是为了减轻网站服务器的压力，要做一只有道德的 Crawler。所以，视情况而 定。

3.Master 中只有一个集合，它只有查询的作用。Slaver 在遇到新任务时询问 Master 此 任务是否已爬，如果未爬则加入 Slaver 自己的待爬队列中，Master 把此任务记为已爬。它 和策略一比较像，但明显比策略一简单。策略一的简单是因为有 scrapy-redis 实现了 scheduler 中间件，它并不适用于非 scrapy 框架的爬虫

优点：

实现简单，非 scrapy 框架的爬虫也适用。Master 端压力比较小，Master 与 Slaver 的数据交流也不大。

缺点：

“健壮性”不够，需要另外定时保存待爬队列以实现“断点续爬”功能。各 Slaver 的待爬任务不通用。 如果把 Slaver 比作工人，把 Master 比作工头。策略一就是工人遇到新任务都上报给工头，需要 干活的时候就去工头那里领任务；策略二就是工头去找新任务，工人只管从工头那里领任务干活；策略 三就是工人遇到新任务时询问工头此任务是否有人做了，没有的话工人就将此任务加到自己的“行程 表”。