三種分布式爬蟲策略：
（1）Slaver端從Master端拿任務(wù)(Request/url/ID)進行數(shù)據(jù)抓取，在抓取數(shù)據(jù)的同時也生成新任務(wù)，并將任務(wù)分配給Master端。
Master端只有一個Redis數(shù)據(jù)庫，負(fù)責(zé)對Slaver提交的任務(wù)進行去重、加入待爬隊列。
優(yōu)點
scrapy-redis默認(rèn)使用的就是這種策略，我們實現(xiàn)起來很簡單，因為任務(wù)調(diào)度等工作scrapy-redis都已經(jīng)幫我們做好了，我們只需要繼承RedisSpider、指定redis_key即可。
缺點
scrapy-redis調(diào)度的任務(wù)是Request對象，里面信息量比較大(不僅包含URL，還有callback函數(shù)、headers等信息)，會降低爬蟲速度，而且會占用Redis大量的存儲空間。當(dāng)然，我們可以重寫方法實現(xiàn)調(diào)度URL或者用戶ID。
（2）Master端跑一個程序去生成任務(wù)(Request/url/ID)。
Master端負(fù)責(zé)的是生產(chǎn)任務(wù)，并把任務(wù)去重，加入到待爬隊列中。Slaver端只負(fù)責(zé)從Master端獲取任務(wù)進行爬取。
優(yōu)點
將生成任務(wù)和抓取數(shù)據(jù)分開，分工明確，減少了Master和Slaver端之間的數(shù)據(jù)交流;Master端生成任務(wù)還有一個好處，那就是可以便捷地重寫判重策略(當(dāng)數(shù)據(jù)量大時優(yōu)化判重的性能和速度還是很重要的)。
缺點
像QQ或者新浪微博這種網(wǎng)站，發(fā)送一個請求，返回的內(nèi)容里面可能包含幾十個待爬的用戶ID，即幾十個新爬蟲任務(wù)。但有些網(wǎng)站一個請求只能得到一兩個新任務(wù)，并且返回的內(nèi)容里也包含爬蟲要抓取的目標(biāo)信息，如果將生成任務(wù)和抓取任務(wù)分開反而會降低爬蟲抓取效率，畢竟帶寬也是爬蟲的一個瓶頸問題。我們要秉著發(fā)送盡量少的請求為原則，同時也是為了減輕網(wǎng)站服務(wù)器的壓力，要做一只有道德的Crawler。所以，視情況而定。
（3）Master中只有一個集合，它只有查詢的作用。Slaver在遇到新任務(wù)時詢問Master此任務(wù)是否已爬，如果未爬則加入Slaver自己的待爬隊列中，Master把此任務(wù)記為已爬。它和策略一比較像，但明顯比策略一簡單。策略一的簡單是因為有Scrapy-redis實現(xiàn)了scheduler中間件，它并不適用于非Scrapy框架的爬蟲。
優(yōu)點
實現(xiàn)簡單，非Scrapy框架的爬蟲也適用。Master端壓力比較小，Master與Slaver的數(shù)據(jù)交流也不大。
缺點
“健壯性”不夠，需要另外定時保存待爬隊列以實現(xiàn)“斷點續(xù)爬”功能。各Slaver的待爬任務(wù)不通用。
如果把Slaver比作工人，把Master比作工頭。
策略一就是工人遇到新任務(wù)都上報給工頭，需要干活的時候就去工頭那里領(lǐng)任務(wù);
策略二就是工頭去找新任務(wù)，工人只管從工頭那里領(lǐng)任務(wù)干活;
策略三就是工人遇到新任務(wù)時詢問工頭此任務(wù)是否有人做了，沒有的話工人就將此任務(wù)加到自己的“行程表”。
