最近大火的直播答題系統在技術上難實現嗎?挑戰有多大?

即構科技ZEGO發表於2018-01-29

最近大火的直播答題系統在技術上難實現嗎?挑戰有多大?

作者|冼牛

編輯|徐川


直播答題已經是風口,毋容置疑。對攻城獅們來說,2018 年春節是個坎,直播答題技術做細緻做到位了,才能安心過個好年。


為了應對這個挑戰,我們首先分析一下直播答題和傳統直播在技術上的不同,然後深度解釋一下直播答題解決方案的海量併發派題和收題。


最近大火的直播答題系統在技術上難實現嗎?挑戰有多大?


直播答題和傳統直播在技術上的不同

直播答題首先是直播,然後是答題。直播答題是構建在傳統直播基礎上的創新玩法,和傳統直播的不同包括下面幾點:




1. 海量併發派題

就傳統視訊直播而言,直播間通常線上使用者人數是少幾萬人,通常情況下超過五萬的不多。而對直播答題來說,直播間線上使用者人數超過百萬那是很平常的事情,某一線直播平臺旗下的直播答題直播間線上人數更是突破了五百萬人。因此,派題的環節要承受百萬級別的海量併發壓力,而且所有使用者都是在活躍答題的,這是傳統視訊直播不曾面對過的壓力。幸運的是,直播答題可以利用視訊直播實時媒體通道來派發題目,為派題的實時性和可達性提供了天然的基礎。


2. 海量併發收題

派題可以重用視訊直播實時媒體通道,可是收題卻不能這麼做,因為使用者端不推流,而且收題要反饋標準答案和進行統計。收題不但不能重用實時媒體通道,而且還帶來同樣是百萬級別的併發壓力,那麼要在視訊直播架構以外構建一個分散式的子系統來處理。


3. 視訊和答題同步

派題重用視訊直播實時媒體通道,和語音視訊資料包是天然同步的。需要在實時媒體通道擴充套件一個資料通道,題目資訊可以附著在相應的語音視訊資料包上傳輸,做到視訊和答題同步。同時,為了應對網路損傷,在隨後的資料中可以傳送一定的冗餘拷貝,接收端再進行排重。


4. 主持人背景特效

中國的直播答題應用受美國同類先行產品 HQ Trivia 的啟發,主播的背景都是虛擬的特效,比如變幻的色彩,以後也可能演變成 AR 特效。這裡有一個技術點就是要把畫面上除了主持人以外的部分去除,然後填充上特效的畫面。主持人主持直播答題節目的背景幕布是綠色的,因為在拜耳陣列中綠色的成分最多,攝影機捕捉到的綠色資訊最多,在後期更容易去除綠色通道的資訊。


直播答題:海量併發派題和收題

直播答題是疊加在視訊直播上的業務創新,題目資料量比語音視訊少很多,但派題和收題的併發壓力是海量的。下面對關鍵技術點進行探討,拋磚引玉,希望對大家有所啟發。




首先,我們看一下直播答題的業務流程:

1.主持人發出派題指令;

2.題目資訊通過實時通訊網路和實時分發網路送達給使用者;

3.VIP 使用者從實時通訊網路拉取題目資訊;

4.普通使用者從實時分發網路拉取題目資訊;

5.如題目資訊包含完整內容,則下一步,如果只有題目 ID,則到業務伺服器查詢題目內容;

6.使用者把題目答案提交給答題統計分析伺服器,同時得到標準答案反饋;答題統計分析伺服器是分散式的叢集,統計答題結果,反饋給主持人;



然後,我們看看各個網路服務實體的分工:

1.實時通訊網路:為實時傳輸而設計的網路,能實時傳輸海量資料,不只是語音視訊。它比實時分發網路(比如 CDN)的延遲更低,具有動態回源和對抗弱網等特點。

2.實時分發網路:為實時分發海量內容而設計的網路,優點是能支撐海量併發,成本相對也比較低,缺點是延遲相對於實時通訊網路要高一些。

3.答題統計服務:為統計使用者提交的題目答案而在視訊直播架構外設計的服務,能反饋標準答案,並且統計所有題目答案,最後反饋給主持人。該服務要能承受海量併發壓力。

4.業務伺服器:如果派題資訊包含完整題目內容,使用者不需要再查詢題目內容;如果派題資訊只有題目 ID, 那麼使用者要到業務伺服器查詢題目內容。該服務也要承受海量併發壓力。


最後,我們再分析直播答題中的關鍵環節:


1. 海量併發派題

派題的指令必須是主持人端發出,然後伺服器會擔負起啟動向海量使用者群發題目的任務。題目是優先順序最高的訊息,不能像處理 IM 訊息那樣採取低優先順序訊息拋棄,或者使用者分桶等應對海量併發的策略,必須要確保訊息內容實時到達每個使用者的終端,這是實打實的實時海量併發。另外,如果由伺服器單點在毫秒級別時間內複製群發 N 份訊息,那麼單點就要承受巨大的壓力,這明顯是不可能的。那麼海量併發派題要依仗內容分發網路的能力。內容分發可以通過實時低延遲網路或者 CDN 來完成,考慮到 CDN 有成本的優勢,因此 VIP 使用者的派題由實時網路完成,其它使用者的派題要由 CDN 來完成。


2. 海量併發收題

收題的環節由使用者觸發,每個使用者答題的時間視窗不盡相同,因此每個使用者提交題目的時間有秒級的差別。然而,海量使用者在數秒之內提交答案,題目答案屬於重要訊息,不能做拋棄處理,伺服器的壓力也是巨大的。為了減少伺服器壓力,使用者的答題將會被就近提交到邊緣節點並且獲得正確答案反饋,整體的答題統計結果將會由分散式的伺服器叢集來完成,最後傳達到主持人端,使得主持人可以近乎實時地宣佈統計的結果。


3. 視訊和答題同步

視訊直播要低延遲,題目派送同樣也要低延遲,而且要和視訊畫面同步。通過 IM 的能力來派題是很難做到視訊和派題同步的,因為語音視訊傳輸通道和 IM 的通道是相互獨立的。一般的做法是通過實時語音視訊的擴充套件資料通道來附帶傳輸題目資訊,讓視訊和題目天然就同步。考慮到網路抖動和丟包等網路損傷的情況,在答題時間視窗內,要適當傳送題目的冗餘 copy,然後使用者端做排重,避免題目資訊丟失而導致使用者收不到題目。

通過實時語音視訊傳輸通道來派題的技術手段其實並不新鮮。在視訊直播的 K 歌場景中,主播 K 歌要儘量還原線下的體驗 -- 主播的歌聲、畫面還有歌詞必須要同步在使用者端顯示。歌詞資訊在主播端打點,通過實時語音視訊傳輸通道同步傳輸給使用者端。

另外,還可以為主持人的背景增加特效,甚至 AR 效果。主持人要在綠幕背景前進行節目主持。在採集和編碼之間的前處理環節,開發者獲得原始視訊資料,把綠色的畫面部分去除,把主持人的畫像扣出來,補充上動畫或者 AR 等特效處理後,再把視訊資料塞給編碼環節。使用第三方視訊直播 SDK 的話,那麼該視訊直播 SDK 必須要開放前處理介面,開發者才能獲得原始視訊資料,否則開發者沒辦法通過前處理的方式在視訊畫面增加特效。比如說,支援 WebRTC 的瀏覽器沒有開放前處理介面,那麼基於 WebRTC 的視訊直播方案在瀏覽器端就不支援在視訊畫面上增加特效。


4. 題目內容安全性

直播答題懸賞鉅額獎金,各種黑產活躍到其中,題目內容的安全性十分重要。題目內容快取在使用者終端是萬萬不可的,必須實時地送達使用者終端,否則黑產從使用者終端可以提前獲得題目內容。

針對題目派送的方式,目前市面上有兩種第三方直播答題方案:第一種方案,技術方案通過實時語音視訊通道派送題目的全部內容,該方案的優勢是完全負責了派題的安全性和併發壓力,開發者不需要投入開發成本。第二種方案,技術方案通過實時語音視訊通道只派送題目 ID,使用者終端獲得題目 ID 後,到開發者的業務伺服器查詢題目內容。該方案的優勢是開發者完全把控題目內容的私密性。

以即構 ZEGO 的直播答題方案為例,如果題目內容小於 1000 位元組,也就是 500 箇中文字元,可以通過實時語音視訊通道傳輸所有題目內容;如果超過 1000 位元組,通過實時語音視訊通道傳輸題目 ID, 然後由使用者終端以題目 ID 從就近伺服器拉取題目內容。

如果第三方直播答題方案只派送題目 ID,開發者可以把題目內容快取在就近伺服器,通過題目 ID 獲取題目內容,增加的延遲很小,不會影響使用者體驗。然而,開發者要承擔查詢題目的海量併發壓力,還要實現題目內容的安全保護機制,比如說拉取題目要鑑權,題目傳輸要加密,和題目時效視窗的控制等,開發成本也就水漲船高。



寫在最後

視訊直播的魅力在於,它已經成為類電視的流量入口,類似開心辭典等在電視上被驗證過的業務玩法也會逐一在視訊直播平臺上嘗試和落地。如果說直播答題是視訊直播的第二春,那麼每年春天還會來,請不要意外。


作者介紹

冼牛,即構科技資深語音視訊專家,北京郵電大學計算機碩士,香港大學工商管理碩士,多年從事語音視訊雲服務技術研究,專注互動直播技術、語音視訊社交和實時遊戲語音。


相關文章