21、大规模优化：Simulcast与SVC、分层编码、选择性转发、负载均衡
做WebRTC多人视频会议，最头疼的问题是什么？
我告诉你，不是功能实现，而是人一多就卡。
3个人聊得挺好，加到8个人开始掉帧，加到16个人直接幻灯片。这问题我踩过太多次了。说白了，视频会议的核心瓶颈就两个：上行带宽和服务器压力。
这一章，我们就来拆解大规模场景下的四大杀器：Simulcast、SVC、选择性转发（SFU）和负载均衡。
21.1 为什么不能全量转发？
先想一个问题：一个20人的会议室，每个人都要看其他19个人的视频。
如果每个人都发送一路1080p视频，服务器要同时转发19路流给每个人。算一下：
- 发送端：上行带宽需要支撑19路 × 2Mbps ≈ 38Mbps。普通家庭宽带根本扛不住。
- 接收端：下行带宽同样需要38Mbps，手机4G网络直接跪。
- 服务器：CPU和带宽双重爆炸。
所以，必须做优化。核心思路就一句话：按需分配，能省则省。
核心原则：每个参与者只接收自己真正需要的视频质量。大屏看高清，小屏看低清，不看的直接不推流。
21.2 Simulcast：同时发送多个质量版本
Simulcast，中文叫「联播」或「同时广播」。什么意思呢？
发送端同时编码并发送多个分辨率/码率版本的视频流。比如：
- 高清流：720p，1.5Mbps
- 标清流：360p，500Kbps
- 低清流：180p，150Kbps
接收端根据自身网络条件和屏幕大小，选择订阅其中一个版本。
我在项目中遇到过这样一个场景：一个客户在海外，网络延迟高得离谱。如果用单流方案，他要么看高清卡死，要么看低清糊成马赛克。用了Simulcast之后，服务器自动给他推送360p的流，体验瞬间好了很多。
Simulcast的优缺点：
| 优点 | 缺点 |
|---|---|
| 接收端可以灵活选择质量 | 发送端编码压力大（同时编多路） |
| 对服务器CPU要求相对较低 | 上行带宽消耗增加（发多路） |
| 实现简单，浏览器原生支持 | 多路流占用更多网络连接 |
我的建议：如果客户端设备性能较强（PC端），优先用Simulcast。移动端慎用，因为同时编码多路视频会发热、耗电。
21.3 SVC：分层编码，一次编码多次解码
SVC（Scalable Video Coding，可伸缩视频编码）是另一种思路。
它只编码一路流，但这路流内部包含多个层次：
- 基础层：最低质量，必须接收才能解码
- 增强层：在基础层之上叠加，提升质量
接收端可以根据网络情况，选择接收「基础层」或者「基础层+增强层」。
举个例子：
- 网络差：只收基础层，得到360p画面
- 网络好：收基础层+增强层，得到720p画面
服务器不需要转码，只需要选择性转发对应的层即可。
嗯，这里要注意：SVC虽然优雅，但浏览器支持度不如Simulcast。Chrome从M90才开始支持VP9的SVC，而且编码器性能开销比普通H.264高不少。
避坑指南：我曾经在一个项目中全量使用SVC，结果发现部分老旧手机不支持VP9解码，导致黑屏。后来改成「Simulcast为主，SVC为辅」的混合方案才解决问题。
21.4 选择性转发（SFU）的核心逻辑
不管是Simulcast还是SVC，最终都需要一个转发节点来做决策。这个节点就是SFU（Selective Forwarding Unit）。
SFU不混流、不转码，只做一件事：根据订阅关系，把对应的流转发给对应的接收端。
它的工作流程大致如下：
- 发送端推流到SFU（可能是多路Simulcast流，也可能是单路SVC流）
- 接收端向SFU发送订阅请求：「我要看A的高清流，B的低清流」
- SFU根据订阅关系，把对应的RTP包转发给接收端
说白了，SFU就是一个智能路由器。它不碰视频内容，只做包的转发和丢弃。
我习惯用Janus或Mediasoup来做SFU。Mediasoup性能更好，Janus功能更全。选哪个？看你的场景：
- 纯视频会议：Mediasoup，轻量高效
- 需要录制、转码等附加功能：Janus
21.5 负载均衡：别让一台服务器扛所有
当会议规模超过100人时，单台SFU服务器肯定扛不住。这时候就需要负载均衡。
负载均衡的策略有很多，我列几个常用的：
- 基于房间的均衡：每个房间分配一台SFU服务器。简单粗暴，但大房间依然会压垮单机。
- 基于用户的均衡：同一个房间的用户分散到多台SFU上。需要SFU之间做媒体流的中继，延迟会增加。
- 基于流的均衡：同一个用户的多个视频流分散到不同SFU。复杂度最高，但弹性最好。
我在实际项目中用的是「房间+用户」混合策略：
- 小房间（≤10人）：一台SFU搞定
- 大房间（>10人）：按用户ID哈希分配到多台SFU，SFU之间通过内部高速网络互连
关键指标：负载均衡器要关注三个维度的负载——CPU使用率、内存使用率、网络带宽。任何一个维度超过80%，就要触发扩容。
21.6 知识体系总览
下面这张图，把本章的核心逻辑串起来了：
21.7 实战中的选择建议
说了这么多，到底怎么选？我直接给结论：
- 10人以内：不用优化，直接全量转发都行。别折腾。
- 10-50人：Simulcast + SFU。发送端发2-3路流，SFU按需转发。这是最成熟的方案。
- 50-200人：Simulcast + SVC混合 + SFU + 负载均衡。大屏用户订阅高清Simulcast流，小屏用户订阅SVC基础层。
- 200人以上：必须上多层负载均衡 + 动态码率调整 + 音视频分离。这时候已经不是技术问题了，是架构问题。
一个小技巧：在SFU层面做「最近活跃发言者」检测。只转发当前发言人的高清流，其他参与者只转发低清流。这样能大幅降低带宽消耗。我管它叫「焦点转发」，效果立竿见影。
好了，这一章的内容就到这里。大规模优化没有银弹，核心就是「按需分配，能省则省」。Simulcast和SVC是编码层面的优化，SFU是转发层面的优化，负载均衡是架构层面的优化。三层叠加，才能支撑起真正的大规模视频会议。