如今的世界正處于互聯(lián)網(wǎng)信息飛速增長的時代,常見的搜索渠道如百度等搜索引擎只能給我們提供一些雜亂無章的淺顯信息,僅根據(jù)相關(guān)度等因子顯示而未經(jīng)過算法針對性的篩選。網(wǎng)絡(luò)爬蟲是網(wǎng)頁信息抓取的一種常用手段,但常見的單機(jī)網(wǎng)絡(luò)爬蟲系統(tǒng)效率較低,雖然后續(xù)改進(jìn)的利用VM做分布式系統(tǒng)的效率有所提升,但是離用戶真正所期待的速度還有很大的差距。傳統(tǒng)的爬蟲系統(tǒng)對于URL去重和頁面內(nèi)容去重等功能需求不夠友好,一些簡易爬蟲系統(tǒng)還會經(jīng)常被網(wǎng)站的反爬蟲系統(tǒng)限制。為了有針對性地快速獲取有效信息,本文設(shè)計了一個基于Docker容器集群的分布式網(wǎng)絡(luò)爬蟲系統(tǒng)。此系統(tǒng)基于Scrapy-Redis框架,利用Redis存儲爬取解析到的URL,利用MongoDB存儲爬取解析到的網(wǎng)頁內(nèi)容,采用主從混合分布式系統(tǒng)部署。經(jīng)實驗證明,此系統(tǒng)能夠有效地爬取用戶需要的信息且速度較分布式VM系統(tǒng)有很大提升。本文所做的工作及創(chuàng)新點如下:（1）深入研究了BloomFilter去重算法,在原算法的基礎(chǔ)上加以創(chuàng)新,提出了二階段BloomFilter去重方案,使其具備更低的誤判率。（2）改進(jìn)了通用的爬蟲框架,使其更好地支持分布式系統(tǒng)。增加了頁面內(nèi)容查重模塊,... 

【文章來源】：武漢郵電科學(xué)研究院湖北省

【文章頁數(shù)】：69 頁

【學(xué)位級別】：碩士

【部分圖文】：

Docker總架構(gòu)

武漢郵電科學(xué)研究院碩士學(xué)位論文13考慮整個系統(tǒng)的負(fù)載均衡的問題。不能讓某個從節(jié)點壓力過大，也不能讓某個從節(jié)點一直空閑。主節(jié)點需要根據(jù)從節(jié)點反饋的任務(wù)執(zhí)行情況來增減某一個從節(jié)點的負(fù)載壓力，以發(fā)揮整個系統(tǒng)最大的效率。在各個從節(jié)點之間一般沒有通信鏈路，各個從節(jié)點只會和主節(jié)點相互聯(lián)系。因為后期URL的數(shù)量巨大，所以主節(jié)點的URL服務(wù)器對待爬取隊列的維護(hù)和URL的分發(fā)將會承受極大壓力。因此，主從分布式結(jié)構(gòu)性能效率的提升關(guān)鍵在于主節(jié)點的URL服務(wù)器。主從分布式拓?fù)涫疽鈭D如2-2所示。圖2-2主從分布式2.2.2對等式架構(gòu)在對等式架構(gòu)中，各個節(jié)點之間不存在所謂的主從之分。每個節(jié)點都會有爬蟲任務(wù)運行，各個節(jié)點各自維護(hù)自己的待爬取URL隊列。因此這就存在數(shù)據(jù)同步的問題，多個節(jié)點可能會對同一網(wǎng)頁多次爬取，這會大大的浪費節(jié)點的資源。既然各個節(jié)點不能各自為政，那么如何分工協(xié)作就是一個問題了。常見的有以下兩種解決方式：哈希取模和一致性哈希。哈希取模是在爬取之前各節(jié)點會計算網(wǎng)站域名的哈希值，然后對節(jié)點個數(shù)取模，取模的結(jié)果就代表了該域名下應(yīng)由哪個節(jié)點進(jìn)行爬齲但該方法存在一些弊端，若有一個節(jié)點宕機(jī)了，取模數(shù)就會發(fā)生變化，以致于最終結(jié)果就會發(fā)生混亂。另外，不同網(wǎng)站的網(wǎng)頁數(shù)據(jù)量也不一樣，不同的節(jié)點爬取不同域名下的網(wǎng)站，這也可能會存在負(fù)載均衡的問題。一致性哈希算法直接將網(wǎng)站主域名進(jìn)行哈希映射，結(jié)果范圍是0-2^32之間的某個數(shù)。將該范圍首尾相連成環(huán)，每個服務(wù)器就負(fù)責(zé)其中的一小段，如果某一個節(jié)點服務(wù)器宕機(jī)，就將該服務(wù)器的任務(wù)順延至下一個節(jié)點服務(wù)器。對等式架構(gòu)不存在獨立的URL服務(wù)器，因此不會存在性能瓶頸的問題，但是整個InternetURL抓取服務(wù)器URL服務(wù)器抓取服務(wù)器抓取服務(wù)器URL

武漢郵電科學(xué)研究院碩士學(xué)位論文23（5）將該指紋對象與Redis中的set的指紋數(shù)據(jù)進(jìn)行比對，若不重復(fù)，則存儲Redis中的request隊列中。（6）scheduler從Redis中的request隊列中獲取request，傳給Scrapyengine。（7）Scrapyengine將request經(jīng)過下載器中間件downloadmiddleware傳至下載器downloader下載。（8）下載器downloader將下載的response對象返回給Scrapyengine。（9）Scrapyengine將response傳給Spider。（10）然后再從第一步開始循環(huán)。詳細(xì)框架及運行過程如圖3-1所示。圖3-1Scrapy-Redis架構(gòu)圖3.1.4分布式爬蟲架構(gòu)分布式爬蟲系統(tǒng)采用主從結(jié)構(gòu)，設(shè)置一個Master端和多個Slave端，Master端部署Redis數(shù)據(jù)庫以存儲和被調(diào)度待爬取請求，Slave端部署爬蟲主程序爬取網(wǎng)頁和解析提取數(shù)據(jù)，然后各個Slave端將解析的網(wǎng)頁數(shù)據(jù)存儲在同一個MongoDB數(shù)據(jù)庫中。分布式爬蟲架構(gòu)如圖3-2所示。

【參考文獻(xiàn)】：
期刊論文
[1]基于Docker容器的Redis高可用實現(xiàn)方案[J]. 王佩劍.  信息通信. 2019(08)
[2]云服務(wù)下的最佳拍檔——容器和微服務(wù)[J]. 金琦,邱元陽,劉宗凡,倪俊杰,楊磊.  中國信息技術(shù)教育. 2019(Z4)
[3]面向網(wǎng)絡(luò)爬蟲的高可用動態(tài)池系統(tǒng)設(shè)計與實現(xiàn)[J]. 王佳鵬,徐海蛟,許培宇,何佳蕾,林冠成.  福建電腦. 2019(06)
[4]基于Python的網(wǎng)絡(luò)爬蟲與反爬蟲技術(shù)研究[J]. 李培.  計算機(jī)與數(shù)字工程. 2019(06)
[5]基于Spring Cloud和Docker的分布式微服務(wù)架構(gòu)設(shè)計[J]. 黃強(qiáng)文,曾丹.  微型電腦應(yīng)用. 2019(06)
[6]Docker技術(shù)在軟件開發(fā)過程中的應(yīng)用研究[J]. 龐宇.  信息技術(shù). 2019(05)
[7]基于Python的新浪微博爬蟲分析[J]. 杜曉旭,賈小云.  軟件. 2019(04)
[8]一種基于Scrapy-Redis的分布式微博數(shù)據(jù)采集方案[J]. 鄧萬宇,劉光達(dá),董瑩瑩.  信息技術(shù). 2018(11)
[9]基于Docker Swarm集群的調(diào)度策略優(yōu)化算法[J]. 劉梅,高岑,田月,王嵩,劉璐.  計算機(jī)系統(tǒng)應(yīng)用. 2018(09)
[10]主動獲取式的分布式網(wǎng)絡(luò)爬蟲集群方法研究[J]. 董禹龍,楊連賀,馬欣.  計算機(jī)科學(xué). 2018(S1)

碩士論文
[1]基于Scrapy框架的分布式爬蟲系統(tǒng)設(shè)計與實現(xiàn)[D]. 汪兵.合肥工業(yè)大學(xué) 2019
[2]基于Kubernetes的調(diào)度方案研究與設(shè)計[D]. 李思達(dá).東南大學(xué) 2018
[3]基于服務(wù)器集群的可伸縮架構(gòu)設(shè)計與實現(xiàn)[D]. 繆海鋒.浙江工業(yè)大學(xué) 2018
[4]基于Hadoop的分布式網(wǎng)絡(luò)爬蟲設(shè)計與實現(xiàn)[D]. 李優(yōu).西北大學(xué) 2018
[5]基于高實時分布式網(wǎng)絡(luò)的爬蟲軟件設(shè)計與實現(xiàn)[D]. 張峰.浙江大學(xué) 2018
[6]面向模型的數(shù)據(jù)質(zhì)量管理系統(tǒng)的設(shè)計與實現(xiàn)[D]. 勾德杰.大連理工大學(xué) 2018
[7]基于Hadoop的分布式網(wǎng)絡(luò)爬蟲研究[D]. 李松.電子科技大學(xué) 2016



本文編號：3586405