分佈式代理爬蟲:架構篇

歷時大體兩個月，到如今終於完成了分佈式代理抓取爬蟲，目前開源在了Github上。寫這個項目的緣由主要有兩點，一是本身平時的部分工做須要和爬蟲打交道，代理IP在有的時候能夠發揮很是重要的做用，調研過一些開源的代理IP採集程序，發如今抓取、解析、校驗、資源調度等這些方面總有一些不盡人意的地方；二是和一個網友（不嚴格的說算得上是伯樂）的交流讓我有了關於使用Scrapy來寫分佈式爬蟲的一些想法，正好能夠藉助這個機會來嘗試證明這些想法。

---

這篇文章的目的是闡述haipproxy的主要架構和流程。該項目關鍵部分是

• 基於Scrapy和Redis的分佈式爬蟲，用做IP抓取和校驗，對應於項目的crawler
• 基於Redis實現的分佈式任務調度工具，對應於項目的scheduler和redis_util.py

Crawler分爲代理抓取和校驗，二者實現思想相似，主要使用Scrapy的spider_idle信號和DontCloseSpider異常來阻止Scrapy在沒有數據的時候關閉，靈感來自scrapy-redis。爲了方便闡述，我畫了一張包含各個組件的流程圖，以下

• 啓動調度器，包括代理爬蟲調度器和校驗爬蟲調度器。調度器會讀取rules.py中待抓取的網站，將其編排成任務存入各個任務隊列中
• 啓動各個爬蟲，包括IP抓取和校驗程序。項目中爬蟲和調度器都是高可用的，能夠根據實際狀況進行分佈式部署，無需改動代碼。因爲本文的目標不是寫成該項目的詳細使用文檔，因此省略瞭如指定啓動爬蟲類型和調度器類型的介紹
• 代理IP採集爬蟲啓動後會到對應的任務隊列中獲取任務並執行，再把獲取到的結果存入一個init隊列中
• init隊列由一個特殊的校驗器HttpbinInitValidator進行消費，它會過濾掉透明代理，再把可用代理輸入各個Validated隊列中
• 調度器會定時從Validated隊列中獲取代理IP，再將其存入一個臨時的隊列。這裏用一個臨時隊列是爲了讓校驗更加公平，若是直接從Validated隊列中獲取資源進行校驗，那麼會增大不公平性
• 這時候各個校驗器(非init校驗器)會從對應的臨時隊列中獲取待校驗的IP並對其進行校驗，此處省略校驗細節
• 校驗完成後再將其放回到Validated隊列中，等待下一輪校驗
• 請求成功率(體現爲分數)、響應速度和最近校驗時間知足settings.py所配置要求的代理IP將會被爬蟲客戶端所消費
• 爲了屏蔽各個調用語言的差別性，目前實現的客戶端是squid客戶端，它能夠做爲爬蟲客戶端的中間件

到此，整個流程便完了。

---

效果測試

以單機模式部署haipproxy和測試代碼，以知乎爲目標請求站點，
每一萬條成功請求爲統計結果，實測抓取效果以下

請求量	時間	耗時	IP負載策略	客戶端
0	2018/03/03 22:03	0	greedy	py_cli
10000	2018/03/03 11:03	1 hour	greedy	py_cli
20000	2018/03/04 00:08	2 hours	greedy	py_cli
30000	2018/03/04 01:02	3 hours	greedy	py_cli
40000	2018/03/04 02:15	4 hours	greedy	py_cli
50000	2018/03/04 03:03	5 hours	greedy	py_cli
60000	2018/03/04 05:18	7 hours	greedy	py_cli
70000	2018/03/04 07:11	9 hours	greedy	py_cli
80000	2018/03/04 08:43	11 hours	greedy	py_cli

可見haipporxy的代理效果還算不錯，在開始的時候能夠達到1w/hour的請求量，幾個小時候請求量請求量
降爲了5k/hour。下降的結果可能有三個: (1)隨着數據量的增大,Redis的性能受到了必定的影響(2)知乎校驗器在把Init Queue中的代理消費完以後，因爲是定時任務，因此致使某段時間內新鮮的IP空缺。而免費IP大多數都是短效的，因此這段時間出現了IP的空缺;(3)因爲咱們採用的是greedy模式調用IP，它的調用策略是: 高質量代理IP會一直被調用直至該代理IP不能用或者被封，而低應速度IP會輪詢調用。這也可能致使高質量IP的空缺。
可見IP校驗和調用策略還有很大的優化空間。

項目地址: https://github.com/SpiderClub...

歡迎star和fork，也歡迎你們交流和PR。