對于商業(yè)搜索引擎來說，分布式爬蟲架構(gòu)是必須采用的技術(shù)屹逛。面對海量待抓取網(wǎng)頁础废，只有采用分布式架構(gòu)汛骂，才有可能在較短時(shí)間內(nèi)完成一輪抓取工作。
分布式爬蟲可以分為若干個(gè)分布式層級色迂，不同的應(yīng)用可能由其中部分層級構(gòu)成香缺。大型分布式爬蟲主要分為以下3個(gè)層級：分布式數(shù)據(jù)中心手销、分布式抓取服務(wù)器及分布式爬蟲程序歇僧。整個(gè)爬蟲系統(tǒng)由全球多個(gè)分布式數(shù)據(jù)中心共同組成，每個(gè)數(shù)據(jù)中心負(fù)責(zé)抓取本地區(qū)周邊的互聯(lián)網(wǎng)網(wǎng)頁锋拖，比如歐洲的數(shù)據(jù)中心抓取英國诈悍、法國、德國等歐洲國家的網(wǎng)頁兽埃，由于爬蟲與要抓取的網(wǎng)頁地緣較近，在抓取速度上會較遠(yuǎn)程抓取快很多柄错。
每個(gè)數(shù)據(jù)中心又由多臺高速網(wǎng)絡(luò)連接的抓取服務(wù)器構(gòu)成舷夺，而每臺服務(wù)器又可以部署多個(gè)爬蟲程序。通過多層級的分布式爬蟲體系售貌，才可能保證抓取數(shù)據(jù)的及時(shí)性和全面性颂跨。
對于同一中心的多臺抓取服務(wù)器恒削，不同機(jī)器之間的分工協(xié)同方式會有差異，常見的分布式架構(gòu)有兩種：主從分布爬蟲和對等分布爬蟲躯砰。
主從式分布爬蟲
對于主從分布式爬蟲弃揽，不同的服務(wù)器承擔(dān)不同的角色分工矿微，其中有一臺專門負(fù)責(zé)對其他服務(wù)器提供URL分發(fā)服務(wù)涌矢，其他機(jī)器則進(jìn)行實(shí)際的網(wǎng)頁下載塔次。URL服務(wù)器維護(hù)待抓取URL隊(duì)列，并從中獲得待抓取網(wǎng)頁的URL继榆，分配給不同的抓取服務(wù)器考阱，另外還要對抓取服務(wù)器之間的工作進(jìn)行負(fù)載均衡秽之，使得各服務(wù)器承擔(dān)的工作量大致相等，不至于出現(xiàn)忙閑不均的情況。抓取服務(wù)器之間沒有通信聯(lián)系科吭，每個(gè)待抓取服務(wù)器只和URL服務(wù)器進(jìn)行消息傳遞对人。
Google在早期即采用此種主從分布式爬蟲咱台，在這種架構(gòu)中祥诽，因?yàn)閁RL服務(wù)器承擔(dān)很多管理任務(wù)绳姨，同時(shí)待抓取URL隊(duì)列數(shù)量巨大飘庄，所以URL服務(wù)器容易成為整個(gè)系統(tǒng)的瓶頸。
對等式分布爬蟲
在對等式分布爬蟲體系中付枫，服務(wù)器之間不存在分工差異，每臺服務(wù)器承擔(dān)相同的功能址儒，各自負(fù)擔(dān)一部分URL的抓取工作，下圖是其中一種對等式分布爬蟲翁逞，Mercator爬蟲采用此種體系結(jié)構(gòu)。
由于沒有URL服務(wù)器存在，每臺待抓取服務(wù)器的任務(wù)分工就成為問題膏执。在下圖所示的體系結(jié)構(gòu)下眶痰，有服務(wù)器自己來判斷某個(gè)URL是否應(yīng)該由自己來抓取，或者將這個(gè)URL傳遞給相應(yīng)的服務(wù)器吗伤。至于采取的判斷方法，則是對網(wǎng)址的主域名進(jìn)行哈希計(jì)算嚼锄，之后取模（即hash【域名】%m斯棒，這里的m為服務(wù)器個(gè)數(shù)），如果計(jì)算所得的值和服務(wù)器編號匹配主经，則自己下載該網(wǎng)頁荣暮，否則將網(wǎng)址轉(zhuǎn)發(fā)給對應(yīng)編號的抓取服務(wù)器。
以上圖的例子來說罩驻，因?yàn)橛?臺服務(wù)器穗酥，所以取模的時(shí)候m設(shè)定為3，圖中的1號抓取服務(wù)器負(fù)責(zé)抓取哈希取模后值為1的網(wǎng)頁惠遏，當(dāng)其接受到網(wǎng)址www.google.com時(shí)砾跃，首先利用哈希函數(shù)計(jì)算這個(gè)主域名的哈希值，之后對3取模节吮，發(fā)現(xiàn)取模后值為1抽高，屬于自己的職責(zé)范圍，于是就自己下載網(wǎng)頁透绩；如果接受到網(wǎng)頁www.baidu.com翘骂，哈希后對3取模，發(fā)現(xiàn)值等于2帚豪，不屬于自居的職責(zé)范圍碳竟，則會將這個(gè)要下載的URL轉(zhuǎn)發(fā)給2號服務(wù)器，由2號抓取服務(wù)器來進(jìn)行下載狸臣。通過這種方式莹桅，每臺服務(wù)器平均承擔(dān)大約1/3的抓取工作量。
由于沒有URL分發(fā)服務(wù)器烛亦，所以此種方法不存在系統(tǒng)瓶頸問題诈泼，另外其哈希數(shù)不是針對整個(gè)URL，而只針對主域名此洲，所以可以保證同一網(wǎng)站的網(wǎng)頁都由同一臺服務(wù)器抓取厂汗，這樣一方面可以提高下載效率（DNS域名解析可以緩存），另外一方面也可以主動控制對某個(gè)網(wǎng)站的訪問速度呜师，避免對某個(gè)網(wǎng)站訪問壓力過大娶桦。
上圖這種體系結(jié)構(gòu)也存在一些缺點(diǎn)，假設(shè)在抓取過程中某個(gè)服務(wù)器宕機(jī)，或者此時(shí)新加入一臺抓取服務(wù)器 衷畦，因?yàn)槿∧r(shí)m是以服務(wù)器個(gè)數(shù)確定的栗涂，所以此時(shí)m值發(fā)生變化，導(dǎo)致發(fā)部分URL哈希取模后的值跟著變化祈争，這意味著幾乎所有任務(wù)都需要重新進(jìn)行分配斤程，無疑會導(dǎo)致資源的極大浪費(fèi)。
為了解決哈希取模的對等式分布爬蟲存在的問題菩混，UbiCrawler爬蟲提出了改進(jìn)方案忿墅，即放棄哈希取模方式，轉(zhuǎn)而采用一致性哈希方法來確定服務(wù)器的任務(wù)分工沮峡。
一致性哈希將網(wǎng)站的主域名進(jìn)行哈希疚脐，映射為一個(gè)范圍在0到2的32次方之間的某個(gè)數(shù)值，大量的網(wǎng)站主域名會被平均的哈希到這個(gè)數(shù)值區(qū)間邢疙」髋可以如下圖所示那樣，將哈希值范圍首尾相接疟游，即認(rèn)為數(shù)值0和最大值重合呼畸，這樣可以將其看做有序的環(huán)狀序列，從數(shù)值0開始颁虐，沿著環(huán)的順時(shí)針方向蛮原，哈希值逐漸增大，直到環(huán)的結(jié)尾聪廉。而某個(gè)抓取服務(wù)器則負(fù)責(zé)這個(gè)環(huán)裝序列的一個(gè)片段瞬痘，即落在某個(gè)哈希取值范圍內(nèi)的URL都由該服務(wù)器負(fù)責(zé)下載。這樣即可確定每臺服務(wù)器的職責(zé)范圍板熊。
我們以下圖為例說明其優(yōu)勢，假設(shè)2號抓取服務(wù)器接收到了域名www.baidu.com察绷，經(jīng)過哈希值計(jì)算后干签，2號服務(wù)器知道在自己的管轄范圍內(nèi)，于是自己下載這個(gè)URL拆撼。在此之后容劳，2號服務(wù)器收到了www.sina.com.cn這個(gè)域名，經(jīng)過哈希計(jì)算闸度，可知是3號服務(wù)器負(fù)責(zé)的范圍竭贩，于是將這個(gè)URL轉(zhuǎn)發(fā)給3號服務(wù)器。如果3號服務(wù)器死機(jī)莺禁，那么2號服務(wù)器得不到回應(yīng)留量，于是知道3號服務(wù)器出了狀況，此時(shí)順時(shí)針按照環(huán)的大小順序查找，將URL轉(zhuǎn)發(fā)給第一個(gè)碰到的服務(wù)器楼熄，即1號服務(wù)器忆绰，此后3號服務(wù)器的下載任務(wù)都由1號服務(wù)器接管，直接到3號服務(wù)器重新啟動為止可岂。
從上面的流程可知错敢，即使某臺服務(wù)器出了問題，那么本來應(yīng)該由這臺服務(wù)器負(fù)責(zé)URL則由順時(shí)針的下一個(gè)服務(wù)器接管缕粹，并不會對其他服務(wù)器的任務(wù)造成影響稚茅，這樣就解決了哈希取模方式的弊端，將影響范圍從全局限制到了局部平斩，如果新加入下一臺服務(wù)器也是如此峰锁。
如果您對爬蟲有興趣，還可以閱讀：
