前言：
爬蟲是偏IO型的任務，分布式爬蟲的實現難度比分布式計算和分布式存儲簡單得多。
個人以為分布式爬蟲須要考慮的點主要有下面幾個：
- 爬蟲任務的統一調度
- 爬蟲任務的統一去重
- 存儲問題
- 速度問題
- 足夠“健壯”的情況下實現起來越簡單/方便越好
- 最好支持“斷點續爬”功能
Python分布式爬蟲比較經常使用的應該是scrapy框架加上Redis內存數據庫，中間的調度任務等用scrapy-redis模塊實現。
此處簡介一下基於Redis的三種分布式策略，事實上它們之間還是非常類似的。僅僅是為適應不同的網絡或爬蟲環境作了一些調整而已（如有錯誤歡迎留言拍磚）。
【策略一】
Slaver端從Master端拿任務（Request/url/ID）進行數據抓取。在抓取數據的同一時候也生成新任務。並將任務拋給Master。Master端僅僅有一個Redis數據庫，負責對Slaver提交的任務進行去重、增加待爬隊列。
長處： scrapy-redis默認使用的就是這樣的策略，我們實現起來非常easy。由於任務調度等工作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。即幾十個新爬蟲任務。但有些站點一個請求僅僅能得到一兩個新任務，並且返回的內容里也包括爬蟲要抓取的目標信息。假設將生成任務和抓取任務分開反而會減少爬蟲抓取效率。
畢竟帶寬也是爬蟲的一個瓶頸問題，我們要秉着發送盡量少的請求為原則，同一時候也是為了減輕站點server的壓力，要做一僅僅有道德的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）