內容來源：2018 年 09 月 07 日，新浪微博系統開發工程師陳浩在“RTC2018 實時網際網路大會”進行《微博直播場景下百萬併發的訊息互動系統》演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

閱讀字數：2867 | 8分鐘閱讀

摘要

本次分享主要介紹微博直播場景系如何實現答題互動系統的技術方案。

直播答題簡介

傳統的手機直播主頁面一般由直播音視訊流和下方的訊息互動兩部分組成。直播答題不同的地方僅在於引入了一個答題互動的方式。主持人的口令能夠控制客戶端行為，也就是答題的發起由他決定，答對的使用者會獲得獎金激勵，每輪答題結束後會立刻展示出實時資料，比如每個選項的選擇人數。

技術挑戰分析

直播答題的核心需求是在海量使用者同時線上的情況下，確保每個使用者的答題畫面都能展現，並能在直播過程中流暢的參與答題，最終分得獎金。

高併發

在直播答題中，海量使用者要在首題下發的前幾分鐘全部成功加入房間，在答題的10秒倒計時內又會有海量使用者同時提交答案，答題的過程中會產生海量答題的訊息下發。這三個場景都存在一個明顯的波峰，給我們帶來的技術挑戰在於海量資料高併發的處理能力。

可靠性

成功展示答題畫面是使用者參與答題的首要條件，每輪答題都可能淘汰一批參與使用者，正常情況下只有在使用者答錯的時候才會被淘汰。但如果由於未展示答題畫面而產生淘汰，那就是技術問題了，而我們的硬性要求是不能因為技術原因導致使用者淘汰。所以這裡的技術難點是海量題目訊息下發的成功率以及答題畫面的成功展現。

實時效能

每一輪的答題只有10秒的倒計時，因此要確保在這個時間內確保能展示畫面給使用者，答題結束後需要實時展示出統計結果。這個技術難點在於極短時間內對海量資料的實時下發和統計分析。

答題設計方案

我們為解決問題所設計的技術方案是基於微博直播現有的技術架構，上圖是微博直播互動的架構圖，核心在於短連和長連這塊。短連線使用私有Wesync協議，支援SSL，它是支撐百萬下發訊息互動的核心服務。長連負責維護訊息可通道可動態擴縮容，並支援使用者分組。

其實整個方案設計的核心是解決答題信令通道選擇問題，也就是如何下發題目的訊息，讓使用者在短時間內收到。

方案一

我們首先想到的方案是輪詢，客戶端不斷髮起查詢請求，由服務端控制是否返回結果。不過大量無用的請求會消耗頻寬資源，給服務端帶來了持續性的壓力。同時由於和音視訊流不在一個通道內，所以題目到達的時間和音視訊流到達時間難以保持一致。

方案二

方案二是複用音視訊流的通道，將題目資訊直接放入音視訊流中一起下發。這樣題目下發的時間就和主持人口令發出的時間一致，使用者感知不到時間差，體驗要好很多。它的缺點是一旦網路抖動或者直播中斷，題目資訊就會丟失。

方案三

第三個方案是不依賴直播通道，轉而複用互動通道下發，這樣通道就獨立了，不再受直播流影響。它的缺陷也是在於無法保持題目下發時間和音視訊到達時間的一致。

這是3個方案的一個簡單對比。可以看到採用互動通道的方式，接入難度和擴充套件性較好，而直播流通道的方式，擴充套件性就比較差，因為它依賴於音視訊流。

經過綜合考慮，我們最終的方案決定使用獨立通道，確保答題信令不受直播流訊號影響。且由於微博直播現有的互動通道能支援千萬級訊息下發，所以複用互動訊息通道的方式是更好的選擇。

上圖為直播答題的整個流程圖，答題和評論互動由短連服務支撐，在發題和結果展示資訊方面使用pub的方式，然後經過廣播訊息通過長連發送給使用者。

典型問題解決

實時典型問題解決

直播流經過採編裝置最終推給客戶是有時間延遲的，客戶端收到的題目和視訊流到達時間不一致。如上圖所示，主持人在t0發題，使用者在t2才能聽到聲音，而題目在t1就到達了。

對此的解決方案是在視訊流的擴充套件欄位中新增伺服器時間戳，並在互動通道的下發題目訊息體中也新增伺服器時間戳，最終客戶端通過直播流擴充套件欄位中的時間戳匹配答題訊息進行展現。

實時方面的另一個典型問題是海量資料的實時統計。首先每一輪答題都要實時計算海量使用者的狀態和統計結果，這些資料包括使用者答案是否正確、使用者是否需要復活、使用者是否有復活卡。其次每一輪答題只有發題和展示答案兩個指令，因此沒有單獨的指令告訴伺服器何時處理資料，而且海量資料還需要快速計算。

一次性獲取所有資料肯定是不現實的，所有我們的方案是化整為零，並行處理。當發題指令到達服務端的時候，先按照一定規則對使用者進行細粒度拆分，同時根據流延時、答題結束時間計算出資料處理的開始時間，然後將切分好的使用者分片和執行時間封裝成任務分片置於一個延時佇列中，到達執行時間後由處理機的叢集拉取任務。

處理機拉取到任務後會根據使用者的選擇、狀態以及長連地址，對使用者訊息進行整合，將眾多小訊息合併成訊息體。

訊息體最後會發送給長連，長連線服務收到訊息體後再進行拆分，按照uid拆分下發給使用者。

可靠性典型問題解決

就像前面提到的，使用者在弱網環境下很容易發生丟包斷連導致無法收到題目資訊，從而被淘汰。既然使用者的網路環境我們無法保證，那麼只能去實現更穩定更快速的自動重連機制，同時服務端在一定時間內無條件重傳題目訊息，客戶端通過訊息id判重。另外下發的訊息體內包含了最遲展現時間，這樣即使直播流斷了也能展示答題畫面。

高併發典型問題解決

高併發涉及的問題有多個。首先是如何高併發提交答案，如果有百萬使用者線上，需10秒內提交完答案，提交請求集中在3-6秒，此時QPS峰值預估在30萬。另外還要保證使用者答案能在短時間內完全提交，不能請求撤回。

解決的思路也很簡單，主要是實現邏輯分離和請求合併。對使用者的請求處理快速返回，重邏輯往後延遲，上行保持輕邏輯。在資源端對使用者的請求做合併，交給獨立的執行緒池進行批量的提交。但流量達到負荷設計閾值的時候，自動隨機重試請求做時間補償，以保證使用者都能提交答案。

第二個問題是海量訊息下發，對於千萬級訊息實時下發的系統來說，訂閱端的網路頻寬壓力也是巨大的。面對頻寬壓力，一方面可以進行訊息壓縮，減少傳輸中的冗餘，另一方面是訊息降量，根據使用者選項對一些小訊息進行分組合並。訊息推送能力在於提升訊息的吞吐量。

第三個問題是上線保證方面，直播答題沒有灰度放量的過程，上線即全量，對系統服務承載能力需要一個量化的資料進行評估。

所有我們在上線之前要進行多輪壓測以及持續的效能優化，功能開發的同時測試人員會進行測試方案設計，問題修復階段進行單介面測試，找出介面效能瓶頸點。介面優化的同時進行整體壓測環境搭建。之後的效能優化階段，由測試人員著手單機的綜合壓測和全鏈路壓測。

以上為本次分享內容，謝謝大家！