歷時大致兩個月，到現(xiàn)在終于完成了高可用分布式代理IP池，目前開源在了Github上。寫這個項目的原因主要有兩點，一是自己平時的部分工作需要和爬蟲打交道，代理IP在有的時候可以發(fā)揮非常重要的作用，調(diào)研過一些開源的代理IP采集程序，發(fā)現(xiàn)在抓取、解析、校驗、資源調(diào)度等這些方面總有一些不盡人意的地方；二是和一個網(wǎng)友（不嚴格的說算得上是伯樂）的交流讓我有了關(guān)于使用Scrapy來寫分布式爬蟲的一些想法，正好可以借助這個機會來嘗試證實這些想法。

這篇文章的目的是闡述haipproxy的主要架構(gòu)和流程。該項目關(guān)鍵部分是

• 基于Scrapy和Redis的分布式爬蟲，用作IP抓取和校驗，對應(yīng)于項目的crawler
• 基于Redis實現(xiàn)的分布式任務(wù)調(diào)度工具，對應(yīng)于項目的scheduler和redis_util.py

Crawler分為代理抓取和校驗，兩者實現(xiàn)思想類似，主要使用Scrapy的spider_idle信號和DontCloseSpider異常來阻止Scrapy在沒有數(shù)據(jù)的時候關(guān)閉，靈感來自scrapy-redis。為了方便闡述，我畫了一張包含各個組件的流程圖，如下

haipproxy workflow

• 啟動調(diào)度器，包括代理爬蟲調(diào)度器和校驗爬蟲調(diào)度器。調(diào)度器會讀取rules.py中待抓取的網(wǎng)站，將其編排成任務(wù)存入各個任務(wù)隊列中
• 啟動各個爬蟲，包括IP抓取和校驗程序。項目中爬蟲和調(diào)度器都是高可用的，可以根據(jù)實際情況進行分布式部署，無需改動代碼。由于本文的目標不是寫成該項目的詳細使用文檔，所以省略了如指定啟動爬蟲類型和調(diào)度器類型的介紹
• 代理IP采集爬蟲啟動后會到對應(yīng)的任務(wù)隊列中獲取任務(wù)并執(zhí)行，再把獲取到的結(jié)果存入一個init隊列中
• init隊列由一個特殊的校驗器HttpbinInitValidator進行消費，它會過濾掉透明代理，再把可用代理輸入各個Validated隊列中
• 調(diào)度器會定時從Validated隊列中獲取代理IP，再將其存入一個臨時的隊列。這里用一個臨時隊列是為了讓校驗更加公平，如果直接從Validated隊列中獲取資源進行校驗，那么會增大不公平性
• 這時候各個校驗器(非init校驗器)會從對應(yīng)的臨時隊列中獲取待校驗的IP并對其進行校驗，此處省略校驗細節(jié)
• 校驗完成后再將其放回到Validated隊列中，等待下一輪校驗
• 請求成功率(體現(xiàn)為分數(shù))、響應(yīng)速度和最近校驗時間滿足settings.py所配置要求的代理IP將會被爬蟲客戶端所消費
• 為了屏蔽各個調(diào)用語言的差異性，目前實現(xiàn)的客戶端是squid客戶端，它可以作為爬蟲客戶端的中間件

到此，整個流程便完了。

效果測試

以單機模式部署haipproxy和測試代碼，以知乎為目標請求站點，
每一萬條成功請求為統(tǒng)計結(jié)果，實測抓取效果如下

可見haipporxy的代理效果還算不錯，在開始的時候可以達到1w/hour的請求量，幾個小時候請求量請求量
降為了5k/hour。降低的結(jié)果可能有三個: (1)隨著數(shù)據(jù)量的增大,Redis的性能受到了一定的影響(2)知乎校驗器在把Init Queue中的代理消費完之后，由于是定時任務(wù)，所以導(dǎo)致某段時間內(nèi)新鮮的IP空缺。而免費IP大多數(shù)都是短效的，所以這段時間出現(xiàn)了IP的空缺;(3)由于我們采用的是greedy模式調(diào)用IP，它的調(diào)用策略是: 高質(zhì)量代理IP會一直被調(diào)用直至該代理IP不能用或者被封，而低應(yīng)速度IP會輪詢調(diào)用。這也可能導(dǎo)致高質(zhì)量IP的空缺。
可見IP校驗和調(diào)用策略還有很大的優(yōu)化空間。希望志同道合的朋友加入進來一起優(yōu)化，這也挺有意思的。

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

歡迎star和fork，也歡迎大家交流和PR。