動態網頁解析下的分布式網絡爬蟲系統設計

陳春暉

(福建農業職業技術學院,福建 福州 350000)

0 引言

近年來,互聯網數據的需求急劇增長,不僅是正在研發高性能爬蟲技術的傳統搜索引擎公司,還有大數據、人工智能等新興企業和學術機構有著巨大的需求,這就需要一種低成本的網絡爬蟲器,以解決購買數據的資金問題[1-2]。 本文在對系統需求進行分析的基礎上,提出了一種基于分布式爬蟲的算法。

1 系統需求

1.1 能夠獲取站點的非同步載入

隨著異步負載技術的不斷發展,動態頁面的異步負載在網絡產品中得到了越來越多的應用。 當前主要的爬蟲無法對動態頁面進行有效分析,如何實現動態網頁的爬蟲是本設計的主要內容。

1.2 反爬處理

數據站點設計了一套防爬策略,以保護站點資料和普通使用者的存取,如當前IP 訪問被禁用、單位時間訪問限制等。 所以,在設計系統時,必須考慮如何處理好防爬蟲問題。

1.3 健壯性

一個好的系統,不僅要有很好的容錯率,還要有很高的穩定性。 實例證明,這種分布式爬蟲系統必須具有良好的性能,可以在幾個星期甚至幾個月內連續運行。

1.4 擴展性

在分布式網絡中,可擴展性非常重要,因為分布的網絡爬蟲程序會經常添加或移除節點,而Scrapy-Redis 分布體系結構恰好能解決這個問題,Scrapy-Redis 最大的優勢在于可擴充性,可以隨意添加和刪除任何一個節點。

1.5 低成本和高效率

本設計的爬蟲系統期望在硬件成本最小的情況下獲得更高的性能,Scrapy-Redis 的分布架構正是最佳的解決辦法,其所需的服務器數量很少,普通的計算機也能使用,即使是樹莓派(一種卡式的微型計算機,造價約在200 RMB)也可以充當Slave 節點。 而且,基于Scrapy-Redis 結構的爬蟲系統也是分布的,可以很好地實現對頁面的高效爬取[3]。

2 系統結構與模塊設計

本文根據系統需求提出了基于分布式爬蟲體系結構的結構模型,并將其劃分為數據層和業務邏輯兩個層次,結合現有的分布式框架進行了詳細的設計,如圖1 所示,實線箭頭表示數據流方向,虛線箭頭表示分布群集的Master 節點和Slave 節點間的“請求應答”通信。

2.1 初始化參數模塊

初始化參數模塊是為了讓系統能夠正常工作而初始化特定的參數,在Slave 節點上,主節點IP 位址和要爬取的站點的參數都要初始化。 Slave 節點要在主節點上的IP 位址,并從Master 節點上的Redis 獲取爬取作業,主節點無需事先知曉Slave 節點的IP 位址,而Slave節點可以隨時進出。 此外,系統還會對網站的URL 初始化,該URL 將會出現在工作分配模組中的待執行工作序列中。

2.2 任務分配與爬取策略

2.2.1 任務分派

主要是對待完成的任務和已完成的任務進行記錄,并根據已完成的任務排隊來防止對爬取的重復訪問。

當系統開始時,任務指派模塊會收到種子URL 的初始化,并將其放到要爬取的隊列中。

集群中Master 節點對Slave 節點采取優先服務的原則,即從主節點的任務隊列中提取爬取任務,提取完后記錄在已爬取任務隊列中[4]。

若某個Slave 節點表現得更好,那么該節點可以更快地獲得任務;相反,則會變得更慢。 所以,這個策略可以最大限度地利用各個Slave 節點的最高性能,而這些Slave 節點本身是否在線,并不會對其他Slave 節點的處理任務造成任何影響。

2.2.2 爬蟲策略模塊

不同的站點對數據的爬蟲策略是不同的,一般采用廣度優先策略和深度優先策略獲取數據。

2.3 系統的穩健維護模塊

系統的穩健性維護模塊包括4 個子模塊:心跳探測、IP 代理、類人爬取模塊、記錄遺失任務模塊。

2.3.1 心跳探測模塊

模塊包括監控進程、狀態記錄、保護進程等,是系統的一個關鍵部件,可以監控每一個Slave 節點的登錄和訪問,包括當前的狀態(比如:正常的爬蟲、異常的要求、退出的情況)。

系統狀況監控流程模塊:位于主節點,作用是監控當前Slave 節點的狀態,并對監控結果進行處理和記錄。

Slave 節點狀態記錄:將Slave 節點的狀態存入諸如 MySQL 之類的關系數據庫中。

Slave 守護模塊:在Slave 的節點中,其功能是將自身的狀態在特定的時間段內傳遞出去,并存儲在一個資料庫中。

Slave Device 模塊對Slave 節點的狀態記錄進行計時寫入,而Slave Development 通過該過程的狀態信息來判定該節點的狀態。

2.3.2 IP 代理模塊

是非常關鍵的模塊,能有效地防止網絡爬蟲,通過特定的策略,持續地修改IP 地址,使其造成多個站點的訪問,降低被攔截的概率。

IP 代理替換模塊:在Slave 節點上,主要作用是從IP 代理池中隨機提取IP,用于爬蟲系統的爬蟲和記錄IP 的異常情況。

2.3.3 類人爬蟲模塊

作為系統的關鍵部件,其作用是通過仿真用戶訪問網站,欺騙網站的防爬機制,獲取用戶的數據。 本文提出了一種類人爬取策略,主要內容如下。

用戶代理策略:由一些常見的用戶代理組成用戶代理庫,在用戶使用時隨機選擇一個,并將其安裝到爬蟲系統中。

Cookie 戰略:選擇是否使用Cookie,取決于目標站點對數據的爬蟲。

隨機時間爬蟲策略:通過仿真用戶在特定時間周期內的存取次數和存取時間,欺騙目標站點的頻率和存取時間,從而判定該系統是不是爬蟲;針對特定區域的爬蟲限制,隨機產生一定的時間間隔。

通常情況下,使用最佳策略進行組合,而在實際的爬行前,先對網站的忍耐程度進行檢測(即嚴格的抗爬行戰略)。

2.3.4 記錄遺失任務模塊

模塊位于主計算機上,用于記錄因異常退出Slave節點而導致的丟失任務。 若Slave 節點沒有完成爬取,此時出現異常的Slave 節點,爬蟲任務將不能被發送到Master 節點上,這就會導致任務丟失。 本模塊主要包括任務丟失和任務丟失的日志。

2.4 資料爬取組件

數據爬蟲模塊是利用特定的策略從頁面中獲取相應的URL,包括自定義的爬蟲策略和動態的網頁爬蟲。

2.4.1 添加自定義爬取策略模塊

在實際的爬行過程中,通常只需要特定的類別或特定區域的信息,廣度優先,深度優先。 而爬行的覆蓋區域太大,則無法快速準確地獲取所需要的信息,這就需要一個特殊的爬行器策略為特定站點提供有吸引力的信息。 此外,對不同站點的蠕動行為所能忍受的范圍也不盡相同。 為了應對更多的爬蟲數據,在此將加入一些事先設置的戰略配置。

2.4.2 動態、靜態的網頁爬蟲模塊

主要針對動態頁面和靜止頁面采用不同的爬蟲策略,分析動態頁面所需的時間一般要比靜態頁面多,區分動態頁面和靜態頁面,可以提高爬蟲效率。

在動態網頁分析方面,根據鄔柏[5]的建議,向白名單中添加網址,新網址將依據查詢的白名單,決定是否使用動態頁面的解析方式,并將不包含白名單但視為動態頁面的URL。 在此基礎上,本設計采用了如下的改進方法。

利用規則基礎來判定URL 對應于存儲預先調查的目標站點動態頁面URL 的正則表達式的規則庫,利用規則表達式,可以極大地減少規則庫的容量,減少系統的維護費用。

對于異常解析的網站日志,由管理員進行分析,然后確定是否進行更新。 在相同的網站上,由于用戶關注的數據,動態頁面的分布規則是有限制的,通常不會因為規則表達式的覆蓋而無法進行動態分析,大多數的異常都是由網絡異常或者防爬蟲因子引起的。 所以,管理員在分析不正常的日志之后,就可以決定是否進行規則的更新。

2.5 異常處理模塊和解析模塊

2.5.1 異常處理模塊

處理在執行爬蟲作業URL 時出現的異常,并將其傳回Master 節點,由Master 節點進行記錄。

2.5.2 數據分析模塊

根據預定的規則,對采集到的數據進行分析,生成URL 或最終存儲的數據。 用戶依據網站、調查需求,從網站中提取或存儲的數據類型(頁面文字格式、JSON格式、URL 的鏈接類型)和URL 的規則,對相關的規則進行配置。 在同一網站上,使用者要抽取的數據與URL 的鏈接是一樣的,符合一定規則的URL,就會相應地抽取規則或者行為,例如,從某一列中抽取某一段話、某一段文字、點擊加載內容等。

2.6 數據儲存模塊

將Redis 在Master 端收到的數據(異常和爬蟲)進行統一處理,包括:記錄、緩存、異常記錄、數據存儲等。

2.6.1 Slave 記錄數據模塊

模塊的作用是將Slave 的例外訪問、數據處理系統中的數據處理、被Slave 節點獲取的工作、Slave 節點請求的下載量(包括請求例外)返回到主要節點的Redis中,并大量地傳送給關聯資料庫。

2.6.2 異常情況

保存異常數據,主要是利用傳統的關系數據庫,將異常爬蟲記錄(在爬蟲過程中出現的URL)保存下來,以便管理員查詢異常,補充數據。

2.6.3 資料儲存

儲存爬取資料,采用傳統的關聯式資料庫,存取主節點上的Redis 中儲存的資料,如最后儲存使用者所需要的資料,以備日后使用者查詢時所用。

3 結語

本文在基于動態網頁解析的網絡爬蟲系統需求基礎上,對系統進行了整體的設計,并將其劃分為數據采集級和數據解析級、數據存儲層、節點接入層和系統管理層。 各層共包括存儲層、網頁下載和任務調度、網頁信息提取、網頁刪除、節點管理、爬蟲管理6 大部分。隨著大數據時代的到來,各種頁面的涌現,傳統基于計算機的爬蟲系統已不能很好地適應目前的檢索需求,同時也需要更高的、實時的、精確的信息采集。 因此,如何有效地從網頁中抽取網頁信息,建立一個基于動態網頁解析的網絡爬蟲系統是十分必要的。