基於Redis的三種分布式爬蟲策略

前言：

爬蟲是偏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比作工頭。策略一就是工人遇到新任務都上報給工頭，需要幹活的時候就去工頭那裡領任務；策略二就是工頭去找新任務，工人只管從工頭那裡領任務幹活；策略三就是工人遇到新任務時詢問工頭此任務是否有人做了，沒有的話工人就將此任務加到自己的“行程表”。

轉載請註明出處，謝謝。（原文連結：http://blog.csdn.net/bone_ace/article/details/50989104）