流媒体服务器选型：先定场景，再定软件

三类候选的真实面貌

一个务实的路径：用 MediaMTX 两周出原型验证推拉流通路，定型后迁到 SRS 做长期承载。两套软件的推流地址格式接近，迁移成本主要是配置而非业务改造。

五个选型维度

1. 协议矩阵：SRT 推流、WebRTC 分发、HTTP-FLV、HLS，逐项对照需求清单，缺一项就是硬伤。协议本身的对比见推流分发方案。
2. 单机并发：拉流并发是核心数字，转发型 4 核 8G 机器扛 2000-5000 路是常见区间，别信厂商页面的理论峰值。
3. 转码能力：软编吃 CPU、硬编看机型，档位策略的成本账在推流分发专题里算过。
4. 集群与扩容：边缘节点怎么加、源站怎么主备，决定了后续能不能平滑扩到多区域。
5. 运维成本：监控指标暴露、日志格式、社区活跃度——停更的软件选了就是自己养。

容量公式与压测方法

容量规划一个粗公式：出口带宽（Gbps）= 峰值并发观看数 × 码率（Mbps）÷ 1000。1 万人看 720p（2 Mbps）就是 20 Gbps 出口，单机扛不住，必须靠CDN分发边缘节点分摊。压测别用厂商工具自测，用真实推流源加分布式拉流工具，观察三个指标：卡顿率、首屏时间、CPU 峰值。首屏时间超过 3 秒，观众流失率翻倍。

高可用：直播挂了就是全站事故

直播服务不可用时没有降级方案，观众等不了。高可用三件套：源站主备，推流地址双写、备机热切换，切换窗口控制在 10 秒内；边缘节点多 CDN 互备，主 CDN 故障时 DNS 切换；推流、转码、分发三段各自独立的探活告警，定位故障不用猜在哪一段。演练别省——每季度做一次主动断源演练，验证切换真的会发生。没演练过的高可用设计，默认按没有设计处理。

低延迟场景对服务器的额外要求——UDP 缓冲、SFU 能力——在低延迟实现路径的 WebRTC 章节有展开。