海量資料的挑戰：微博直播答題架構實踐
本文將分享新浪微博系統開發工程師陳浩在 RTC 2018 實時網際網路大會上的演講。他分享了新浪微博直播互動答題架構設計的實戰經驗。其背後的百萬高併發實時架構，值得借鑑並用於未來更多場景中。以下是對演講內容的整理。歡迎大家留言提問，我們將邀請演講人為你解答。
什麼是直播答題
首先，如下圖所示，這是一個傳統的直播頁面。它的主頁面是直播的音視訊流，下面顯示的是訊息互動，包括評論、點贊和分享。什麼是直播答題呢？
直播答題其實本質上還是一個直播的場景，只是引入了答題的互動方式。主持人可以通過口令控制客戶端的行為，比如控制發題。同時，直播答題通過獎金激勵，帶動更多使用者參與進來。在每一次答題之後，會將資料實時展示出來。下圖展示的是直播答題的流程，中間的部分是會重複進行的環節。
直播答題的技術挑戰
直播答題的核心需求用一句話就可以概括： 海量使用者同時線上 的場景下，確保使用者的 答題畫面能展現 ，在直播過程中 流暢地參與答題 ，最終分到獎金。
這一句話中有三個關鍵點，分別對應了不同的技術要求。第一個就是“海量使用者同時線上”。海量使用者帶來的就是海量的資料。在這個場景下第一個使用者高峰出現在活動開始前，海量的使用者會在幾分鐘內加入房間。在直播進行中，答題的十秒倒計時內，海量使用者會同時提交答案，會產生海量的答題訊息，包括我們互動與題目結果的訊息，所以下發、上傳雙向都會出現高併發。這就考驗我們對海量資料高併發的處理能力。
第二個關鍵點是“答題畫面能夠展示”，這是非常基礎且首要的需求，因為使用者參與答題，如果畫面都展示不出來，那麼這場遊戲就沒法進行下去了。每一輪答題都可能淘汰一批使用者，淘汰答錯題的使用者是正常的，但如果是因為未能展示出答題畫面而淘汰，那就是技術問題。其技術難點在於海量題目的下發成功率要有保證，給技術提出的對應要求就是服務的可靠性。
最後一個是“流暢地參與答題”，這與使用者體驗相關，每一輪答題時間間隔很短，一旦錯過一道題的答題時間，使用者就沒法完成這個遊戲，所以要保證訊息下發後，10秒內讓使用者收到並且正常展示。同時，每一輪答題後，主持人需要立刻看到答題資料，包括有多少使用者答對，有多少使用者使用了復活卡等。這給我們帶來的是對海量資料進行實時下發、實時統計的挑戰。
答題直播技術方案
我們基於微博直播的技術現狀，設計了一個方案。如下圖所示，這是我們微博直播互動的架構圖。左側是微博的基礎設施服務，基本上都是自研的，比如最核心的短連使用的是自研的 wesync 協議，支援SSL，是支撐百萬互動訊息下發的核心服務之一。長連維護訊息通道可動態擴容，海量使用者同時湧入後會進行容量的計算，對我們的資源進行擴縮容。
在直播答題方案設計（下圖）中，最核心的就是解決答題信令通道的選擇問題。我們想到了三個方案來解決。
方案一：輪詢
客戶端不斷進行請求，由服務端控制時間視窗，到時間我們開放請求，結果返回。優點是實現簡單。缺點在於大量無用請求會消耗大量頻寬資源，給服務端帶來持續性的壓力。而且，題目到達時間與音視訊流到達時間難以保持一致。
方案二：複用音視訊通道
我們可以在音視訊流裡面直接加入題目的資訊。在主持人口令位置插入題目訊息。客戶端播放音視訊流，收到題號資料的時候，直接把題目給展示出來。這個方案的特點就是題目展示的時間能和主持人口令一致，也就是說使用者是感知不到時間差的，體驗非常好。缺點是太依賴於音視訊流，一旦出現網路抖動，或者直播流中斷，使用者可能會收不到題目，這個遊戲就沒法繼續下去了。
方案三：複用互動通道
直播有音視訊流通道和互動通道，題目使用互動通道獨立下發。它的特點是題目下發不依賴於音視訊流，它的通道是獨立的，不受直播流的影響，即使直播中斷了，哪怕是黑屏，我們也可以把題目的畫面展示給使用者。缺點也是一樣，因為它並不是跟音視訊在一個通道，所以它們兩者時間難以保持一致。
我們從接入難度、擴充套件性和音視訊同步三方面，對三個方案進行了對比。針對以上三個方案，我們最終使用方案三。首先要保證答題不受直播流訊號的影響。我們現在微博直播現有的架構上能夠支援千萬級訊息的下發，我們把答題資訊放到互動通道下發，這是我們有能力支援的。答題和互動的上行訊息由短連服務支撐，在發題以及結果展示資訊的時候，我們直接通過主動推送，經過廣播訊息，通過長連最終發給使用者。也就是說整個答題就直接採用了互動的通道，與音視訊流完全隔離開來。
如何解決實時性、可靠性與高併發？
針對實時性、可靠性和高併發，三個典型的問題，我們也有不同的解決方法。
實時性問題主要體現在兩方面，一個是答題畫面的實時展現，另一個是海量資料的實時統計。
答題畫面的實時展現
直播流經過採編裝置發給使用者客戶端是有延時的，中間經過編解碼，到達客戶端的時間和主持人發出口令時間，有一個時間間隔。我們採用互動通道的時候，這兩個時間我們是不容易做同步的。客戶端收到題目和視訊流最終到達的時間會出現不一致的情況。我們看下圖，當主持人 T0 時間發題，使用者在 T2 時間有可能才收到這個視訊流。如果我們 T0 的時間進行發題，在 T1 的時間題目就到使用者客戶端了。問題在於我們如何抹去 T2-T1 的時間差。對於使用者體驗來說，我們在 T1 把題目畫面展示出來，在下一秒才能聽到主持人說“請聽題”，這體驗肯定不好。
我們的處理方式是在音視訊每隔一幀，或者一定幀數內，插入伺服器的時間戳。同時，我們在下發的訊息體內也埋入伺服器的時間戳。客戶端播放音視訊流的時候，到達相應的時間戳時，把跟這個時間戳相匹配的訊息在頁面上渲染出來，也就是展示出了答題的畫面。通過使用統一時間戳進行對標，就抹平了視訊與題目的時間差。
海量使用者資料實時統計
我們每一輪答題結束的時候，都要統計使用者的答題狀態，比如使用者答案是否正確，使用者是否復活，以及他是否有復活卡。當這些邏輯都放在一起需要處理，並且又是在一個海量資料場景下時，就變得非常複雜了。
另一方面，每一輪的答題只有發題和展示答案兩個指令。主持人在發題時會說題目是什麼，最終說出結果是什麼。沒有單獨指令觸發告訴伺服器端什麼時候進行資料處理。而且，海量資料需要得到快速的計算。
把海量使用者產生的海量資料一次性的獲取出來，這是不現實的，耗費資源相當巨大，所以我們的思路就是化整為零，做並行處理。
首先，當發題指令到達服務端的時候，我們按照一定的規則對使用者進行細粒度的拆分。同時根據倒計時和流延時等等時間綜合考慮，能夠計算出我們什麼時候才能開始進行資料處理。然後將剛才做好的使用者分片，封裝成任務分片，放在延時隊列當中。到達這個執行時間的時候，由我們處理機的機群拉取這個任務，只有在執行時間才會去處理這個任務，不會出現使用者答案沒有提交上來，我們就開始計算了。所以不會有將一部分使用者漏掉的狀況。
處理機拉到使用者的任務分片時，根據使用者選擇、狀態，以及長連的地址，我們對使用者的訊息整合。因為有海量的使用者，所以體量巨大，但是答案選擇往往只有 A、B、C、D 四種，針對答案我們可以做一個分組，比如選 A 使用者有多少，選 B 使用者有多少。我們把單獨訊息進行合併，選A的使用者做為一個集合。也就是說這一個訊息體其實包含了很多使用者的訊息，從訊息體量上，我們進行降量，把小的訊息合成成一個訊息體，把一個訊息體發給我們長連線的服務，長連線收到這個訊息體的時候再進行拆分。它類似於訊息的一個包，我們把它按照使用者的維度進行拆分，比如使用者選擇了什麼答案，它是否使用過復活卡，以及它的狀態，進行拆分後，最終下發給使用者。這樣在前面進行拆，在後面進行合，合完之後再拆一遍，這是我們解決海量資料實時計算的思路。
海量題目下發的可靠性
剛才我們提到，使用者如果在弱網情況下發生丟包，我們推送的訊息有可能他沒法收到，他一旦收不到訊息，整個答題沒有辦法進行，有可能導致他在這一輪就被淘汰了。我們的解決方案是實現更穩定更快速的自動重連。雖然使用者的網路環境是我們沒有辦法去保證的，但我們可以更快速發現他和我們長連伺服器斷連，並進行更快速的重連。
同時，在答題倒計時內我們無條件對題目訊息進行重傳。例如我們 T0 的時候發現使用者斷連，他在 T1 的時候，下發的題目收不到，然後我們在 T2 進行重連，在 T3 進行無條件重傳的時候保證他收到這個題目。我們在訊息體埋了一個最遲的展現時間，到這個時間後客戶端一定會把題目展示出來，保證他就算直播流斷了，我們也可以正常答題。面對黑屏的場景我們也可以完成答題的遊戲。
高併發提交答案
每道題目下發後有一個10秒倒計時。假設有百萬使用者線上，在10秒之內都可以提交完答案，使用者提交答案大概集中在第3至第6秒之間，QPS 峰值預估會有30萬。其次，我們保證使用者答案在短時間都能提交，因為它是有時間限制的，如果我們做了削峰限流，他就會錯過答題的時間視窗。所以我們不能對請求做削峰限流。
我們的解決方案就是使用者請求處理快速返回時，把重邏輯往後延，前面上行請求只是保證輕邏輯，讓它可以迅速返回。
同時，在資源層，我們對資料進行處理時，把使用者提交的請求做一個合併，交給獨立的資源池進行批量提交。我們的設計方案有一個閾值，當遇到不可控，比如負荷達到我們設計的閾值時，我們有自動隨機重試的機制，保證使用者把答案都可以提交上來。對於重試請求我們做針對性的時間補償，這樣保證流量達到我們負載的時候，答題請求也可以提交上來。
海量訊息下發
一條題目訊息，會被複制N份後下發給使用者。百萬使用者產生的答案訊息是海量的，對於千萬級訊息實時下發的系統來說，訂閱端的網路頻寬壓力也是巨大的。如下圖所示，訊息出口的頻寬消耗非常大，因為我們是針對海量使用者的連線。 
我們的解決方法有兩方面。第一就是針對海量訊息下發，對訊息進行體積上的壓縮，減少訊息傳輸的冗餘。壓縮訊息的時候我們採用了一個私有協議，我們儘量壓縮裡面無用的東西，減小傳輸冗餘，減小頻寬的消耗。
第二個是訊息降量，我們根據使用者的答案進行分組，按照分組把這些訊息進行合併，由原來的一條訊息都要推送一次，轉變成下發一個訊息集合。同時，我們提升訊息的吞吐量，採用中介軟體的叢集，進行多埠並行的下發。
上線前的保障
直播答題場景有一個特別明顯的特徵，它不像我們上線其它功能或者介面，我們可以進行灰度放量。直播答題一上線，就是全量，沒有能通過灰度放量發現問題的過程。所以我們對系統服務承載能力需要有一個量化的評估。
我們的處理方式就是進行多輪壓測和持續的效能優化。
首先我們做開發的時候已經開始同步壓測。我們進行一些功能問題修復的時候，壓測的同事可以進行做一些單介面的壓測，找出介面效能的臨界點。開發的同事做優化的同時，壓測組模擬海量使用者線上的場景，搭建壓測的環境。總體來講，有四輪壓測：
1.單機單介面壓測：掌握單機效能資料
2.單機綜合壓測：定位效能損耗點，優化業務處理邏輯
3.負載均衡壓測：評估負載均衡數量
4.叢集全鏈路壓測：
a.搭建起壓機測試叢集，保證能模擬百萬量級使用者產生的資料量
b.按照預估百萬量級使用者消耗的公網頻寬配置起壓機出口頻寬，真實模擬線上業務場景
c.按照預估使用者量和資源消耗量對線上服務及資源叢集進行擴容，對線上服務真實壓測
總結
簡單總結一下，針對音畫與題目同步的實時性問題，我們將直播流和互動通道進行對標，解決題目與音視訊之間的同步問題。
針對海量訊息的實時下發問題，我們通過將使用者分組，把大體量的訊息任務化整為零，做分散式的分批次處理。
針對可靠性的問題，我們通過完善快速自動斷連重試機制，以及題目訊息無條件重傳，來保證弱網下的使用者也能正常參與答題活動。
另外，對於高併發問題，我們將訊息按照使用者選項進行分組，化零為整，降低資訊的推送量。同時，我們對訊息結構進行了優化，從這兩方面解決高併發問題。
最後，還有一個關鍵的核心，就是壓測，通過壓測我們可以快速瞭解上述解決方案是否有效，讓我們可以持續優化解決方案。
掃碼看視訊回顧
（觀看該演講，請空降01:58分）
點選
閱讀原文
獲取更多資料