? ? ? 自己喜歡在上班的途中聽點有聲書契吉，所以經(jīng)常在喜馬拉雅上找資源耗拓，要找到一個好聽的節(jié)目不容易次询，雖然在喜馬拉雅官網(wǎng)上可以按分類來看贸呢，但是卻不能按點贊數(shù)或者評論內(nèi)容排序找镰烧，不是很方便，于是就用Python寫了個爬蟲楞陷，把所有聲音的相關(guān)信息怔鳖、評論內(nèi)容都抓取下來，然后放到數(shù)據(jù)庫來分析固蛾，這樣喜歡什么樣的資源结执，直接根據(jù)聲音或評論的內(nèi)容來匯總分析度陆，結(jié)果就一目了然了。
流程實現(xiàn)圖
Urllib,request, selenium
? ? ? Web的訪問使用urllib和urllib2献幔，相比request懂傀、selenium來說，效率更高些蜡感，感覺也穩(wěn)定些蹬蚁，之前使用request的遇到https的網(wǎng)址處理起來有點問題。而selenium呢郑兴，自動化操作可以不用分析具體頁面的處理邏輯缚忧，不過對于這種海量數(shù)據(jù)，處理起來速度就會慢很多杈笔。
多線程和隊列
? ? ? 使用了2個threading.Thread的繼承類闪水，Ximalaya類用來解析聲音專輯，分析提取專輯內(nèi)的聲音信息蒙具，解析出評論地址球榆；CommentDown類專門用來提取保存評論內(nèi)容信息；一般一個聲音會有多條評論禁筏，多的上千條評論持钉，所以CommentDown分配了10個線程來提取評論，Ximalaya分配了3個線程來分析專輯的聲音信息篱昔。
? ? ? 使用了2個隊列每强，1個用來保存專輯url，大小100州刽，1個用來保存評論url空执，大小設(shè)置為200；這樣在超過隊列最大值的時候就會停下來穗椅，等待前面隊列里處理了再繼續(xù)辨绊，可以有效控制整個爬蟲速度，以免訪問太過頻繁被網(wǎng)站給屏蔽了匹表。
數(shù)據(jù)保存
? ? ? 使用了Mongodb數(shù)據(jù)庫门坷，Nosql處理高并發(fā)的，相比SQL速度和效率要高得多袍镀。Mongodb里在music下保存聲音的相關(guān)信息（比如聲音的專輯名默蚌、專輯地址、聲音的地址苇羡、聲音的時長绸吸、點贊數(shù)等等），bookcomment下保存聲音的評論內(nèi)容。
斷點續(xù)傳惯裕、重復(fù)處理
? ? ? 遇到中途中斷后要繼續(xù)執(zhí)行温数，還得考慮下斷點續(xù)傳，這里處理得比較簡單粗暴蜻势，在Ximalaya處理聲音的時候撑刺，會先判斷數(shù)據(jù)庫是否有聲音的地址，如果存在就是跳過不再處理握玛，在CommentDown處理評論的時候够傍，判斷判斷數(shù)據(jù)庫是否有聲音的地址，如果存在就是跳過不再處理挠铲，這樣對于后面比較費時處理部分都可以直接跳過冕屯，也不會存在有重復(fù)的數(shù)據(jù)會影響最后的分析的問題。
異常處理
? ? ? 程序在解析頁面的時候拂苹，可能會有超時之類的異常情況安聘，增加了對應(yīng)的異常處理，socket.setdefaulttimeout(20)設(shè)置全局超時為20秒瓢棒，超過20秒就會超時報錯浴韭，這樣再通過異常捕獲來處理，設(shè)置了異常處理記數(shù)器脯宿，對于異常頁面重復(fù)處理指定次數(shù)后不再處理念颈，避免部分聲音頁面被刪除一直訪問異常的情況。
數(shù)據(jù)分析
? ? ? 最后對保存到數(shù)據(jù)庫的數(shù)據(jù)進行分析连霉，做分析的時候Nosql做關(guān)聯(lián)分析太痛苦了榴芳，完全不如sql查詢方便，于是把數(shù)據(jù)導(dǎo)入到Oracle來進行的分析跺撼，根據(jù)評論內(nèi)容中的關(guān)鍵字來標識判斷（例如：“點贊”窟感，“好聽”，“太棒“之類的都判斷成受歡迎）财边，最后再用匯總統(tǒng)計出結(jié)果肌括。
評論最受歡迎的TOP20有聲書：
評論最受歡迎的TOP10綜藝節(jié)目：
評論最受歡迎的TOP20音樂：
評論普通話說得最好的節(jié)目：
最后源代碼也附上了，有興趣的朋友可以自己看看：
