如何制定反反爬蟲的策略

反反爬蟲策略是依靠定向爬取源的反爬蟲策略而定的。一般有一下幾種:

IP代理

對于IP代理,各個語言的Native Request API都提供的IP代理響應的API, 需要解決的主要就是IP源的問題了。

網絡上有廉價的代理IP(1元4000個左右), 我做過簡單的測試, 100個IP中, 平均可用的在40-60左右, 訪問延遲均在200以上. 網絡有高質量的代理IP出售, 前提是你有渠道. 因為使用IP代理后, 延遲加大, 失敗率提高, 所以可以將爬蟲框架中將請求設計為異步, 將請求任務加入請求隊列(RabbitMQ,Kafka,Redis), 調用成功后再進行回調處理, 失敗則重新加入隊列. 每次請求都從IP池中取IP, 如果請求失敗則從IP池中刪除該失效的IP.

Cookies

有一些網站是基于cookies做反爬蟲,維護一套Cookies池。注意研究下目標網站的cookies過期事件, 可以模擬瀏覽器, 定時生成cookies 。

限速訪問

像開多線程,循環無休眠的的暴力爬取數據, 那真是分分鐘被封IP的事, 限速訪問實現起來也挺簡單(用任務隊列實現), 效率問題也不用擔心, 一般結合IP代理已經可以很快地實現爬去目標內容.

一些坑

大批量爬取目標網站的內容后, 難免碰到紅線觸發對方的反爬蟲機制. 所以適當的告警提示爬蟲失效是很有必有的. 一般被反爬蟲后, 請求返回的HttpCode為403的失敗頁面, 有些網站還會返回輸入驗證碼(如豆瓣), 所以檢測到403調用失敗, 就發送報警, 可以結合一些監控框架, 如Metrics等, 設置短時間內, 告警到達一定閥值后, 給你發郵件,短信等. 當然, 單純的檢測403錯誤并不能解決所有情況. 有一些網站比較奇葩, 反爬蟲后返回的頁面仍然是200的(如去哪兒), 這時候往往爬蟲任務會進入解析階段, 解析失敗是必然的. 應對這些辦法, 也只能在解析失敗的時候, 發送報警, 當告警短時間到達一定閥值, 再觸發通知事件.

當然這個解決部分并不完美, 因為有時候, 因為網站結構改變, 而導致解析失敗, 同樣回觸發告警. 而你并不能很簡單地區分, 告警是由于哪個原因引起的.

大发快3