基于asyncio 異步協程框架實現收集B站直播彈幕

2019-11-25 16:34:48

字體：大中小

來源：轉載

供稿：網友

前言

雖然標題是全站，但目前只做了等級 top 100 直播間的全天彈幕收集。

彈幕收集系統基于之前的B 站直播彈幕姬 Python 版修改而來。具體協議分析可以看上一篇文章。

直播彈幕協議是直接基于 TCP 協議，所以如果 B 站對類似我這種行為做反制措施，比較困難。應該有我不知道的技術手段來檢測類似我這種惡意行為。

我試過同時連接 100 個房間，和連接單個房間 100 次的實驗，都沒有問題。>150 會被關閉鏈接。

直播間的選取

現在彈幕收集系統在選取直播間上比較簡單，直接選取了等級 top100。

以后會修改這部分，改成定時去 http://live.bilibili.com/all 查看新開播的直播間，并動態添加任務。

異步任務和彈幕存儲

收集系統仍舊使用了 asyncio 異步協程框架，對于每一個直播間都使用如下方法來加進 loop 中。

danmuji = bilibiliClient(url, self.lock, self.commentq, self.numq)task1 = asyncio.ensure_future(danmuji.connectServer())task2 = asyncio.ensure_future(danmuji.HeartbeatLoop())

其實若將心跳任務 HeartbeatLoop 放入 connectorServer 中去啟動，代碼看起來更優雅一些。但這么做是因為我需要維護一個任務列表，后面會有描述。

在彈幕存儲上我花了些時間選擇。

數據庫存儲是一個同步 IO 的過程，Insert 的時候會阻塞彈幕收集的任務。雖然有 aiomysql 這種異步接口，但配置數據庫太麻煩，我的設想是這個小系統能夠方便地部署。

最終我選擇使用自帶的 sqlite3。但 sqlite3 無法做并行操作，故開了一個線程單獨進行數據庫存儲。在另一個線程中，100 * 2 個任務搜集所有的彈幕、人數信息，并塞進隊列 commentq, numq 中。存儲線程每隔 10s 喚醒一次，將隊列中的數據寫進 sqlite3 中，并清空隊列。

在多線程和異步的配合下，網絡流量沒有被阻塞。

可能的連接失敗場景處理

彈幕協議是直接基于 TCP，位與位直接關聯性較強，一旦解析錯誤，很容易就拋 Exception（個人感覺，雖然 TCP 是可靠傳輸，但B站服務器自身發生錯誤也是有可能的）。所以有必要設計一個自動重連機制。

在 asyncio 文檔中提到，

Done means either that a result / exception are available, or that the future was cancelled.

函數正常返回、拋出異常或者是被 cancel，都會退出當前任務。可以使用 done() 來判斷。

每一個直播間對應兩個任務，解析任務是最容易掛的，但并不會影響心跳任務，所以必須找出并將對應心跳任務結束。
在創建任務的時候使用字典記錄每個房間的兩個任務，

self.tasks[url] = [task1, task2]

在運行過程中，每隔 10s 做一次檢查，

for url in self.tasks:  item = self.tasks[url]  task1 = item[0]  task2 = item[1]  if task1.done() == True or task2.done() == True:    if task1.done() == False:      task1.cancel()    if task2.done() == False:      task2.cancel()    danmuji = bilibiliClient(url, self.lock, self.commentq, self.numq)    task11 = asyncio.ensure_future(danmuji.connectServer())    task22 = asyncio.ensure_future(danmuji.HeartbeatLoop())    self.tasks[url] = [task11, task22]

實際我只見過一次任務失敗的場景，是因為主播房間被封了，導致無法進入直播間。

結論