2020年春節(jié)的這場疫情讓線下零售降至冰點(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年多前就開始興起了蒲凶，秀場直播和游戲直播是PC時(shí)代比較成功的應(yīng)用場景拆内，直到16年，隨著移動(dòng)互聯(lián)網(wǎng)的大規(guī)模普及麸恍，直播行業(yè)迎來了真正的元年搀矫，成百上千的直播APP出現(xiàn)在大眾視野刻肄，大概在18年年初，直播答題當(dāng)時(shí)火了一把卦羡，那算是直播類應(yīng)用的第一次全民普及，然后是19年短視頻網(wǎng)站掀起的直播電商麦到÷潭回顧直播行業(yè)的發(fā)展歷程，直播類應(yīng)用在各個(gè)領(lǐng)域遍地開花瓶颠，那么它背后的技術(shù)架構(gòu)你是否了解拟赊？
兩年前，我參與了一個(gè)支持100萬用戶同時(shí)在線粹淋、20萬并發(fā)的直播答題系統(tǒng)的架構(gòu)設(shè)計(jì)吸祟，下文將以『直播答題』的應(yīng)用場景為例，帶你了解當(dāng)前疫情下火爆的直播應(yīng)用背后的技術(shù)架構(gòu)桃移。內(nèi)容分成以下4個(gè)部分：
1屋匕、產(chǎn)品功能簡介
2、面臨的技術(shù)挑戰(zhàn)
3借杰、技術(shù)選型及依據(jù)
4炒瘟、架構(gòu)設(shè)計(jì)方案
01 產(chǎn)品功能簡介
直播答題能在當(dāng)時(shí)成為風(fēng)口，得益于它的玩法足夠簡單第步，用戶教育成本幾乎為0疮装。簡單來說就是：全民在線PK、10秒答題粘都、超時(shí)或答錯(cuò)即退出游戲廓推、成功答對(duì)所有題即可平分獎(jiǎng)金，俗稱在線版的開心辭典翩隧。
在了解系統(tǒng)設(shè)計(jì)方案和架構(gòu)之前樊展，先看看直播答題應(yīng)用有哪些核心功能？下面是APP端的幾張產(chǎn)品截圖：
1堆生、答題以活動(dòng)的形式展開专缠，每場活動(dòng)都會(huì)預(yù)先公布直播開始時(shí)間、答題總獎(jiǎng)金淑仆、紅包雨獎(jiǎng)金等信息涝婉。
2墩弯、活動(dòng)時(shí)間到后，用戶就可以進(jìn)入直播間锌钮，看到實(shí)時(shí)的視頻流梁丘，有專業(yè)的主持人進(jìn)行串詞口播兰吟，場控人員會(huì)配合主持人同步進(jìn)行發(fā)題、公布答案等操作珊燎。
3晚吞、題目下發(fā)后槽地，用戶有10秒的作答時(shí)間捌蚊，答錯(cuò)或者超時(shí)即退出游戲缅糟，如果用戶有復(fù)活道具在答錯(cuò)時(shí)會(huì)自動(dòng)使用窗宦，用戶能繼續(xù)進(jìn)行答題。
4订讼、為了留住答錯(cuò)用戶纱烘，活動(dòng)期間有多場紅包雨擂啥，用戶點(diǎn)擊屏幕就有概率搶到哺壶。
5山宾、活動(dòng)期間用戶可發(fā)彈幕资锰，同時(shí)會(huì)有彈幕滾屏輪播绷杜，以營造熱鬧的直播氛圍。
6瑰剃、其他功能：邀請新人粤剧、活動(dòng)榜單俊扳、獎(jiǎng)金提現(xiàn)等馋记。
其他直播類應(yīng)用在產(chǎn)品功能上和直播答題類似梯醒，基本也是這兩類：
1茸习、直播的基礎(chǔ)功能：連麥互動(dòng)直播（支持多碼率号胚、多協(xié)議，多主播同框）箱亿、美顏特效届惋、彈幕、IM聊天衡查、點(diǎn)贊拌牲、屏幕共享等功能性需求稍途，以及防盜鏈砚婆、涉黃涉政鑒別等非功能性需求坷虑。
2迄损、應(yīng)用本身的個(gè)性化功能：比如答題場景中的發(fā)題目芹敌、作答氏捞、公布答案液茎，電商場景中的商品展示滞造、一鍵下單購買谒养，網(wǎ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ā)請求：參考了沖頂大會(huì)等答題競品的用戶量級(jí)讳推，預(yù)計(jì)會(huì)有100W用戶同時(shí)在線银觅，1秒內(nèi)有20W用戶同時(shí)答題究驴；1秒內(nèi)單個(gè)用戶可觸屏發(fā)起4-5次搶紅包請求，并發(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、資金流的正確性和安全性：單個(gè)用戶最多搶3個(gè)紅包如何不多領(lǐng)燃辖？財(cái)務(wù)上如何保證答題獎(jiǎng)金鬼店、紅包獎(jiǎng)勵(lì)不出現(xiàn)1分錢的誤差？
6黔龟、低延遲性要求：直播場景下如何整合視頻流和業(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)的低干擾茂洒？
可見答題這種泛娛樂的直播場景還是有挺多技術(shù)挑戰(zhàn)的堵未，它取決于直播應(yīng)用的用戶量級(jí)和業(yè)務(wù)流程授艰。就算是直播電商這種低頻交易轉(zhuǎn)化的場景屉佳，要是李佳琪在帶貨，同樣也會(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)用場景相關(guān)的數(shù)據(jù)（比如題目、答案、彈幕、紅包等）暑认。騰訊云提供了兩種可選方案：
1根穷、題目預(yù)先設(shè)置好递递，直接由騰訊云的SDK通過音視頻通道下發(fā)，打入直播流中哮独。
2羡疗、讓題目先通過騰訊云的IM通道快速送達(dá)觀眾端APP，在觀眾端先緩存下來别洪，等待播放器通知了預(yù)期的 NTP 時(shí)間戳之后叨恨，再把題目顯示出來。
騰訊云的這兩種方案都可以提供“音-畫-題”的完美同步蕉拢，但是存在以下局限：用戶的答案必須以HTTP請求方式匯總到答題服務(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ù)場景中，涉及到題目下發(fā)扎瓶、彈幕所踊、下紅包雨等非常多的推送場景，而且一場答題活動(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)通道等」径校現(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ù)請求蛀柴，不負(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ī)制保證連接的有效性以及檢測僵尸連接肮韧。
4、消息推送（比如彈幕旺订、下發(fā)題目弄企、公布答案等諸多場景）由下層業(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 客戶端請求消息的格式
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í)：和請求中的消息類型保持一致
2洁段、狀態(tài)碼：0表示處理失敗，1表示處理成功
3共郭、BizData：真正的業(yè)務(wù)數(shù)據(jù)祠丝，如果狀態(tài)碼為0疾呻，該字段為4字節(jié)的異常碼（100表示token驗(yàn)證失敗，101表示請求業(yè)務(wù)層失斉ε薄）罐韩，如果狀態(tài)碼為1憾赁，該字段為業(yè)務(wù)層返回的protobuf序列化后的byte數(shù)組污朽，同樣由下層業(yè)務(wù)自行定義更具體的格式
4.3 業(yè)務(wù)數(shù)據(jù)的ProtoBuf格式定義
message Message
{
MessageType messageType = 1; // 消息類型，枚舉值
string sequence = 2; // 消息序號(hào)
Request request = 3; // 請求類消息
Response response = 4; // 響應(yīng)類消息
Notification notification = 5; // 推送類消息
}
這里的格式設(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ù)請求川背，比如活動(dòng)首頁贰拿、排行榜、個(gè)人獎(jiǎng)金明細(xì)熄云、新人邀請膨更、分享等場景。
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í)的場控人員使用艺玲，可以管理活動(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ì)方案之前，先簡單列一下答題接口的判斷邏輯：
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次搶紅包請求擂错，按照百萬用戶在線，并發(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的請求能發(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ì)象要盡可能簡化（用不到的字段不要存）边灭，key的長度要盡可能短（高并發(fā)下的瓶頸在于IO）异希，善于利用pipeline組裝多個(gè)命令（但是命令個(gè)數(shù)不能過多）
2、各種連接池和JVM參數(shù)的調(diào)整：涉及redis連接池绒瘦、dubbo的線程池称簿、JVM內(nèi)存大小，可以在壓測環(huán)境下找到合理值惰帽。
3憨降、答題系統(tǒng)可水平擴(kuò)展（scale out），同時(shí)通過dubbo的分組配置將ToB和ToC接口進(jìn)行隔離部署该酗，避免相互影響授药。
最后，關(guān)于直播架構(gòu)再簡單總結(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ā)場景，要把高并發(fā)當(dāng)做一個(gè)系統(tǒng)性問題去對(duì)待：從客戶端到服務(wù)端虑鼎，從網(wǎng)絡(luò)帶寬到部署架構(gòu)辱匿，甚至產(chǎn)品設(shè)計(jì)等各個(gè)維度全盤考慮，要摳各種細(xì)節(jié)炫彩。
其他推薦：
1匾七、線程池運(yùn)用不當(dāng)?shù)囊淮尉€上事故
2、工程師如何從技術(shù)轉(zhuǎn)型做管理江兢？
作者簡介：程序員昨忆，985碩士，前亞馬遜Java工程師杉允，現(xiàn)58轉(zhuǎn)轉(zhuǎn)技術(shù)總監(jiān)邑贴。持續(xù)分享技術(shù)和管理方向的文章。如果感興趣叔磷，可微信掃描下面的二維碼關(guān)注我的公眾號(hào)：『IT人的職場進(jìn)階』
