深入剖析Python的爬蟲框架Scrapy的結構與運作流程

網絡爬蟲（Web Crawler, Spider）就是一個在網絡上亂爬的機器人。當然它通常并不是一個實體的機器人，因為網絡本身也是虛擬的東西，所以這個“機器人”其實也就是一段程序，并且它也不是亂爬，而是有一定目的的，并且在爬行的時候會搜集一些信息。例如 Google 就有一大堆爬蟲會在 Internet 上搜集網頁內容以及它們之間的鏈接等信息；又比如一些別有用心的爬蟲會在 Internet 上搜集諸如 foo@bar.com 或者 foo [at] bar [dot] com 之類的東西。除此之外，還有一些定制的爬蟲，專門針對某一個網站，例如前一陣子 JavaEye 的 Robbin 就寫了幾篇專門對付惡意爬蟲的 blog （原文鏈接似乎已經失效了，就不給了），還有諸如小眾軟件或者 LinuxToy 這樣的網站也經常被整個站點 crawl 下來，換個名字掛出來。其實爬蟲從基本原理上來講很簡單，只要能訪問網絡和分析 Web 頁面即可，現在大部分語言都有方便的 Http 客戶端庫可以抓取 Web 頁面，而 HTML 的分析最簡單的可以直接用正則表達式來做，因此要做一個最簡陋的網絡爬蟲實際上是一件很簡單的事情。不過要實現一個高質量的 spider 卻是非常難的。

爬蟲的兩部分，一是下載 Web 頁面，有許多問題需要考慮，如何最大程度地利用本地帶寬，如何調度針對不同站點的 Web 請求以減輕對方服務器的負擔等。一個高性能的 Web Crawler 系統里，DNS 查詢也會成為急需優化的瓶頸，另外，還有一些“行規”需要遵循（例如 robots.txt）。而獲取了網頁之后的分析過程也是非常復雜的，Internet 上的東西千奇百怪，各種錯誤百出的 HTML 頁面都有，要想全部分析清楚幾乎是不可能的事；另外，隨著 AJAX 的流行，如何獲取由 Javascript 動態生成的內容成了一大難題；除此之外，Internet 上還有有各種有意或無意出現的 Spider Trap ，如果盲目的跟蹤超鏈接的話，就會陷入 Trap 中萬劫不復了，例如這個網站，據說是之前 Google 宣稱 Internet 上的 Unique URL 數目已經達到了 1 trillion 個，因此這個人 is proud to announce the second trillion 。 :D

不過，其實并沒有多少人需要做像 Google 那樣通用的 Crawler ，通常我們做一個 Crawler 就是為了去爬特定的某個或者某一類網站，所謂知己知彼，百戰不殆，我們可以事先對需要爬的網站結構做一些分析，事情就變得容易多了。通過分析，選出有價值的鏈接進行跟蹤，就可以避免很多不必要的鏈接或者 Spider Trap ，如果網站的結構允許選擇一個合適的路徑的話，我們可以按照一定順序把感興趣的東西爬一遍，這樣以來，連 URL 重復的判斷也可以省去。

舉個例子，假如我們想把 pongba 的 blog mindhacks.cn 里面的 blog 文字爬下來，通過觀察，很容易發現我們對其中的兩種頁面感興趣：

文章列表頁面，例如首頁，或者 URL 是 /page/\d+/ 這樣的頁面，通過 Firebug 可以看到到每篇文章的鏈接都是在一個 h1 下的 a 標簽里的（需要注意的是，在 Firebug 的 HTML 面板里看到的 HTML 代碼和 View Source 所看到的也許會有些出入，如果網頁中有 Javascript 動態修改 DOM 樹的話，前者是被修改過的版本，并且經過 Firebug 規則化的，例如 attribute 都有引號擴起來等，而后者通常才是你的 spider 爬到的原始內容。如果是使用正則表達式對頁面進行分析或者所用的 HTML Parser 和 Firefox 的有些出入的話，需要特別注意），另外，在一個 class 為 wp-pagenavi 的 div 里有到不同列表頁面的鏈接。
文章內容頁面，每篇 blog 有這樣一個頁面，例如 /2008/09/11/machine-learning-and-ai-resources/ ，包含了完整的文章內容，這是我們感興趣的內容。
因此，我們從首頁開始，通過 wp-pagenavi 里的鏈接來得到其他的文章列表頁面，特別地，我們定義一個路徑：只 follow Next Page 的鏈接，這樣就可以從頭到尾按順序走一遍，免去了需要判斷重復抓取的煩惱。另外，文章列表頁面的那些到具體文章的鏈接所對應的頁面就是我們真正要保存的數據頁面了。

這樣以來，其實用腳本語言寫一個 ad hoc 的 Crawler 來完成這個任務也并不難，不過今天的主角是 Scrapy ，這是一個用 Python 寫的 Crawler Framework ，簡單輕巧，并且非常方便，并且官網上說已經在實際生產中在使用了，因此并不是一個玩具級別的東西。不過現在還沒有 Release 版本，可以直接使用他們的 Mercurial 倉庫里抓取源碼進行安裝。不過，這個東西也可以不安裝直接使用，這樣還方便隨時更新，文檔里說得很詳細，我就不重復了。

Scrapy 使用 Twisted 這個異步網絡庫來處理網絡通訊，架構清晰，并且包含了各種中間件接口，可以靈活的完成各種需求。整體架構如下圖所示：

綠線是數據流向，首先從初始 URL 開始，Scheduler 會將其交給 Downloader 進行下載，下載之后會交給 Spider 進行分析，Spider 分析出來的結果有兩種：一種是需要進一步抓取的鏈接，例如之前分析的“下一頁”的鏈接，這些東西會被傳回 Scheduler ；另一種是需要保存的數據，它們則被送到 Item Pipeline 那里，那是對數據進行后期處理（詳細分析、過濾、存儲等）的地方。另外，在數據流動的通道里還可以安裝各種中間件，進行必要的處理。

具體的內容在最后的附屬中還會介紹。

看起來好像很復雜，其實用起來很簡單，就如同 Rails 一樣，首先新建一個工程：

會創建一個 blog_crawl 目錄，里面有個 scrapy-ctl.py 是整個項目的控制腳本，而代碼全都放在子目錄 blog_crawl 里面。為了能抓取 mindhacks.cn ，我們在 spiders 目錄里新建一個mindhacks_spider.py ，定義我們的 Spider 如下：

我們的 MindhacksSpider 繼承自 BaseSpider （通常直接繼承自功能更豐富的 scrapy.contrib.spiders.CrawlSpider 要方便一些，不過為了展示數據是如何 parse 的，這里還是使用 BaseSpider 了），變量 domain_name 和 start_urls 都很容易明白是什么意思，而 parse 方法是我們需要定義的回調函數，默認的 request 得到 response 之后會調用這個回調函數，我們需要在這里對頁面進行解析，返回兩種結果（需要進一步 crawl 的鏈接和需要保存的數據），讓我感覺有些奇怪的是，它的接口定義里這兩種結果竟然是混雜在一個 list 里返回的，不太清楚這里為何這樣設計，難道最后不還是要費力把它們分開？總之這里我們先寫一個空函數，只返回一個空列表。另外，定義一個“全局”變量 SPIDER ，它會在 Scrapy 導入這個 module 的時候實例化，并自動被 Scrapy 的引擎找到。這樣就可以先運行一下 crawler 試試了：

會有一堆輸出，可以看到抓取了 http://mindhacks.cn ，因為這是初始 URL ，但是由于我們在 parse 函數里沒有返回需要進一步抓取的 URL ，因此整個 crawl 過程只抓取了主頁便結束了。接下來便是要對頁面進行分析，Scrapy 提供了一個很方便的 Shell （需要 IPython ）可以讓我們做實驗，用如下命令啟動 Shell ：

它會啟動 crawler ，把命令行指定的這個頁面抓取下來，然后進入 shell ，根據提示，我們有許多現成的變量可以用，其中一個就是 hxs ，它是一個 HtmlXPathSelector ，mindhacks 的 HTML 頁面比較規范，可以很方便的直接用 XPath 進行分析。通過 Firebug 可以看到，到每篇 blog 文章的鏈接都是在 h1 下的，因此在 Shell 中使用這樣的 XPath 表達式測試：

這正是我們需要的 URL ，另外，還可以找到“下一頁”的鏈接所在，連同其他幾個頁面的鏈接一同在一個 div 里，不過“下一頁”的鏈接沒有 title 屬性，因此 XPath 寫作

不過如果向后翻一頁的話，會發現其實“上一頁”也是這樣的，因此還需要判斷該鏈接上的文字是那個下一頁的箭頭 u'\xbb' ，本來也可以寫到 XPath 里面去，但是好像這個本身是 unicode escape 字符，由于編碼原因理不清楚，直接放到外面判斷了，最終 parse 函數如下：

前半部分是解析需要抓取的 blog 正文的鏈接，后半部分則是給出“下一頁”的鏈接。需要注意的是，這里返回的列表里并不是一個個的字符串格式的 URL 就完了，Scrapy 希望得到的是 Request 對象，這比一個字符串格式的 URL 能攜帶更多的東西，諸如 Cookie 或者回調函數之類的?？梢钥吹轿覀冊趧摻?blog 正文的 Request 的時候替換掉了回調函數，因為默認的這個回調函數 parse 是專門用來解析文章列表這樣的頁面的，而 parse_post 定義如下：

很簡單，返回一個 BlogCrawlItem ，把抓到的數據放在里面，本來可以在這里做一點解析，例如，通過 XPath 把正文和標題等解析出來，但是我傾向于后面再來做這些事情，例如 Item Pipeline 或者更后面的 Offline 階段。BlogCrawlItem 是 Scrapy 自動幫我們定義好的一個繼承自 ScrapedItem 的空類，在 items.py 中，這里我加了一點東西：

定義了 __str__ 函數，只給出 URL ，因為默認的 __str__ 函數會把所有的數據都顯示出來，因此會看到 crawl 的時候控制臺 log 狂輸出東西，那是把抓取到的網頁內容輸出出來了。-.-bb

這樣一來，數據就取到了，最后只剩下存儲數據的功能，我們通過添加一個 Pipeline 來實現，由于 Python 在標準庫里自帶了 Sqlite3 的支持，所以我使用 Sqlite 數據庫來存儲數據。用如下代碼替換 pipelines.py 的內容：

在 __init__ 函數中，使用 dispatcher 將兩個信號連接到指定的函數上，分別用于初始化和關閉數據庫連接（在 close 之前記得 commit ，似乎是不會自動 commit 的，直接 close 的話好像所有的數據都丟失了 dd-.-）。當有數據經過 pipeline 的時候，process_item 函數會被調用，在這里我們直接講原始數據存儲到數據庫中，不作任何處理。如果需要的話，可以添加額外的 pipeline ，對數據進行提取、過濾等，這里就不細說了。

最后，在 settings.py 里列出我們的 pipeline ：

ITEM_PIPELINES = ['blog_crawl.pipelines.SQLiteStorePipeline']
再跑一下 crawler ，就 OK 啦！

PS1：Scrapy的組件

1.Scrapy Engine（Scrapy引擎）

Scrapy引擎是用來控制整個系統的數據處理流程，并進行事務處理的觸發。更多的詳細內容可以看下面的數據處理流程。

2.Scheduler（調度程序）

調度程序從Scrapy引擎接受請求并排序列入隊列，并在Scrapy引擎發出請求后返還給它們。

3.Downloader（下載器）

下載器的主要職責是抓取網頁并將網頁內容返還給蜘蛛（Spiders）。

4.Spiders（蜘蛛）

蜘蛛是有Scrapy用戶自己定義用來解析網頁并抓取制定URL返回的內容的類，每個蜘蛛都能處理一個域名或一組域名。換句話說就是用來定義特定網站的抓取和解析規則。

5.Item Pipeline（項目管道）

項目管道的主要責任是負責處理有蜘蛛從網頁中抽取的項目，它的主要任務是清晰、驗證和存儲數據。當頁面被蜘蛛解析后，將被發送到項目管道，并經過幾個特定的次序處理數據。每個項目管道的組件都是有一個簡單的方法組成的Python類。它們獲取了項目并執行它們的方法，同時還需要確定的是是否需要在項目管道中繼續執行下一步或是直接丟棄掉不處理。

項目管道通常執行的過程有：

清洗HTML數據 驗證解析到的數據（檢查項目是否包含必要的字段） 檢查是否是重復數據（如果重復就刪除） 將解析到的數據存儲到數據庫中

6.Middlewares（中間件）

中間件是介于Scrapy引擎和其他組件之間的一個鉤子框架，主要是為了提供一個自定義的代碼來拓展Scrapy的功能。

PS2：Scrapy的數據處理流程

Scrapy的整個數據處理流程有Scrapy引擎進行控制，其主要的運行方式為：

引擎打開一個域名，時蜘蛛處理這個域名，并讓蜘蛛獲取第一個爬取的URL。

引擎從蜘蛛那獲取第一個需要爬取的URL，然后作為請求在調度中進行調度。

引擎從調度那獲取接下來進行爬取的頁面。

調度將下一個爬取的URL返回給引擎，引擎將它們通過下載中間件發送到下載器。

當網頁被下載器下載完成以后，響應內容通過下載中間件被發送到引擎。

引擎收到下載器的響應并將它通過蜘蛛中間件發送到蜘蛛進行處理。

蜘蛛處理響應并返回爬取到的項目，然后給引擎發送新的請求。

引擎將抓取到的項目項目管道，并向調度發送請求。

系統重復第二部后面的操作，直到調度中沒有請求，然后斷開引擎與域之間的聯系。