火山引擎 RTC 助力抖音百萬并發(fā)“云侃球”
1. 背景及技術挑戰(zhàn)
從電視看直播到手機電腦看直播，直播技術的發(fā)展讓觀眾可以隨時、隨地觀看自己喜歡的比賽，并且在看比賽時通過發(fā)送表情、發(fā)文字進行互動。但表情、文字承載的信息量較小、溝通效率低，我們無法像線下一起看比賽那樣和好友邊看邊聊、一起為精彩的比賽吶喊，觀賽體驗大打折扣。
為了讓觀眾獲得更好的觀賽體驗，抖音在 2022 世界杯比賽直播中推出了“邊看邊聊”的玩法：每個觀眾都可以邀請好友（或分享聊天頻道信息邀請）一起觀看世界杯比賽；在頻道中，好友既可以發(fā)送文字、表情聊天，還可以上麥進行語音聊天，一起為精彩進球歡呼，大大提升“異地好友線上觀賽”的體驗。
進入“抖音體育”直播間，邀請好友加入個人聊天頻道，即可以和好友“邊看邊聊”
我們使用 RTC 來實現“邊看邊聊”的功能——觀眾可以隨時上麥進行語音聊天，同時頻道中的普通觀眾也可以聽到麥上用戶的精彩評論。但在抖音“邊看邊聊世界杯”的玩法中，RTC 面臨著幾個比較大的挑戰(zhàn)：
一是高并發(fā)的問題，包括音視頻流數高并發(fā)和大量進退房請求對系統的沖擊。世界杯是四年一度的體育盛會，會有大量用戶同時在線看球聊球，這為 RTC 房間帶來了持續(xù)高并發(fā)的音視頻推拉流壓力，對于系統的性能及穩(wěn)定性提出了巨大挑戰(zhàn)。同時，在比賽開始和比賽結束時，短時間內大量用戶進房、退房的請求也會對 RTC 系統形成沖擊 。
二是觀賽中的音視頻體驗問題。 包括外放時，比賽的聲音被麥克風采集并發(fā)送到遠端形成回聲的問題；通話人聲響度低于直播聲音響度導致聽不清問題；整體音質優(yōu)化等難點問題。
2. 整體方案設計
抖音“邊看邊聊”的玩法允許單房間 500 人加入，每個房間允許 9 個用戶上麥聊天，另外 491 個未上麥用戶只旁聽不發(fā)言。在整體方案設計的過程中，火山引擎 RTC 考慮了“語音聊天室方案”和“ RTC 互動語聊方案”兩種方案，并對兩種方案架構進行了分析。
2.1 語音聊天室方案
方案選型初期，其中一個候選方案是“在直播間中再嵌入一個語音聊天室”，即，在觀看比賽直播的同時，上麥用戶加入 RTC 進行語音聊天，其余未上麥觀眾再多拉一路 CDN 流收聽聊天內容， 整體結構如下：
該方案的優(yōu)勢是可以快速復用線上業(yè)務語音聊天室的主播、觀眾代碼，以及復用當前線上業(yè)務中上麥、下麥流程，快速搭建該玩法場景。但這個方案也存在一個問題， 即未上麥的用戶（圖中好友 C、好友 D）聽到的聊天內容會有較大的延時， 麥下用戶會在進球后大約 1~3 秒（CDN 轉推延時）才能聽到麥上用戶聊進球相關內容，這會導致比賽進程畫面和聊天內容不同步、聊天內容延時大，對于需要“同頻共振”的大型賽事觀播是無法接受的體驗。
2.2 RTC 互動語聊方案
為了保證所有用戶“邊看邊聊、精彩共享”的核心體驗，“邊看邊聊”玩法選擇了“ RTC 互動語聊”的方案，即所有用戶都加入 RTC 房間，使用火山引擎 RTC 為支持超大型視頻會議、在線教育大班課場景打造的“千人上麥”和“穩(wěn)定支持超百萬人同時在線”能力，來應對百萬人并發(fā)量級的世界杯“邊看邊聊”需求。
方案整體架構如下：
方案核心要點如下:
（1）觀眾使用播放器從 CDN 拉取高清比賽直播流，播放器支持用戶手動選擇清晰度檔位、支持 seek 觀看高光時刻等操作；
（2）頻道中好友通過 RTC 進行實時音頻通話；
（3）RTC 支持將通話的語音切片后存儲，供業(yè)務進行審核，保障通話內容安全；同時，平臺還可以通過踢人/拉黑等運維 OpenAPI，處理不合規(guī)或不符合業(yè)務預期的用戶，保障平臺運營安全。
在確認整體方案架構后，我們重點對如何應對超高并發(fā)、如何提升邊看邊聊體驗進行了深度優(yōu)化。
3. 關于超高并發(fā)問題的優(yōu)化和實踐
“超高并發(fā)”是本次世界杯“邊看邊聊”場景的最大挑戰(zhàn)，由于比賽活動時間集中，相關流量都會集中出現在 64 場比賽的時間段，特別是在開幕戰(zhàn)、明星球隊出戰(zhàn)、決賽等熱門比賽場次，會有超大量觀眾同時進入直播間；而且，用戶在比賽開始前后集中上線、比賽結束后集中離線也會對 RTC 系統穩(wěn)定運行形成巨大壓力。
3.1 關于流數高并發(fā)的優(yōu)化
世界杯“邊看邊聊”場景的特點是流量大，DAU 高（預估峰值將超過百萬觀眾同時“邊看邊聊”），抽象到 RTC 場景，就是房間數量多，每個房間的用戶數也多。因此，我們設計了一套高效率的方案，來兼顧用戶實時交互體驗以及承載更多量級用戶的需求。
3.1.1 常規(guī)方案
首先是常規(guī)方案。在常規(guī)方案中，服務器只需要轉發(fā)流，不需要做過多額外的處理，用戶在最后一公里就近接入，服務器之間做級聯。在這種架構下，用戶的實時交互體驗極佳，但對于大房間（用戶多）來說不夠合理，用戶訂閱壓力大，客戶端面臨一定的拉流壓力，服務端也面臨性能和容量的雙重挑戰(zhàn)。
常規(guī)方案架構圖如下：
以“500 人房間”為例，單房間 500 個用戶看球，其中 9 個人開麥聊天，訂閱端每個用戶需要訂閱 9 路流，用戶下行拉流過多，對用戶的客戶端造成一定的性能壓力。再說服務端，假設考慮到服務器之間級聯，在最差情況下（500 個用戶連接到 500 個不同服務器節(jié)點，服務器之間都需要級聯轉發(fā)），平均一個用戶會給整個系統帶來 10+ 路媒體流。再考慮到這個場景的 DAU，這套常規(guī)方案對服務端性能、容量都會造成很大的壓力。
3.1.2 公共流擴展方案
常規(guī)方案在房間人數多時會面臨諸多性能壓力，因此我們又設計了一套公共流擴展方案。在公共流方案中，發(fā)布端（上麥用戶）仍然使用常規(guī)方案的設計，媒體服務器只需要純轉發(fā)，不需要做過多額外的處理；訂閱端（閉麥用戶）則訂閱經過 MCU（Multipoint Control Units，多點控制單元）服務器處理的公共流，在這個架構下，用戶的訂閱流數降低至 1 路。
同樣以“500 人房間”為例，單房間 500 個用戶看球，其中 9 個人開麥聊天，訂閱端每個用戶只需要訂閱 1 路流，釋放了客戶端使用壓力。對于服務端來說，平均一個用戶只會給整個系統只會帶來 2-3 路媒體流的增加，極大優(yōu)化了服務端資源消耗。
這套方案架構可以很好地解決熱流分發(fā)的壓力，相同的服務器資源可以承載更大的容量，單流可支持 10w 量級的并發(fā)訂閱。客戶端也因為訂閱變少，性能得到很大的提升。但這套方案架構也會對用戶的交互體驗產生影響，當用戶從“只訂閱的角色”切換至“發(fā)布 + 訂閱”的角色時，用戶需要先切換到“常規(guī)方案”，即“從公共流”進入到“RTC 房間”，這個時候，用戶的流內容會發(fā)生切換，用戶會有“卡頓一下”的感覺。如果這個用戶頻繁地切換角色，那就會頻繁地感覺到“卡頓”，用戶體驗反而惡化。
3.1.3 融合方案
常規(guī)方案帶給用戶的交互性好，但是增加了大多數訂閱端用戶的設備端性能壓力以及服務端的資源消耗；公共流方案減少了 RTC 系統全鏈路并發(fā)音視頻流數，緩解了訂閱端用戶的性能壓力，但是在頻繁上下麥時，頻繁地“常規(guī)方案”和“公共流方案”之間切換會導致戶體驗受損。基于以上特點，火山引擎 RTC 在抖音“邊看邊聊”場景中設計了一套“有房間+公共流”的融合方案，來兼顧用戶體驗和設備端、服務端性能優(yōu)化。
融合方案設計流程如下：
具體流程為：
- 用戶進房
a. 當一個聊天頻道的用戶小于 M 人時，該房間使用“常規(guī)方案”，用戶使用“靜默用戶”的身份進入 RTC 房間并訂閱流；
b. 當一個聊天頻道的用戶大于等于 M 人時，用戶使用“公共流擴展方案”加入。 - 首次上麥
a. 當用戶以常規(guī) RTC 方案訂閱流時，上麥時用戶改變狀態(tài)，靜默用戶 -> 非靜默用戶；
b. 當用戶以公共流方式訂閱流時，上麥時用戶以非靜默用戶身份直接進入 RTC 房間。 - 二次上麥
a. 用戶改變狀態(tài)，靜默用戶 -> 非靜默用戶。 - 用戶下麥
a. 用戶改變狀態(tài)，非靜默用戶 -> 靜默用戶。
將常規(guī)方案與公共流方案結合的方案融合了兩者的優(yōu)點：
（1）用戶默認以訂閱公共流的方式加入“大房間”中，可以減少 RTC 系統全鏈路的并發(fā)音視頻流數，擴大 RTC 系統并發(fā)容量；
（2）能有效減少用戶在不拉流時候的設備端性能壓力；
（3）用戶在上麥時切換為常規(guī) RTC 方案“有房間”的模式，可以保證用戶實時的交互音視頻體驗。在切換為有房間模式后，后續(xù)的上下麥則不會再變更模式，保證了用戶的平滑體驗。
3.2 系統容災保護
抖音 DAU 很大，參與“邊看邊聊”玩法的用戶并發(fā)峰值超過百萬量級，并且，世界杯類大型賽事活動有個特征——在比賽開始的時候，用戶集中進房；比賽結束時刻，用戶又會集中停止使用音視頻功能，所以在比賽開始和結束的時候會有大量請求發(fā)到 RTC 云端服務器，對云服務造成很大壓力，極端情況下甚至會導致服務異常。針對進房和退房的不同特點，火山引擎 RTC 分別采用了“多級限流”的進房保護策略和“延時處理”的退房保護策略。
3.2.1 進房多級限流保護
火山引擎 RTC 采用“邊緣+中心”結構，用戶就近接入邊緣節(jié)點，數據則存儲在中心機房。在做限流保護的時候，我們也采用了相似的策略，即多級保護、分段限流，包括全局分布式 QPS 限流，中心 QPS 限流，中心房間數限流。
架構如下：
全局分布式 QPS 限流
全局分布式 QPS 限流采用滑動窗口算法實現。中心信令通過存儲維護每秒可以消耗的令牌數量，邊緣節(jié)點定時向中心同步自己的令牌數量，同時中心返回當前時間戳內消耗的總令牌數。進房時刻的尖峰流量對中心節(jié)點不友好，全局分布式 QPS 限流可以保證限流平滑，即使部分節(jié)點有瞬時尖峰流量，整個系統也不會受到過大沖擊。
中心 QPS 限流
中心 QPS 限流采用令牌桶算法實現。中心信令以恒定的速率產生令牌，然后把令牌放到令牌桶中，令牌桶有一個容量，當令牌桶滿了后，如果再向其中放入令牌，多余令牌就會被丟棄。當中心信令想要處理一個請求的時候，需要從令牌桶中取出一個令牌，如果此時令牌桶中沒有令牌，那么該請求就會被拒絕，客戶端會收到服務端返回的錯誤碼提示。
中心房間數限流
中心信令會在存儲中維護當前系統可以承載的最大房間數量，每當新用戶使用火山引擎 RTC 之后，中心信令就會查詢存儲判斷當前的房間數量是否已到達上限，如果超過了，則會拒絕本次用戶的請求，客戶端會收到服務端返回的錯誤碼提示。
全局分布式 QPS 限流、中心 QPS 限流，中心房間數限流“三管齊下”的進房多級限流保護措施解決了“邊看邊聊”場景大流量對整個系統的威脅。云服務系統在處理高并發(fā)請求時，先進行全局分布式 QPS 限流，然后再進行中心 QPS 限流，當整體系統處于高水位時，又會采取全局分布式房間數限流。
3.2.2 退房/斷連延時處理保護
進房操作對實時性要求很高，如果進房慢，用戶的體驗也會嚴重受損。不同于進房操作，用戶可以在一定程度上忍受“退房慢”，因此服務端的保護策略上也和進房略有不同。退房/斷連保護的策略核心是“延時處理”，在邊緣節(jié)點設置一個定長的 FIFO 隊列，每個邊緣節(jié)點的請求先進入 FIFO 隊列中，后續(xù)按照一定的速率重新發(fā)送到中心信令。經過這樣的保護，服務可以處理超百萬 QPS 的退房操作。
退房/斷連保護的基本執(zhí)行步驟：
- 檢測用戶退房事件（包括用戶正常離開房間與斷網離房）的 QPS，如果 QPS 超過可以立即處理的閾值，將事件觸發(fā)的上下文保存到隊列中，且記錄當前時間戳到事件的上下文中；
- 在隊列中啟動一個 Loop，嘗試獲取隊列中請求任務去執(zhí)行，每次在執(zhí)行前，還會檢查退房事件觸發(fā)事件的時間戳與當前時間差是否小于某個定義的閾值，小于該閾值的請求會被執(zhí)行發(fā)送到中心信令；大于等于該閾值的請求則會被丟棄；
- 在發(fā)送成功后，從隊列中刪除該事件的上下文信息。
異常場景考慮
- 用戶發(fā)送退房請求，且被攔截保存到緩存隊列中，之后很短時間內用戶又重新進房，那么會出現用戶退房事件與用戶下次進房存在時序問題，我們用引入“退房時間戳”來解決這個問題。中心信令在接收到用戶退房請求時，會比較當前用戶進房時間戳與退房時間戳，若進房時間晚于退房時間，說明是用戶退房后再進房，系統可以直接忽略該用戶的離房請求。
- 退房請求放入隊列超過一定時長后可能會觸發(fā)斷連請求。這里的處理方式就是依次處理退房請求和斷連請求，如果用戶已經退房，則忽略斷連請求。
4. 極致用戶體驗
極致的音視頻體驗是業(yè)務玩法獲得用戶認可的必要條件。在邊看邊聊場景中，我們面對著本地直播音頻被麥克風采集形成回聲、使用通話模式導致直播音質變差、比賽聲音比聊天聲音大導致人聲聽不清楚等問題，這些問題都嚴重影響了用戶的邊看邊聊體驗；為了解決相關問題，我們使用了直播音頻托管 RTC 播放、全鏈路音頻媒體通道模式、智能音頻閃避等方案，為邊看邊聊提供了良好的音視頻體驗。
4.1 音頻托管
回聲消除問題是 RTC 的重點和難點問題；在邊看邊聊場景中，部分用戶會使用外放音頻方式來觀看比賽， 在這種情況下，RTC 播放的遠端人聲和直播播放器播放的比賽聲音會被麥克風采集后發(fā)送到遠端形成回聲。
為了解決邊看邊聊場景的回聲問題，RTC 和播放器提供了播放器音頻托管由 RTC 來播放的解決方案，由播放器將解碼后的直播音頻數據調用 RTC 音頻托管接口來播放；在 RTC 內部，直播音頻會和遠端用戶音頻進行混合，再調用系統音頻播放接口進行播放，同時將混合信號送到 RTC 回聲消除模塊，回聲消除模塊會將麥克風采集到的聲音中的遠端音頻和直播比賽聲音消除，這樣就得到了沒有回聲的本地人聲數據，這些數據會在編碼后送到遠端，避免了回聲問題的出現。
4.2 外放媒體模式
在移動端設備上，音頻播放區(qū)分通話模式（通話模式音頻通道）和媒體模式（媒體模式音頻通道），二者在音質表現、音量控制上略有不同，從而適用于不同的業(yè)務場景， 具體表現如下：?
由于邊看邊聊場景是在直播間觀看比賽過程中開啟音頻通話，我們既要保障通話沒有回聲，也要保障直播音頻音質；我們分別對邊看邊聊場景 RTC 使用媒體通道和通話通道進行了對比測試結果如下：
為了給用戶提供更好的音質體驗，本次邊看邊聊場景配置了外放媒體模式；為了解決外放媒體模式時系統回聲消除效果差的問題，火山引擎 RTC 引入了基于深度學習的回音消除算法，對傳統算法難以覆蓋的場景進行音質提升，比如信號回聲比較大的情況，非線性失真加大的情況，以及音樂場景等，在保障聊天回聲消除條件下，達到了高音質體驗。
4.3 智能音頻閃避
邊看邊聊場景的另外一個特點是直播流中現場聲音、解說聲音的音量通常會比好友之間聊天聲音音量大，這就造成了聊天的聲音偏小或者幾乎聽不到遠端好友聲音的問題；為了解決直播聲音大而聊天聲音比較小的問題，我們在邊看邊聊場景中調整了遠端人聲和直播聲音的音量配比，保障遠端聊天人聲和直播聲音響度基本持平。
為了更進一步避免比賽聲音和遠端人聲沖突導致無法聽清聊天內容的問題， 我們引入了智能音頻閃避算法。音頻閃避（Audio Ducking）的功能是當檢測到 A 信號出現時，將 B 信號的電平降低，仿佛 B 信號「躲避」了 A 信號，因此得名「閃避」。閃避算法非常適合在「邊看邊聊」和「游戲直播」場景中開啟，在邊看邊聊場景中，A 信號是遠端用戶人聲，B 信號是播放器播放的比賽聲音。開啟閃避功能后，RTC 在收到遠端語音時，將播放的直播聲音進行閃避，能讓用戶更清晰地聽到遠端好友的語音， 經過驗證，達到了非常好的音頻體驗。
邊看邊聊場景添加智能音頻閃避后的音頻處理流程如圖：
關于智能音頻閃避功能中的音頻增益控制，還有一些經驗性原則需注意：
- 增益下降應足夠快，否則語音的開始片段仍會被音樂掩蔽；但又不能過快，導致出現音質問題；
- 增益下降后，應該保持足夠的時間，等待人聲消失一段時間后再恢復，否則，正常講話的停頓會頻繁觸發(fā)閃避效果，體驗很差；
- 增益的恢復可以稍慢，不要給人很突然的感覺；
- 要對遠端人聲進行智能識別檢測，避免遠端噪聲引起過度閃避。
5. 總結與展望
火山引擎 RTC 邊看邊聊場景解決方案， 通過 RTC 公共流 + RTC 有房間無縫切換的方案，在兼顧實時音視頻體驗基礎上，支持了單流超大規(guī)模的并發(fā)，降低了用戶拉流數量，不僅提高了觀賽機型滲透率也提高了 RTC 系統容量；針對世界杯觀賽用戶集中進房 ，集中退房的特點，RTC 服務端制定了 “邊緣限流”，“中心限流” ，“信令平滑發(fā)送” 等重保策略，提高了 RTC 服務在高 QPS 場景下的穩(wěn)定性；使用直播流音頻托管給 RTC 播放的方案，解決了雙端同時播放直播流音頻引入的回聲問題；使用外放媒體模式 + 軟件 3A 方案，在兼顧回聲消除基礎上保障了高音質邊看邊聊體驗；通過調整音量配比和智能音頻閃避功能，解決了直播流聲音大， 聊天聲音小的問題。經線上打磨驗證，方案設計合理有效，為世界杯邊看邊聊觀賽體驗提供了有力的保障。
更進一步，在一起看短視頻、一起看電影等場景，業(yè)務還可以通過實時信令(RTS)來對房間中各個用戶觀看進度進行集中控制，保障房間中用戶觀看相同內容；業(yè)務還可以選擇打開視頻， 更進一步增加好友之間的觀影、觀賽體驗；在UGC 大咖解說場景，我們還可以支持用戶上麥與主播進行互動聊天，更進一步拉近主播和觀眾的距離，實現更好的互動效果。
6. Demo 和場景搭建
我們將支持邊看邊聊的材料整理成了場景化解決方案文檔和 Demo， 供有需要的開發(fā)者來快速實現自己的業(yè)務場景， 歡迎廣大開發(fā)者點擊閱讀原文參考和體驗。
7. 加入我們
火山引擎 RTC，致力于提供全球互聯網范圍內高質量、低延時的實時音視頻通信能力，幫助開發(fā)者快速構建語音通話、視頻通話、互動直播、轉推直播等豐富場景功能，目前已覆蓋互娛、教育、會議、游戲、汽車、金融、IoT 等豐富實時音視頻互動場景，服務數億用戶。
