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