爬虫 : 分布式爬虫搭建 [TODO]

  1. scrapy-redis

2.

作者:杨恒
链接:https://www.zhihu.com/question/32302268/answer/55724369
来源:知乎
著作权归作者所有,转载请联系作者获得授权。

一时兴起写了篇回复,能给大家解决一点小问题,十分高兴。但偶尔被误认为是大牛,诚惶诚恐。
只是当初一点小爱好而已,大牛实在是不敢当。

另外要对私信给我请求帮助的朋友说声抱歉,我已经离开技术岗位很长时间了,手头上早已没有了编程的环境,加上目前工作太多,对大家的问题也是有心无力(我这人太怂,也不敢给大家随便丢个回复)。

最后祝大家学习爬虫的路上一帆风顺~(虽然不大可能,不过加油吧)

以下是正文
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
不妖自来~
我刚刚接触scrapy的时候,也看过这个项目,奈何对scrapy本身就不怎么熟悉,所以当时怎么也想不明白,直到后来开始看scrapy 的源代码,才渐渐明白。这里提一下我的看法,水平有限,不敢保证完全正确,欢迎指正。

一、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组件有什么突出特点呢?他们使用了redis数据库来替换scrapy原本使用的队列结构(deque),换了数据结构,那么相应的操作当然都要换啦,所以与队列相关的这些组件都做了更换。

二、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,其实可以对比一下看,操作什么的都差不太多。主要是操作的数据结构变了。

———————————————-被当众抓住的分割线———————————————————
那么既然使用了redis做主要数据结构,能不能把其他使用自带数据结构关键功能模块也换掉呢?(关键部分使用自带数据结构简直有种没穿小内内的危机感,这是本人的想法~)
在我们爬取过程当中,还有一个重要的功能模块,就是request去重(已经发送过得请求就别再发啦,也要考虑一下服务器君的感受好伐)。

scrapy中是如何实现这个去重功能的呢?用集合~
scrapy中把已经发送的request指纹放入到一个集合中,把下一个request的指纹拿到集合中比对,如果该指纹存在于集合中,说明这个request发送过了,如果没有则继续操作。这个核心的判重功能是这样实现的:

def request_seen(self, request):
    #self.figerprints就是一个指纹集合
    fp = self.request_fingerprint(request)
    if fp in self.fingerprints:#这就是判重的核心操作。
        return True
    self.fingerprints.add(fp)
    ......

详见源代码:scrapy/dupefilters.py at master · scrapy/scrapy · GitHub

为了分布式,把这个集合也换掉吧,换了redis,照样也得把去重类给换了。
于是就有了scrapy-redis的dupefilter:scrapy-redis/dupefilter.py at master · darkrho/scrapy-redis · GitHub

——————————————把分割线掀起来(╯‵□′)╯︵||||||\\\\\\\\\\\\\————————————
那么依次类推,接下来的其他组件(Pipeline和Spider),我们也可以轻松的猜到,他们是为什么要被修改呢。对,都是因为redis,全怪redis,redis是罪魁祸首。(其实我不知道,我只是在凑字数而已)

以上是我个人见解,不代表权威说法。希望对你有帮助。如有纰漏请指正(但是别打我

 

参考:

[1]https://www.zhihu.com/question/32302268/answer/55724369   [知乎这篇scrapy-redis 和 scrapy 有什么区别,写的通俗易懂,讲解了分布式爬虫的原型]

[2]https://georgezouq.github.io/2016/06/27/%E5%9F%BA%E4%BA%8ERedis%E7%9A%84%E4%B8%89%E7%A7%8D%E5%88%86%E5%B8%83%E5%BC%8F%E7%88%AC%E8%99%AB%E7%AD%96%E7%95%A5/

[3]https://www.oschina.net/code/snippet_209440_20495

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注