更新時(shí)間:2020-12-11 來源:黑馬程序員 瀏覽量:
三種分布式爬蟲策略:
(1)Slaver端從Master端拿任務(wù)(Request/url/ID)進(jìn)行數(shù)據(jù)抓取,在抓取數(shù)據(jù)的同時(shí)也生成新任務(wù),并將任務(wù)分配給Master端。Master端只有一個(gè)Redis數(shù)據(jù)庫,負(fù)責(zé)對Slaver提交的任務(wù)進(jìn)行去重、加入待爬隊(duì)列。
優(yōu)點(diǎn)
scrapy-redis默認(rèn)使用的就是這種策略,我們實(shí)現(xiàn)起來很簡單,因?yàn)槿蝿?wù)調(diào)度等工作scrapy-redis都已經(jīng)幫我們做好了,我們只需要繼承RedisSpider、指定redis_key即可。
缺點(diǎn)
scrapy-redis調(diào)度的任務(wù)是Request對象,里面信息量比較大(不僅包含URL,還有callback函數(shù)、headers等信息),會降低爬蟲速度,而且會占用Redis大量的存儲空間。當(dāng)然,我們可以重寫方法實(shí)現(xiàn)調(diào)度URL或者用戶ID。
(2)Master端跑一個(gè)程序去生成任務(wù)(Request/url/ID)。Master端負(fù)責(zé)的是生產(chǎn)任務(wù),并把任務(wù)去重,加入到待爬隊(duì)列中。Slaver端只負(fù)責(zé)從Master端獲取任務(wù)進(jìn)行爬取。
優(yōu)點(diǎn)
將生成任務(wù)和抓取數(shù)據(jù)分開,分工明確,減少了Master和Slaver端之間的數(shù)據(jù)交流;Master端生成任務(wù)還有一個(gè)好處,那就是可以便捷地重寫判重策略(當(dāng)數(shù)據(jù)量大時(shí)優(yōu)化判重的性能和速度還是很重要的)。
缺點(diǎn)
像QQ或者新浪微博這種網(wǎng)站,發(fā)送一個(gè)請求,返回的內(nèi)容里面可能包含幾十個(gè)待爬的用戶ID,即幾十個(gè)新爬蟲任務(wù)。但有些網(wǎng)站一個(gè)請求只能得到一兩個(gè)新任務(wù),并且返回的內(nèi)容里也包含爬蟲要抓取的目標(biāo)信息,如果將生成任務(wù)和抓取任務(wù)分開反而會降低爬蟲抓取效率,畢竟帶寬也是爬蟲的一個(gè)瓶頸問題。我們要秉著發(fā)送盡量少的請求為原則,同時(shí)也是為了減輕網(wǎng)站服務(wù)器的壓力,要做一只有道德的Crawler。所以,視情況而定。
(3)Master中只有一個(gè)集合,它只有查詢的作用。Slaver在遇到新任務(wù)時(shí)詢問Master此任務(wù)是否已爬,如果未爬則加入Slaver自己的待爬隊(duì)列中,Master把此任務(wù)記為已爬。它和策略一比較像,但明顯比策略一簡單。策略一的簡單是因?yàn)橛蠸crapy-redis實(shí)現(xiàn)了scheduler中間件,它并不適用于非Scrapy框架的爬蟲。
優(yōu)點(diǎn)
實(shí)現(xiàn)簡單,非Scrapy框架的爬蟲也適用。Master端壓力比較小,Master與Slaver的數(shù)據(jù)交流也不大。
缺點(diǎn)
“健壯性”不夠,需要另外定時(shí)保存待爬隊(duì)列以實(shí)現(xiàn)“斷點(diǎn)續(xù)爬”功能。各Slaver的待爬任務(wù)不通用。
如果把Slaver比作工人,把Master比作工頭。策略一就是工人遇到新任務(wù)都上報(bào)給工頭,需要干活的時(shí)候就去工頭那里領(lǐng)任務(wù);策略二就是工頭去找新任務(wù),工人只管從工頭那里領(lǐng)任務(wù)干活;策略三就是工人遇到新任務(wù)時(shí)詢問工頭此任務(wù)是否有人做了,沒有的話工人就將此任務(wù)加到自己的“行程表”。
猜你喜歡: