爬蟲爬取過程中代理IP會遇到什么問題

小編給大家分享一下爬蟲爬取過程中代理IP會遇到什么問題，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

學爬蟲數據，必然是爬蟲和反爬蟲的對抗。

用代理ip做反爬蟲還是比較有效的。

在做抓取代理ip項目之前，還搜索了一些相關項目。qiye的項目還不錯，但是用起來也有問題。比如偶爾會被個別代理網站關閉ip(某段時間重啟太多程序)。

當scrapy使用qiye項目時，經常會出現10060和10061的錯誤，以及超時等錯誤，從而導致代理ip在代理池中不斷地刷。為了解決這個問題，我們考慮了兩種方法：

1.更改scrapy代碼

當使用代理時，request沒有成功重啟。切記，scrapy不會重新啟動request。

2.確保代理ip的有效性

方法2更合適，scrapy應該專注于抓取網站。方法2也保證了代理ip的有效性。

這意味著你重寫了一個爬行代理ip項目。

工程設計與實現。

最初的想法比較簡單，直接實現了代理ip的捕捉、驗證、存儲和獲取功能。類似于qiye項目。在代理網站上獲取代理ip，驗證url后存儲sqlite，然后要求webapi返回代理ip。

問題來了:

1、目標網站是douban[雖然豆瓣上有api，但是api不能滿足我的需求，只能自己爬豆瓣]，相當于測試代理ip欺騙豆瓣的反爬蟲設置。豆瓣反爬蟲最重要的是訪問cookie。這個cookie也可以隨機模仿。

2、sqlite本身就是一個輕量級數據庫。單個過程/線程訪問沒有問題。并行訪問時，需要建立自己的鎖保護。我覺得用sqlite比較低，不需要用mysql。qiye項目使用sqlalchemy支持各種數據庫。我覺得沒必要，因為作為輔助項目，定位小，重量輕。可以快速返回用戶代理ip。

3、在測試豆瓣和豆瓣api時遇到的坑，就是豆瓣api使用代理ip基本無效.代理ip爬豆瓣還不錯，但通過代理ip突破了豆瓣api分鐘的限制，代理ip全部失敗，很少成功.估計豆瓣api對反爬的設置要嚴格些，使用高匿的代理ip就可以了.但實際上高匿的ip很少，代理網站說是高匿的，不一定是高匿的。

就豆瓣而言，cookie需要設置兩個項目，否則很容易被ban使用。并非ip問題。事實上，這也說明了一個問題，需要了解一些抓取網站的機制，多嘗試。

4、數據庫中存儲的數據越多，一個過程處理不完就會被淹沒。

5、各種細節。

設計/實現。

1) 使用bloomfilter判重.所獲代理ip可以在判重復之前判重，通過檢查判重，減少資源消耗.bf每隔一段時間就會被清空。

python本身就有bf，當時好像遇到了什么問題，實際使用和需求有點不一致，具體記不清了，最后拋棄了bf，使用了別人的bfonredis項目.paramiao/pydrbloomfilter。

其實我只是想用bf。做輪子需要時間，暫時不做。

2) 目標站點檢測中使用的反爬蟲方法：

代理人ip[廢話，測試]隨機agent帶cookie訪問。

3) 多個過程進行ip判斷.防止過多的過程一直運行.當前判斷過程的數量是直接配置在配置文件中，以后要做到自適應。

4) 代理ip以輪詢方式提供。接著更新算法，根據時間和數量進行選擇。

5) web緩存，選擇一定數量的ip，每2-3分鐘測試一次。這個測試不需要爬網站的網站，因為測試后可以連接代理訪問，比如baidu。

6) 數據庫使用redis.redis作為兩點，一是數據存儲，二是web緩存。redis本身不大。適合這里。此外，bf-redis項目也使用redis。

7) 為多個目標網站提供不同的代理和緩存。

以上是“爬蟲爬取過程中代理IP會遇到什么問題”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！