兩年前，我參與了一個支持100萬用戶同時在線、20萬並發的直播答題系統的架構設計，下文將以『直播答題』的應用場景為例，帶你了解當前疫情下火爆的直播應用背后的技術架構。內容分成以下4個部分：
- 產品功能簡介
-
面臨的技術挑戰
-
技術選型及依據
-
架構設計方案
01 產品功能簡介
直播答題能在當時成為風口，得益於它的玩法足夠簡單，用戶教育成本幾乎為0。簡單來說就是：全民在線PK、10秒答題、超時或答錯即退出游戲、成功答對所有題即可平分獎金，俗稱在線版的開心辭典。在了解系統設計方案和架構之前，先看看直播答題應用有哪些核心功能？下面是APP端的幾張產品截圖：
1、答題以活動的形式展開，每場活動都會預先公布直播開始時間、答題總獎金、紅包雨獎金等信息。
2、活動時間到后，用戶就可以進入直播間，看到實時的視頻流，有專業的主持人進行串詞口播，場控人員會配合主持人同步進行發題、公布答案等操作。3、題目下發后，用戶有10秒的作答時間，答錯或者超時即退出游戲，如果用戶有復活道具在答錯時會自動使用，用戶能繼續進行答題。4、為了留住答錯用戶，活動期間有多場紅包雨，用戶點擊屏幕就有概率搶到。
5、活動期間用戶可發彈幕，同時會有彈幕滾屏輪播，以營造熱鬧的直播氛圍。
6、其他功能：邀請新人、活動榜單、獎金提現等。
其他直播類應用在產品功能上和直播答題類似，基本也是這兩類：
1、直播的基礎功能：連麥互動直播（支持多碼率、多協議，多主播同框）、美顏特效、彈幕、IM聊天、點贊、屏幕共享等功能性需求，以及防盜鏈、涉黃涉政鑒別等非功能性需求。
2、應用本身的個性化功能：比如答題場景中的發題目、作答、公布答案，電商場景中的商品展示、一鍵下單購買，網紅直播場景中的禮物打賞。
02 面臨的技術挑戰
當時我們做直播答題應用時，面臨以下技術挑戰：
1、音視頻處理及傳輸：涉及音視頻編碼、實時美顏、視頻推流、CDN加速分發、終端適配和播放，流量統計等諸多技術點，而且我們當時的技術團隊沒有專門做音視頻方面的專家。
2、高並發請求：參考了沖頂大會等答題競品的用戶量級，預計會有100W用戶同時在線，1秒內有20W用戶同時答題；1秒內單個用戶可觸屏發起4-5次搶紅包請求，並發最大可達到500W QPS.3、高帶寬壓力：按照標清視頻的標准，觀看直播的碼流至少為1Mbps，如果100W用戶在線，光視頻流的出口帶寬能達到976.56G bps。1條彈幕可達到130字節，1秒要滾屏20條彈幕，如果需要同時推送給100W用戶，彈幕的出口帶寬也將達到19.37G bps.4、高計算壓力：1道題目的對錯判斷涉及到答案比對、復活道具的使用、判斷用戶是否創了新紀錄，同時還涉及一系列的反作弊策略（比如前面的題目答錯了將無法繼續作答），在主持人口播公布答案的瞬間，如何快速完成100W用戶的答題結果計算？5、資金流的正確性和安全性：單個用戶最多搶3個紅包如何不多領？財務上如何保證答題獎金、紅包獎勵不出現1分錢的誤差？6、低延遲性要求：直播場景下如何整合視頻流和業務數據流，做到聲音、主播畫面和題目同步，以保證用戶體驗？
7、對商城交易業務的低干擾：直播答題僅作為商城的一個運營活動，核心目標是導流，它依托商城原有的用戶體系，運營系統，大數據系統，提現通道等，如何做到對商城現有交易系統的低干擾？
可見答題這種泛娛樂的直播場景還是有挺多技術挑戰的，它取決於直播應用的用戶量級和業務流程。就算是直播電商這種低頻交易轉化的場景，要是李佳琪在帶貨，同樣也會面臨瞬時搶購的高並發挑戰，所以架構設計時必須考慮業務最高峰時的壓力，並且系統的各個環節必須具備動態可伸縮的能力。
03 技術選型及依據
一. 音視頻處理及傳輸的方案選型
音視頻處理及傳輸，因為技術團隊不具備這方面的能力，所以當時調研了各種雲廠商的付費解決方案，最終采用了騰訊雲的直播解決方案。主持人側：通過演播室的專業攝像設備，搭載騰訊雲提供的obs推流軟件，即可進行視頻錄制和推流。用戶側：APP端集成騰訊雲的SDK，動態拿到推流地址后即可觀看直播。
二. 業務數據流的方案選型
業務數據是指除音視頻以外的，和答題應用場景相關的數據（比如題目、答案、彈幕、紅包等）。騰訊雲提供了兩種可選方案：
1、題目預先設置好，直接由騰訊雲的SDK通過音視頻通道下發，打入直播流中。
2、讓題目先通過騰訊雲的IM通道快速送達觀眾端APP，在觀眾端先緩存下來，等待播放器通知了預期的 NTP 時間戳之后，再把題目顯示出來。
騰訊雲的這兩種方案都可以提供“音-畫-題”的完美同步，但是存在以下局限：用戶的答案必須以HTTP請求方式匯總到答題服務器，這一塊必須自己開發，另外公布答案、搶紅包、彈幕這些業務騰訊雲系統都是不支持的，在底層通信通道上仍然需要自行開發。考慮上述局限以及業務的多變性，我們最終打算自研業務數據流通道。這樣視頻流和業務數據流會分兩個通道下發，因為業務流相對視頻流的數據量很小，只要能保證業務邏輯的處理速度和業務數據的下行速度，“音-畫-題”的延遲是可以接受的。畢竟當時已經是4G時代，如果用戶側的網速不行，視頻流可能都無法正常觀看了。為了做到業務數據流的獨立傳輸，需要實現一個長連接、高性能的網關服務器（支持100W用戶同時在線，20W並發答題，彈幕實時推送等要求），我們的技術選型是：Netty、ProtoBuf、WebSocket，選型理由：
1、Netty：Netty是當時最流行的高性能和異步NIO框架，直播答題的業務場景中，涉及到題目下發、彈幕、下紅包雨等非常多的推送場景，而且一場答題活動中，客戶端和服務端的通信頻繁，長連接比短連接在性能上更優。
2、ProtoBuf：作為客戶端和服務端的數據交換格式，PB是一種效率和兼容性都很優秀的二進制數據傳輸格式，在碼流和序列化速度上明顯優於JSON、XML、hessian等主流格式，同時支持向前向后兼容以及各種主流語言。
3、WebSocket：是 HTML5 一種新的協議，用來實現客戶端與服務器端的長連接通訊。
三. 服務端的部署方案選型前面提過，直播答題僅作為商城的一個運營活動，它依托商城原有的用戶體系，運營系統，大數據系統，提現通道等。現有的商城系統部署在我們自建的機房中，為了降低對商城現有交易系統的低干擾，我們采用了『私有雲+公有雲』的混合部署方案。將高並發的答題系統以及它所依賴的緩存、MQ等公共組件部署在公有雲上，方便彈性擴展，同時降低對商城交易系統的流量沖擊。
04 架構設計方案
一. 音視頻直播架構
上面是騰訊雲直播解決方案的架構圖，其他雲廠商（比如阿里雲）的直播解決方案，技術架構類似。感興趣的同學可以直接去騰訊雲官網上詳細了解，這里不做展開。
二. 數據流方案
音視頻流采用了騰訊雲的直播解決方案，而業務數據流（活動、題目、答案、彈幕、紅包等）則采用了自研的長連接方案。架構圖中的答題系統和答題運營后台也均為自研。客戶端會分開處理兩個通道的數據，以控制用戶交互上的變化。
三. 基於TCP長連接的通信架構
上面的通信架構用於業務數據流的傳輸，流程如下：
1、客戶端使用websocket與服務端進行通訊，用戶進入答題直播間時建立連接，退出直播間時斷開連接。
2、Nginx對websocket做負載均衡。
3、TCP網關基於netty實現，用於維持長連接和轉發業務請求，不負責具體的業務邏輯，它和下層業務系統（答題系統）通過RPC接口進行交互，主要考慮后續其他業務可以復用TCP網關層，所以將業務下沉。客戶端和網關之間通過心跳機制保證連接的有效性以及檢測僵屍連接。
4、QQ號碼轉讓平台地圖消息推送（比如彈幕、下發題目、公布答案等諸多場景）由下層業務（答題系統）通過MQ通知TCP網關，再由TCP網關推送給客戶端。
四. 長連接通信中的數據傳輸格式定義
通信架構中另外比較重要的是數據傳輸格式的定義，客戶端和TCP網關之間，TCP網關和答題系統之間均采用的是protobuf格式。下面分開說一下比較關鍵的幾個格式定義。
4.1 客戶端請求消息的格式
1、消息類型標識：-1表示心跳消息、0表示用戶驗證消息、>0 表示業務類消息
2、用戶ID：用戶的唯一標識，在前置的登錄流程中已經獲得
3、Token：用戶登錄APP后的授權令牌，在前置的登錄流程中已經獲得
4、BizData：真正的業務數據，protobuf序列化后的byte數組，由下層業務自行定義更具體的格式
4.2 客戶端響應消息的格式
1、消息類型標識：和請求中的消息類型保持一致
2、狀態碼：0表示處理失敗，1表示處理成功
3、BizData：真正的業務數據，如果狀態碼為0，該字段為4字節的異常碼（100表示token驗證失敗，101表示請求業務層失敗），如果狀態碼為1，該字段為業務層返回的protobuf序列化后的byte數組，同樣由下層業務自行定義更具體的格式
4.3 業務數據的ProtoBuf格式定義
1message Message
2{
3 MessageType messageType = 1; // 消息類型，枚舉值
4 string sequence = 2; // 消息序號
5
6 Request request = 3; // 請求類消息
7 Response response = 4; // 響應類消息
8 Notification notification = 5; // 推送類消息
9}
這里的格式設計比較巧妙，通過Message頂層消息把Request、Response、Notification這3類消息包裝起來，並且定義一個MessageType枚舉值，用來表示消息類型，另外sequence字段表示消息的唯一序列號，需要保證發送端內唯一，這樣發送端收到Response后可以進行匹配處理。有了上面的統一消息格式，答題系統就可以針對不同的MessageType定義不同的消息處理器，配置好映射關系后，即可實現消息路由。
五. 系統總體架構
1、網關層：架構上同時采用了TCP網關和HTTP網關，TCP網關上一章節已經講解，它主要用於維持百萬用戶同時在線，以及答題期間的實時數據交互（包括加入直播間、推送題目、答題、推送答案、搶紅包、彈幕推送等）。HTTP網關為APP端提供Restful接口，用於低頻的數據請求，比如活動首頁、排行榜、個人獎金明細、新人邀請、分享等場景。
2、答題系統：Dubbo實現，最核心的業務服務，同時面向C端和B端系統提供RPC接口，包括活動管理、題庫管理、直播間管理、以及面向C端的高並發接口（比如加入直播間、答題、搶紅包等）。這個集群用到了很多高並發設計的通用方法：比如服務的橫向擴容能力、多級緩存、異步化、限流等，后面的章節再做具體介紹。另外，通過MQ的事務消息+對賬機制保證資金流在答題系統和余額系統的一致性。3、答題運營系統：后台系統，供運營人員和直播時的場控人員使用，可以管理活動和題目，以及直播過程中的各種業務操作（比如配合主持人的口播下發題目、公布答案、發紅包等）。六. 部署架構
直播答題的在線用戶量以及並發量遠超過商城的交易系統，為了減少對主交易流程的影響，采用了上述『私有雲+公有雲』的混合部署方案，自建機房和雲機房之間通過網絡專線打通。直播答題有關的應用服務器、存儲服務器、網絡帶寬都在雲端，可以根據流量監控做到快速擴容，隨着運營計划的調整，也可以隨時增減服務器，靈活性高。
七. 答題系統的高並發設計方案
7.1 答題接口的高並發設計方案
答題接口的並發預計20W QPS，在說設計方案之前，先簡單列一下答題接口的判斷邏輯：
1、需要判斷答題活動是否仍在進行中
2、需要判斷用戶是否已經答錯出局
3、需要判斷用戶輸入的題目是否是當前正在作答的題目
4、需要判斷用戶上一道答對的題和當前這題是否連續
5、需要判斷用戶作答是否已經超時
6、需要判斷用戶的答案是否是正確答案
7、如果答錯了，需要判斷用戶是否有復活卡
8、如果有復活卡，需要判斷前面的題是否用過復活卡了
除了上述判斷邏輯外，還有一些寫操作，比如更新每個答案選項的選擇人數，更新用戶的答對題號或者出局題號，更新復活卡的使用記錄等，總的來說，答題是一個讀多寫少的接口。為了應對高並發，我們采取了以下技術方案：1、答題接口的所有邏輯只操作緩存，不操作數據庫。采用Write Behind Caching的更新模式（即只更新緩存，在答題結束后再異步批量更新數據庫）。2、多級緩存：本地緩存+Redis緩存。同時在答題活動開始之前，會先將活動的配置信息，題目，答案等所有靜態數據都預熱到本地緩存中。
3、Redis 一主多從 + 哨兵的部署架構，確保高並發和高可用，同時分業務模塊配置了多套Redis實例（用戶、彈幕、直播作答、獎金榜單）做進一步分流。
4、調整判斷邏輯的順序，上面提到的8個判斷邏輯，其中前4個都屬於安全校驗，因為客戶端已經通過交互做了攔截，如果用戶不采取作弊手段肯定都能校驗通過。所以我們將第5、6、7步邏輯做了前置，通過后再進行前4步校驗，這樣大大減少了計算量。
7.2 答題結果推送的設計方案如何在主持人口播公布答案的瞬間，將答題結果推送給幾十萬作答用戶？因為用戶的作答結果有非常多的狀態：有答對的和答錯的，有使用復活卡和未使用復活卡的，有出局的，不同狀態下APP端的交互均不同，完全是一種依賴服務端的有狀態推送。為了解決這個並發計算問題，我們采用了一個比較巧的設計方案，很好地將有狀態推送轉變成了無狀態推送：1、將答題結果的計算前置到用戶提交答案的時候同步完成（上一節的方案），這樣相當於將瞬時的計算壓力分散到10秒作答時間里了。
2、用戶的作答結果也在第1步計算完成后立刻推送給用戶了，不用等到主持人口播公布答案的瞬間，否則的話仍然涉及到並發讀取作答結果以及有狀態推送，對存儲服務器以及帶寬的瞬時壓力仍然存在。
3、但是作答結果如果提前推送給客戶端必然存在安全問題，黑客抓包就能提前知道是否答對了，可以利用批量賬號進行作弊。為了解決這個問題，我們對作答結果采用XOR進行了對稱加密，同時將秘鑰延遲到公布答案的瞬間才下發，而且每道題的秘鑰均是隨機生成的。這樣就很好地解決了安全問題。
4、公布答案的瞬間，我們只需要推送一個非常小的數據包給客戶端即可，而且這個數據包所有用戶都是一樣的。
7.3 搶紅包接口的高並發設計方案
屏幕下紅包雨，用戶觸屏點中紅包就直接拆了，所以搶紅包接口的並發非常高，1秒內單個用戶可觸屏發起4-5次搶紅包請求，按照百萬用戶在線，並發最大可達到上百萬QPS，下面說下技術方案：
1、紅包金額提前計算好並加載到redis中：在創建活動時，運營可配置紅包總金額以及紅包總個數，系統在創建活動時就會提前計算出各個紅包的金額並存儲到redis中，相當於計算前置。
2、客戶端限流：在接口設計時，我們就預埋了一個限流因子參數，可由服務端動態控制客戶端的限流比例，在通知客戶端搶紅包的接口中，我們根據當前的在線人數以及紅包總個數動態算出限流因子，控制最多只有10W QPS的請求能發到服務端。
3、服務端限流：根據服務器數量以及紅包總數量提前計算出每秒令牌的生成數量，基於guava的RateLimiter進行二次限流。
4、前面3步基本把並發降下來了，再通過lua腳本保證原子性即可，搶紅包的結果也是在活動結束后再異步刷新到數據庫。
7.4 其他高並發的優化點
1、Redis緩存的對象要盡可能簡化（用不到的字段不要存），key的長度要盡可能短（高並發下的瓶頸在於IO），善於利用pipeline組裝多個命令（但是命令個數不能過多）
2、各種連接池和JVM參數的調整：涉及redis連接池、dubbo的線程池、JVM內存大小，可以在壓測環境下找到合理值。
3、答題系統可水平擴展（scale out），同時通過dubbo的分組配置將ToB和ToC接口進行隔離部署，避免相互影響。
最后，關於直播架構再簡單總結下:
1、音視頻編碼和傳輸，這些基礎性的直播功能，除非公司有錢有實力，否則建議直接用騰訊雲或者阿里雲的解決方案（斗魚、蘑菇街這些知名的直播應用都還用的騰訊雲）。
2、架構設計重點放在應用本身，根據直播應用的用戶量級和業務特性先確定通信架構（長連接還是短鏈接，或者兩者混用）。3、要根據業務高峰來做方案設計，如果是高並發場景，要把高並發當做一個系統性問題去對待：從客戶端到服務端，從網絡帶寬到部署架構，甚至產品設計等各個維度全盤考慮，要摳各種細節。