目录

原文链接：

万人场景下传输挑战和演进实践 LiveVideoStackCon2022音视频技术大会上海站邀请到了火山引擎的汪俊老师，为我们分享万人场景下的传输挑战和演进实践。 https://mp.weixin.qq.com/s?__biz=MzU1NTEzOTM5Mw==&mid=2247525422&idx=1&sn=4acf497d0121ba2fcc36f9589bde72d5&chksm=fbdacc00ccad451672b38a281b6d5dca803d708857acb0cc4944c8b97f8f1c32353f989fa951&mpshare=1&scene=1&srcid=0817mFUmv5elycCQ8wfhecn5&sharer_sharetime=1660699915608&sharer_shareid=6b408f28ef68da245dcad63a23c76e10#rd

RTC基于房间来进行音视频通话，房间压力主要集中下面几点：

  • 1、进房压力
    • 与房间用户数(T)、用户进房速率(Q)有关
  • 2、发布压力
    • 与音频/视频并发发布人数M有关
  • 3、订阅压力
    • 与房间用户数(T)、单用户并发订阅流数(S)有关

  • 1、小房间：并发发布人数小于等于50，总人数小于等于50
    • 特点：特点是人数少，用户进房速率小
  • 2、千人房间：房间并发发布数最大可达到1000，总人数可达到1000
    • 特点：音视频推流人数多，用户进房速率较大
  • 3、万人房间
    • 1.大讲堂模型：并发发布人数<=50;总人数<=100w
      • 特点：推流少，拉流特多；用户分布广；用户进房速率大
    • 2. 研讨会模型：并发发布人数<=1000;总人数<=5w
      • 特点：推流多，拉流多；用户分布广；用户进房速率大

RTC房间内业务的核心指标：

    二、万人演进路线

    主要路线为：

    • 分布式架构演进
      • 多中心架构
      • 分布式信令
    • 音频传输架构演进
      • 音视频分离、自动订阅
    • 视频传输架构演进，用于超大规模的分发
      • 边缘聚合
      • 树形分发

    多中心架构演进

    早期单中心架构总结

    中心机房负责：接入、调度、信令、配置，也就是控制层面

    边缘机房负责：音视频传输、上报状态信息，也就是数据层面

    分布在各地的用户，信令传输直连中心机房，音视频传输智联就近边缘节点。

    优点：边缘节点天然分布式

    缺点：

    • 中心故障容灾能力差
    • 用户数增长，容量不足瓶颈
    • 中心机房负责全部用户的进房请求，导致进房延迟很高

    急需改进点：

    • 做到跨地域低延时

    改进多中心架构总结

    针对容灾、容量、就近接入等需求，进行改造。

    边缘节点存储数据类型：

    • 静态节点数据：可以容忍短时间不一致，不需要改造
    • 周期上报的动态数据：
      • 如房间数据，相同房间数据聚合到一个中心机房。一个中心机房故障了，边缘接入用户流量、媒体上报流量自动切到其他机房，在其他中心机房重新进房

    这样就能初步满足容灾容量问题。

    缺点：

    • 大房间消息广播风暴
    • 容灾平滑迁移：需要重新进房和房间数据重建
    • 跨地域进房延时高：按房间维度数据分片，跨地域用户进房需要获取跨机房的房间的数据

    分布式信令演进

    在中心架构1.0中，采取的是用户从中心开始接入，属于单级信令。这样有一个缺点：房间人数较多的时候，任何一个用户的进退房、流变更，中心信令会对其他用户进行广播推流，面临巨大压力。

    采用多级分布式信令，主要特点：信令下沉到边缘，形成多级推送框架；消息聚合，按需分发

    • 边缘节点接入信令通道，房间用户的消息广播时，中心下发信令到边缘节点，边缘信令对接入的用户广播消息。
    • 中心信令压力 * 边缘信令压力 * 边缘机器数 = 原有中心信令压力，通过减少分发树的广度，增加分发树的深度减少根节点的压力。
    • 消息聚合，根据订阅列表、被订阅列表，将接入同一个边缘节点的用户信令一次性下发，根据列表还可以进行按需发送，从而减少广播量

    通过信令的分布式改造，减缓了广播风暴的可能。

    分布式房间

    多中心架构中一开始使用的仍然是集中式房间，针对容灾平滑迁移、跨地域进房两个问题，需要将集中式房间演进到分布式房间。