分布式爬虫2种方法

主从式分布爬虫

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

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

对等式分布爬虫

在对等式分布爬虫体系中，服务器之间不存在分工差异，每台服务器承担相同的功能，各自负担一部分URL的抓取工作，下图是其中一种对等式分布爬虫，Mercator爬虫采用此种体系结构。

由于没有URL服务器存在，每台待抓取服务器的任务分工就成为问题。在下图所示的体系结构下，有服务器自己来判断某个URL是否应该由自己来抓取，或者将这个URL传递给相应的服务器。至于采取的判断方法，则是对网址的主域名进行哈希计算，之后取模（即hash【域名】%m，这里的m为服务器个数），如果计算所得的值和服务器编号匹配，则自己下载该网页，否则将网址转发给对应编号的抓取服务器。

 

上图这种体系结构也存在一些缺点，假设在抓取过程中某个服务器宕机，或者此时新加入一台抓取服务器 ，因为取模时m是以服务器个数确定的，所以此时m值发生变化，导致发部分URL哈希取模后的值跟着变化，这意味着几乎所有任务都需要重新进行分配，无疑会导致资源的极大浪费。

为了解决哈希取模的对等式分布爬虫存在的问题，UbiCrawler爬虫提出了改进方案，即放弃哈希取模方式，转而采用一致性哈希方法来确定服务器的任务分工。

一致性哈希将网站的主域名进行哈希，映射为一个范围在0到2的32次方之间的某个数值，大量的网站主域名会被平均的哈希到这个数值区间。可以如下图所示那样，将哈希值范围首尾相接，即认为数值0和最大值重合，这样可以将其看做有序的环状序列，从数值0开始，沿着环的顺时针方向，哈希值逐渐增大，直到环的结尾。而某个抓取服务器则负责这个环装序列的一个片段，即落在某个哈希取值范围内的URL都由该服务器负责下载。这样即可确定每台服务器的职责范围。

我们以下图为例说明其优势，假设2号抓取服务器接收到了域名www.baidu.com，经过哈希值计算后，2号服务器知道在自己的管辖范围内，于是自己下载这个URL。在此之后，2号服务器收到了www.sina.com.cn这个域名，经过哈希计算，可知是3号服务器负责的范围，于是将这个URL转发给3号服务器。如果3号服务器死机，那么2号服务器得不到回应，于是知道3号服务器出了状况，此时顺时针按照环的大小顺序查找，将URL转发给第一个碰到的服务器，即1号服务器，此后3号服务器的下载任务都由1号服务器接管，直接到3号服务器重新启动为止。

 

 从上面的流程可知，即使某台服务器出了问题，那么本来应该由这台服务器负责URL则由顺时针的下一个服务器接管，并不会对其他服务器的任务造成影响，这样就解决了哈希取模方式的弊端，将影响范围从全局限制到了局部，如果新加入下一台服务器也是如此