分布式網(wǎng)路爬蟲(chóng)關(guān)鍵技術(shù)剖析與實(shí)現——分布式網(wǎng)路爬蟲(chóng)體系結構設計 分布式網(wǎng)路爬蟲(chóng)體系結構設計 分布式網(wǎng)路爬蟲(chóng)關(guān)鍵技術(shù)剖析與實(shí)現?一、 研究所屬范圍分布式網(wǎng)路爬蟲(chóng)包含多個(gè)爬蟲(chóng)， 每個(gè)爬蟲(chóng)須要完成的任務(wù)和單個(gè)的爬行器類(lèi)似， 它們從互聯(lián) 網(wǎng)上下載網(wǎng)頁(yè)，并把網(wǎng)頁(yè)保存在本地的c盤(pán)，從中抽取 URL 并順著(zhù)這種 URL 的指向繼續爬 行。由于并行爬行器須要分割下載任務(wù)，可能爬蟲(chóng)會(huì )將自己抽取的 URL 發(fā)送給其他爬蟲(chóng)。 這些爬蟲(chóng)可能分布在同一個(gè)局域網(wǎng)之中，或者分散在不同的地理位置。根據爬蟲(chóng)的分散程度不同，可以把分布式爬行器分成以下兩大類(lèi)： 1、基于局域網(wǎng)分布式網(wǎng)路爬蟲(chóng)：這種分布式爬行器的所有爬蟲(chóng)在同一個(gè)局域網(wǎng)里運行，通過(guò)高 速的網(wǎng)路聯(lián)接互相通訊。這些爬蟲(chóng)通過(guò)同一個(gè)網(wǎng)路去訪(fǎng)問(wèn)外部互聯(lián)網(wǎng)，下載網(wǎng)頁(yè)，所有的網(wǎng) 絡(luò )負載都集中在她們所在的那種局域網(wǎng)的出口上。 由于局域網(wǎng)的帶寬較高， 爬蟲(chóng)之間的通訊 的效率能否得到保證； 但是網(wǎng)路出口的總帶寬上限是固定的， 爬蟲(chóng)的數目會(huì )遭到局域網(wǎng)出口 帶寬的限制。 2、基于廣域網(wǎng)分布式網(wǎng)路爬蟲(chóng)：當并行爬行器的爬蟲(chóng)分別運行在不同地理位置（或網(wǎng)路位置）， 我們稱(chēng)這些并行爬行器為分布式爬行器。

　　例如，分布式爬行器的爬蟲(chóng)可能坐落中國，日本， 和英國，分別負責下載這三地的網(wǎng)頁(yè)；或者坐落 CHINANET，CERNET，CEINET，分別負責 下載這三個(gè)網(wǎng)路的中的網(wǎng)頁(yè)。分布式爬行器的優(yōu)勢在于可以子在一定程度上分散網(wǎng)路流量， 減小網(wǎng)路出口的負載。如果爬蟲(chóng)分布在不同的地理位置（或網(wǎng)路位置），需要間隔多長(cháng)時(shí)間 進(jìn)行一次互相通訊就成為了一個(gè)值得考慮的問(wèn)題。 爬蟲(chóng)之間的通信帶寬可能是有限的， 通常 需要通過(guò)互聯(lián)網(wǎng)進(jìn)行通訊。 在實(shí)際應用中， 基于局域網(wǎng)分布式網(wǎng)路爬蟲(chóng)應用的更廣一些， 而基于廣域網(wǎng)的爬蟲(chóng)因為 實(shí)現復雜， 設計和實(shí)現成本偏高， 一般只有實(shí)力雄厚和采集任務(wù)較重的大公司才能使用這些 爬蟲(chóng)。本論文所設計的爬蟲(chóng)就是基于局域網(wǎng)分布式網(wǎng)路爬蟲(chóng)。二、分布式網(wǎng)路爬蟲(chóng)整體剖析分布式網(wǎng)路爬蟲(chóng)的整體設計重點(diǎn)應當在于爬蟲(chóng)怎樣進(jìn)行通訊。目前分布式網(wǎng) 絡(luò )爬蟲(chóng)按通訊方法不同分布式網(wǎng)絡(luò )爬蟲(chóng)可以分為主從模式、 自治模式與混和模式 三種。主從模式是指由一臺主機作為控制節點(diǎn)負責所有運行網(wǎng)路爬蟲(chóng)的主機進(jìn)行管理， 爬蟲(chóng)只 需要從控制節點(diǎn)哪里接收任務(wù)， 并把新生成任務(wù)遞交給控制節點(diǎn)就可以了， 在這個(gè)過(guò)程中不 必與其他爬蟲(chóng)通訊，這種方法實(shí)現簡(jiǎn)單利于管理。

　　而控制節點(diǎn)則須要與所有爬蟲(chóng)進(jìn)行通訊， 它須要一個(gè)地址列表來(lái)保存系統中所有爬蟲(chóng)的信息。 當系統中的爬蟲(chóng)數目發(fā)生變化時(shí)， 協(xié)調 者須要更新地址列表里的數據， 這一過(guò)程對于系統中的爬蟲(chóng)是透明的。 但是隨著(zhù)爬蟲(chóng)網(wǎng)頁(yè)數 量的降低。 控制節點(diǎn)會(huì )成為整個(gè)系統的困局而造成整個(gè)分布式網(wǎng)路爬蟲(chóng)系統性能增長(cháng)。 主從 模式的整體*敏*感*詞*：自治模式是指系統中沒(méi)有協(xié)調者，所有的爬蟲(chóng)都必須互相通訊，比主從模式 下爬蟲(chóng)要復雜一些。自治模式的通訊方法可以使用全聯(lián)接通訊或環(huán)型通訊。全連 接通訊是指所用爬蟲(chóng)都可以互相發(fā)送信息， 使用這些方法的每位網(wǎng)絡(luò )爬蟲(chóng)會(huì )維護 一個(gè)地址列表，表中儲存著(zhù)整個(gè)系統中所有爬蟲(chóng)的位置，每次通訊時(shí)可以直接把 數據發(fā)送給須要此數據的爬蟲(chóng)。當系統中的爬蟲(chóng)數目發(fā)生變化時(shí)，每個(gè)爬蟲(chóng)的地 址列表都須要進(jìn)行更新。環(huán)形通訊是指爬蟲(chóng)在邏輯上構成一個(gè)環(huán)形網(wǎng)，數據在環(huán) 上按順時(shí)針或逆時(shí)針雙向傳輸， 每個(gè)爬蟲(chóng)的地址列表中只保存其前驅和后繼的信 息。爬蟲(chóng)接收到數據然后判定數據是否是發(fā)送給自己的，如果數據不是發(fā)送給自 己的，就把數據轉發(fā)給后繼；如果數據是發(fā)送給自己的，就不再發(fā)送。假設整個(gè) 系統中有 n 個(gè)爬蟲(chóng)， 當系統中的爬蟲(chóng)數目發(fā)生變化時(shí)， 系統中只有 n-1 個(gè)爬蟲(chóng)的 地址列表須要進(jìn)行更新。

　　混合模式是結合前面兩種模式的特性的一種折中模式。該模式所有的爬蟲(chóng)都可以 相互通訊同時(shí)都具有任務(wù)分配功能。不過(guò)所有爬蟲(chóng)中有個(gè)特殊的爬蟲(chóng)，該爬蟲(chóng)主 要功能對早已經(jīng)過(guò)爬蟲(chóng)任務(wù)分配后未能分配的任務(wù)進(jìn)行集中分配。 使用這個(gè)方法 的每位網(wǎng)路爬蟲(chóng)只需維護自己采集范圍的地址列表。 而特殊爬蟲(chóng)需不僅保存自己 采集范圍的地址列表*敏*感*詞*。 從上篇開(kāi)始， 我將從單機網(wǎng)路爬蟲(chóng)一步步介紹我們須要考慮的問(wèn)題的解決方案。 如果你們有 更好的解決方案。歡迎指教。 吉日的一句話(huà)說(shuō)的太有道理， 一個(gè)人一輩子只能做好幾件事。 希望你們支持我的這個(gè)系 列。談?wù)劸W(wǎng)路爬蟲(chóng)設計中的問(wèn)題?網(wǎng)絡(luò )蜘蛛現今開(kāi)源的早已有好幾個(gè)了，Larbin，Nutch，Heritrix 都各有用戶(hù)之地，要做 一個(gè)自己的爬蟲(chóng)要解決很多個(gè)問(wèn)題分詞技術(shù) 爬蟲(chóng)，比如調度算法、更新策略、分布式存儲等，我們來(lái)一一 看一下。

　　 一個(gè)爬蟲(chóng)要做的事主要有以下這種 1. 2. 3. 從一個(gè)網(wǎng)頁(yè)入口，分析鏈接，一層一層的遍歷，或者從一組網(wǎng)頁(yè)入口，或者 從一個(gè) rss 源列表開(kāi)始爬 rss； 獲取每位頁(yè)面的源碼保存在c盤(pán)或則數據庫里； 遍歷抓出來(lái)的網(wǎng)頁(yè)進(jìn)行處理，比如提取正文，消重等；4. 根據用途把處理后的文本進(jìn)行索引、分類(lèi)、聚類(lèi)等操作。 以上是個(gè)人理解哦，呵呵。這些過(guò)程中，大約有如下問(wèn)題 如何獲取網(wǎng)頁(yè)源或則 RSS 源 如果是通常的爬蟲(chóng)的話(huà)， 就是給幾個(gè)入口頁(yè)面， 然后沿著(zhù)超鏈接以遍歷圖的算法一個(gè)頁(yè)面一 個(gè)頁(yè)面的爬，這種情況網(wǎng)頁(yè)源極少，可以選擇從 hao123 等網(wǎng)址大全的網(wǎng)站為入口開(kāi)始爬。 如果做垂直搜索的話(huà)就人工去搜集一些這個(gè)行業(yè)的網(wǎng)站， 形成一個(gè)列表， 從這個(gè)列表開(kāi)始爬。 如果是爬 RSS 的話(huà)，需要先搜集 RSS 源，現在大的門(mén)戶(hù)的新聞頻道和主流的博客系統都有 rss 的功能，可以先爬一遍網(wǎng)站，找出 rss 的鏈接，要獲取每位鏈接的內容，分析是否是 rss 格式，如果是就把這個(gè)鏈接保存到 rss 源數據庫里，以后就專(zhuān)門(mén)爬這個(gè) rss 源的 rss。還有一 種就是人工來(lái)整理，一般 blog 的 rss 都是有規律的，主域名跟一個(gè)用戶(hù)名旁邊再跟上一個(gè) rss 的固定頁(yè)面，比如 ，這樣就弄一個(gè)用戶(hù)字典，拼接 rss 地址， 然后用程序去偵測是否有這個(gè)頁(yè)面來(lái)整理出每位網(wǎng)站的 rss 源。

　　 整理出 rss 源后再 人工設置 rss 源的權重及刷新時(shí)間間隔等。 如果源頁(yè)面好多，如何用多線(xiàn)程去有效的調度處理， 如果源頁(yè)面好多，如何用多線(xiàn)程去有效的調度處理，而不會(huì )相互等待或則重復處理 如果現今有 500 萬(wàn)個(gè)頁(yè)面要去爬，肯定要用多線(xiàn)程或則分布式多進(jìn)程去處理了?？梢园秧?yè) 面進(jìn)行水平分割，每個(gè)線(xiàn)程處理一段兒，這樣每位線(xiàn)程之間不需要同步，各自處理各自的就 行了。比如給這 500W 個(gè)頁(yè)面分配一個(gè)自增 ID,2 個(gè)線(xiàn)程的話(huà)就讓第一個(gè)線(xiàn)程去爬 1，3，5 的網(wǎng)頁(yè)，第二個(gè)線(xiàn)程去爬 2，4，6 的網(wǎng)頁(yè)，這樣做空個(gè)線(xiàn)程間基本上能均衡，而且不會(huì )相 互等待，而且不會(huì )重復處理，也不會(huì )拉掉網(wǎng)頁(yè)。每個(gè)線(xiàn)程一次取出 1w 個(gè)頁(yè)面，并記錄最高 的源頁(yè)面 ID 號，處理完這一批后再從數據庫里提取小于這個(gè)源頁(yè)面 ID 號的下 1W 個(gè)頁(yè)面， 直到抓取完本線(xiàn)程要處理的所有頁(yè)面。1w 這個(gè)值按照機器的顯存可做適當的調整。為了防 止抓了半截兒關(guān)機，所以要支持斷點(diǎn)續抓，要為每位線(xiàn)程的處理進(jìn)度保存狀態(tài)，每取一批網(wǎng) 頁(yè)都要記錄本線(xiàn)程最大的網(wǎng)頁(yè) ID，記錄到數據庫里，進(jìn)程重啟后可以讀取這個(gè) ID，接著(zhù)抓 后面的頁(yè)面。 如何盡量的借助 CPU，盡量的不使線(xiàn)程處于等待、休眠、阻塞等空閑狀態(tài)并且要盡量用少 ，盡量的不使線(xiàn)程處于等待、休眠、 的線(xiàn)程以降低上下文切換。

　　 的線(xiàn)程以降低上下文切換。 爬蟲(chóng)有兩個(gè)地方須要 IO 操作，抓網(wǎng)頁(yè)的時(shí)侯須要通過(guò)網(wǎng)卡訪(fǎng)問(wèn)網(wǎng)路，抓到網(wǎng)頁(yè)后要把內容 寫(xiě)到c盤(pán)或則數據庫里。所以這兩個(gè)部份要用異步 IO 操作，這樣可以不用線(xiàn)程阻塞在那里 等待網(wǎng)頁(yè)抓過(guò)來(lái)或則寫(xiě)完磁盤(pán)文件，網(wǎng)卡和硬碟都支持顯存直接讀取，大量的 IO 操作會(huì )在 硬件驅動(dòng)的隊列里排隊，而不消耗任何 CPU。.net 的異步操作使用了線(xiàn)程池，不用自己頻繁 的創(chuàng )建和銷(xiāo)毀線(xiàn)程，減少了開(kāi)支，所以線(xiàn)程模型不用考慮，IO 模型也不用考慮，.net 的異 步 IO 操作直接使用了完成端口，很高效了，內存模型也不需要考慮，整個(gè)抓取過(guò)程各線(xiàn)程不需要訪(fǎng)問(wèn)共享資源分詞技術(shù) 爬蟲(chóng)，除了數據庫里的源頁(yè)面，各管各的，而且也是每位線(xiàn)程分段處理，可 以實(shí)現無(wú)鎖編程。 如何不采集重復的網(wǎng)頁(yè) 去重可以使用 king 總監的布隆過(guò)濾器，每個(gè)線(xiàn)程使用一個(gè) bitarray，里面保存本批源頁(yè)面先前 抓取的頁(yè)面的哈希值情況，抓取出來(lái)的源頁(yè)面剖析鏈接后，去這個(gè) bitarray 里判定曾經(jīng)有沒(méi) 有抓過(guò)這個(gè)頁(yè)面，沒(méi)有的話(huà)就抓出來(lái)，抓過(guò)的話(huà)就不管了。假設一個(gè)源頁(yè)面有 30 個(gè)鏈接把， 一批 10W 個(gè)源頁(yè)面， 300w 個(gè)鏈接的 bitarray 應該也不會(huì )占很大顯存。

　　 所以有個(gè)五六個(gè)線(xiàn)程 同時(shí)處理也是沒(méi)問(wèn)題的。 抓出來(lái)的頁(yè)面更快的保存保存到分布式文件系統還是保存在數據庫里 如果保存到c盤(pán)， 可以每位域名創(chuàng )建一個(gè)文件夾， 凡是這個(gè)網(wǎng)站的頁(yè)面都放在這個(gè)文件夾下， 只要文件名不一樣，就不會(huì )出現沖突。如果把頁(yè)面保存到c盤(pán)，數據庫有自己的一套鎖管理 機制，直接用 bulk copy 放數據庫就行了。一般頻繁的寫(xiě)c盤(pán)可能會(huì )導致 CPU 過(guò)高，而頻繁 的寫(xiě)數據庫 CPU 還好一些。而且 sqlserver2008 支持 filestream 類(lèi)型的數組，在保存大文本字 段的時(shí)侯有挺好的性能，并且能夠使用數據庫的 API 來(lái)訪(fǎng)問(wèn)。所以我認為假如沒(méi)有 GFS 那 樣高效成熟的分布式文件系統的話(huà)還不如存 sqlserver 里面呢。 如何有效的依據網(wǎng)頁(yè)的更新頻度來(lái)調整爬蟲(chóng)的采集時(shí)間間隔 做爬蟲(chóng)要了解一些 HTTP 協(xié)議，如果要抓的網(wǎng)頁(yè)支持 Last-Modified 或者 ETag 頭，我們可以先 發(fā)個(gè) head 請求來(lái)試探這個(gè)頁(yè)面有沒(méi)有變化來(lái)決定是否要重新抓取，但是很多網(wǎng)站根本就不 支持這個(gè)東西，所以使爬蟲(chóng)也太費力，讓自己的網(wǎng)站也會(huì )損失更多的性能。這樣我們就要自 己去標明每個(gè)源頁(yè)面的更新時(shí)間間隔及權重，再依照這兩個(gè)值去用一定的算法制訂蜘蛛的更 新策略。

　　 采集下來(lái)的數據做什么用 可以抓取一個(gè)行業(yè)的網(wǎng)站，在本地進(jìn)行動(dòng)詞和索引，做成垂直搜索引擎?？梢杂靡欢ǖ挠柧?算法對抓取出來(lái)的頁(yè)面進(jìn)行自動(dòng)分類(lèi)，做成新聞門(mén)戶(hù)。也可以用死小風(fēng)行的文本相似度算法處理 后進(jìn)行文本降維處理。 如何不影響對方網(wǎng)站的性能 現在很多網(wǎng)站都被爬蟲(chóng)爬怕了， 因為有些蜘蛛弄住一個(gè)網(wǎng)站可勁兒的爬， 爬的人家網(wǎng)站的正 常用戶(hù)都未能訪(fǎng)問(wèn)了。所以很多站長(cháng)想了很多辦法來(lái)對付爬蟲(chóng)，所以我們寫(xiě)爬蟲(chóng)也要遵守機器 人合同，控制單位時(shí)間內對一個(gè)網(wǎng)站的訪(fǎng)問(wèn)量。