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