PHP爬蟲：百萬級別知乎使用者資料爬取與分析

程式碼託管地址：https://github.com/hoohack/zhihuSpider

這次抓取了110萬的使用者資料，資料分析結果如下：

開發前的準備

安裝Linux系統（Ubuntu14.04），在VMWare虛擬機器下安裝一個Ubuntu；

安裝PHP5.6或以上版本；

安裝MySQL5.5或以上版本；

安裝curl、pcntl擴充套件。

使用PHP的curl擴充套件抓取頁面資料

PHP的curl擴充套件是PHP支援的允許你與各種伺服器使用各種型別的協議進行連線和通訊的庫。

本程式是抓取知乎的使用者資料，要能訪問使用者個人頁面，需要使用者登入後的才能訪問。當我們在瀏覽器的頁面中點選一個使用者頭像連結進入使用者個人中心頁面的時候，之所以能夠看到使用者的資訊，是因為在點選連結的時候，瀏覽器幫你將本地的cookie帶上一齊提交到新的頁面，所以你就能進入到使用者的個人中心頁面。因此實現訪問個人頁面之前需要先獲得使用者的cookie資訊，然後在每次curl請求的時候帶上cookie資訊。在獲取cookie資訊方面，我是用了自己的cookie，在頁面中可以看到自己的cookie資訊：

一個個地複製，以”__utma=?;__utmb=?;”這樣的形式組成一個cookie字串。接下來就可以使用該cookie字串來傳送請求。

初始的示例：

執行上面的程式碼可以獲得mora-hu使用者的個人中心頁面。利用該結果再使用正規表示式對頁面進行處理，就能獲取到姓名，性別等所需要抓取的資訊。

圖片防盜鏈

在對返回結果進行正則處理後輸出個人資訊的時候，發現在頁面中輸出使用者頭像時無法開啟。經過查閱資料得知，是因為知乎對圖片做了防盜鏈處理。解決方案就是請求圖片的時候在請求頭裡偽造一個referer。

在使用正規表示式獲取到圖片的連結之後，再發一次請求，這時候帶上圖片請求的來源，說明該請求來自知乎網站的轉發。具體例子如下：

爬取更多使用者

抓取了自己的個人資訊後，就需要再訪問使用者的關注者和關注了的使用者列表獲取更多的使用者資訊。然後一層一層地訪問。可以看到，在個人中心頁面裡，有兩個連結如下：

這裡有兩個連結，一個是關注了，另一個是關注者，以“關注了”的連結為例。用正則匹配去匹配到相應的連結，得到url之後用curl帶上cookie再發一次請求。抓取到使用者關注了的用於列表頁之後，可以得到下面的頁面：

分析頁面的html結構，因為只要得到使用者的資訊，所以只需要框住的這一塊的div內容，使用者名稱都在這裡面。可以看到，使用者關注了的頁面的url是：

不同的使用者的這個url幾乎是一樣的，不同的地方就在於使用者名稱那裡。用正則匹配拿到使用者名稱列表，一個一個地拼url，然後再逐個發請求（當然，一個一個是比較慢的，下面有解決方案，這個稍後會說到）。進入到新使用者的頁面之後，再重複上面的步驟，就這樣不斷迴圈，直到達到你所要的資料量。

Linux統計檔案數量

指令碼跑了一段時間後，需要看看究竟獲取了多少圖片，當資料量比較大的時候，開啟資料夾檢視圖片數量就有點慢。指令碼是在Linux環境下執行的，因此可以使用Linux的命令來統計檔案數量：

其中， ls -l 是長列表輸出該目錄下的檔案資訊（這裡的檔案可以是目錄、連結、裝置檔案等）； grep "^-" 過濾長列表輸出資訊， "^-" 只保留一般檔案，如果只保留目錄是 "^d" ； wc -l 是統計輸出資訊的行數。下面是一個執行示例：

插入MySQL時重複資料的處理

程式執行了一段時間後，發現有很多使用者的資料是重複的，因此需要在插入重複使用者資料的時候做處理。處理方案如下：

1）插入資料庫之前檢查資料是否已經存在資料庫；

2）新增唯一索引，插入時使用 INSERT INTO ... ON DUPLICATE KEY UPDATE...

3）新增唯一索引，插入時使用 INSERT INGNORE INTO...

4）新增唯一索引，插入時使用 REPLACE INTO...

第一種方案是最簡單但也是效率最差的方案，因此不採取。二和四方案的執行結果是一樣的，不同的是，在遇到相同的資料時， INSERT INTO ... ON DUPLICATE KEY UPDATE 是直接更新的，而 REPLACE INTO 是先刪除舊的資料然後插入新的，在這個過程中，還需要重新維護索引，所以速度慢。所以在二和四兩者間選擇了第二種方案。而第三種方案， INSERT INGNORE 會忽略執行INSERT語句出現的錯誤，不會忽略語法問題，但是忽略主鍵存在的情況。這樣一來，使用 INSERT INGNORE 就更好了。最終，考慮到要在資料庫中記錄重複資料的條數，因此在程式中採用了第二種方案。

使用curl_multi實現多執行緒抓取頁面

剛開始單程式而且單個curl去抓取資料，速度很慢，掛機爬了一個晚上只能抓到2W的資料，於是便想到能不能在進入新的使用者頁面發curl請求的時候一次性請求多個使用者，後來發現了curl_multi這個好東西。curl_multi這類函式可以實現同時請求多個url，而不是一個個請求，這類似於linux系統中一個程式開多條執行緒執行的功能。下面是使用curl_multi實現多執行緒爬蟲的示例：

HTTP 429 Too Many Requests

使用curl_multi函式可以同時發多個請求，但是在執行過程中使同時發200個請求的時候，發現很多請求無法返回了，即發現了丟包的情況。進一步分析，使用 curl_getinfo 函式列印每個請求控制程式碼資訊，該函式返回一個包含HTTP response資訊的關聯陣列，其中有一個欄位是http_code，表示請求返回的HTTP狀態碼。看到有很多個請求的http_code都是429，這個返回碼的意思是傳送太多請求了。我猜是知乎做了防爬蟲的防護，於是我就拿其他的網站來做測試，發現一次性發200個請求時沒問題的，證明了我的猜測，知乎在這方面做了防護，即一次性的請求數量是有限制的。於是我不斷地減少請求數量，發現在5的時候就沒有丟包情況了。說明在這個程式裡一次性最多隻能發5個請求，雖然不多，但這也是一次小提升了。

使用Redis儲存已經訪問過的使用者

抓取使用者的過程中，發現有些使用者是已經訪問過的，而且他的關注者和關注了的使用者都已經獲取過了，雖然在資料庫的層面做了重複資料的處理，但是程式還是會使用curl發請求，這樣重複的傳送請求就有很多重複的網路開銷。還有一個就是待抓取的使用者需要暫時儲存在一個地方以便下一次執行，剛開始是放到陣列裡面，後來發現要在程式裡新增多程式，在多程式程式設計裡，子程式會共享程式程式碼、函式庫，但是程式使用的變數與其他程式所使用的截然不同。不同程式之間的變數是分離的，不能被其他程式讀取，所以是不能使用陣列的。因此就想到了使用Redis快取來儲存已經處理好的使用者以及待抓取的使用者。這樣每次執行完的時候都把使用者push到一個already_request_queue佇列中，把待抓取的使用者（即每個使用者的關注者和關注了的使用者列表）push到request_queue裡面，然後每次執行前都從request_queue裡pop一個使用者，然後判斷是否在already_request_queue裡面，如果在，則進行下一個，否則就繼續執行。

在PHP中使用redis示例：

使用PHP的pcntl擴充套件實現多程式

改用了curl_multi函式實現多執行緒抓取使用者資訊之後，程式執行了一個晚上，最終得到的資料有10W。還不能達到自己的理想目標，於是便繼續優化，後來發現php裡面有一個pcntl擴充套件可以實現多程式程式設計。下面是多程式設計程式設計的示例：

在Linux下檢視系統的cpu資訊

實現了多程式程式設計之後，就想著多開幾條程式不斷地抓取使用者的資料，後來開了8調程式跑了一個晚上後發現只能拿到20W的資料，沒有多大的提升。於是查閱資料發現，根據系統優化的CPU效能調優，程式的最大程式數不能隨便給的，要根據CPU的核數和來給，最大程式數最好是cpu核數的2倍。因此需要檢視cpu的資訊來看看cpu的核數。在Linux下檢視cpu的資訊的命令：

結果如下：

其中，model name表示cpu型別資訊，cpu cores表示cpu核數。這裡的核數是1，因為是在虛擬機器下執行，分配到的cpu核數比較少，因此只能開2條程式。最終的結果是，用了一個週末就抓取了110萬的使用者資料。

多程式程式設計中Redis和MySQL連線問題

在多程式條件下，程式執行了一段時間後，發現資料不能插入到資料庫，會報mysql too many connections的錯誤，redis也是如此。

下面這段程式碼會執行失敗：

根本原因是在各個子程式建立時，就已經繼承了父程式一份完全一樣的拷貝。物件可以拷貝，但是已建立的連線不能被拷貝成多個，由此產生的結果，就是各個程式都使用同一個redis連線，各幹各的事，最終產生莫名其妙的衝突。

解決方法： >程式不能完全保證在fork程式之前，父程式不會建立redis連線例項。因此，要解決這個問題只能靠子程式本身了。試想一下，如果在子程式中獲取的例項只與當前程式相關，那麼這個問題就不存在了。於是解決方案就是稍微改造一下redis類例項化的靜態方式，與當前程式ID繫結起來。

改造後的程式碼如下：

PHP統計指令碼執行時間

因為想知道每個程式花費的時間是多少，因此寫個函式統計指令碼執行時間：

若文中有不正確的地方，望各位指出以便改正。

打賞支援我寫出更多好文章，謝謝！

打賞作者