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