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