分布式多爬蟲系統——架構設計

前言：

在爬蟲的開發過程中，有些業務場景需要同時抓取幾百個甚至上千個網站，此時就需要一個支持多爬蟲的框架。在設計時應該要注意以下幾點：

1. 代碼復用，功能模塊化。如果針對每個網站都寫一個完整的爬蟲，那其中必定包含了許多重復的工作，不僅開發效率不高，而且到后期整個爬蟲項目會變得臃腫、難以管理。
2. 易擴展。多爬蟲框架，這最直觀的需求就是方便擴展，新增一個待爬的目標網站，我只需要寫少量 必要的內容（如抓取規則、解析規則、入庫規則），這樣最快 最好。
3. 健壯性、可維護性。這么多網站同時抓取，報錯的概率更大，例如斷網、中途被防爬、爬到“臟數據”等等。所以必須要做好日志監控，能實時監控爬蟲系統的狀態，能準確、詳細地定位報錯信息；另外要做好各種異常處理，如果你放假回來發現爬蟲因為一個小問題已經掛掉了，那你會因為浪費了幾天時間而可惜的（雖然事實上我個人會不時地遠程查看爬蟲狀態）。
4. 分布式。多網站抓取，數據量一般也比較大，可分布式擴展，這也是必需的功能了。分布式，需要注意做好消息隊列，做好多結點統一去重。
5. 爬蟲優化。這就是大話題了，但最基本的，框架應該要基于異步，或者使用協程+多進程。
6. 架構簡明，要方便以后未知功能模塊的添加。

需求如上，說的已經很清楚了。下面介紹一種架構設計，是去年做的了，現在分享一下。具體的代碼實現就暫不公開了。

正文：

以下將通過解釋兩張圖來說明架構的設計思想。

1. 框架主要分成兩部分：下載器Downloader和解析器Analyzer。Downloader負責抓取網頁，Analyzer負責解析網頁并入庫。兩者之間依靠消息隊列MQ進行通信，兩者可以分布在不同機器，也可分布在同一臺機器。兩者的數量也是靈活可變的，例如可能有五臺機在做下載、兩臺機在做解析，這都是可以根據爬蟲系統的狀態及時調整的。
2. 從上圖可以看到MQ有兩個管道： HTML/JS文件 和 待爬種子 。 Downloader 從 待爬種子 里拿到一條種子，根據種子信息調用相應的抓取模塊進行網頁抓取，然后存入 HTML/JS文件 這個通道； Analyzer 從 HTML/JS文件 里拿到一條網頁內容，根據里面的信息調用相應的解析模塊進行解析，將目標字段入庫，需要的話還會解析出新的待爬種子加入MQ。
3. 可以看到Downloader是包含User-Agent池、Proxy池、Cookie池的，可以適應復雜網站的抓取。
4. 模塊的調用使用工廠模式。

1. 這張圖是上張圖的另一種表述。
2. Htmls隊列和Seed是隊列可以獨立分開，甚至數量也可以多開，之間沒有聯系。完全可以靈活地根據爬蟲狀態和硬件環境作調整。另外8G的內容可以讓Redis作為Seeds隊列存放5~8千萬個種子。
3. 分布式爬蟲非常關鍵的一點：去重。可以看到多個解析器Analyzer共用一個去重隊列，才能夠保證數據的統一不重復。去重隊列可以放在一臺機上。基于Redis實現了Bloomfilter算法（詳細見 《基于Redis的Bloomfilter去重（附Python代碼）》 ），理論上8G的內存可以滿足30億條URL的去重，如果允許漏失概率再大點的話能去重更多。

結語：

要寫一個支持分布式、多爬蟲的框架，具體的實現上還是有一定難度的。在實現主要功能以外，還要注意做到代碼嚴謹 規范，爬蟲高效 健壯的要求。做完這些以后，你定會成長不少！

來自：http://blog.csdn.net/bone_ace/article/details/55000416