馬志強,張澤廣,李昊甦,劉利民
(內蒙古工業大學 信息工程學院,內蒙古 呼和浩特010080)
主題信息采集系統是智能地在互聯網上采集符合設定專題的軟件系統[1,2]。它的核心問題是如何高速準確得采集主題網頁信息。研究者主要集中在采集策略和體系結構兩個方面進行研究。采集策略的研究主要包括基于文字內容的啟發式方法、基于web超鏈圖評價方法和基于分類器預測等方法[3-5]。體系結構的研究較少,分布式體系結構的核心問題是調度策略與數據同步的問題,主要開展了基于局域網和廣域網的采集系統體系結構等方面的研究[6-11]。
針對主題采集系統存在的采集效率低和可擴展性差等問題,提出了一種基于局域網的分布式架構主題采集系統,實驗結果表明,相對于單服務器架構系統,基于分布式架構的主題采集系統在采集效率和可擴展性方面都得到了提高。
分布式網絡采集系統的架構分為兩類:客戶/服務器模式和自治模式[6]。
客戶/服務器模式由多個客戶采集端和一個服務控制端組成。服務控制端負責所有客戶采集端的任務管理;客戶采集端只需要接收服務控制端發送的任務,并不斷把新完成的任務提交給控制節點。客戶/服務器模式實現簡單利于管理。但是隨著爬蟲網頁數量的增加,服務器控制端會成為整個系統的瓶頸,導致系統性能下降。客戶/服務模式的架構如圖1所示。

圖1 客戶/服務器模式架構
自治模式是指系統中沒有服務控制端,每個系統都獨立運行,但需要彼此交互抓取任務列表。自治模式根據通信方式可以分為全連接模式和環形模式,如圖2所示。全連接模式指所用采集端都可以相互發送信息,每個采集端都維護著一張全局任務表。環形模型是指采集端在邏輯上構成一個環網,數據在環上按照某種方向單向傳輸,每個客戶端的任務地址列表中只保存其前驅和后繼的信息。自治模式的缺點會增加網絡間的通信信息,網絡帶寬和數據延遲成為瓶頸。
為了彌補客戶/服務器模式在采集網頁數據增多時,服務器控制端性能下降的問題;以及在自治模式下增加網絡間信息傳遞的數量,導致數據延遲的缺陷。我們在主題采集系統中設計了負載平衡下的多節點服務器控制模式,如圖3所示。
負載平衡下的多節點服務器控制模式架構分為四層。分別是執行層、服務層、面向消息的中間層和持久層。
(1)執行層:主要工作是在收到服務器層下達的采集任務后,負責完成采集網頁操作,并與服務器交互采集任務的地址信息和數據信息。

圖3 負載平衡下的多服務器控制模式
(2)服務層:為執行層提供采集任務,分析執行層采集到的數據,進行主題判斷,并在負載均衡服務器的控制下形成新的任務列表。服務層包括采集服務器和負載均衡服務器。負載均衡服務器的目的是實現采集服務器的均衡調度。
(3)面向消息的中間件層:負責服務器間消息傳遞,達到數據同步的目的。服務層各個服務器間的數據共享主要采用基于 “發布者/訂閱者”模型的消息總線來實現。各個服務器之間需要共享的信息主要是去重后的HTML文檔信息和鏈接信息,為保證在每一個服務器上請求過的目標鏈接不會出現在其它服務器的連接緩沖池 (LinkPool)數據中,各服務器定時向其它爬行服務器發送一次各自的去重后HTML文檔和鏈接信息。本服務器架構通過增加一臺JMS服務器來實現消息總線。
(4)持久層:將采集到的數據進行保存,為后續工作服務。為提高系統的可擴展性,使用接口實現,用戶可以根據需要,通過定義不同的目標存儲,將數據存入數據庫或HDFS文件。
執行層采用多線程實現,包括一個任務線程和多個采集線程。任務線程負責向爬行服務器請求目標鏈接資源;采集線程負責從爬行客戶端的鏈接池中取出目標鏈接,發起HTTP請求,獲取主題網頁,并向爬行服務器返回網頁文檔。在獲得目標文檔后,統一轉換成UTF-8編碼,實現與爬行客戶端的編碼統一。工作流程如圖4所示。
工作流程描述:
(1)執行層客戶端程序啟動后,任務線程向負載均衡服務器請求爬行服務器IP;
(2)根據爬行服務器IP,向爬行服務器發送HTTP請求,請求目標鏈接資源;
(3)將請求得到的目標鏈接資源,按照目標鏈接的權值大小作為優先級順序插入到爬行客戶端的鏈接緩沖池(LinkPool)中;
(4)多個采集線程并發的從鏈接緩沖池中取出目標鏈接;
(5)向目標鏈接發送HTTP請求,獲取對應的HTML文檔 (目標文檔);
(6)向采集服務器返回得到的目標文檔。

圖4 執行層工作流程
采集服務器的核心工作線程有5個,分別是Crawler-Master、HtmlPusher、HtmlAnalyser、LinkPusher和 Distributer。LinkPool用來保存等待處理的HTML文檔對象緩沖池;HtmlMessageQueue和LinkMessageQueue,用于保存等待發送到消息總線上的去重信息。
CrawlerMaster線程負責響應爬行客戶端的爬行數據請求。
HtmlPusher線程負責定時的從HTML數據庫中提取出等待處理的HTML文檔,并推入到HtmlPool中。
HtmlAnalyser線程負責從HTML文檔對象緩沖池(HtmlPool)中提取等待處理的HTML文檔,執行具體的過濾、分析操作。
LinkPusher線程負責定時的從URL數據庫中提取出等待執行的目標鏈接資源,并推入到LinkPool中。
工作流程如圖5所示,具體描述:
(1)將采集種子加入鏈接緩沖池,爬行服務器開始工作;
(2)CrawlerMaster從LinkPool中提取目標鏈接資源,等待采集客戶端的采集數據請求。將任務隊列發送給請求;將執行層客戶端采集的HTML文檔進行去重處理;將去重處理后的 HTML 文檔對象,則添加到HtmlMessageQueue中;

圖5 服務器工作流程
(3)將不重復的HTML文檔存儲到數據庫 (HTML數據庫);
(4)HtmlPusher定時的從HTML數據庫中提取等待進行分析過濾的HTML文檔,將HTML文檔對象推入到HtmlPool中;
(5)HtmlAnalyser發現HtmlPool中有新的HTML文檔對象加入時,將其取出進行鏈接分析,提取HTML中的鏈接,并將重復的鏈接去除,按照采集策略計算每個新鏈接的權值;將經過分析處理的連接對象添加到LinkMessageQueue中;
(6)將不重復的鏈接存儲到數據庫 (URL數據庫);
(7)LinkPusher定時從URL數據庫中提取出等待執行的目標鏈接資源,推入到LinkPool中;
(8)Distributer定時將 HtmlMessageQueue和LinkMessageQueue中的消息通過面向消息的中間件總線發送給其它服務器。
負載均衡服務器實際上就是一個調度中心,主要工作是將任務派給負載最輕的采集服務器,并通知執行客戶端工作。它保存著各個采集服務器的負載信息 (Workload),元素中存儲著采集服務器的IP和在消息總線上發送的消息數量。并且用戶可以通過實現接口自行定義負載均衡服務器的調度策略。目前采用了最簡單的策略,任務最少的優先提供服務。
負載均衡服務器工作流程描述:
(1)消息發布線程在消息總線上獲取各個爬行服務器發送的去重信息;并在Workload中查找發送消息的服務器IP,若不存在,則為Workload添加新元素,IP為發送消息的爬行服務器IP,初始發送消息數目為1;若存在,則將該元素的發送消息數目加1;
(2)負載均衡服務器每隔規定的時間,將Workload中所有元素的發送消息數重置為0,以實現各采集服務器的負載統計;
(3)負載均衡服務器從Workload中選擇出發送消息數目最小的元素,將得到的IP(節點服務器地址)返回給執行客戶端。
實驗分別采用單服務器架構和多服務器架構進行,仿真實驗環境采用PC機做服務器,服務器與客戶端采用Hub相連,內網帶寬為100M,外網帶寬為2M。具體配置見表1。單節點服務器架構實驗采用服務器1臺 (PC模式),采集客戶端2臺 (PC機1臺,平板電腦1臺)。多節點服務器架構實驗采用服務器2臺 (PC機模擬服務器),采集客戶端4臺 (PC機3臺,平板電腦1臺)。

表1 仿真實驗環境配置
對采集系統進行配置,采集主題設置為 “蒙古文”,采集策略使用啟發式策略進行設計。分別采用架構性能與主題采集策略指標體系對實驗結果進行評價。架構性能評價指標包括:解析鏈接總數、采集網頁數和采集速度。主題采集策略評價指標包括:目標網頁個數、采集目標網頁速度、準確率和目標網頁空間。
采集速度:表示單位時間里系統采集網頁的個數,用于衡量系統的采集性能

式中:Ci——第i臺服務器采集的網頁數;T——采集的時間。
平均采集速度:表示每臺機器的采集速度,用于衡量采集效率

其中:M——系統中機器的總臺數。
準確率:表示已采集的指定主題網頁數量占網頁總數的比例,用于衡量主題識別性能。

其中:Zi——第i臺服務器采集到的目標網頁數。
系統運行3小時的實驗結果,架構性能見表2。多節點服務器架構從采集速度和目標網頁的采集速度上都優于單點服務器架構。主題采集性能見表3。通過實驗結果可以看出,在主題采集準確率上分布式結構服務器系統略有下降,主要原因是在分布式情況下采集鏈接出現了重復采集的情況。

表2 架構性能實驗結果

表3 主題采集性能
通過對網絡信息采集系統的體系結構分析,設計了基于局域網的分布式主題采集系統的體系結構。實驗結果表明,基于多節點服務器架構的主題采集系統在采集速度和平均采集速度明顯優于單節點服務器體系結構。
進一步研究的目標是開展負載均衡服務器端調度策略的研究;開展服務器間消息協議的研究,減少服務器間信息的交互量,進一步提升平均采集速度和主題采集準確率等。
[1]Yakushev A V,Boukhanovsky A V,Sloot P M A.Topic crawler for social networks monitoring [M].Springer Berlin Heidelberg,2013:214-227.
[2]Jeffrey Dean,Sanjay Ghemawat.MapReduce:Simplified data processing on large clusters [J].Communication of the ACM,2008,5 (1):107-113.
[3]Denis Shestakov.Current challenges in web crawling [G].LNCS 7977:13th International Conference Web Engineering,2013:518-521.
[4]Faheem M,MinesTelecom I,ParisTech T.Intelligent and adaptive crawling of web applications for web archiving [C]//13th International Conference Web Engineering,2013:306-322.
[5]Banerjee S,Das A,Mazumder A,et al.On the impact of coding parameters on storage requirement of region-based fault tolerant distributed file system design [C]//International Conference on Computing,Networking and Communications.IEEE,2014:78-82.
[6]Patel P,Hasan M,Tanawala B.Distributed high performance web crawler [J].International Journal of Innovative Technology and Research,2013,1 (3):236-239.
[7]Jain N,Mangal M P.An approach to build a web crawler using clustering based K-means algorithm [J].Journal of Global Research in Computer Science,2014,4 (12):14-22.
[8]ZHOU Demao,LI Zhoujun.Survey of high-performance web crawler[J].Computer Science,2009,36 (8):26-30 (in Chinese). [周德懋,李舟軍.高性能網絡爬蟲:研究綜述[J].計算機科學,2009,36 (8):26-30.]
[9]LI Yuejian,ZHU Chengrong.Study and improvement on system architectures of Larbin web crawler [J].Computer Technology and Development,2012,22 (7):147-151 (in Chinese). [李躍健,朱程榮.基于Larbin的網絡爬蟲體系結構的研究與改進 [J].計算機技術與發展,2012,22 (7):147-151.]
[10]ZHANG Weizhe,ZHANG Hongli,FANG Binxing,et al.WAN-based distributed Web crawling [J].Journal of Software,2010,21 (5):1067-1082 (in Chinese). [張偉哲,張宏莉,方濱興.廣域網分布式 Web爬蟲 [J].軟件學報,2010,21 (5):1067-1082.]
[11]YANG Dingzhong,ZHAO Gang,WANG Tai.Application of Web crawler in information search and data mining [J].Computer Engineering and Design,2009,30 (24):5658-5661(in Chinese).[楊定中,趙剛,王泰.網絡爬蟲在 Web信息搜索和數據挖掘中應用 [J].計算機工程與設計,2009,30 (24):5658-5661.]