爬蟲架構理解
爬蟲是偏IO型的任務,分散式爬蟲的實現難度比分散式計算和分散式儲存簡單得多。
個人以為分散式爬蟲需要考慮的點主要有以下幾個:
- 爬蟲任務的統一排程
- 爬蟲任務的統一去重
- 儲存問題
- 速度問題
- 足夠“健壯”的情況下實現起來越簡單/方便越好
- 最好支援“斷點續爬”功能
Python分散式爬蟲比較常用的應該是scrapy框架加上Redis記憶體資料庫,中間的排程任務等用scrapy-redis模組實現。
此處簡單介紹一下基於Redis的三種分散式策略,其實它們之間還是很相似的,只是為適應不同的網路或爬蟲環境作了一些調整而已(如有錯誤歡迎留言拍磚)。
【策略一】 
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。
【策略二】 
這是對策略的一種優化改進:在Master端跑一個程式去生成任務(Request/url/ID)。Master端負責的是生產任務,並把任務去重、加入到待爬佇列。Slaver只管從Master端拿任務去爬。
優點: 將生成任務和抓取資料分開,分工明確,減少了Master和Slaver之間的資料交流;Master端生成任務還有一個好處就是:可以很方便地重寫判重策略(當資料量大時優化判重的效能和速度還是很重要的)。
缺點: 像QQ或者新浪微博這種網站,傳送一個請求,返回的內容裡面可能包含幾十個待爬的使用者ID,即幾十個新爬蟲任務。但有些網站一個請求只能得到一兩個新任務,並且返回的內容裡也包含爬蟲要抓取的目標資訊,如果將生成任務和抓取任務分開反而會降低爬蟲抓取效率。畢竟頻寬也是爬蟲的一個瓶頸問題,我們要秉著傳送儘量少的請求為原則,同時也是為了減輕網站伺服器的壓力,要做一隻有道德的Crawler。所以,視情況而定。
【策略三】 
Master中只有一個集合,它只有查詢的作用。Slaver在遇到新任務時詢問Master此任務是否已爬,如果未爬則加入Slaver自己的待爬佇列中,Master把此任務記為已爬。它和策略一比較像,但明顯比策略一簡單。策略一的簡單是因為有scrapy-redis實現了scheduler中介軟體,它並不適用於非scrapy框架的爬蟲。
優點: 實現簡單,非scrapy框架的爬蟲也適用。Master端壓力比較小,Master與Slaver的資料交流也不大。
缺點: “健壯性”不夠,需要另外定時儲存待爬佇列以實現“斷點續爬”功能。各Slaver的待爬任務不通用。
結語:如果把Slaver比作工人,把Master比作工頭。策略一就是工人遇到新任務都上報給工頭,需要幹活的時候就去工頭那裡領任務;策略二就是工頭去找新任務,工人只管從工頭那裡領任務幹活;策略三就是工人遇到新任務時詢問工頭此任務是否有人做了,沒有的話工人就將此任務加到自己的“行程表”。