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