IP代理
對於IP代理，各語言的原生請求API提供了IP代理的響應API，要解決的主要問題是IP來源。
網絡上有便宜的代理IP(0元65438+4000)。我做了壹個簡單的測試。在100個IP中，平均可用IP在40-60左右，訪問延遲在200以上。
網絡有優質代理IP出售，前提是妳有渠道。
因為使用IP代理後延遲增加，失敗率增加，所以我們可以在爬蟲框架中把請求設計成異步，把請求任務加入請求隊列(RabbitMQ，Kafka，Redis)，成功後回調，失敗後重新加入隊列。每個請求都從IP池中獲取IP，如果請求失敗，則從IP池中刪除無效的IP。
餅幹
壹些網站基於Cookies作為反爬蟲。這基本就是像@朱天翼說的維持壹套餅幹池。
註意研究目標網站的cookie過期事件，可以模擬瀏覽器，定時生成cookie。
限速進入
比如多線程抓取數據真的是分分鐘被IP阻塞的事情，實現限速訪問(通過任務隊列實現)也是相當簡單的事情，效率不用擔心。壹般結合IP proxy可以快速抓取目標內容。
壹些坑
大量抓取目標網站的內容後，紅線難免會觸發對方的反爬蟲機制，所以需要適當報警，提醒爬蟲無效。
壹般反爬後會返回請求的HttpCode為403的頁面，部分網站也會返回輸入驗證碼(如豆瓣)。所以當403呼叫失敗時，會發出警報，可以結合壹些監控框架，比如Metrics，在短時間內將警報設置到壹定的閾值，然後給妳發郵件、短信等。
當然，單純檢測403錯誤並不能解決所有情況。有的網站很精彩，反抓取後返回的頁面還是200(比如去哪兒)。此時爬蟲任務往往會進入解析階段，解析失敗在所難免。應對這些措施，我們只能在解析失敗時發出警報，然後在短時間內警報達到壹定閾值時觸發通知事件。
當然，這部分解決方案並不完美，因為有時候，因為網站結構變化，導致分析失敗，觸發警報。而且不能簡單的說是哪個原因引起的報警。