直播平台服务器如何规划？推流、转码、分发与并发容量设计

直播和点播视频看起来差不多，实际上服务器规划的思路完全不同。点播是"文件已经躺在那儿，用户什么时候来看都行"，直播是"数据实时流过来，用户必须现在就看到"。这个差别带来两个硬约束：一是延迟必须压住，二是容量必须扛住瞬时并发——直播间一开，可能是几千人同时涌入，而直播又不能像点播那样慢慢加载。

这篇文章按直播的真实链路讲：主播推流、服务器转码、观众分发，每一段需要什么资源，并发容量怎么估算，延迟和协议怎么权衡，带宽怎么规划。文中给的容量估算公式和数字都是行业里常见的经验值，用来做规划参考。读完你应该能算出一场直播大概需要多大的带宽和多少转码资源，也能判断该用哪套协议组合。

一、直播链路的四个环节

一场直播从主播按下"开始"到观众看到画面，经过了这样一条链路：

1. 采集与推流：主播端的摄像头和麦克风采集音视频，编码后推给服务器。常用协议是 RTMP（老牌、兼容好）和 SRT（较新，抗丢包强，适合网络不稳定的推流）。
2. 接入与转码：服务器接收推流，然后转成多种清晰度和码率（比如 480P、720P、1080P），供不同网络的观众选择。
3. 分发：转码后的流以 HLS、HTTP-FLV 或 WebRTC 等协议分发给观众，大规模的观众流量通常由 CDN 承担。
4. 播放：观众的播放器拉流播放，可以根据网络自适应切换到合适的码率。

和点播不同，直播是边生成边分发，服务器不能等文件齐全再处理。所以接流服务、转码服务、分发服务往往要独立部署，各自承担不同的资源压力。

二、推流：接入协议怎么选

推流这一端，协议选择直接影响主播的体验和源站的承受力。

推流端如果是固定场地、网络稳定，RTMP 就够用；如果是户外直播、网络抖动大，SRT 的抗丢包优势明显，能显著减少卡顿。源站接流服务需要开放对应端口，RTMP 默认 1935，SRT 常用自定义 UDP 端口。接流服务器要特别注意 UDP 放行和内核缓冲，否则弱网推流会莫名其妙卡。

一个典型的用 FFmpeg 做 RTMP 推流的命令：

# 安装 FFmpeg：RHEL/CentOS/Rocky 用 dnf，Debian/Ubuntu 用 apt
dnf install -y ffmpeg
apt-get update && apt-get install -y ffmpeg

# 推本地文件到 RTMP 服务器（常用于测试和拉流验证）
ffmpeg -re -i demo.mp4 -c copy -f flv rtmp://直播服务器IP/live/streamkey

其中 -re 表示按原始帧率推送（模拟真实直播节奏），-c copy 表示不重新编码直接封装，节省主播端 CPU。

用 SRT 推流则是这样（接收端需要部署支持 SRT 的服务，比如 SRS、OBS 的 SRT 输出）：

ffmpeg -re -i demo.mp4 -c copy -f mpegts "srt://直播服务器IP:10080?mode=caller"

三、转码：多码率是刚需，也是最贵的环节

直播转码和点播转码最大的不同，是它必须实时。点播可以慢慢转，直播是"晚一秒就积压一秒"，所以直播转码对性能的要求比点播苛刻得多。

多码率转码是直播的标配。 一个 1080P 源流，通常要同时转出多档：1080P（高码率）、720P（中）、480P（低）、360P（极速）。观众网络好的看高清，网络差的自动降档，避免卡顿。每多一档，就多一路编码，多耗一份算力。

转码资源方面，CPU 软转码单机并发的路数很有限。经验上，一台 16 核服务器做实时 720P 转码，能同时处理的直播路数在个位数到十路左右（取决于码率、帧率、preset）。所以直播平台几乎一定需要 GPU 硬转码——一张主流转码卡能并行处理十几路甚至几十路实时转码，单位产能成本更低。

转码和接流分离是重要原则。 接流服务负责把推流接进来，转码服务负责处理，两者通过网络或本地回环通信。接流本身很轻，转码很重，混在一起会导致接流也被拖慢，主播一卡就是全直播间的事故。

如果直播平台自己按多码率跑 FFmpeg，一个实时转码 + HLS 输出的示例：

# 实时转 720P 并输出 HLS（-re 必须加，按实时速度处理）
ffmpeg -re -i rtmp://localhost/live/streamkey \
  -c:v libx264 -preset veryfast -b:v 2500k -maxrate 2500k -bufsize 5000k \
  -c:a aac -b:a 128k \
  -f hls -hls_time 3 -hls_list_size 6 -hls_flags delete_segments \
  -hls_segment_filename "720p_%03d.ts" 720p.m3u8

hls_time 3 表示每个分片 3 秒，直播场景通常比点播用更短的分片来降低延迟；hls_list_size 6 表示播放列表只保留 6 个分片，配合 delete_segments 自动清理旧分片，避免磁盘无限增长。

四、分发：协议决定延迟，CDN 决定容量

观众侧的拉流协议，直接决定延迟量级和兼容性。

延迟和协议的权衡，本质是"要兼容性还是要实时性"。 秀场直播、电商带货，2–5 秒延迟完全够用，选 HTTP-FLV 或 LL-HLS；连麦互动、在线教育，必须 < 1 秒，只能上 WebRTC，但 WebRTC 的大规模分发成本和复杂度都高得多。

分发容量靠 CDN。 直播的观众并发通常远大于主播数，一个热门主播可能带来几万甚至几十万观众。源站不可能直接扛这么多连接，必须把观众流量交给 CDN，源站只负责给 CDN 回源。CDN 的边缘节点缓存直播分片，观众就近拉流，同时把回源的并发收敛。选 CDN 时要关注它对直播协议的支持（FLV 拉流、HLS、低延迟直播）、回源带宽、以及能否抗住瞬时并发。

五、并发容量估算与带宽规划

这是直播服务器规划里最实际的部分。核心是两条公式。

带宽估算：

所需出口带宽 ≈ 平均码率 × 并发观众数 × 冗余系数

举例：一场直播峰值 5000 人同时在线，选择 720P（约 2.5Mbps）为主，那么纯下行带宽约为：

5000 × 2.5Mbps = 12500Mbps ≈ 12.5Gbps

这还只是单档。如果考虑多码率分发（有人看 1080P 有人看 480P），实际按平均码率算，再乘 1.5–2 倍冗余应对峰值和波动，就要准备 15–25Gbps 级别的分发能力。这个量级显然要靠 CDN，源站只需要回源带宽（回源带宽远小于分发带宽，因为 CDN 节点间的复用）。

转码资源估算：

转码路数 = 直播频道数 × 每频道码率档数

如果同时有 100 个频道在播，每个频道转 3 档，就是 300 路实时转码。按一张 GPU 卡并行 20 路 720P 的经验值算，大约需要 15 张卡的转码能力，实际还要留冗余和应对突发开播。直播的特点是并发不稳定——可能晚上 8 点突然几十个主播同时开播，转码资源必须能弹性扩容，否则新开播的直播会排队等待转码。

一个务实的做法是：常备资源覆盖日常负载，高峰期靠转码集群弹性扩容。转码集群用队列调度，新开播的流进入待转码队列，有空闲 worker 就处理，同时监控队列长度触发扩容。

六、常见误区与注意事项

把接流、转码、分发塞在一台机器上。 这是最常见的错误。转码吃满 CPU 时，接流和分发都会受影响，主播端表现为推流中断，观众端表现为集体卡顿。三者一定要分开部署。

忽视推流端带宽。 很多人只算观众的下行带宽，忘了主播的上行。主播推 1080P 需要稳定上行 4–6Mbps，如果主播在家用宽带，上行本来就是短板，推流质量差不能全怪服务器。

分片时长设得太随意。 分片越短延迟越低，但请求数越多、CDN 压力越大、卡顿概率也可能升高。3 秒左右是直播 HLS 常见的折中值，追求低延迟可以配合 LL-HLS 而不是无脑缩短分片。

忘了考虑回源。 CDN 边缘没有内容时要回源，如果源站回源能力弱，热度一上来 CDN 频繁回源，源站就成了瓶颈。回源带宽和并发连接数要单独规划。

弹幕、礼物、连麦这些实时互动没算进去。 直播平台的服务器规划往往还要包含弹幕、IM、礼物、连麦信令等服务，这些和视频流是两条链路，但同样吃资源和连接数，别漏掉。

常见问题

Q：小规模直播，可以不用 CDN 吗？
可以。几百人在线、码率不高时，源站带宽能扛住，直接分发也行。但一旦规模上千人，源站出口带宽成本会迅速超过 CDN 费用，且抗突发能力差，建议尽早接入 CDN。

Q：RTMP 推流和 SRT 推流，到底用哪个？
场地固定、网络稳定用 RTMP，工具兼容性最好；户外、移动、弱网、跨境用 SRT，抗丢包能明显减少卡顿。很多平台让主播按场景自选。

Q：为什么我的直播延迟有 20 秒？
大概率用的是默认配置的 HLS，且分片较长、播放器还做了缓冲。想降延迟可以改用 HTTP-FLV，或者用 LL-HLS，并检查播放器的缓冲策略。延迟是协议和配置共同决定的。

Q：转码一定要 GPU 吗？
不是绝对，但规模化直播里 GPU 几乎是必然选择。少量频道用 CPU 也能撑，一旦频道数多、要转多档，CPU 的资源消耗和成本会迅速失控。

Q：带宽估算出来的数字太大怎么办？
这正说明必须用 CDN。源站只承担回源，观众流量由 CDN 边缘承担，源站的带宽需求会大幅下降。另外可以通过码率自适应，让弱网用户自动降到低码率档，整体平均带宽也会下降。

总结

• 直播服务器按推流接入、转码、分发三段分开规划，接流、转码、分发必须解耦，不能塞一台机器。
• 推流协议按场景选：稳定网络用 RTMP，弱网/户外用 SRT；播放协议按延迟要求选：大并发兼容优先用 HLS/HTTP-FLV，低延迟互动用 WebRTC/LL-HLS。
• 多码率转码是标配，规模化直播上 GPU 硬转码，转码资源要能弹性扩容并应对瞬时开播高峰。
• 带宽靠 CDN 承担，按"平均码率 × 并发观众数 × 冗余系数"估算，源站只负责回源，别漏算主播上行和回源带宽。
• 别忽视弹幕、IM、连麦信令这条并行链路，它们同样占用服务器资源和连接数。