如何利用scrapy進行八千萬用戶數(shù)據(jù)爬取與優(yōu)化，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：主機域名、虛擬主機、營銷軟件、網(wǎng)站建設、武邑網(wǎng)站維護、網(wǎng)站推廣。

最近準備把數(shù)據(jù)分析這塊補一下，加上一直在聽喜馬拉雅的直播，有一個比較喜歡的主播，突然萌生了爬取喜馬拉雅所有主播信息以及打賞信息，來找一找喜馬拉雅上比較火的主播和有錢的大哥，看看這些有錢人是怎么揮霍的。

爬取信息分析

打開喜馬拉雅的主播頁面，查看人氣主播

第一個是喜馬拉雅好聲音，官方的賬號，很多人的喜馬拉雅賬號應該會默認關注這個。我們看到粉絲關注數(shù)有八千多萬，實際的喜馬拉雅用戶量肯定超過這個數(shù)值，我們暫且估計可爬取數(shù)量為一億，主播頁面只顯示五50頁，每頁20個用戶，我的思路是爬取顯示的主播信息，進入主播主頁

爬取相關信息，然后查看粉絲信息

粉絲頁只顯示10頁，每頁10個用戶。雖然看起來不多，但是我們可以進行擴展，每個粉絲點進去后又是一個用戶主頁，又可以爬取他的粉絲信息。就這樣一直進行擴展，然后使用去重處理，過濾已經(jīng)爬取過的用戶數(shù)據(jù)。

我們要爬取的數(shù)據(jù)：用戶名、簡介、粉絲數(shù)、關注數(shù)、聲音、專輯數(shù)。

另外還有贊賞信息需要通過APP抓取，我們先抓用戶信息吧。

爬取技術選擇

這么大量的數(shù)據(jù)爬取，優(yōu)秀的框架是必不可少的，我們就使用大名鼎鼎的scrapy框架為基礎來進行爬取。另外分布式爬取也是必不可少，雖然我沒有那么多機器去做，但是我琢磨了一下，百度云、阿里云、騰訊云、華為云等一系列云服務器新用戶都有幾天試用期，這集群機器不就有了嗎？嘿嘿

數(shù)據(jù)庫我們使用MongoDB，因為我們的數(shù)據(jù)并不要求多精確。redis肯定是必選了。但是作為內存數(shù)據(jù)庫，占用內存的大小這就是我們必須要考慮的。我們的去重過濾都是放在redis中的，所以必須對齊進行優(yōu)化。具體原因請看：

redis存儲為什么必須優(yōu)化？

我先在自己機器上抓取了部分數(shù)據(jù)，查看redis中的請求列表和去重列表

從請求列表中的數(shù)據(jù)量可以知道下載還是比較慢的，這就是為什么我們要用分布式進行爬取了。然后再看去重數(shù)據(jù)，七十五萬條。不大的數(shù)據(jù)量，但是看下內存占用情況。

執(zhí)行刪除語句flushall后，再查看內存使用情況

在我8G內存的Mac上占用260M的內存可以忍受，但是在我那可憐的只有1G的云服務器上，卡到我都快鏈接不上了，我們可是以八千萬數(shù)據(jù)為目標的，實際才爬取了二十多萬條有效數(shù)據(jù)，去重記錄都七十多萬了，如果到了一億條數(shù)據(jù)，以目前的情況來看，卡爆服務器也到不了。

本來還有一個xmla:items結構，存儲我們的抓取數(shù)據(jù)，我把它提取到了MongoDB當中。xmla:requests中是待爬取請求列表，我們爬取下載的時候這個數(shù)據(jù)量還是會逐漸減少的，至少不會無限增大。但是這個xmla:dupefilter中存取的是去重數(shù)據(jù)，每一次請求都會記錄下來，所以這個數(shù)據(jù)只會隨著我們的爬取一直增大。那么這就是我們要進行優(yōu)化的重點。

下面我們來規(guī)劃一下下來要做的事情，按步驟來：

1. docker環(huán)境安裝部署

2. redis集群配置操作

3. 用戶數(shù)據(jù)抓取流程分析

4. 用戶打賞信息抓取流程分析

5. 使用BloomFilter修改scrapy-redis，減少過濾內存占用

6. 反爬處理：IP代理池、User-Agent池

7. 使用Gerapy和docker部署分布式環(huán)境

8. 抓取數(shù)據(jù)清理，數(shù)據(jù)分析規(guī)劃

看完上述內容，你們掌握如何利用scrapy進行八千萬用戶數(shù)據(jù)爬取與優(yōu)化的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！