爬虫架构理解

• 摘要：前言:爬虫是偏IO型的任务,分布式爬虫的实现难度比分布式计算和分布式存储简单得多。 我的觉得分布式爬虫须要考虑的点主要有如下几个:爬虫任务的统一调度爬虫任务的统一去重存储问题速度问题足够“健壮”的状况下实现起来越简单/方便越好最好支持“断点续爬”功能Python分布式爬虫比较经常使用的应该是scrapy框架加上Redis内存数据库,中间的调度任务等用scrapy-redis模块实现。 此处简单介绍一下基于Redis的三种分布式策略,其实它们之间仍是很类似的,只
• 前言:

  爬虫是偏IO型的任务,分布式爬虫的实现难度比分布式计算和分布式存储简单得多。 
  我的觉得分布式爬虫须要考虑的点主要有如下几个:

  • 爬虫任务的统一调度
  • 爬虫任务的统一去重
  • 存储问题
  • 速度问题
  • 足够“健壮”的状况下实现起来越简单/方便越好
  • 最好支持“断点续爬”功能

  Python分布式爬虫比较经常使用的应该是scrapy框架加上Redis内存数据库,中间的调度任务等用scrapy-redis模块实现。 
  此处简单介绍一下基于Redis的三种分布式策略,其实它们之间仍是很类似的,只是为适应不一样的网络或爬虫环境做了一些调整而已(若有错误欢迎留言拍砖)。 

   

  【策略一】

   
  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。 

   

  【策略二】

  
  这是对策略的一种优化改进:在Master端跑一个程序去生成任务(Request/url/ID)。Master端负责的是生产任务,并把任务去重、加入到待爬队列。Slaver只管从Master端拿任务去爬。

  优势: 将生成任务和抓取数据分开,分工明确,减小了Master和Slaver之间的数据交流;Master端生成任务还有一个好处就是:能够很方便地重写判重策略(当数据量大时优化判重的性能和速度仍是很重要的)。 
  缺点: 像QQ或者新浪微博这种网站,发送一个请求,返回的内容里面可能包含几十个待爬的用户ID,即几十个新爬虫任务。但有些网站一个请求只能获得一两个新任务,而且返回的内容里也包含爬虫要抓取的目标信息,若是将生成任务和抓取任务分开反而会下降爬虫抓取效率。毕竟带宽也是爬虫的一个瓶颈问题,咱们要秉着发送尽可能少的请求为原则,同时也是为了减轻网站服务器的压力,要作一只有道德的Crawler。因此,视状况而定。 

   

  【策略三】

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

  优势: 实现简单,非scrapy框架的爬虫也适用。Master端压力比较小,Master与Slaver的数据交流也不大。 
  缺点: “健壮性”不够,须要另外定时保存待爬队列以实现“断点续爬”功能。各Slaver的待爬任务不通用。 

   

  结语: 若是把Slaver比做工人,把Master比做工头。策略一就是工人遇到新任务都上报给工头,须要干活的时候就去工头那里领任务;策略二就是工头去找新任务,工人只管从工头那里领任务干活;策略三就是工人遇到新任务时询问工头此任务是否有人作了,没有的话工人就将此任务加到本身的“行程表”。