火山引擎RTC助力抖音百万并发云侃球

　　1。背景及技术挑战
　　从电视看直播到手机电脑看直播，直播技术的发展让观众可以随时、随地观看自己喜欢的比赛，并且在看比赛时通过发送表情、发文字进行互动。但表情、文字承载的信息量较小、沟通效率低，我们无法像线下一起看比赛那样和好友边看边聊、一起为精彩的比赛呐喊，观赛体验大打折扣。
　　为了让观众获得更好的观赛体验，抖音在2022世界杯比赛直播中推出了边看边聊的玩法：每个观众都可以邀请好友（或分享聊天频道信息邀请）一起观看世界杯比赛；在频道中，好友既可以发送文字、表情聊天，还可以上麦进行语音聊天，一起为精彩进球欢呼，大大提升异地好友线上观赛的体验。
　　进入抖音体育直播间，邀请好友加入个人聊天频道，即可以和好友边看边聊
　　我们使用RTC来实现边看边聊的功能观众可以随时上麦进行语音聊天，同时频道中的普通观众也可以听到麦上用户的精彩评论。但在抖音边看边聊世界杯的玩法中，RTC面临着几个比较大的挑战：
　　一是高并发的问题，包括音视频流数高并发和大量进退房请求对系统的冲击。世界杯是四年一度的体育盛会，会有大量用户同时在线看球聊球，这为RTC房间带来了持续高并发的音视频推拉流压力，对于系统的性能及稳定性提出了巨大挑战。同时，在比赛开始和比赛结束时，短时间内大量用户进房、退房的请求也会对RTC系统形成冲击。
　　二是观赛中的音视频体验问题。包括外放时，比赛的声音被麦克风采集并发送到远端形成回声的问题；通话人声响度低于直播声音响度导致听不清问题；整体音质优化等难点问题。2。整体方案设计
　　抖音边看边聊的玩法允许单房间500人加入，每个房间允许9个用户上麦聊天，另外491个未上麦用户只旁听不发言。在整体方案设计的过程中，火山引擎RTC考虑了语音聊天室方案和RTC互动语聊方案两种方案，并对两种方案架构进行了分析。
　　2。1语音聊天室方案
　　方案选型初期，其中一个候选方案是在直播间中再嵌入一个语音聊天室，即，在观看比赛直播的同时，上麦用户加入RTC进行语音聊天，其余未上麦观众再多拉一路CDN流收听聊天内容，整体结构如下：
　　该方案的优势是可以快速复用线上业务语音聊天室的主播、观众代码，以及复用当前线上业务中上麦、下麦流程，快速搭建该玩法场景。但这个方案也存在一个问题，即未上麦的用户（图中好友C、好友D）听到的聊天内容会有较大的延时，麦下用户会在进球后大约13秒（CDN转推延时）才能听到麦上用户聊进球相关内容，这会导致比赛进程画面和聊天内容不同步、聊天内容延时大，对于需要同频共振的大型赛事观播是无法接受的体验。
　　2。2RTC互动语聊方案
　　为了保证所有用户边看边聊、精彩共享的核心体验，边看边聊玩法选择了RTC互动语聊的方案，即所有用户都加入RTC房间，使用火山引擎RTC为支持超大型视频会议、在线教育大班课场景打造的千人上麦和稳定支持超百万人同时在线能力，来应对百万人并发量级的世界杯边看边聊需求。
　　方案整体架构如下：
　　方案核心要点如下：
　　（1）观众使用播放器从CDN拉取高清比赛直播流，播放器支持用户手动选择清晰度档位、支持seek观看高光时刻等操作；
　　（2）频道中好友通过RTC进行实时音频通话；
　　（3）RTC支持将通话的语音切片后存储，供业务进行审核，保障通话内容安全；同时，平台还可以通过踢人拉黑等运维OpenAPI，处理不合规或不符合业务预期的用户，保障平台运营安全。
　　在确认整体方案架构后，我们重点对如何应对超高并发、如何提升边看边聊体验进行了深度优化。3。关于超高并发问题的优化和实践
　　超高并发是本次世界杯边看边聊场景的最大挑战，由于比赛活动时间集中，相关流量都会集中出现在64场比赛的时间段，特别是在开幕战、明星球队出战、决赛等热门比赛场次，会有超大量观众同时进入直播间；而且，用户在比赛开始前后集中上线、比赛结束后集中离线也会对RTC系统稳定运行形成巨大压力。
　　3。1关于流数高并发的优化
　　世界杯边看边聊场景的特点是流量大，DAU高（预估峰值将超过百万观众同时边看边聊），抽象到RTC场景，就是房间数量多，每个房间的用户数也多。因此，我们设计了一套高效率的方案，来兼顾用户实时交互体验以及承载更多量级用户的需求。
　　3。1。1常规方案
　　首先是常规方案。在常规方案中，服务器只需要转发流，不需要做过多额外的处理，用户在最后一公里就近接入，服务器之间做级联。在这种架构下，用户的实时交互体验极佳，但对于大房间（用户多）来说不够合理，用户订阅压力大，客户端面临一定的拉流压力，服务端也面临性能和容量的双重挑战。
　　常规方案架构图如下：
　　以500人房间为例，单房间500个用户看球，其中9个人开麦聊天，订阅端每个用户需要订阅9路流，用户下行拉流过多，对用户的客户端造成一定的性能压力。再说服务端，假设考虑到服务器之间级联，在最差情况下（500个用户连接到500个不同服务器节点，服务器之间都需要级联转发），平均一个用户会给整个系统带来10路媒体流。再考虑到这个场景的DAU，这套常规方案对服务端性能、容量都会造成很大的压力。
　　3。1。2公共流扩展方案
　　常规方案在房间人数多时会面临诸多性能压力，因此我们又设计了一套公共流扩展方案。在公共流方案中，发布端（上麦用户）仍然使用常规方案的设计，媒体服务器只需要纯转发，不需要做过多额外的处理；订阅端（闭麦用户）则订阅经过MCU（MultipointControlUnits，多点控制单元）服务器处理的公共流，在这个架构下，用户的订阅流数降低至1路。
　　同样以500人房间为例，单房间500个用户看球，其中9个人开麦聊天，订阅端每个用户只需要订阅1路流，释放了客户端使用压力。对于服务端来说，平均一个用户只会给整个系统只会带来23路媒体流的增加，极大优化了服务端资源消耗。
　　这套方案架构可以很好地解决热流分发的压力，相同的服务器资源可以承载更大的容量，单流可支持10w量级的并发订阅。客户端也因为订阅变少，性能得到很大的提升。但这套方案架构也会对用户的交互体验产生影响，当用户从只订阅的角色切换至发布订阅的角色时，用户需要先切换到常规方案，即从公共流进入到RTC房间，这个时候，用户的流内容会发生切换，用户会有卡顿一下的感觉。如果这个用户频繁地切换角色，那就会频繁地感觉到卡顿，用户体验反而恶化。
　　3。1。3融合方案
　　常规方案带给用户的交互性好，但是增加了大多数订阅端用户的设备端性能压力以及服务端的资源消耗；公共流方案减少了RTC系统全链路并发音视频流数，缓解了订阅端用户的性能压力，但是在频繁上下麦时，频繁地常规方案和公共流方案之间切换会导致户体验受损。基于以上特点，火山引擎RTC在抖音边看边聊场景中设计了一套有房间公共流的融合方案，来兼顾用户体验和设备端、服务端性能优化。
　　融合方案设计流程如下：
　　具体流程为：
　　1。用户进房
　　a。当一个聊天频道的用户小于M人时，该房间使用常规方案，用户使用静默用户的身份进入RTC房间并订阅流；
　　b。当一个聊天频道的用户大于等于M人时，用户使用公共流扩展方案加入。
　　2。首次上麦
　　a。当用户以常规RTC方案订阅流时，上麦时用户改变状态，静默用户非静默用户；
　　b。当用户以公共流方式订阅流时，上麦时用户以非静默用户身份直接进入RTC房间。
　　3。二次上麦a。用户改变状态，静默用户非静默用户。
　　4。用户下麦a。用户改变状态，非静默用户静默用户。
　　将常规方案与公共流方案结合的方案融合了两者的优点：
　　（1）用户默认以订阅公共流的方式加入大房间中，可以减少RTC系统全链路的并发音视频流数，扩大RTC系统并发容量；
　　（2）能有效减少用户在不拉流时候的设备端性能压力；
　　（3）用户在上麦时切换为常规RTC方案有房间的模式，可以保证用户实时的交互音视频体验。在切换为有房间模式后，后续的上下麦则不会再变更模式，保证了用户的平滑体验。
　　3。2系统容灾保护
　　抖音DAU很大，参与边看边聊玩法的用户并发峰值超过百万量级，并且，世界杯类大型赛事活动有个特征在比赛开始的时候，用户集中进房；比赛结束时刻，用户又会集中停止使用音视频功能，所以在比赛开始和结束的时候会有大量请求发到RTC云端服务器，对云服务造成很大压力，极端情况下甚至会导致服务异常。针对进房和退房的不同特点，火山引擎RTC分别采用了多级限流的进房保护策略和延时处理的退房保护策略。
　　3。2。1进房多级限流保护
　　火山引擎RTC采用边缘中心结构，用户就近接入边缘节点，数据则存储在中心机房。在做限流保护的时候，我们也采用了相似的策略，即多级保护、分段限流，包括全局分布式QPS限流，中心QPS限流，中心房间数限流。
　　架构如下：
　　全局分布式QPS限流
　　全局分布式QPS限流采用滑动窗口算法实现。中心信令通过存储维护每秒可以消耗的令牌数量，边缘节点定时向中心同步自己的令牌数量，同时中心返回当前时间戳内消耗的总令牌数。进房时刻的尖峰流量对中心节点不友好，全局分布式QPS限流可以保证限流平滑，即使部分节点有瞬时尖峰流量，整个系统也不会受到过大冲击。
　　中心QPS限流
　　中心QPS限流采用令牌桶算法实现。中心信令以恒定的速率产生令牌，然后把令牌放到令牌桶中，令牌桶有一个容量，当令牌桶满了后，如果再向其中放入令牌，多余令牌就会被丢弃。当中心信令想要处理一个请求的时候，需要从令牌桶中取出一个令牌，如果此时令牌桶中没有令牌，那么该请求就会被拒绝，客户端会收到服务端返回的错误码提示。
　　中心房间数限流
　　中心信令会在存储中维护当前系统可以承载的最大房间数量，每当新用户使用火山引擎RTC之后，中心信令就会查询存储判断当前的房间数量是否已到达上限，如果超过了，则会拒绝本次用户的请求，客户端会收到服务端返回的错误码提示。
　　全局分布式QPS限流、中心QPS限流，中心房间数限流三管齐下的进房多级限流保护措施解决了边看边聊场景大流量对整个系统的威胁。云服务系统在处理高并发请求时，先进行全局分布式QPS限流，然后再进行中心QPS限流，当整体系统处于高水位时，又会采取全局分布式房间数限流。
　　3。2。2退房断连延时处理保护
　　进房操作对实时性要求很高，如果进房慢，用户的体验也会严重受损。不同于进房操作，用户可以在一定程度上忍受退房慢，因此服务端的保护策略上也和进房略有不同。退房断连保护的策略核心是延时处理，在边缘节点设置一个定长的FIFO队列，每个边缘节点的请求先进入FIFO队列中，后续按照一定的速率重新发送到中心信令。经过这样的保护，服务可以处理超百万QPS的退房操作。
　　退房断连保护的基本执行步骤：检测用户退房事件（包括用户正常离开房间与断网离房）的QPS，如果QPS超过可以立即处理的阈值，将事件触发的上下文保存到队列中，且记录当前时间戳到事件的上下文中；在队列中启动一个Loop，尝试获取队列中请求任务去执行，每次在执行前，还会检查退房事件触发事件的时间戳与当前时间差是否小于某个定义的阈值，小于该阈值的请求会被执行发送到中心信令；大于等于该阈值的请求则会被丢弃；在发送成功后，从队列中删除该事件的上下文信息。
　　异常场景考虑用户发送退房请求，且被拦截保存到缓存队列中，之后很短时间内用户又重新进房，那么会出现用户退房事件与用户下次进房存在时序问题，我们用引入退房时间戳来解决这个问题。中心信令在接收到用户退房请求时，会比较当前用户进房时间戳与退房时间戳，若进房时间晚于退房时间，说明是用户退房后再进房，系统可以直接忽略该用户的离房请求。退房请求放入队列超过一定时长后可能会触发断连请求。这里的处理方式就是依次处理退房请求和断连请求，如果用户已经退房，则忽略断连请求。4。极致用户体验
　　极致的音视频体验是业务玩法获得用户认可的必要条件。在边看边聊场景中，我们面对着本地直播音频被麦克风采集形成回声、使用通话模式导致直播音质变差、比赛声音比聊天声音大导致人声听不清楚等问题，这些问题都严重影响了用户的边看边聊体验；为了解决相关问题，我们使用了直播音频托管RTC播放、全链路音频媒体通道模式、智能音频闪避等方案，为边看边聊提供了良好的音视频体验。
　　4。1音频托管
　　回声消除问题是RTC的重点和难点问题；在边看边聊场景中，部分用户会使用外放音频方式来观看比赛，在这种情况下，RTC播放的远端人声和直播播放器播放的比赛声音会被麦克风采集后发送到远端形成回声。
　　为了解决边看边聊场景的回声问题，RTC和播放器提供了播放器音频托管由RTC来播放的解决方案，由播放器将解码后的直播音频数据调用RTC音频托管接口来播放；在RTC内部，直播音频会和远端用户音频进行混合，再调用系统音频播放接口进行播放，同时将混合信号送到RTC回声消除模块，回声消除模块会将麦克风采集到的声音中的远端音频和直播比赛声音消除，这样就得到了没有回声的本地人声数据，这些数据会在编码后送到远端，避免了回声问题的出现。
　　4。2外放媒体模式
　　在移动端设备上，音频播放区分通话模式（通话模式音频通道）和媒体模式（媒体模式音频通道），二者在音质表现、音量控制上略有不同，从而适用于不同的业务场景，具体表现如下：
　　由于边看边聊场景是在直播间观看比赛过程中开启音频通话，我们既要保障通话没有回声，也要保障直播音频音质；我们分别对边看边聊场景RTC使用媒体通道和通话通道进行了对比测试结果如下：
　　为了给用户提供更好的音质体验，本次边看边聊场景配置了外放媒体模式；为了解决外放媒体模式时系统回声消除效果差的问题，火山引擎RTC引入了基于深度学习的回音消除算法，对传统算法难以覆盖的场景进行音质提升，比如信号回声比较大的情况，非线性失真加大的情况，以及音乐场景等，在保障聊天回声消除条件下，达到了高音质体验。
　　4。3智能音频闪避
　　边看边聊场景的另外一个特点是直播流中现场声音、解说声音的音量通常会比好友之间聊天声音音量大，这就造成了聊天的声音偏小或者几乎听不到远端好友声音的问题；为了解决直播声音大而聊天声音比较小的问题，我们在边看边聊场景中调整了远端人声和直播声音的音量配比，保障远端聊天人声和直播声音响度基本持平。
　　为了更进一步避免比赛声音和远端人声冲突导致无法听清聊天内容的问题，我们引入了智能音频闪避算法。音频闪避（AudioDucking）的功能是当检测到A信号出现时，将B信号的电平降低，仿佛B信号躲避了A信号，因此得名闪避。闪避算法非常适合在边看边聊和游戏直播场景中开启，在边看边聊场景中，A信号是远端用户人声，B信号是播放器播放的比赛声音。开启闪避功能后，RTC在收到远端语音时，将播放的直播声音进行闪避，能让用户更清晰地听到远端好友的语音，经过验证，达到了非常好的音频体验。
　　边看边聊场景添加智能音频闪避后的音频处理流程如图：
　　关于智能音频闪避功能中的音频增益控制，还有一些经验性原则需注意：增益下降应足够快，否则语音的开始片段仍会被音乐掩蔽；但又不能过快，导致出现音质问题；增益下降后，应该保持足够的时间，等待人声消失一段时间后再恢复，否则，正常讲话的停顿会频繁触发闪避效果，体验很差；增益的恢复可以稍慢，不要给人很突然的感觉；要对远端人声进行智能识别检测，避免远端噪声引起过度闪避。5。总结与展望
　　火山引擎RTC边看边聊场景解决方案，通过RTC公共流RTC有房间无缝切换的方案，在兼顾实时音视频体验基础上，支持了单流超大规模的并发，降低了用户拉流数量，不仅提高了观赛机型渗透率也提高了RTC系统容量；针对世界杯观赛用户集中进房，集中退房的特点，RTC服务端制定了边缘限流，中心限流，信令平滑发送等重保策略，提高了RTC服务在高QPS场景下的稳定性；使用直播流音频托管给RTC播放的方案，解决了双端同时播放直播流音频引入的回声问题；使用外放媒体模式软件3A方案，在兼顾回声消除基础上保障了高音质边看边聊体验；通过调整音量配比和智能音频闪避功能，解决了直播流声音大，聊天声音小的问题。经线上打磨验证，方案设计合理有效，为世界杯边看边聊观赛体验提供了有力的保障。
　　更进一步，在一起看短视频、一起看电影等场景，业务还可以通过实时信令（RTS）来对房间中各个用户观看进度进行集中控制，保障房间中用户观看相同内容；业务还可以选择打开视频，更进一步增加好友之间的观影、观赛体验；在UGC大咖解说场景，我们还可以支持用户上麦与主播进行互动聊天，更进一步拉近主播和观众的距离，实现更好的互动效果。6。Demo和场景搭建
　　我们将支持边看边聊的材料整理成了场景化解决方案文档和Demo，供有需要的开发者来快速实现自己的业务场景，欢迎广大开发者点击阅读原文参考和体验。7。关于我们
　　火山引擎RTC，致力于提供全球互联网范围内高质量、低延时的实时音视频通信能力，帮助开发者快速构建语音通话、视频通话、互动直播、转推直播等丰富场景功能，目前已覆盖互娱、教育、会议、游戏、汽车、金融、IoT等丰富实时音视频互动场景，服务数亿用户。