在上一篇文章中，主要講了我獲取斗魚彈幕和某些靜態(tài)頁面的方法，在數(shù)據(jù)獲取到之后，如何有效的組織和存儲數(shù)據(jù)直接關系到后續(xù)數(shù)據(jù)能否可以背有效使用。
為了更直觀的說明獲取到的這些數(shù)據(jù)如何組織和使用，我大致花了兩張圖來說明。
數(shù)據(jù)存儲結構
通過爬蟲或是直接通過tcp通訊獲取到的斗魚靜態(tài)頁面數(shù)據(jù)和彈幕聊天內容數(shù)據(jù)組織形式如下圖所示：
我使用mongodb來存儲和管理數(shù)據(jù)，把上述的數(shù)據(jù)存儲在名為Douyu的數(shù)據(jù)庫中，將數(shù)據(jù)分別存于Roominfo、chatmsg、rocket、rocketbyDay四個表中。
靜態(tài)頁面數(shù)據(jù)存儲
其中Roominfo庫主要記錄通過爬蟲獲取到的當前開播房間信息，字段主要包括用以紀錄數(shù)據(jù)獲取時間的date、開播房間人氣audience、房間標題roomtitle、主播名anchor、房間標簽tag、當前房間封面圖片img、房間標識符roomid。
在實際使用中，可以隔時執(zhí)行靜態(tài)頁面數(shù)據(jù)獲取腳本從而獲取這些數(shù)據(jù)，通過對audience進行排序可以輕易獲取到人氣最高的房間，并且能夠將這些房間信息以json的格式傳輸?shù)叫枰牡胤健６鴄udience和tag的組合也可以獲取不同類型直播房間人氣對比結果。
我在項目中通過服務器上的crontab每隔10分鐘執(zhí)行一次靜態(tài)頁面數(shù)據(jù)獲取任務.
0,10,20,30,40,55 * * * * python /path/to/allRooms.py
反應給前端的結果可以通過這個頁面看到。
彈幕聊天內容
上一篇說過，最初打算是想要對彈幕聊天內容進行自然語言分析的，但是由于一直沒來得及搞，也就擱淺了，對與彈幕聊天內容，只是簡要的紀錄了包括發(fā)送者sender_id、發(fā)送時間date和彈幕內容content，由于每次獲取的彈幕數(shù)據(jù)都是獲取當時人氣最高的房間彈幕，所以彈幕內容大都是什么“白銀三杰”、“最強王者”之類的。。。
火箭紀錄
自然語言分析沒搞成，所以現(xiàn)在的重點工作是紀錄觀眾贈送火箭，通過這些數(shù)據(jù)做出一些圖表。
對火箭信息紀錄使用了兩個表：rocket和rocketbyDay。
rocket主要是獲取實時火箭信息，通過與斗魚彈幕服務器建立連接，根據(jù)彈幕消息類型將贈送火箭的信息獲取到，主要包括：贈送者sender_id、接受者recver_id、贈送時間date和禮物類型gift。
rocketbyDay則是通過每天0:05分統(tǒng)計前一天火箭隨著時間的分布情況，以天為單位的date、每天火箭總數(shù)count和當天火箭具體數(shù)據(jù)data。
紀錄這些內容主要是可以統(tǒng)計出每日逐時禮物贈送情況、每天贈送禮物的土豪排名、受到火箭主播排名等。大致結果可以點擊當天火箭信息和火箭歷史數(shù)據(jù)查看具體內容。
消息實時轉發(fā)
上述數(shù)據(jù)可以看作直播數(shù)據(jù)中的長時間數(shù)據(jù)，而其中的一些需要“保鮮”的數(shù)據(jù)例如在有土豪贈送給主播火箭之后，觀眾可以在兩分鐘內到該房間搶魚丸禮物，對于這種需要“保鮮”的數(shù)據(jù)，我通過redis的pub／sub來接收和轉發(fā)，并通過socke.io實時發(fā)送給當前打開頁面的觀眾。大致過程如下圖所示：
遇到的問題和下一步計劃
在實際項目運行中，有好幾次出現(xiàn)mongodb莫名其妙掛掉的現(xiàn)象，由于項目運行在騰訊1核心1gb內存的云主機上（學生優(yōu)惠一個月只要一塊錢，23333333），這讓我很快想到是不是在寫入數(shù)據(jù)的時候，mongodb占用內存過高導致掛掉（之前在學校做項目的時候曾經見到過mongodb在大量寫入數(shù)據(jù)的時候數(shù)據(jù)庫掛掉的現(xiàn)象）。
于是，打開終端，連接到云主機上， 進入到mongodb目錄：
./mongo
use Douyu
db.setProfilingLevel(1)
然后靜待下次數(shù)據(jù)庫掛掉。果然在某個整10分鐘的時候，數(shù)據(jù)又數(shù)不出來了，重啟數(shù)據(jù)庫，打開mongodb客戶端：
db.system.profile.find().limit(2)
出現(xiàn)的內容：
正如猜想的那樣，果然是由于寫入的時候造成了數(shù)據(jù)庫的問題。
這時，機智的我想到了師妹那里還有個閑置的云主機，征用過來做個讀寫分離試下吧（當然我也想搞個副本集，好多主、好多從、好多分片。。。關鍵不是沒條件嘛）。減輕了服務器負載之后，數(shù)據(jù)庫掛掉的現(xiàn)象沒有再出現(xiàn)啦。
到目前為止，項目基本上可以正常運行，在數(shù)據(jù)操作這方面，打算在增加一些內容，比如分析某個游戲在每天隨時間觀眾人數(shù)變化、某個主播直播時段、某個游戲人氣變化情況等等。
下一篇內容主要講后端flask的一些情況以及前后端數(shù)據(jù)傳輸方式等。
