對于商業搜索引擎來說，分布式爬蟲架構是必須采用的技術。面對海量待抓取網頁，只有采取分布式架構，才有可能在較短時間內完成一輪抓取工作。 分布式爬蟲可以分為若千個分布式層級。不同的應用可能由其中部分層級構成，下圖是一個大型分布式爬蟲的3個層級:分布式數據中心、分布式抓取服務器及分布式爬蟲程序。整個爬蟲系統由全球多個分布式數據中心共同構成，每個數據中心負責抓取本地域周邊的互聯網網頁，比如歐洲的數據中心負責抓取英國、法國、德國等歐洲國家的網頁，由于爬蟲與要抓取的網頁地緣較近，在抓取速度上會較遠程抓取快很多。 每個數據中心義由多臺高速網絡連接的抓取服務器構成，而每臺服務器又可以部署多個爬蟲程序。通過多層級的分布式爬蟲體系，才一可能保證抓取數據的及時性和全面性。 對于同一數據中心的多臺抓取服務器，不同機器之間的分工協同方式會有差異，常見的分布式架構有兩種:主從式分布爬蟲和對等式分布爬蟲。 　　1、主從式分布爬蟲(Master-Slave） 對于主從式分布爬蟲，不同的服務器承擔不同的角色分工，其中有一臺專門負責對其他服務器提供URL分發服務，其他機器則進行實際的網貞F載口URL服務器維護待抓取URL隊列，并從中獲得待抓取網頁的URL，分配給不同的抓取服務器，另外還要對抓取服務器之間的工作進行負載均衡，使得各個服務器承擔的工作量大致相等，不至于出現忙的過忙、閑的過閑的情形。抓取服務器之間沒有通信聯系，每個抓取服務器只和URL服務器進行消息傳遞。 Google在早期即采用此種卞從分布式爬蟲，在這種架構中，因為URL服務器承擔很多管理任務，同時待抓取URL隊列數量巨大，所以URL服務器容易成為整個系統的瓶頸。 　　2、對等式分布爬蟲(Peer to Peer） 在對等式分布爬蟲體系中，服務器之間不存在分工差異，每臺服務器承擔相同的功能，各自負擔一部分URL的抓取工作，如圖所示即是其中一種對等式分布爬蟲，Mercator爬蟲采用此種體系結構。 由于沒有URL服務器存在，每臺抓取服務器的任務分工就成為問題。在如圖所示體系結構下，由服務器自己來判斷某個URL是否應該由自己來抓取，或者將這個URL傳遞給相應的服務器。至于采取的判斷方法，則是對網址的主域名進行哈希計算，之后取模(即hash域名」%m，這里的m對應服務器個數)，如果計算所得的值和抓取服務器編號匹配，則自己下載該網頁，否則將該網址轉發給對應編號的抓取服務器。 以圖中的例子來說，因為有3臺抓取服務器，所以取模的時候m設定為3。圖中的1號抓取服務器負責抓取哈希取模后值為1的網頁，當其接收到網址www.google.com時，首先用哈希函數計算這個主域名的哈希值，之后對3取模，發現取模后值為1，屬于自己的職責范圍，于是就自己下載網頁;如果接收到網址www.baidu.com，哈希后對3取模，發現其值等于2，不屬于自己的職責范疇，則會將這個要下載的URL轉發給2號抓取服務器，由2號抓取服務器來進行下載。通過這種方式，每臺服務器平均承擔大約1/3的抓取工作量。 由于沒有URL分發服務器，所以此種方法不存在系統瓶頸問題，另外其哈希函數不是針對整個URL,而只針對主域名，所以可以保證同一網站的網頁都由同一臺服務器抓取，這樣一方面可以提高下載效率(DNS域名解析可以緩存)，另外一方面也可以主動控制對某個網站的訪問速度，避免對某個網站訪問壓力過大。 圖中這種體系結構也存在一些缺點，假設在抓取過程中某臺服務器宕機，或者此時新加入一臺抓取服務器，因為取模時，是以服務器個數確定的，所以此時m值發生變化，導致大部分URL,哈希取模后的值跟著變化，這意味著兒乎所有任務都需要重新進行分配，無疑會導致資源的極大浪費。 為了解決哈希取模的對等式分布爬蟲存在的問題，UbiCrawle:爬蟲提出了改進方案，即放棄哈希取模方式，轉而采用一致性哈希方法C Consisting Hash )來確定服務器的任務分工，如下圖所示： 一致性哈希將網站的主域名進行哈希，映射為一個范圍在O到2的32次方之問的某個數值，大量的網站主域名會被均勻地哈希到這個數位區間。可以像圖中所示那樣，將哈希值范圍首尾相接，即認為數值0和最大值重合，這樣可以將其看做有序的環狀序列，從數值O開始，沿著環的順時針方向，哈希值逐漸增大，自到環的結尾。而某個抓取服務器則負責這個環狀序列的一個片段，即落在某個哈希取位范闊內的URL都由該服務器負責下載。這樣即可確定每臺服務器的職責范。 我們以圖為例說明其優勢，假設2號抓取服務器接收到了域名www.baidu.cam,經過哈希值計算后，2號服務器知道在自己的管轄范圍內，于是自己下載這個URL。在此之后，2號服務器收到了www.sina.com.cn這個域名，經過哈希計算，可知是3號服務器負責的范圍，于是將這個URL轉發給3號服務器。如果3號服務器死機，那么2號服務器得不到回應，于是知道3號服務器出了狀況，此時順時針按照環的大小順序查找，將URL轉發給第一個碰到的服務器，即1號服務器，此后3號服務器的下載任務都由l號服務器接管，直到3號服務器重新啟動為止。

從上面的流程可知，即使某臺服務器出了問題，那么本來應該由這臺服務器負責的URL則由順時針的下個服務器接管，并不會對其他服務器的任務造成影響，這樣就解決了哈希取模方式的弊端，將影響范圍從全局限制到了局部，如果新加入一臺下載服務器也是如此。 http://www.xiaomayi88.com/seoenginer/32500_2.html

總結

以上是生活随笔為你收集整理的搜索引擎分布式爬虫介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。