這場(chǎng)疫情讓線下零售降至冰點(diǎn)，但是卻帶火了直播應(yīng)用。直播電商、直播教育等各類直播應(yīng)用可謂贏得了歷史性的機(jī)會(huì)，很多大眾開始接受并認(rèn)可這種新型應(yīng)用的便利和價(jià)值，個(gè)人感覺隨著5G的普及，『直播+垂直領(lǐng)域+精細(xì)化的私域流量』將會(huì)是互聯(lián)網(wǎng)的一個(gè)大熱點(diǎn)，迎來真正的紅利期。

直播行業(yè)大概在10年多前就開始興起了，秀場(chǎng)直播和游戲直播是PC時(shí)代比較成功的應(yīng)用場(chǎng)景，直到16年，隨著移動(dòng)互聯(lián)網(wǎng)的大規(guī)模普及，直播行業(yè)迎來了真正的元年，成百上千的直播APP出現(xiàn)在大眾視野，大概在18年年初，直播答題當(dāng)時(shí)火了一把，那算是直播類應(yīng)用的第一次全民普及，然后是19年短視頻網(wǎng)站掀起的直播電商?；仡欀辈バ袠I(yè)的發(fā)展歷程，直播類應(yīng)用在各個(gè)領(lǐng)域遍地開花，那么它背后的技術(shù)架構(gòu)你是否了解？

兩年前，我參與了一個(gè)支持100萬用戶同時(shí)在線、20萬并發(fā)的直播答題系統(tǒng)的架構(gòu)設(shè)計(jì)，下文將以『直播答題』的應(yīng)用場(chǎng)景為例，帶你了解當(dāng)前疫情下火爆的直播應(yīng)用背后的技術(shù)架構(gòu)。內(nèi)容分成以下4個(gè)部分：

•  產(chǎn)品功能簡(jiǎn)介
•  面臨的技術(shù)挑戰(zhàn)
•  技術(shù)選型及依據(jù)
•  架構(gòu)設(shè)計(jì)方案

01 產(chǎn)品功能簡(jiǎn)介

直播答題能在當(dāng)時(shí)成為風(fēng)口，得益于它的玩法足夠簡(jiǎn)單，用戶教育成本幾乎為0。簡(jiǎn)單來說就是：全民在線PK、10秒答題、超時(shí)或答錯(cuò)即退出游戲、成功答對(duì)所有題即可平分獎(jiǎng)金，俗稱在線版的開心辭典。

在了解系統(tǒng)設(shè)計(jì)方案和架構(gòu)之前，先看看直播答題應(yīng)用有哪些核心功能？下面是APP端的幾張產(chǎn)品截圖：

1、答題以活動(dòng)的形式展開，每場(chǎng)活動(dòng)都會(huì)預(yù)先公布直播開始時(shí)間、答題總獎(jiǎng)金、紅包雨獎(jiǎng)金等信息。

2、活動(dòng)時(shí)間到后，用戶就可以進(jìn)入直播間，看到實(shí)時(shí)的視頻流，有專業(yè)的主持人進(jìn)行串詞口播，場(chǎng)控人員會(huì)配合主持人同步進(jìn)行發(fā)題、公布答案等操作。

3、題目下發(fā)后，用戶有10秒的作答時(shí)間，答錯(cuò)或者超時(shí)即退出游戲，如果用戶有復(fù)活道具在答錯(cuò)時(shí)會(huì)自動(dòng)使用，用戶能繼續(xù)進(jìn)行答題。

4、為了留住答錯(cuò)用戶，活動(dòng)期間有多場(chǎng)紅包雨，用戶點(diǎn)擊屏幕就有概率搶到。

5、活動(dòng)期間用戶可發(fā)彈幕，同時(shí)會(huì)有彈幕滾屏輪播，以營造熱鬧的直播氛圍。

6、其他功能：邀請(qǐng)新人、活動(dòng)榜單、獎(jiǎng)金提現(xiàn)等。

其他直播類應(yīng)用在產(chǎn)品功能上和直播答題類似，基本也是這兩類：

1、直播的基礎(chǔ)功能：連麥互動(dòng)直播（支持多碼率、多協(xié)議，多主播同框）、美顏特效、彈幕、IM聊天、點(diǎn)贊、屏幕共享等功能性需求，以及防盜鏈、涉黃涉政鑒別等非功能性需求。

2、應(yīng)用本身的個(gè)性化功能：比如答題場(chǎng)景中的發(fā)題目、作答、公布答案，電商場(chǎng)景中的商品展示、一鍵下單購買，網(wǎng)紅直播場(chǎng)景中的禮物打賞。

02 面臨的技術(shù)挑戰(zhàn)

當(dāng)時(shí)我們做直播答題應(yīng)用時(shí)，面臨以下技術(shù)挑戰(zhàn)：

1、音視頻處理及傳輸：涉及音視頻編碼、實(shí)時(shí)美顏、視頻推流、CDN加速分發(fā)、終端適配和播放，流量統(tǒng)計(jì)等諸多技術(shù)點(diǎn)，而且我們當(dāng)時(shí)的技術(shù)團(tuán)隊(duì)沒有專門做音視頻方面的專家。

2、高并發(fā)請(qǐng)求：參考了沖頂大會(huì)等答題競(jìng)品的用戶量級(jí)，預(yù)計(jì)會(huì)有100W用戶同時(shí)在線，1秒內(nèi)有20W用戶同時(shí)答題；1秒內(nèi)單個(gè)用戶可觸屏發(fā)起4-5次搶紅包請(qǐng)求，并發(fā)最大可達(dá)到500W QPS.

3、高帶寬壓力：按照標(biāo)清視頻的標(biāo)準(zhǔn)，觀看直播的碼流至少為1Mbps，如果100W用戶在線，光視頻流的出口帶寬能達(dá)到976.56G bps。1條彈幕可達(dá)到130字節(jié)，1秒要滾屏20條彈幕，如果需要同時(shí)推送給100W用戶，彈幕的出口帶寬也將達(dá)到19.37G bps.

4、高計(jì)算壓力：1道題目的對(duì)錯(cuò)判斷涉及到答案比對(duì)、復(fù)活道具的使用、判斷用戶是否創(chuàng)了新紀(jì)錄，同時(shí)還涉及一系列的反作弊策略（比如前面的題目答錯(cuò)了將無法繼續(xù)作答），在主持人口播公布答案的瞬間，如何快速完成100W用戶的答題結(jié)果計(jì)算？

5、資金流的正確性和安全性：?jiǎn)蝹€(gè)用戶最多搶3個(gè)紅包如何不多領(lǐng)？財(cái)務(wù)上如何保證答題獎(jiǎng)金、紅包獎(jiǎng)勵(lì)不出現(xiàn)1分錢的誤差？

6、低延遲性要求：直播場(chǎng)景下如何整合視頻流和業(yè)務(wù)數(shù)據(jù)流，做到聲音、主播畫面和題目同步，以保證用戶體驗(yàn)？

7、對(duì)商城交易業(yè)務(wù)的低干擾：直播答題僅作為商城的一個(gè)運(yùn)營活動(dòng)，核心目標(biāo)是導(dǎo)流，它依托商城原有的用戶體系，運(yùn)營系統(tǒng)，大數(shù)據(jù)系統(tǒng)，提現(xiàn)通道等，如何做到對(duì)商城現(xiàn)有交易系統(tǒng)的低干擾？

可見答題這種泛娛樂的直播場(chǎng)景還是有挺多技術(shù)挑戰(zhàn)的，它取決于直播應(yīng)用的用戶量級(jí)和業(yè)務(wù)流程。就算是直播電商這種低頻交易轉(zhuǎn)化的場(chǎng)景，要是李佳琪在帶貨，同樣也會(huì)面臨瞬時(shí)搶購的高并發(fā)挑戰(zhàn)，所以架構(gòu)設(shè)計(jì)時(shí)必須考慮業(yè)務(wù)最高峰時(shí)的壓力，并且系統(tǒng)的各個(gè)環(huán)節(jié)必須具備動(dòng)態(tài)可伸縮的能力。

03 技術(shù)選型及依據(jù)

一. 音視頻處理及傳輸?shù)姆桨高x型

音視頻處理及傳輸，因?yàn)榧夹g(shù)團(tuán)隊(duì)不具備這方面的能力，所以當(dāng)時(shí)調(diào)研了各種云廠商的付費(fèi)解決方案，最終采用了騰訊云的直播解決方案。主持人側(cè)：通過演播室的專業(yè)攝像設(shè)備，搭載騰訊云提供的obs推流軟件，即可進(jìn)行視頻錄制和推流。用戶側(cè)：APP端集成騰訊云的SDK，動(dòng)態(tài)拿到推流地址后即可觀看直播。

二. 業(yè)務(wù)數(shù)據(jù)流的方案選型

業(yè)務(wù)數(shù)據(jù)是指除音視頻以外的，和答題應(yīng)用場(chǎng)景相關(guān)的數(shù)據(jù)（比如題目、答案、彈幕、紅包等）。騰訊云提供了兩種可選方案：

1、題目預(yù)先設(shè)置好，直接由騰訊云的SDK通過音視頻通道下發(fā)，打入直播流中。

2、讓題目先通過騰訊云的IM通道快速送達(dá)觀眾端APP，在觀眾端先緩存下來，等待播放器通知了預(yù)期的 NTP 時(shí)間戳之后，再把題目顯示出來。

騰訊云的這兩種方案都可以提供“音-畫-題”的完美同步，但是存在以下局限：用戶的答案必須以HTTP請(qǐng)求方式匯總到答題服務(wù)器，這一塊必須自己開發(fā)，另外公布答案、搶紅包、彈幕這些業(yè)務(wù)騰訊云系統(tǒng)都是不支持的，在底層通信通道上仍然需要自行開發(fā)。

考慮上述局限以及業(yè)務(wù)的多變性，我們最終打算自研業(yè)務(wù)數(shù)據(jù)流通道。這樣視頻流和業(yè)務(wù)數(shù)據(jù)流會(huì)分兩個(gè)通道下發(fā)，因?yàn)闃I(yè)務(wù)流相對(duì)視頻流的數(shù)據(jù)量很小，只要能保證業(yè)務(wù)邏輯的處理速度和業(yè)務(wù)數(shù)據(jù)的下行速度，“音-畫-題”的延遲是可以接受的。畢竟當(dāng)時(shí)已經(jīng)是4G時(shí)代，如果用戶側(cè)的網(wǎng)速不行，視頻流可能都無法正常觀看了。

為了做到業(yè)務(wù)數(shù)據(jù)流的獨(dú)立傳輸，需要實(shí)現(xiàn)一個(gè)長連接、高性能的網(wǎng)關(guān)服務(wù)器（支持100W用戶同時(shí)在線，20W并發(fā)答題，彈幕實(shí)時(shí)推送等要求），我們的技術(shù)選型是：Netty、ProtoBuf、WebSocket，選型理由：

1、Netty：Netty是當(dāng)時(shí)最流行的高性能和異步NIO框架，直播答題的業(yè)務(wù)場(chǎng)景中，涉及到題目下發(fā)、彈幕、下紅包雨等非常多的推送場(chǎng)景，而且一場(chǎng)答題活動(dòng)中，客戶端和服務(wù)端的通信頻繁，長連接比短連接在性能上更優(yōu)。

2、ProtoBuf：作為客戶端和服務(wù)端的數(shù)據(jù)交換格式，PB是一種效率和兼容性都很優(yōu)秀的二進(jìn)制數(shù)據(jù)傳輸格式，在碼流和序列化速度上明顯優(yōu)于JSON、XML、hessian等主流格式，同時(shí)支持向前向后兼容以及各種主流語言。

3、WebSocket：是 HTML5 一種新的協(xié)議，用來實(shí)現(xiàn)客戶端與服務(wù)器端的長連接通訊。

三. 服務(wù)端的部署方案選型

前面提過，直播答題僅作為商城的一個(gè)運(yùn)營活動(dòng)，它依托商城原有的用戶體系，運(yùn)營系統(tǒng)，大數(shù)據(jù)系統(tǒng)，提現(xiàn)通道等?，F(xiàn)有的商城系統(tǒng)部署在我們自建的機(jī)房中，為了降低對(duì)商城現(xiàn)有交易系統(tǒng)的低干擾，我們采用了『私有云+公有云』的混合部署方案。將高并發(fā)的答題系統(tǒng)以及它所依賴的緩存、MQ等公共組件部署在公有云上，方便彈性擴(kuò)展，同時(shí)降低對(duì)商城交易系統(tǒng)的流量沖擊。

04 架構(gòu)設(shè)計(jì)方案

一. 音視頻直播架構(gòu)

上面是騰訊云直播解決方案的架構(gòu)圖，其他云廠商（比如阿里云）的直播解決方案，技術(shù)架構(gòu)類似。感興趣的同學(xué)可以直接去騰訊云官網(wǎng)上詳細(xì)了解，這里不做展開。

二. 數(shù)據(jù)流方案

音視頻流采用了騰訊云的直播解決方案，而業(yè)務(wù)數(shù)據(jù)流（活動(dòng)、題目、答案、彈幕、紅包等）則采用了自研的長連接方案。架構(gòu)圖中的答題系統(tǒng)和答題運(yùn)營后臺(tái)也均為自研。客戶端會(huì)分開處理兩個(gè)通道的數(shù)據(jù)，以控制用戶交互上的變化。

三. 基于TCP長連接的通信架構(gòu)

上面的通信架構(gòu)用于業(yè)務(wù)數(shù)據(jù)流的傳輸，流程如下：

1、客戶端使用websocket與服務(wù)端進(jìn)行通訊，用戶進(jìn)入答題直播間時(shí)建立連接，退出直播間時(shí)斷開連接。

2、Nginx對(duì)websocket做負(fù)載均衡。

3、TCP網(wǎng)關(guān)基于netty實(shí)現(xiàn)，用于維持長連接和轉(zhuǎn)發(fā)業(yè)務(wù)請(qǐng)求，不負(fù)責(zé)具體的業(yè)務(wù)邏輯，它和下層業(yè)務(wù)系統(tǒng)（答題系統(tǒng)）通過RPC接口進(jìn)行交互，主要考慮后續(xù)其他業(yè)務(wù)可以復(fù)用TCP網(wǎng)關(guān)層，所以將業(yè)務(wù)下沉。客戶端和網(wǎng)關(guān)之間通過心跳機(jī)制保證連接的有效性以及檢測(cè)僵尸連接。

4、消息推送（比如彈幕、下發(fā)題目、公布答案等諸多場(chǎng)景）由下層業(yè)務(wù)（答題系統(tǒng)）通過MQ通知TCP網(wǎng)關(guān)，再由TCP網(wǎng)關(guān)推送給客戶端。

四. 長連接通信中的數(shù)據(jù)傳輸格式定義

通信架構(gòu)中另外比較重要的是數(shù)據(jù)傳輸格式的定義，客戶端和TCP網(wǎng)關(guān)之間，TCP網(wǎng)關(guān)和答題系統(tǒng)之間均采用的是protobuf格式。下面分開說一下比較關(guān)鍵的幾個(gè)格式定義。

4.1 客戶端請(qǐng)求消息的格式

1、消息類型標(biāo)識(shí)：-1表示心跳消息、0表示用戶驗(yàn)證消息、>0 表示業(yè)務(wù)類消息

2、用戶ID：用戶的唯一標(biāo)識(shí)，在前置的登錄流程中已經(jīng)獲得

3、Token：用戶登錄APP后的授權(quán)令牌，在前置的登錄流程中已經(jīng)獲得

4、BizData：真正的業(yè)務(wù)數(shù)據(jù)，protobuf序列化后的byte數(shù)組，由下層業(yè)務(wù)自行定義更具體的格式

4.2 客戶端響應(yīng)消息的格式

1、消息類型標(biāo)識(shí)：和請(qǐng)求中的消息類型保持一致

2、狀態(tài)碼：0表示處理失敗，1表示處理成功

3、BizData：真正的業(yè)務(wù)數(shù)據(jù)，如果狀態(tài)碼為0，該字段為4字節(jié)的異常碼（100表示token驗(yàn)證失敗，101表示請(qǐng)求業(yè)務(wù)層失?。?，如果狀態(tài)碼為1，該字段為業(yè)務(wù)層返回的protobuf序列化后的byte數(shù)組，同樣由下層業(yè)務(wù)自行定義更具體的格式

4.3 業(yè)務(wù)數(shù)據(jù)的ProtoBuf格式定義 

1message Message   
2{  
3    MessageType messageType = 1; // 消息類型，枚舉值  
4    string sequence = 2; // 消息序號(hào)  
6    Request request = 3; // 請(qǐng)求類消息  
7    Response response = 4; // 響應(yīng)類消息  
8    Notification notification = 5; // 推送類消息  
9} 

這里的格式設(shè)計(jì)比較巧妙，通過Message頂層消息把Request、Response、Notification這3類消息包裝起來，并且定義一個(gè)MessageType枚舉值，用來表示消息類型，另外sequence字段表示消息的唯一序列號(hào)，需要保證發(fā)送端內(nèi)唯一，這樣發(fā)送端收到Response后可以進(jìn)行匹配處理。有了上面的統(tǒng)一消息格式，答題系統(tǒng)就可以針對(duì)不同的MessageType定義不同的消息處理器，配置好映射關(guān)系后，即可實(shí)現(xiàn)消息路由。

五. 系統(tǒng)總體架構(gòu)

1、網(wǎng)關(guān)層：架構(gòu)上同時(shí)采用了TCP網(wǎng)關(guān)和HTTP網(wǎng)關(guān)，TCP網(wǎng)關(guān)上一章節(jié)已經(jīng)講解，它主要用于維持百萬用戶同時(shí)在線，以及答題期間的實(shí)時(shí)數(shù)據(jù)交互（包括加入直播間、推送題目、答題、推送答案、搶紅包、彈幕推送等）。HTTP網(wǎng)關(guān)為APP端提供Restful接口，用于低頻的數(shù)據(jù)請(qǐng)求，比如活動(dòng)首頁、排行榜、個(gè)人獎(jiǎng)金明細(xì)、新人邀請(qǐng)、分享等場(chǎng)景。

2、答題系統(tǒng)：Dubbo實(shí)現(xiàn)，最核心的業(yè)務(wù)服務(wù)，同時(shí)面向C端和B端系統(tǒng)提供RPC接口，包括活動(dòng)管理、題庫管理、直播間管理、以及面向C端的高并發(fā)接口（比如加入直播間、答題、搶紅包等）。這個(gè)集群用到了很多高并發(fā)設(shè)計(jì)的通用方法：比如服務(wù)的橫向擴(kuò)容能力、多級(jí)緩存、異步化、限流等，后面的章節(jié)再做具體介紹。另外，通過MQ的事務(wù)消息+對(duì)賬機(jī)制保證資金流在答題系統(tǒng)和余額系統(tǒng)的一致性。

3、答題運(yùn)營系統(tǒng)：后臺(tái)系統(tǒng)，供運(yùn)營人員和直播時(shí)的場(chǎng)控人員使用，可以管理活動(dòng)和題目，以及直播過程中的各種業(yè)務(wù)操作（比如配合主持人的口播下發(fā)題目、公布答案、發(fā)紅包等）。

六. 部署架構(gòu)

直播答題的在線用戶量以及并發(fā)量遠(yuǎn)超過商城的交易系統(tǒng)，為了減少對(duì)主交易流程的影響，采用了上述『私有云+公有云』的混合部署方案，自建機(jī)房和云機(jī)房之間通過網(wǎng)絡(luò)專線打通。直播答題有關(guān)的應(yīng)用服務(wù)器、存儲(chǔ)服務(wù)器、網(wǎng)絡(luò)帶寬都在云端，可以根據(jù)流量監(jiān)控做到快速擴(kuò)容，隨著運(yùn)營計(jì)劃的調(diào)整，也可以隨時(shí)增減服務(wù)器，靈活性高。

七. 答題系統(tǒng)的高并發(fā)設(shè)計(jì)方案

7.1 答題接口的高并發(fā)設(shè)計(jì)方案

答題接口的并發(fā)預(yù)計(jì)20W QPS，在說設(shè)計(jì)方案之前，先簡(jiǎn)單列一下答題接口的判斷邏輯：

    1、需要判斷答題活動(dòng)是否仍在進(jìn)行中 

    2、需要判斷用戶是否已經(jīng)答錯(cuò)出局 

    3、需要判斷用戶輸入的題目是否是當(dāng)前正在作答的題目 

    4、需要判斷用戶上一道答對(duì)的題和當(dāng)前這題是否連續(xù) 

    5、需要判斷用戶作答是否已經(jīng)超時(shí) 

    6、需要判斷用戶的答案是否是正確答案 

    7、如果答錯(cuò)了，需要判斷用戶是否有復(fù)活卡

    8、如果有復(fù)活卡，需要判斷前面的題是否用過復(fù)活卡了

除了上述判斷邏輯外，還有一些寫操作，比如更新每個(gè)答案選項(xiàng)的選擇人數(shù)，更新用戶的答對(duì)題號(hào)或者出局題號(hào)，更新復(fù)活卡的使用記錄等，總的來說，答題是一個(gè)讀多寫少的接口。為了應(yīng)對(duì)高并發(fā)，我們采取了以下技術(shù)方案：

1、答題接口的所有邏輯只操作緩存，不操作數(shù)據(jù)庫。采用Write Behind Caching的更新模式（即只更新緩存，在答題結(jié)束后再異步批量更新數(shù)據(jù)庫）。

2、多級(jí)緩存：本地緩存+Redis緩存。同時(shí)在答題活動(dòng)開始之前，會(huì)先將活動(dòng)的配置信息，題目，答案等所有靜態(tài)數(shù)據(jù)都預(yù)熱到本地緩存中。

3、Redis 一主多從 + 哨兵的部署架構(gòu)，確保高并發(fā)和高可用，同時(shí)分業(yè)務(wù)模塊配置了多套R(shí)edis實(shí)例（用戶、彈幕、直播作答、獎(jiǎng)金榜單）做進(jìn)一步分流。

4、調(diào)整判斷邏輯的順序，上面提到的8個(gè)判斷邏輯，其中前4個(gè)都屬于安全校驗(yàn)，因?yàn)榭蛻舳艘呀?jīng)通過交互做了攔截，如果用戶不采取作弊手段肯定都能校驗(yàn)通過。所以我們將第5、6、7步邏輯做了前置，通過后再進(jìn)行前4步校驗(yàn)，這樣大大減少了計(jì)算量。

7.2 答題結(jié)果推送的設(shè)計(jì)方案

如何在主持人口播公布答案的瞬間，將答題結(jié)果推送給幾十萬作答用戶？因?yàn)橛脩舻淖鞔鸾Y(jié)果有非常多的狀態(tài)：有答對(duì)的和答錯(cuò)的，有使用復(fù)活卡和未使用復(fù)活卡的，有出局的，不同狀態(tài)下APP端的交互均不同，完全是一種依賴服務(wù)端的有狀態(tài)推送。

為了解決這個(gè)并發(fā)計(jì)算問題，我們采用了一個(gè)比較巧的設(shè)計(jì)方案，很好地將有狀態(tài)推送轉(zhuǎn)變成了無狀態(tài)推送：

1、將答題結(jié)果的計(jì)算前置到用戶提交答案的時(shí)候同步完成（上一節(jié)的方案），這樣相當(dāng)于將瞬時(shí)的計(jì)算壓力分散到10秒作答時(shí)間里了。

2、用戶的作答結(jié)果也在第1步計(jì)算完成后立刻推送給用戶了，不用等到主持人口播公布答案的瞬間，否則的話仍然涉及到并發(fā)讀取作答結(jié)果以及有狀態(tài)推送，對(duì)存儲(chǔ)服務(wù)器以及帶寬的瞬時(shí)壓力仍然存在。

3、但是作答結(jié)果如果提前推送給客戶端必然存在安全問題，黑客抓包就能提前知道是否答對(duì)了，可以利用批量賬號(hào)進(jìn)行作弊。為了解決這個(gè)問題，我們對(duì)作答結(jié)果采用XOR進(jìn)行了對(duì)稱加密，同時(shí)將秘鑰延遲到公布答案的瞬間才下發(fā)，而且每道題的秘鑰均是隨機(jī)生成的。這樣就很好地解決了安全問題。

4、公布答案的瞬間，我們只需要推送一個(gè)非常小的數(shù)據(jù)包給客戶端即可，而且這個(gè)數(shù)據(jù)包所有用戶都是一樣的。

7.3 搶紅包接口的高并發(fā)設(shè)計(jì)方案

屏幕下紅包雨，用戶觸屏點(diǎn)中紅包就直接拆了，所以搶紅包接口的并發(fā)非常高，1秒內(nèi)單個(gè)用戶可觸屏發(fā)起4-5次搶紅包請(qǐng)求，按照百萬用戶在線，并發(fā)最大可達(dá)到上百萬QPS，下面說下技術(shù)方案：

1、紅包金額提前計(jì)算好并加載到redis中：在創(chuàng)建活動(dòng)時(shí)，運(yùn)營可配置紅包總金額以及紅包總個(gè)數(shù)，系統(tǒng)在創(chuàng)建活動(dòng)時(shí)就會(huì)提前計(jì)算出各個(gè)紅包的金額并存儲(chǔ)到redis中，相當(dāng)于計(jì)算前置。

2、客戶端限流：在接口設(shè)計(jì)時(shí)，我們就預(yù)埋了一個(gè)限流因子參數(shù)，可由服務(wù)端動(dòng)態(tài)控制客戶端的限流比例，在通知客戶端搶紅包的接口中，我們根據(jù)當(dāng)前的在線人數(shù)以及紅包總個(gè)數(shù)動(dòng)態(tài)算出限流因子，控制最多只有10W QPS的請(qǐng)求能發(fā)到服務(wù)端。

3、服務(wù)端限流：根據(jù)服務(wù)器數(shù)量以及紅包總數(shù)量提前計(jì)算出每秒令牌的生成數(shù)量，基于guava的RateLimiter進(jìn)行二次限流。

4、前面3步基本把并發(fā)降下來了，再通過lua腳本保證原子性即可，搶紅包的結(jié)果也是在活動(dòng)結(jié)束后再異步刷新到數(shù)據(jù)庫。

7.4 其他高并發(fā)的優(yōu)化點(diǎn)

1、Redis緩存的對(duì)象要盡可能簡(jiǎn)化（用不到的字段不要存），key的長度要盡可能短（高并發(fā)下的瓶頸在于IO），善于利用pipeline組裝多個(gè)命令（但是命令個(gè)數(shù)不能過多）

2、各種連接池和JVM參數(shù)的調(diào)整：涉及redis連接池、dubbo的線程池、JVM內(nèi)存大小，可以在壓測(cè)環(huán)境下找到合理值。

3、答題系統(tǒng)可水平擴(kuò)展（scale  out），同時(shí)通過dubbo的分組配置將ToB和ToC接口進(jìn)行隔離部署，避免相互影響。

最后，關(guān)于直播架構(gòu)再簡(jiǎn)單總結(jié)下:

1、音視頻編碼和傳輸，這些基礎(chǔ)性的直播功能，除非公司有錢有實(shí)力，否則建議直接用騰訊云或者阿里云的解決方案（斗魚、蘑菇街這些知名的直播應(yīng)用都還用的騰訊云）。

2、架構(gòu)設(shè)計(jì)重點(diǎn)放在應(yīng)用本身，根據(jù)直播應(yīng)用的用戶量級(jí)和業(yè)務(wù)特性先確定通信架構(gòu)（長連接還是短鏈接，或者兩者混用）。

3、要根據(jù)業(yè)務(wù)高峰來做方案設(shè)計(jì)，如果是高并發(fā)場(chǎng)景，要把高并發(fā)當(dāng)做一個(gè)系統(tǒng)性問題去對(duì)待：從客戶端到服務(wù)端，從網(wǎng)絡(luò)帶寬到部署架構(gòu)，甚至產(chǎn)品設(shè)計(jì)等各個(gè)維度全盤考慮，要摳各種細(xì)節(jié)。