摘 要：互聯(lián)網(wǎng)時代，如何從海量數(shù)據(jù)中收集信息是一個關鍵問題。目前，使用最頻繁的信息檢索與收集工具是基于通用爬蟲的搜索引擎。與通用爬蟲相比，主題爬蟲盡量避免與主題不相關頁面的抓取，存儲的頁面數(shù)量更少，所獲取的信息價值密度更高，是一種有效的信息收集工具。如何通過有效的架構設計降低爬蟲任務的耗時是一個關鍵問題。

關鍵詞：主題爬蟲;架構;Scrapy

網(wǎng)絡爬蟲指的就是一種根據(jù)既定規(guī)則對Web網(wǎng)頁中應用程序或腳本進行自動提取的技術。如今，各大搜索引擎網(wǎng)站和大型互聯(lián)網(wǎng)企業(yè)均在大幅使用此類爬蟲程序，爬取目標網(wǎng)站的網(wǎng)頁信息，以實時更新企業(yè)內部服務器關于這類信息的內容。網(wǎng)絡爬蟲的步驟流程一般可分為采集數(shù)據(jù)，分析或轉換數(shù)據(jù)，存儲數(shù)據(jù)三個部分。在傳統(tǒng)爬蟲中，首先給定一個或者多個URL，爬蟲程序開始運行，從給定的URL上獲取網(wǎng)頁的信息，分析過濾新獲取的URL，存入等待爬取的URL數(shù)據(jù)庫表中，不斷重復此過程。

單機版本的網(wǎng)絡爬蟲存在很明顯的缺陷，受限于單獨的主機配置，不能任意擴展性能，在生產環(huán)境中極少使用。因此，目前網(wǎng)絡爬蟲一般均會使用分布式爬蟲架構，可以在多個節(jié)點同時運行，大幅提高了爬蟲速度和效率。對于分布式爬蟲架構，常見的有主從式、對等式、混合式架構。

1? 主從式架構

在主從分布式結構中，一般只有一個主節(jié)點，其余均為從節(jié)點。主節(jié)點負責URL的存儲與分發(fā)，其它節(jié)點則進行網(wǎng)頁的爬取下載工作。主節(jié)點服務器負責維護待爬取的URL隊列，并且主動給從節(jié)點分配URL，所以主節(jié)點還需要考慮整個系統(tǒng)的負載均衡的問題。不能讓某個從節(jié)點壓力過大，也不能讓某個從節(jié)點一直空閑。主節(jié)點需要根據(jù)從節(jié)點反饋的任務執(zhí)行情況來增減某一個從節(jié)點的負載壓力，以發(fā)揮整個系統(tǒng)最大的效率。在各個從節(jié)點之間一般沒有通信鏈路，各個從節(jié)點只會和主節(jié)點相互聯(lián)系。因為后期URL的數(shù)量巨大，所以主節(jié)點的URL服務器對待爬取隊列的維護和URL的分發(fā)將會承受極大壓力。

因此，主從分布式結構性能效率的提升關鍵在于主節(jié)點的URL服務器。主從分布式拓撲示意圖如1-1所示。

2? 對等式架構

在對等式架構中，各個節(jié)點之間不存在所謂的主從之分。每個節(jié)點都會有爬蟲任務運行，各個節(jié)點各自維護自己的待爬取URL隊列。因此這就存在數(shù)據(jù)

同步的問題，多個節(jié)點可能會對同一網(wǎng)頁多次爬取，這會大大的浪費節(jié)點的資源。既然各個節(jié)點不能各自為政，那么如何分工協(xié)作就是一個問題了。常見的有以下兩種解決方式：哈希取模和一致性哈希。哈希取模是在爬取之前各節(jié)點會計算網(wǎng)站域名的哈希值，然后對節(jié)點個數(shù)取模，取模的結果就代表了該域名下應由哪個節(jié)點進行爬取。但該方法存在一些弊端，若有一個節(jié)點宕機了，取模數(shù)就會發(fā)生變化，以致于最終結果就會發(fā)生混亂。另外，不同網(wǎng)站的網(wǎng)頁數(shù)據(jù)量也不一樣，不同的節(jié)點爬取不同域名下的網(wǎng)站，這也可能會存在負載均衡的問題。一致性哈希算法直接將網(wǎng)站主域名進行哈希映射，結果范圍是0-2^32之間的某個數(shù)。將該范圍首尾相連成環(huán)，每個服務器就負責其中的一小段，如果某一個節(jié)點服務器宕機，就將該服務器的任務順延至下一個節(jié)點服務器。對等式架構不存在獨立的URL服務器，因此不會存在性能瓶頸的問題，但是整個系統(tǒng)實現(xiàn)起來比主從式架構更加復雜。對等分布式拓撲示意圖如圖2-1所示。

3? 主從混合模式

此模式是參考了主從式架構的設計基礎，并且也揉合了對等式架構的特性。在此架構模式中，由主節(jié)點和從節(jié)點之分，每個節(jié)點均會有爬蟲任務。主節(jié)點上有著系統(tǒng)唯一的URL服務器，各個從節(jié)點與主節(jié)點相互通信，各個從節(jié)點之間不會相互通信。該模式主要是考慮到了目的網(wǎng)站鏈接的特殊性，主節(jié)點僅對一類特殊鏈接進行爬取，從節(jié)點也僅對另一類特殊鏈接爬取，兩類節(jié)點爬取的鏈接不會交疊重復。此模式設計的好處是比對等式更簡單，系統(tǒng)設計和程序代碼實現(xiàn)起來更加容易;而與主從式相比，增設了主節(jié)點爬取小部分特殊鏈接的任務。本系統(tǒng)參考了Python語言編寫的經(jīng)典的爬蟲框架Scrapy，利用Redis數(shù)據(jù)庫，解決了其不支持分布式的缺點。

4 Scrapy-Redis框架

Scrapy 是一款基于Python開發(fā)的開源web爬蟲框架，可快速抓取Web站點并提取頁面中的結構化數(shù)據(jù)，具有高度的擴展性和魯棒性。但是在面對大量的網(wǎng)頁數(shù)據(jù)需要處理時，單主機的爬蟲程序效率低下的缺點就顯得尤為突出，遠遠不能滿足項目的要求了，此時就必須使用分布式爬蟲了。然而單獨的原始Scrapy?框架并不支持分布式，因此在Scrapy的框架基礎上衍生出了Scrapy-Redis分布式爬蟲框架。它利用Redis?調度和存儲需要爬取的請求，并存儲爬取產生的項目以供后續(xù)處理使用。Scrapy-Redis重寫了Scrapy一些比較關鍵的模塊，使Scrapy支持了分布式架構。

在信息時代的今天，互聯(lián)網(wǎng)數(shù)據(jù)量爆發(fā)增長，云計算和大數(shù)據(jù)的應用場景也越來越豐富?；ヂ?lián)網(wǎng)大數(shù)據(jù)對于大型企業(yè)收集分析客戶需求、意向和商業(yè)前景市場調研就極為重要。在企業(yè)的商業(yè)決策上、經(jīng)營方向上需要大量準確的可靠數(shù)據(jù)做支撐，所以如何快速準確地獲取大量的目的數(shù)據(jù)信息就是一個迫切需要解決的問題。本系統(tǒng)基于Docker容器集群部署的分布式爬蟲系統(tǒng)，采用了Scrapy-Redis分布式爬蟲框架，改進了URL去重模塊，增設了頁面文本去重模塊，優(yōu)化了對于反爬蟲問題的處理，對于整個系統(tǒng)的高效性與健壯性增加了一層堅實保障。

參考文獻：

[1] 杜曉旭，賈小云.基于Python 的新浪微博爬蟲分析[J].軟件，2019，40（04）

[2]鄧萬宇，劉光達，董瑩瑩.一種基于Scrapy-Redis 的分布式微博數(shù)據(jù)采集方案[J].信息技術，2018（11）.

作者簡介：

和乾（1981）男，黑龍江大慶人，講師，大學本科， 主要從事計算機網(wǎng)絡專業(yè)網(wǎng)絡安全、網(wǎng)絡操作系統(tǒng)的教學及安全理論考試點的運維工作。

（大慶職業(yè)學院? 黑龍江? 大慶? 163255）