分布式爬虫

目录

分布式爬虫

主从式分布爬虫

对等式爬虫 


分布式爬虫

三个层级

 分布式数据中心,分布式抓取服务器,分布式爬虫程序

每个数据中心又由多台高速网络连接的抓取服务器构成,而每台服 务器又可以部署多个爬虫程序。通过多层级的分布式爬虫体系,才可能 保证抓取数据的及时性和全面性。

主从式分布爬虫

对于主从式分布爬虫,不同的服务器承担不同的角色分工(参考图 2-15),其中有一台专门负责对其他服务器提供URL分发服务,其他机 器则进行实际的网页下载。URL服务器维护待抓取URL队列,并从中获 得待抓取网页的URL,分配给不同的抓取服务器,另外还要对抓取服务 器之间的工作进行负载均衡,使得各个服务器承担的工作量大致相等, 不至于出现忙的过忙、闲的过闲的情形。抓取服务器之间没有通信联 系,每个抓取服务器只和URL服务器进行消息传递

Google在早期即采用此种主从分布式爬虫,在这种架构中,因为 URL服务器承担很多管理任务,同时待抓取URL队列数量巨大,所以 URL服务器容易成为整个系统的瓶颈

对等式爬虫 

在对等式分布爬虫体系中,服务器之间不存在分工差异,每台服务 器承担相同的功能,各自负担一部分URL的抓取工作,如图2-16所示即 是其中一种对等式分布爬虫,Mercator爬虫采用此种体系结构(关于 Mercator爬虫具体技术细节可以参考文献7)。在对等式分布爬虫体系中,服务器之间不存在分工差异,每台服务 器承担相同的功能,各自负担一部分URL的抓取工作,如图2-16所示即 是其中一种对等式分布爬虫,Mercator爬虫采用此种体系结构(关于 Mercator爬虫具体技术细节可以参考文献7)。

由于没有URL服务器存在,每台抓取服务器的任务分工就成为问 题。在如图2-16所示体系结构下,由服务器自己来判断某个URL是否应 该由自己来抓取,或者将这个URL传递给相应的服务器。至于采取的判 断方法,则是对网址的主域名进行哈希计算,之后取模(即hash[域 名]%m,这里的m对应服务器个数),如果计算所得的值和抓取服务 器编号匹配,则自己下载该网页,否则将该网址转发给对应编号的抓取 服务器。 以图2-16的例子来说,因为有3台抓取服务器,所以取模的时候m设 定为3。图中的1号抓取服务器负责抓取哈希取模后值为1的网页,当其 接收到网址www.google.com时,首先利用哈希函数计算这个主域名的哈 希值,之后对3取模,发现取模后值为1,属于自己的职责范围,于是就 自己下载网页;如果接收到网址www.baidu.com,哈希后对3取模,发现 其值等于2,不属于自己的职责范畴,则会将这个要下载的URL转发给2 号抓取服务器,由2号抓取服务器来进行下载。通过这种方式,每台服 务器平均承担大约1/3的抓取工作量。 由于没有URL分发服务器,所以此种方法不存在系统瓶颈问题,另 外其哈希函数不是针对整个URL,而只针对主域名,所以可以保证同一 网站的网页都由同一台服务器抓取,这样一方面可以提高下载效率 (DNS域名解析可以缓存),另外一方面也可以主动控制对某个网站的 访问速度,避免对某个网站访问压力过大。 图2-16这种体系结构也存在一些缺点,假设在抓取过程中某台服务 器宕机,或者此时新加入一台抓取服务器,因为取模时m是以服务器个 数确定的,所以此时m值发生变化,导致大部分URL哈希取模后的值跟 着变化,这意味着几乎所有任务都需要重新进行分配,无疑会导致资源 的极大浪费。 为了解决哈希取模的对等式分布爬虫存在的问题,UbiCrawler爬虫 提出了改进方案,即放弃哈希取模方式,转而采用一致性哈希方法 (Consisting Hash)来确定服务器的任务分工(参考图2-17)。

一致性哈希将网站的主域名进行哈希,映射为一个范围在0到2 32 之 间的某个数值,大量的网站主域名会被均匀地哈希到这个数值区间。可 以如图2-17所示那样,将哈希值范围首尾相接,即认为数值0和最大值 重合,这样可以将其看做有序的环状序列,从数值0开始,沿着环的顺 时针方向,哈希值逐渐增大,直到环的结尾。而某个抓取服务器则负责 这个环状序列的一个片段,即落在某个哈希取值范围内的URL都由该服 务器负责下载。这样即可确定每台服务器的职责范围。 我们以图2-17为例说明其优势,假设2号抓取服务器接收到了域名 www.baidu.com,经过哈希值计算后,2号服务器知道在自己的管辖范围 内,于是自己下载这个URL。在此之后,2号服务器收到了 www.sina.com.cn这个域名,经过哈希计算,可知是3号服务器负责的范 围,于是将这个URL转发给3号服务器。如果3号服务器死机,那么2号 服务器得不到回应,于是知道3号服务器出了状况,此时顺时针按照环 的大小顺序查找,将URL转发给第一个碰到的服务器,即1号服务器, 此后3号服务器的下载任务都由1号服务器接管,直到3号服务器重新启 动为止。 从上面的流程可知,即使某台服务器出了问题,那么本来应该由这 台服务器负责的URL则由顺时针的下一个服务器接管,并不会对其他服 务器的任务造成影响,这样就解决了哈希取模方式的弊端,将影响范围 从全局限制到了局部,如果新加入一台下载服务器也是如此。 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Shallow_Carl

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值