基于集群的分布式爬蟲(chóng)系統(tǒng)的架構(gòu)研究

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

關(guān)鍵詞：主題爬蟲(chóng);架構(gòu);Scrapy

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

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

1? 主從式架構(gòu)

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

因此，主從分布式結(jié)構(gòu)性能效率的提升關(guān)鍵在于主節(jié)點(diǎn)的URL服務(wù)器。主從分布式拓?fù)涫疽鈭D如1-1所示。

2? 對(duì)等式架構(gòu)

在對(duì)等式架構(gòu)中，各個(gè)節(jié)點(diǎn)之間不存在所謂的主從之分。每個(gè)節(jié)點(diǎn)都會(huì)有爬蟲(chóng)任務(wù)運(yùn)行，各個(gè)節(jié)點(diǎn)各自維護(hù)自己的待爬取URL隊(duì)列。因此這就存在數(shù)據(jù)

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

3? 主從混合模式

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

4 Scrapy-Redis框架

Scrapy 是一款基于Python開(kāi)發(fā)的開(kāi)源web爬蟲(chóng)框架，可快速抓取Web站點(diǎn)并提取頁(yè)面中的結(jié)構(gòu)化數(shù)據(jù)，具有高度的擴(kuò)展性和魯棒性。但是在面對(duì)大量的網(wǎng)頁(yè)數(shù)據(jù)需要處理時(shí)，單主機(jī)的爬蟲(chóng)程序效率低下的缺點(diǎn)就顯得尤為突出，遠(yuǎn)遠(yuǎn)不能滿(mǎn)足項(xiàng)目的要求了，此時(shí)就必須使用分布式爬蟲(chóng)了。然而單獨(dú)的原始Scrapy

框架并不支持分布式，因此在Scrapy的框架基礎(chǔ)上衍生出了Scrapy-Redis分布式爬蟲(chóng)框架。它利用Redis

調(diào)度和存儲(chǔ)需要爬取的請(qǐng)求，并存儲(chǔ)爬取產(chǎn)生的項(xiàng)目以供后續(xù)處理使用。Scrapy-Redis重寫(xiě)了Scrapy一些比較關(guān)鍵的模塊，使Scrapy支持了分布式架構(gòu)。

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

參考文獻(xiàn)：

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

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

作者簡(jiǎn)介：

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

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