背景

為了更好的支持東南亞直播業(yè)務(wù)，產(chǎn)品設(shè)計(jì)為直播業(yè)務(wù)增加了彈幕。第一期彈幕使用騰訊云支持，效果并不理想，經(jīng)常出現(xiàn)卡頓、彈幕偏少等問(wèn)題。最終促使我們開(kāi)發(fā)自己的彈幕系統(tǒng)。性能要求是需要支持，單房間百萬(wàn)用戶同時(shí)在線。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

問(wèn)題分析

按照背景來(lái)分析，系統(tǒng)將主要面臨以下問(wèn)題：

1. 帶寬壓力

   假如說(shuō)每3秒促達(dá)用戶一次，那么每次內(nèi)容至少需要有15條才能做到視覺(jué)無(wú)卡頓。15條彈幕+http包頭的大小將超過(guò)3k，那么每秒的數(shù)據(jù)大小約為8Gbps，而運(yùn)維同學(xué)通知我們所有服務(wù)的可用帶寬僅為10Gbps。

2. 弱網(wǎng)導(dǎo)致的彈幕卡頓、丟失

   該問(wèn)題已在線上環(huán)境

3. 性能與可靠性

   百萬(wàn)用戶同時(shí)在線，按照上文的推算，具體QPS將超過(guò)30w QPS。如何保證在雙十一等重要活動(dòng)中不出問(wèn)題，至關(guān)重要。性能也是另外一個(gè)需要著重考慮的點(diǎn)。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

帶寬優(yōu)化

為了降低帶寬壓力，我們主要采用了以下方案：

1. 啟用Http壓縮

   通過(guò)查閱資料，http gzip壓縮比率可以達(dá)到40%以上（gzip比deflate要高出4%~5%）。

2. Response結(jié)構(gòu)簡(jiǎn)化

3. 內(nèi)容排列順序優(yōu)化

   根據(jù)gzip的壓縮的壓縮原理可以知道，重復(fù)度越高，壓縮比越高，因此可以將字符串和數(shù)字內(nèi)容放在一起擺放

4. 頻率控制

• 帶寬控制：通過(guò)添加請(qǐng)求間隔參數(shù)（下次請(qǐng)求時(shí)間），保證客戶端的請(qǐng)求頻率服務(wù)端可控。以應(yīng)對(duì)突發(fā)的流量增長(zhǎng)問(wèn)題，提供有損的服務(wù)。
• 稀疏控制：在彈幕稀疏和空洞的時(shí)間段，通過(guò)控制下次請(qǐng)求時(shí)間，避免客戶端的無(wú)效請(qǐng)求。

彈幕卡頓、丟失分析

在開(kāi)發(fā)彈幕系統(tǒng)的的時(shí)候，最常見(jiàn)的問(wèn)題是該怎么選擇促達(dá)機(jī)制，推送 vs 拉取 ？

Long Polling via AJAX

客戶端打開(kāi)一個(gè)到服務(wù)器端的 AJAX 請(qǐng)求，然后等待響應(yīng)，服務(wù)器端需要一些特定的功能來(lái)允許請(qǐng)求被掛起，只要一有事件發(fā)生，服務(wù)器端就會(huì)在掛起的請(qǐng)求中送回響應(yīng)。如果打開(kāi)Http的Keepalived開(kāi)關(guān)，還可以節(jié)約握手的時(shí)間。

優(yōu)點(diǎn)： 減少輪詢次數(shù)，低延遲，瀏覽器兼容性較好。缺點(diǎn)： 服務(wù)器需要保持大量連接。

WebSockets

長(zhǎng)輪詢雖然省去了大量無(wú)效請(qǐng)求，減少了服務(wù)器壓力和一定的網(wǎng)絡(luò)帶寬的占用，但是還是需要保持大量的連接。那么人們就在考慮了，有沒(méi)有這樣一個(gè)完美的方案，即能雙向通信，又可以節(jié)約請(qǐng)求的 header 網(wǎng)絡(luò)開(kāi)銷(xiāo)，并且有更強(qiáng)的擴(kuò)展性，最好還可以支持二進(jìn)制幀，壓縮等特性呢？于是人們就發(fā)明了這樣一個(gè)目前看似“完美”的解決方案 —— WebSocket。它的最大特點(diǎn)就是，服務(wù)器可以主動(dòng)向客戶端推送信息，客戶端也可以主動(dòng)向服務(wù)器發(fā)送信息，是真正的雙向平等對(duì)話。

優(yōu)點(diǎn)：較少的控制開(kāi)銷(xiāo)，在連接創(chuàng)建后，服務(wù)器和客戶端之間交換數(shù)據(jù)時(shí)，用于協(xié)議控制的數(shù)據(jù)包頭部相對(duì)較小。在不包含擴(kuò)展的情況下，對(duì)于服務(wù)器到客戶端的內(nèi)容，此頭部大小只有2至10字節(jié)（和數(shù)據(jù)包長(zhǎng)度有關(guān)）；對(duì)于客戶端到服務(wù)器的內(nèi)容，此頭部還需要加上額外的4字節(jié)的掩碼。相對(duì)于 HTTP 請(qǐng)求每次都要攜帶完整的頭部，此項(xiàng)開(kāi)銷(xiāo)顯著減少了。更強(qiáng)的實(shí)時(shí)性，由于協(xié)議是全雙工的，所以服務(wù)器可以隨時(shí)主動(dòng)給客戶端下發(fā)數(shù)據(jù)。相對(duì)于HTTP請(qǐng)求需要等待客戶端發(fā)起請(qǐng)求服務(wù)端才能響應(yīng)，延遲明顯更少；即使是和Comet等類(lèi)似的長(zhǎng)輪詢比較，其也能在短時(shí)間內(nèi)更多次地傳遞數(shù)據(jù)。長(zhǎng)連接，保持連接狀態(tài)。

Long Polling vs Websockets

無(wú)論是以上哪種方式，都使用到TCP長(zhǎng)連接，那么TCP的長(zhǎng)連接是如何發(fā)現(xiàn)連接已經(jīng)斷開(kāi)了呢？

TCP Keepalived會(huì)進(jìn)行連接狀態(tài)探測(cè)，探測(cè)間隔主要由三個(gè)配置控制。

keepalive_probes：探測(cè)次數(shù)（默認(rèn)：7次）

keepalive_time 探測(cè)的超時(shí)（默認(rèn)：2小時(shí)）

keepalive_intvl 探測(cè)間隔(默認(rèn)：75s)

但是由于在東南亞的弱網(wǎng)情況下，TCP長(zhǎng)連接會(huì)經(jīng)常性的斷開(kāi):

Long Polling 能發(fā)現(xiàn)連接異常的最短間隔為：min(keepalive_intvl, polling_interval)

Websockets能發(fā)現(xiàn)連接異常的最短間隔為：Websockets: min(keepalive_intvl, client_sending_interval)

如果下次發(fā)送數(shù)據(jù)包的時(shí)候可能連接已經(jīng)斷開(kāi)了，所以使用TCP長(zhǎng)連接對(duì)于兩者均意義不大。并且弱網(wǎng)情況下Websockets其實(shí)已經(jīng)不能作為一個(gè)候選項(xiàng)了

• 即使Websockets服務(wù)端已經(jīng)發(fā)現(xiàn)連接斷開(kāi)，仍然沒(méi)有辦法推送數(shù)據(jù)，只能被動(dòng)等待客戶端重新建立好連接才能推送，在此之前數(shù)據(jù)將可能會(huì)被采取丟棄的措施處理掉。
• 在每次斷開(kāi)后均需要再次發(fā)送應(yīng)用層的協(xié)議進(jìn)行連接建立。

根據(jù)了解騰訊云的彈幕系統(tǒng)，在300人以下使用的是推送模式，300人以上則是采用的輪訓(xùn)模式。但是考慮到資源消耗情況，他們可能使用的是Websocket來(lái)實(shí)現(xiàn)的彈幕系統(tǒng)，所以才會(huì)出現(xiàn)彈幕卡頓、丟失的情況。綜上所述，Long Polling和Websockets都不適用我們面臨的環(huán)境，所以我們最終采取了短輪訓(xùn) 的方案來(lái)實(shí)現(xiàn)彈幕促達(dá)

可靠與性能

為了保證服務(wù)的穩(wěn)定性我們對(duì)服務(wù)進(jìn)行了拆分，將復(fù)雜的邏輯收攏到發(fā)送彈幕的一端。同時(shí)，將邏輯較為復(fù)雜、調(diào)用較少的發(fā)送彈幕業(yè)務(wù)與邏輯簡(jiǎn)單、調(diào)用量高的彈幕拉取服務(wù)拆分開(kāi)來(lái)。服務(wù)拆分主要考慮因素是為了不讓服務(wù)間相互影響，對(duì)于這種系統(tǒng)服務(wù)，不同服務(wù)的QPS往往是不對(duì)等的，例如像拉取彈幕的服務(wù)的請(qǐng)求頻率和負(fù)載通常會(huì)比發(fā)送彈幕服務(wù)高1到2個(gè)數(shù)量級(jí)，在這種情況下不能讓拉彈幕服務(wù)把發(fā)彈幕服務(wù)搞垮，反之亦然，最?度地保證系統(tǒng)的可用性，同時(shí)也更更加方便對(duì)各個(gè)服務(wù)做Scale-Up和Scale-Out。服務(wù)拆分也劃清了業(yè)務(wù)邊界，方便協(xié)同開(kāi)發(fā)。

在拉取彈幕服務(wù)的一端 ，引入了本地緩存。數(shù)據(jù)更新的策略是服務(wù)會(huì)定期發(fā)起RPC調(diào)?從彈幕服務(wù)拉取數(shù)據(jù)，拉取到的彈幕緩存到內(nèi)存中，這樣后續(xù)的請(qǐng)求過(guò)來(lái)時(shí)便能直接?走本地內(nèi)存的讀取，?大幅降低了調(diào)用時(shí)延。這樣做還有另外一個(gè)好處就是縮短調(diào)?鏈路，把數(shù)據(jù)放到離?戶最近的地?，同時(shí)還能降低外部依賴的服務(wù)故障對(duì)業(yè)務(wù)的影響，

為了數(shù)據(jù)拉取方便，我們將數(shù)據(jù)按照時(shí)間進(jìn)行分片，將時(shí)間作為數(shù)據(jù)切割的單位，按照時(shí)間存儲(chǔ)、拉取、緩存數(shù)據(jù)（RingBuffer），簡(jiǎn)化了數(shù)據(jù)處理流程。與傳統(tǒng)的Ring Buffer不一樣的是，我們只保留了尾指針，它隨著時(shí)間向前移動(dòng)，每?秒向前移動(dòng)一格，把時(shí)間戳和對(duì)應(yīng)彈幕列表并寫(xiě)到一個(gè)區(qū)塊當(dāng)中，因此最多保留60秒的數(shù)據(jù)。同時(shí)，如果此時(shí)來(lái)了一個(gè)讀請(qǐng)求，那么緩沖環(huán)會(huì)根據(jù)客戶端傳入的時(shí)間戳計(jì)算出指針的索引位置，并從尾指針的副本區(qū)域往回遍歷直至跟索引重疊，收集到一定數(shù)量的彈幕列表返回，這種機(jī)制保證了緩沖區(qū)的區(qū)塊是整體有序的，因此在讀取的時(shí)候只需要簡(jiǎn)單地遍歷一遍即可，加上使用的是數(shù)組作為存儲(chǔ)結(jié)構(gòu)，帶來(lái)的讀效率是相當(dāng)高的。

再來(lái)考慮可能出現(xiàn)數(shù)據(jù)競(jìng)爭(zhēng)的情況。先來(lái)說(shuō)寫(xiě)操作，由于在這個(gè)場(chǎng)景下，寫(xiě)操作是單線程的，因此?可不必關(guān)心并發(fā)寫(xiě)帶來(lái)的數(shù)據(jù)一致性問(wèn)題。再來(lái)說(shuō)讀操作，由圖可知寫(xiě)的方向是從尾指針以順時(shí)針?向移動(dòng)，?讀?向是從尾指針以逆時(shí)針?lè)较蛞苿?dòng)，?決定讀和寫(xiě)的位置是否出現(xiàn)重疊取決于index的位置，由于我們保證了讀操作最多只能讀到30秒內(nèi)的數(shù)據(jù)，因此緩沖環(huán)完全可以做到無(wú)鎖讀寫(xiě)

在發(fā)送彈幕的一端 ，因?yàn)橛脩粢欢〞r(shí)間能看得過(guò)來(lái)彈幕總量是有限的，所以可以對(duì)彈幕進(jìn)行限流，有選擇的丟棄多余的彈幕。同時(shí)，采用柔性的處理方式，拉取用戶頭像、敏感詞過(guò)濾等分支在調(diào)用失敗的情況下，仍然能保證服務(wù)的核心流程不受影響，即彈幕能夠正常發(fā)送和接收，提供有損的服務(wù)。

總結(jié)

最終該服務(wù)在雙十二活動(dòng)中，在Redis出現(xiàn)短暫故障的背景下，高效且穩(wěn)定的支撐了70w用戶在線，成功完成了既定的目標(biāo)

審核編輯 ：李倩