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