壹些常用的方法
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的(如去哪兒), 這時候往往爬蟲任務會進入解析階段, 解析失敗是必然的. 應對這些辦法, 也只能在解析失敗的時候, 發送報警, 當告警短時間到達壹定閥值, 再觸發通知事件.
當然這個解決部分並不完美, 因為有時候, 因為網站結構改變, 而導致解析失敗, 同樣回觸發告警. 而妳並不能很簡單地區分, 告警是由於哪個原因引起的.