轉(zhuǎn)載自csdn（原文鏈接：http://blog.csdn.net/bone_ace/article/details/55000416）
在爬蟲的開發(fā)過程中，有些業(yè)務(wù)場景需要同時抓取幾百個甚至上千個網(wǎng)站，此時就需要一個支持多爬蟲的框架。在設(shè)計時應(yīng)該要注意以下幾點：
代碼復(fù)用，功能模塊化。如果針對每個網(wǎng)站都寫一個完整的爬蟲，那其中必定包含了許多重復(fù)的工作，不僅開發(fā)效率不高，而且到后期整個爬蟲項目會變得臃腫、難以管理。
易擴展。多爬蟲框架，這最直觀的需求就是方便擴展，新增一個待爬的目標(biāo)網(wǎng)站，我只需要寫少量 必要的內(nèi)容（如抓取規(guī)則、解析規(guī)則、入庫規(guī)則），這樣最快 最好。
健壯性、可維護性。這么多網(wǎng)站同時抓取，報錯的概率更大，例如斷網(wǎng)、中途被防爬、爬到“臟數(shù)據(jù)”等等。所以必須要做好日志監(jiān)控，能實時監(jiān)控爬蟲系統(tǒng)的狀態(tài)，能準(zhǔn)確、詳細地定位報錯信息；另外要做好各種異常處理，如果你放假回來發(fā)現(xiàn)爬蟲因為一個小問題已經(jīng)掛掉了，那你會因為浪費了幾天時間而可惜的（雖然事實上我個人會不時地遠程查看爬蟲狀態(tài)）。
分布式。多網(wǎng)站抓取，數(shù)據(jù)量一般也比較大，可分布式擴展，這也是必需的功能了。分布式，需要注意做好消息隊列，做好多結(jié)點統(tǒng)一去重。
爬蟲優(yōu)化。這就是大話題了，但最基本的，框架應(yīng)該要基于異步，或者使用協(xié)程+多進程。
架構(gòu)簡明，要方便以后未知功能模塊的添加。
需求如上，說的已經(jīng)很清楚了。下面介紹一種架構(gòu)設(shè)計，是去年做的了，現(xiàn)在分享一下。具體的代碼實現(xiàn)就暫不公開了。
以下將通過解釋兩張圖來說明架構(gòu)的設(shè)計思想。?
框架主要分成兩部分：下載器Downloader和解析器Analyzer。Downloader負責(zé)抓取網(wǎng)頁，Analyzer負責(zé)解析網(wǎng)頁并入庫。兩者之間依靠消息隊列MQ進行通信，兩者可以分布在不同機器，也可分布在同一臺機器。兩者的數(shù)量也是靈活可變的，例如可能有五臺機在做下載、兩臺機在做解析，這都是可以根據(jù)爬蟲系統(tǒng)的狀態(tài)及時調(diào)整的。
從上圖可以看到MQ有兩個管道：HTML/JS文件和待爬種子。Downloader從待爬種子里拿到一條種子，根據(jù)種子信息調(diào)用相應(yīng)的抓取模塊進行網(wǎng)頁抓取，然后存入HTML/JS文件這個通道；Analyzer從HTML/JS文件里拿到一條網(wǎng)頁內(nèi)容，根據(jù)里面的信息調(diào)用相應(yīng)的解析模塊進行解析，將目標(biāo)字段入庫，需要的話還會解析出新的待爬種子加入MQ。
可以看到Downloader是包含User-Agent池、Proxy池、Cookie池的，可以適應(yīng)復(fù)雜網(wǎng)站的抓取。
模塊的調(diào)用使用工廠模式。
這張圖是上張圖的另一種表述。
Htmls隊列和Seed是隊列可以獨立分開，甚至數(shù)量也可以多開，之間沒有聯(lián)系。完全可以靈活地根據(jù)爬蟲狀態(tài)和硬件環(huán)境作調(diào)整。另外8G的內(nèi)容可以讓Redis作為Seeds隊列存放5~8千萬個種子。
分布式爬蟲非常關(guān)鍵的一點：去重?？梢钥吹蕉鄠€解析器Analyzer共用一個去重隊列，才能夠保證數(shù)據(jù)的統(tǒng)一不重復(fù)。去重隊列可以放在一臺機上?；赗edis實現(xiàn)了Bloomfilter算法（詳細見《基于Redis的Bloomfilter去重（附Python代碼）》），理論上8G的內(nèi)存可以滿足30億條URL的去重，如果允許漏失概率再大點的話能去重更多。
要寫一個支持分布式、多爬蟲的框架，具體的實現(xiàn)上還是有一定難度的。在實現(xiàn)主要功能以外，還要注意做到代碼嚴謹 規(guī)范，爬蟲高效 健壯的要求。做完這些以后，你定會成長不少！
