基于Scrapy的網絡爬蟲系統框架設計與實現

王磊, 劉曉丹

(陜西廣播電視大學 信息與智能技術學院， 西安 710119)

0 引言

網絡上的信息隨快速發展的互聯網表現出指數級的增長趨勢，增加了用戶快速獲取所需信息的難度。作為數據獲取工具的一種，搜索引擎中通常會應用到網絡爬蟲，但針對中小規模系統的網絡爬蟲往往面臨較多的問題，在抓取數據速度上單機的網絡爬蟲程序難以有效滿足需求，并且網絡爬蟲框架大都沒有實現分布化，單一的網絡爬蟲程序難以滿足多種類型的網頁結構，簡單穩定的高性能分布式網絡爬蟲系統框架以滿足中小規模系統的需求具有較高的實際應用價值。

1 系統設計目標

Scrapy能夠進行屏幕抓取，且具備web抓取框架、快速、高層次的優勢，提供了多種類型爬蟲的基類(包括BaseSpider、sitemap等)，用途廣泛，用于從web站點頁面中抓取并提取出結構化的數據，可用于數據挖掘、監測和自動化測試，同時用戶可以根據實際需求進行修改。

不同于傳統的通用網絡爬蟲，基于Scrapy的網絡爬蟲系統采集的網頁信息需與用戶需求相關，而無需對互聯網上所有的資源進行采集。針對不同網站所具有的網頁結構不僅相同，為降低資源耗費及開發成本，網絡爬蟲系統的設計需具有足夠的靈活性，從而能夠在不同環境下無需做較大改動即可應用；隨著網頁數量的激增，考慮到單機抓取速度的有限性，需在原有Scrapy框架基礎上進行優化，完成部分組件的重寫以支持分布式抓取，以降低采集時間；分布式網絡爬蟲在中小規模系統中的關鍵在于負載均衡，需確保系統分配任務量時以各爬蟲節點的負荷狀態為依據，使爬蟲的抓取效率得以有效提高；同一時刻需限制發送到遠程服務器的請求以及集群中爬蟲節點對網站的訪問頻率；提高系統錯誤處理的能力，能夠及時處理突發狀況；降低系統操作及配置的難度，爬蟲開始或停止操作簡單，對集群中各爬蟲速度進行實時監控。

2 系統總體設計

系統總體架構如圖1所示，(1)用戶交互層由爬蟲管理和配置兩個子頁面構成，完成同用戶的交互，用戶提交的請求(包括查詢爬蟲任務狀態、站點配置信息更新、查詢模塊狀態及爬蟲抓取4類請求)由配置子頁面接收，為便于后續消息預處理模塊解析每類請求各有其固定的格式；集群中爬蟲的啟動與停止以及對各節點上爬蟲實時的運行狀態的監控由爬蟲管理子頁面實現。

(2)對配置子頁面傳遞請求消息的驗證、解析由處理層完成，為有效的處理大量活躍的流數據以滿足不斷增加的業務需求，系統的中間緩存器使用了Kafka，保證數據流轉的高性能及低延遲，其中配置子頁面請求的周期性獲取以及請求格式正確性的驗證由消息預處理模塊完成，單位時間內該模塊請求成功/失敗數量的記錄則由狀態計數器完成，如果請求的驗證結果為爬蟲抓取請求即存入任務隊列，其余3類請求以相應格式存入到Redi中，Redis是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。多個該模塊同時運行以以確保該模塊宕機對系統正常運行不會造成影響；Redis中傳入的驗證成功請求的周期性檢測由Redis監控模塊完成，然后通過相應插件的調用完成該請求的處理解析，將結果傳送到kafka消息系統中，同樣使用多個Redis監控模塊對請求進行檢測處理，從而提高系統的可靠性及請求響應速度[1]。

圖1 系統總體架構

(3)系統的關鍵在于業務邏輯層，其構成為主節點一個及從節點若干個，物理結構如圖2所示。

圖2 物理結構圖

各爬蟲節點的任務調度交通過此種結構由主節點負責統一執行，降低了任務調度的難度，以爬蟲節點實時運行狀態為依據完成最優調度決策的制定。主節點中的爬蟲任務隊列分為總爬蟲和節點兩種，爬蟲抓取請求(由配置子頁面中傳入)及新的爬蟲抓取任務(由后續爬蟲節點在網頁中抽取)存放于總爬蟲任務隊列中；各爬蟲節點待抓取的爬蟲任務存放于節點爬蟲任務隊列中，待抓取爬蟲任務的存放選用內存型數據庫Redis，以確?？焖佾@取與提交爬蟲任務。

該層中爬蟲任務由總爬蟲任務隊列到各節點隊列中的分發由任務調度器完成，以爬蟲節點實時狀態為依據任務調度器采用動態反饋任務調度策略分發爬蟲抓取任務，以確保集群中各爬蟲節點負載均衡；集群中爬蟲節點對某個網站的訪問頻率(在固定時間段內)的控制由限速器完成，避免被網站屏蔽以實現數據的抓取，降低遠程服務器的壓力；為使整體的抓取效率提高，需通過過濾器模塊避免重復抓取相同的URL，海量URL去重通過布隆過濾器算法實現[2]。

爬蟲節點啟動、采集及存儲數據的任務由從節點完成，其中爬蟲管理器分布放置在各個從節點中，從而有效降低管理器的負載，爬蟲的啟動或停止及對節點中各爬蟲運行狀態的監控由其完成；數據采集則由Scrapy爬蟲負責完成，該模塊主要由5個子模塊構成：由調度器子模塊完成爬蟲抓取任務的周期性獲取，將任務以規定的格式進行處理后(即封裝成Request請求)交給中間件，按照既定格式將從數據采集子模塊接收到的URL完成新的爬蟲抓取任務的封裝并提交給總爬蟲任務隊列(主節點)；為確保抓取過程中的穩定性，Request請求中IP地址的動態改變由中間件子模塊完成，從而能夠應對網站的反爬蟲策略；向目標網頁發起訪問及對應網頁內容的下載由下載器子模塊負責完成，然后將下載內容傳輸至數據采集子模塊完成相應網頁數據及URL鏈接的提取(需以用戶自定義的抽取規則為依據)，接下來數據管道子模塊會對網頁數據(主要包括網頁正文提取、編碼轉換、數據清理等操作)進行處理，調度器對需跟進的URL鏈接進行處理；存放最終抓取數據則通過MongoDB集群實現，集群模式能夠滿足業務增長數據量突增的需求。

3 系統框架的實現

系統整體運行數據流圖如圖3所示。

圖3 系統運行數據流圖

(1)用戶先提交待抓取的URL及相關信息并啟動相應的爬蟲，后臺接收到爬蟲抓取請求后即時將其存入Kafka中，當新的抓取請求被消息預處理模塊檢測到后，在總爬蟲任務隊列中存入將符合系統定義格式的請求，將不符合的請求記錄到失敗日志中。

(2)任務調度器對總爬蟲任務隊列采用動態反饋任務調度策略(依據運行中各爬蟲節點負荷狀態)分發爬蟲抓取任務，當有新的爬蟲抓取任務被爬蟲節點的調度器檢測到后，集群中的爬蟲節點的訪問頻率需先由限速器進行判斷，超過系統設定頻率則獲取其它爬蟲抓取任務，從隊列中取出未超過設定頻率的爬蟲抓取任務并將其封裝成Request請求(需按照Soapy規定的格式)后傳給中間件，中間件子模塊會在Request請求中裝載隨機取出的一條高匿IP后傳給下載器，下載器據此向目標網頁發起訪問并對網頁進行下載，數據采集子模塊完成所需網頁數據及URL鏈接(后續待跟進)的提取，數據采集子模塊將URL鏈接提交給調度器，調度器通過過濾器對當前URL鏈接進行判斷，丟棄己經抓取過的，對判斷結果為未抓取過的URL鏈接進行封裝(需按照系統定義的格式)，使其成為新的爬蟲抓取任務，然后提交給總爬蟲任務隊列。

(3)最后將采集到的網頁數據通過數據管道子模塊進行相應處理后(主要包括編碼轉換、正文提取及數據清理)存入MongoDB集群[3]。

4 數據庫設計

爬蟲系統內部使用了MongoDB(存儲爬蟲最終抓取的數據)及Redis(存儲爬蟲抓取請求)兩類數據庫，整個系統的正常運行離不開MongoDB或Redis數據庫的性能及可靠性，因此本文使用集群完成數據庫的搭建。

4.1 MongoDB集群

為滿足數據量不斷增長的需求，通過分片技術的使用實現數據在多臺機器中的存放，MongoDB集群中各組件如圖4所示[4]。

圖4 MongoDB集群組件

Mongos(路由控制器)需對所有的數據庫集群的請求進行協調，并完成數據請求到對應Shard分片服務器上的轉發。

Config Servers(配置服務器)對所有路由、分片的配置進行存儲，mongos則從該服務器中加載配置信息。

最終數據存儲由Shard (分片)完成，并提供方便的數據訪問接口，各分片可以是replica set(副本集)，以避免數據丟失從而確保數據的安全。

本系統中的mongos和config server配置了3個，以確保存儲查詢能夠順利完成，MongoDB集群的結構圖5所示。

4.2 Redis集群

作為內存型數據庫，Redis引入哈希槽概念，各節點負責一部分哈希槽(集群劃分為16 384個槽)，提供多個程序集，有利于多Redis節點間數據的共享，進入的Redis的鍵值對key-value會通過散列分配到某個槽中，使數據庫占用的單臺機器內存得以顯著降低，系統Redis集群結構如圖6所示。

圖5 MongoDB集群結構圖

圖6 Redis集群結構

集群提供主從復制機制，各主節點(負責客戶端的讀寫請求)對應從節點(對主節點中的數據進行備份)若干個，以保證集群在節點出現宕機時仍能夠正常運行，集群可通過在從節點中選取一個節點代替宕機的主節點作為新主節點繼續工作，以防單點故障問題，本系統包含Redis主節點三個，分配在3臺物理機上，哈希槽的具體分配為：1到5500號由節點A負責，5501到11000號由節點B負責，11001到16384號由節點C負責，各主節點都配備一個從節點[5]。

5 總結

本文主要研究了基于Scrapy網絡爬蟲系統框架，以設計目標為依據對網絡爬蟲所需具備的功能特性進行了詳細分析，完成了系統總體框架的設計，該框架采用主從結構，并介紹了各層主要模塊的功能，詳細闡述了完整的抓取過程，為促進網絡爬蟲系統框架的實現，綜合MongoDB及Redis完成了系統數據庫方案的設計，從而提高用戶獲取信息的速度和質量。