今天帶來一個有意思的東西-分布式B站爬蟲任務(wù)系統(tǒng)
老規(guī)矩,還是先看下最終的使用效果,應(yīng)用入口:https://www./LT,(為了防止濫用下載以及記錄下載,所以還麻煩注冊一下啦) 輸入視頻番號,點(diǎn)擊下載,就進(jìn)入任務(wù)界面 任務(wù)界面可以看到視頻信息,實(shí)時(shí)下載信息,和錯誤信息 任務(wù)處理完成后,點(diǎn)擊立即下載,從一個CDN加速的地址得到了視頻 那么下面就把本次的開發(fā)和實(shí)施流水賬記錄一下
想要對B站進(jìn)行爬蟲,首先要準(zhǔn)備好技術(shù)手段和相關(guān)工具,對B站的網(wǎng)站結(jié)構(gòu)和數(shù)據(jù)流向進(jìn)行一些分析,進(jìn)行可行性的調(diào)研 首先打開B站任意一個視頻,可以看到地址都是這樣的格式 于是我們把AV后面的號碼叫做番號(此番號非老司機(jī)番號) 而有些視頻不止一段,如果是第二段視頻,則是這個地址: 而如果把Index后面的2換成1,也可以達(dá)到和第一個地址一樣的效果 然后用Fidder工具,分析一下網(wǎng)頁,可以看到有如下一些資源 剔除基本的JS文件、CSS文件、圖像文件后,剩下來的就是一些有用的信息了,而在有用的信息中最終篩選出如下幾個信息 1、AID是視頻的番號,也就是網(wǎng)址URL后面的那串唯一數(shù)字 2、CID是彈幕的番號,每個視頻AID會對應(yīng)一個CID 3、彈幕的信息存儲在了這樣的URL中:http://comment.bilibili.com/15075110.xml 4、視頻的信息存儲在了這樣的URL中:https://interface.bilibili.com/playurl?cid=15075110&appkey=84956560bc028eb7&otype=json&type=&quality=3&sign=c070bfd93a84cab542e7c874add6839e 因?yàn)楸敬沃饕窍螺d視頻,所以就著重看一下視頻存儲的信息,打開上面的URL后發(fā)現(xiàn)了最終視頻的地址 太好了,一下子就給了視頻尺寸和視頻最終的下載地址,那么我們用瀏覽器打開一下這個URL看一下,可以成功下載! 注:以上相關(guān)分析實(shí)際上是經(jīng)過了1-2個小時(shí)的反復(fù)嘗試和模擬得出的,有2個細(xì)節(jié)補(bǔ)充一下,1、B站的服務(wù)器會根據(jù)HTTP頭信息的不同返回FLV格式或者MP4格式,2、B站的視頻可能用了不同廠商的CDN服務(wù),有些視頻地址無法直接下載,會判斷refer信息和瀏覽器信息) 接下來繼續(xù)分析,注意看這個URL可以發(fā)現(xiàn),尾部有一個sign,說明做了客戶端和服務(wù)端的簽名驗(yàn)證,并不是很傻瓜的有直接通過AID或者CID關(guān)聯(lián)的下載地址,分析進(jìn)入到這一步后,我很快的就打了自己的臉,我曾在文章《關(guān)于.NET玩爬蟲這些事》中說過,一切網(wǎng)站行為都可以分析出HTTP Javascript來,只要分析得當(dāng),根本不需要用瀏覽器來進(jìn)行爬蟲模擬,但這尼瑪B站鬼的Web結(jié)構(gòu)(忍不住想罵人,典型的垃圾Python、PHP向的開發(fā)人員做出來的鬼東西,代碼邏輯混亂、隨便一看就是到處修補(bǔ)修改的痕跡,生成出來的HTML、JS的邏輯和層次毫無美感),看了2個小時(shí),眼睛都看疼了,楞是沒分析出簽名方法,也許再看看會有結(jié)果,但是我等不及了,所以這時(shí)候祭出爬蟲神器-無頭瀏覽器 這里我選擇了PhantomJS這個無頭瀏覽器,具體的使用過程就不詳述了,有興趣可以到官網(wǎng)了解一下,寫了如下分析代碼 通過代碼我們可以很清楚的看到,主要是兩個目的,輸出包含interface.bilibili.com的URL以及本次視頻的標(biāo)題 測試一下,確實(shí)可以得到URL和標(biāo)題,這里有個要注意的是,B站默認(rèn)是GB2312編碼,所以PhantomJS要加一個參數(shù),就是輸出編碼改為GB2312 到此為止,可以說完成了整個爬蟲部分的調(diào)研,至少是有完整的可行性了。
有了可行性后,就可以天馬行空的進(jìn)行業(yè)務(wù)功能的設(shè)計(jì)了,既然上面說到那個雞雞網(wǎng)站特別不好用,那么我們就來重新設(shè)計(jì)一下這個爬蟲的功能 一、用戶端功能 1、用戶可以輸入視頻番號和序號提交視頻下載(注:干凈清爽的提交界面) 最終界面如下: 2、用戶可以在提交視頻下載后,可以看到實(shí)時(shí)的處理進(jìn)度,并且能夠看到自己以前提交的任務(wù)(注:需要設(shè)計(jì)任務(wù)機(jī)制,做好狀態(tài)控制,這里采用Azure的存儲隊(duì)列) 最終界面如下 3、用戶最終的下載速度特別快(注:使用CDN和網(wǎng)絡(luò)存儲技術(shù),這里采用阿里云的CDN和OSS) 最終效果如下: 4、下載進(jìn)度能夠通過郵件進(jìn)行視頻信息的推送(注:使用郵件模板技術(shù),詳見:《使用阿里云郵件推送服務(wù)架設(shè)自己郵件驗(yàn)證與推送體系》,這里采用SendCloud云服務(wù)) 最終效果如下: 二、服務(wù)端功能 1、考慮到B站CDN可能會限制IP地址使用,需要使用分布式的爬蟲設(shè)計(jì)(注:這里使用Windows Console Application程序) 2、增加下載效率,使用多線程技術(shù)(注:因?yàn)槭褂?NET做爬蟲,多線程控制還算比較穩(wěn)定和齊全) 3、對無頭瀏覽器進(jìn)行精準(zhǔn)的控制(注:這里是Windows環(huán)境,考慮使用.NET里面的Process類進(jìn)行控制) 有了業(yè)務(wù)功能做指導(dǎo),下面就可以進(jìn)行完整的系統(tǒng)設(shè)計(jì)了
老規(guī)矩,先放出整體設(shè)計(jì)圖 其中具體的技術(shù)細(xì)節(jié)和代碼如下: 一、分布式架構(gòu)的核心 1、分布式Win32控制臺程序需要有賬號體系,這樣可以進(jìn)行節(jié)點(diǎn)的實(shí)施狀態(tài)管理和記錄
2、任務(wù)的新增、獲取、核銷等,需要精準(zhǔn)的控制,不能出現(xiàn)并發(fā)沖突,所以這里使用了消息隊(duì)列,也就是上面所說的Azure存儲隊(duì)列服務(wù) 任務(wù)的新增和分配主要代碼如下:
3、豐富的日志和錯誤處理機(jī)制 因?yàn)闀恢眻?zhí)行,分布式節(jié)點(diǎn)的穩(wěn)定性非常重要,Windows Console Application程序本身是非常穩(wěn)定,因此在具體的代碼里面,內(nèi)存控制與對象釋放、死循環(huán)的避免、多線程優(yōu)化、異常的捕捉和處理等都非常重要,這里不一一洗漱,都是開發(fā)的基本功,做類似的應(yīng)用的話,大家也需要多注意。另外因?yàn)闊o頭瀏覽器的執(zhí)行,是放在分布式的客戶端里面進(jìn)行的,因此也需要對無頭瀏覽器進(jìn)行精準(zhǔn)控制,下面會詳細(xì)說到
二、爬蟲任務(wù)的數(shù)據(jù)結(jié)構(gòu) 本案例中由于只對單一URL進(jìn)行分析和爬蟲,業(yè)務(wù)邏輯并不復(fù)雜,考慮到需要支持進(jìn)度查詢、狀態(tài)控制等,數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)如下,就2個表 1、爬蟲任務(wù)表(記錄爬蟲任務(wù),控制狀態(tài)、記錄過程參數(shù)等) 2、視頻存儲表 任務(wù)完成后,就把CDN加速好的視頻信息存儲下來,一方面進(jìn)行冗余查詢,另一方面也用于其他用戶下載可以秒下 三、無頭瀏覽器的精準(zhǔn)控制 1、.NET里面的Process類 上面提到了,無頭瀏覽器畢竟有一個瀏覽器內(nèi)核的執(zhí)行,而在任務(wù)處理的高峰,可能會不斷的調(diào)用、銷毀這個瀏覽器,而Web行為又是非常不穩(wěn)定的,所以想要分布式的穩(wěn)定,就一定要進(jìn)行無頭瀏覽器的精準(zhǔn)控制。這里用到了.NET里面Process來控制無頭瀏覽器的執(zhí)行,主要的技術(shù)點(diǎn)有:
這里可以看到,我們之前在PhantomJS里面寫的JS代碼,主要就輸出了兩點(diǎn),一個是包含下載地址JSON數(shù)據(jù)的URL地址,另一個是視頻的標(biāo)題,這里都做了記錄
2、重試的機(jī)制 實(shí)測中發(fā)現(xiàn),無頭瀏覽器的失敗率和出錯率還是挺高的,因此在數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)的時(shí)候,就預(yù)留了重試機(jī)制,當(dāng)分布式客戶端處理視頻失敗時(shí),服務(wù)端重新提交消息隊(duì)列,超過一定的次數(shù)再宣告任務(wù)失敗
三、CDN的加速處理 1、之前在這篇文章《使用阿里云對Web開發(fā)中的資源文件進(jìn)行CDN加速的深入研究和實(shí)踐》中,提出了一種非常好的資源管理和加速方式,核心思路包括三點(diǎn)
2、同樣的,在本次案例中,也使用了這樣的處理方式,最終給用戶的下載地址是CDN下載地址,具體的處理流程可以看上面的設(shè)計(jì)圖,應(yīng)該能一目了然 3、關(guān)于對上傳到OSS的處理 在最初的設(shè)計(jì)方案中,分布式客戶端完全下載到視頻文件的內(nèi)容后,是上傳到服務(wù)端,由服務(wù)端統(tǒng)一進(jìn)行上傳,后來評估這樣的方式,對服務(wù)端的壓力和帶寬占用都明顯提升了,既然是分布式系統(tǒng),應(yīng)當(dāng)充分利用分布式客戶端的資源,所以改為分布式客戶端直接上傳文件到阿里云OSS中,這樣做唯一的弊端是分布式客戶端會獲取明文的阿里云管理密鑰,于是又加入了阿里云RAM權(quán)限管理,加入了OSS子權(quán)限的控制,問題就迎刃而解了。
四、郵件推送的處理 在上面的功能設(shè)計(jì)中,加入了郵件推送的功能,詳細(xì)的設(shè)計(jì)思路參見這篇文章《使用阿里云郵件推送服務(wù)架設(shè)自己郵件驗(yàn)證與推送體系》,郵件模板就是HTML代碼,這里就不多說了,但有一個小插曲,就是阿里云的郵件推送服務(wù),實(shí)在是太爛了,特別是QQ郵箱的到達(dá)率奇差無比,因此最終的實(shí)施部分換成了搜狐的SendCloud解決方案。
好啦,整個實(shí)施到這里基本上就差不多了,老規(guī)矩,還是要總結(jié)和思考一下:
|
|