新浪微博技術分享：微博實時直播答題的百萬高併發架構實踐

併發軟體架構 · 發表 2018-10-22 12:23:24

摘要：本文由“聲網Agora”的RTC開發者社群整理。 1、概述本文將分享新浪微博系統開發工程師陳浩在 RTC 2018 實時網際網路大會上的演講。他分享了新浪微博直播互動答題架構設計的實戰經驗。其背後的百萬高併發實時架構，值得借鑑並用於未來更多場景中。本文正文是對演講內容的整理，請繼...

本文由“聲網Agora”的RTC開發者社群整理。

1、概述

本文將分享新浪微博系統開發工程師陳浩在 ofollow,noindex">RTC 2018 實時網際網路大會上的演講。他分享了新浪微博直播互動答題架構設計的實戰經驗。其背後的百萬高併發實時架構，值得借鑑並用於未來更多場景中。本文正文是對演講內容的整理，請繼續往下閱讀。

另外，即時通訊網整理的直播答題相關文章有：

《近期大熱的實時直播答題系統的實現思路與技術難點分享》

《 2018新“風口”——直播答題應用原理解析》

新浪微博團隊分享的：《新浪微博技術分享：微博短視訊服務的優化實踐之路》一文，您也可能感興趣。

（本文同步釋出於： http://www.52im.net/thread-2022-1-1.html ）

2、什麼是直播答題

首先，如下圖所示，這是一個傳統的直播頁面。它的主頁面是直播的音視訊流，下面顯示的是訊息互動，包括評論、點贊和分享。什麼是直播答題呢？

直播答題其實本質上還是一個直播的場景，只是引入了答題的互動方式。主持人可以通過口令控制客戶端的行為，比如控制發題。同時，直播答題通過獎金激勵，帶動更多使用者參與進來。在每一次答題之後，會將資料實時展示出來。下圖展示的是直播答題的流程，中間的部分是會重複進行的環節。

3、直播答題的技術挑戰

直播答題的核心需求用一句話就可以概括：海量使用者同時線上的場景下，確保使用者的答題畫面能展現，在直播過程中流暢地參與答題，最終分到獎金。

這一句話中有三個關鍵點，分別對應了不同的技術要求：

第一個： 就是“海量使用者同時線上”。海量使用者帶來的就是海量的資料。在這個場景下第一個使用者高峰出現在活動開始前，海量的使用者會在幾分鐘內加入房間。在直播進行中，答題的十秒倒計時內，海量使用者會同時提交答案，會產生海量的答題訊息，包括我們互動與題目結果的訊息，所以下發、上傳雙向都會出現高併發。這就考驗我們對海量資料高併發的處理能力。

第二個： 關鍵點是“答題畫面能夠展示”，這是非常基礎且首要的需求，因為使用者參與答題，如果畫面都展示不出來，那麼這場遊戲就沒法進行下去了。每一輪答題都可能淘汰一批使用者，淘汰答錯題的使用者是正常的，但如果是因為未能展示出答題畫面而淘汰，那就是技術問題。其技術難點在於海量題目的下發成功率要有保證，給技術提出的對應要求就是服務的可靠性。

最後一個： 是“流暢地參與答題”，這與使用者體驗相關，每一輪答題時間間隔很短，一旦錯過一道題的答題時間，使用者就沒法完成這個遊戲，所以要保證訊息下發後，10秒內讓使用者收到並且正常展示。同時，每一輪答題後，主持人需要立刻看到答題資料，包括有多少使用者答對，有多少使用者使用了復活卡等。這給我們帶來的是對海量資料進行實時下發、實時統計的挑戰。

4、答題直播技術方案

我們基於微博直播的技術現狀，設計了一個方案。如下圖所示，這是我們微博直播互動的架構圖。左側是微博的基礎設施服務，基本上都是自研的，比如最核心的短連使用的是自研的 wesync 協議，支援SSL，是支撐百萬互動訊息下發的核心服務之一。長連維護訊息通道可動態擴容，海量使用者同時湧入後會進行容量的計算，對我們的資源進行擴縮容。

在直播答題方案設計（下圖）中，最核心的就是解決答題信令通道的選擇問題。我們想到了三個方案來解決。

方案一：輪詢

客戶端不斷進行請求，由服務端控制時間視窗，到時間我們開放請求，結果返回。優點是實現簡單。缺點在於大量無用請求會消耗大量頻寬資源，給服務端帶來持續性的壓力。而且，題目到達時間與音視訊流到達時間難以保持一致。

方案二：複用音視訊通道

我們可以在音視訊流裡面直接加入題目的資訊。在主持人口令位置插入題目訊息。客戶端播放音視訊流，收到題號資料的時候，直接把題目給展示出來。這個方案的特點就是題目展示的時間能和主持人口令一致，也就是說使用者是感知不到時間差的，體驗非常好。缺點是太依賴於音視訊流，一旦出現網路抖動，或者直播流中斷，使用者可能會收不到題目，這個遊戲就沒法繼續下去了。

方案三：複用互動通道

直播有音視訊流通道和互動通道，題目使用互動通道獨立下發。它的特點是題目下發不依賴於音視訊流，它的通道是獨立的，不受直播流的影響，即使直播中斷了，哪怕是黑屏，我們也可以把題目的畫面展示給使用者。缺點也是一樣，因為它並不是跟音視訊在一個通道，所以它們兩者時間難以保持一致。

我們從接入難度、擴充套件性和音視訊同步三方面，對三個方案進行了對比。針對以上三個方案，我們最終使用方案三。首先要保證答題不受直播流訊號的影響。我們現在微博直播現有的架構上能夠支援千萬級訊息的下發，我們把答題資訊放到互動通道下發，這是我們有能力支援的。答題和互動的上行訊息由短連服務支撐，在發題以及結果展示資訊的時候，我們直接通過主動推送，經過廣播訊息，通過長連最終發給使用者。也就是說整個答題就直接採用了互動的通道，與音視訊流完全隔離開來。

5、如何解決實時性、可靠性與高併發？

針對實時性、可靠性和高併發，三個典型的問題，我們也有不同的解決方法。

實時性問題主要體現在兩方面，一個是答題畫面的實時展現，另一個是海量資料的實時統計。

5.1 答題畫面的實時展現

直播流經過採編裝置發給使用者客戶端是有延時的，中間經過編解碼，到達客戶端的時間和主持人發出口令時間，有一個時間間隔。我們採用互動通道的時候，這兩個時間我們是不容易做同步的。客戶端收到題目和視訊流最終到達的時間會出現不一致的情況。

我們看下圖，當主持人 T0 時間發題，使用者在 T2 時間有可能才收到這個視訊流。如果我們 T0 的時間進行發題，在 T1 的時間題目就到使用者客戶端了。問題在於我們如何抹去 T2-T1 的時間差。對於使用者體驗來說，我們在 T1 把題目畫面展示出來，在下一秒才能聽到主持人說“請聽題”，這體驗肯定不好。

我們的處理方式是在音視訊每隔一幀，或者一定幀數內，插入伺服器的時間戳。同時，我們在下發的訊息體內也埋入伺服器的時間戳。客戶端播放音視訊流的時候，到達相應的時間戳時，把跟這個時間戳相匹配的訊息在頁面上渲染出來，也就是展示出了答題的畫面。通過使用統一時間戳進行對標，就抹平了視訊與題目的時間差。

5.2 海量使用者資料實時統計

我們每一輪答題結束的時候，都要統計使用者的答題狀態，比如使用者答案是否正確，使用者是否復活，以及他是否有復活卡。當這些邏輯都放在一起需要處理，並且又是在一個海量資料場景下時，就變得非常複雜了。

另一方面，每一輪的答題只有發題和展示答案兩個指令。主持人在發題時會說題目是什麼，最終說出結果是什麼。沒有單獨指令觸發告訴伺服器端什麼時候進行資料處理。而且，海量資料需要得到快速的計算。

把海量使用者產生的海量資料一次性的獲取出來，這是不現實的，耗費資源相當巨大，所以我們的思路就是化整為零，做並行處理。

首先，當發題指令到達服務端的時候，我們按照一定的規則對使用者進行細粒度的拆分。同時根據倒計時和流延時等等時間綜合考慮，能夠計算出我們什麼時候才能開始進行資料處理。然後將剛才做好的使用者分片，封裝成任務分片，放在延時隊列當中。到達這個執行時間的時候，由我們處理機的機群拉取這個任務，只有在執行時間才會去處理這個任務，不會出現使用者答案沒有提交上來，我們就開始計算了。所以不會有將一部分使用者漏掉的狀況。

處理機拉到使用者的任務分片時，根據使用者選擇、狀態，以及長連的地址，我們對使用者的訊息整合。因為有海量的使用者，所以體量巨大，但是答案選擇往往只有 A、B、C、D 四種，針對答案我們可以做一個分組，比如選 A 使用者有多少，選 B 使用者有多少。我們把單獨訊息進行合併，選A的使用者做為一個集合。

也就是說這一個訊息體其實包含了很多使用者的訊息，從訊息體量上，我們進行降量，把小的訊息合成成一個訊息體，把一個訊息體發給我們長連線的服務，長連線收到這個訊息體的時候再進行拆分。它類似於訊息的一個包，我們把它按照使用者的維度進行拆分，比如使用者選擇了什麼答案，它是否使用過復活卡，以及它的狀態，進行拆分後，最終下發給使用者。這樣在前面進行拆，在後面進行合，合完之後再拆一遍，這是我們解決海量資料實時計算的思路。

5.3 海量題目下發的可靠性

剛才我們提到，使用者如果在弱網情況下發生丟包，我們推送的訊息有可能他沒法收到，他一旦收不到訊息，整個答題沒有辦法進行，有可能導致他在這一輪就被淘汰了。我們的解決方案是實現更穩定更快速的自動重連。雖然使用者的網路環境是我們沒有辦法去保證的，但我們可以更快速發現他和我們長連伺服器斷連，並進行更快速的重連。

同時，在答題倒計時內我們無條件對題目訊息進行重傳。例如我們 T0 的時候發現使用者斷連，他在 T1 的時候，下發的題目收不到，然後我們在 T2 進行重連，在 T3 進行無條件重傳的時候保證他收到這個題目。我們在訊息體埋了一個最遲的展現時間，到這個時間後客戶端一定會把題目展示出來，保證他就算直播流斷了，我們也可以正常答題。面對黑屏的場景我們也可以完成答題的遊戲。

5.4 高併發提交答案

每道題目下發後有一個10秒倒計時。假設有百萬使用者線上，在10秒之內都可以提交完答案，使用者提交答案大概集中在第3至第6秒之間，QPS 峰值預估會有30萬。其次，我們保證使用者答案在短時間都能提交，因為它是有時間限制的，如果我們做了削峰限流，他就會錯過答題的時間視窗。所以我們不能對請求做削峰限流。

我們的解決方案就是使用者請求處理快速返回時，把重邏輯往後延，前面上行請求只是保證輕邏輯，讓它可以迅速返回。

同時，在資源層，我們對資料進行處理時，把使用者提交的請求做一個合併，交給獨立的資源池進行批量提交。我們的設計方案有一個閾值，當遇到不可控，比如負荷達到我們設計的閾值時，我們有自動隨機重試的機制，保證使用者把答案都可以提交上來。對於重試請求我們做針對性的時間補償，這樣保證流量達到我們負載的時候，答題請求也可以提交上來。