直播系统架构详解：低延迟、高并发与CDN成本的平衡

做"直播系统"最怕一句话需求："又要延迟低、又要扛万人、还要便宜"。这三者天然互相拉扯——压低延迟往往要上更贵的实时通道，扛高并发离不开 CDN 与带宽，而预算又卡着脖子。很多技术负责人因此陷入反复返工。本文把这三角关系讲透，给你一套可操作的架构权衡框架，让决策有据可依。

一、延迟：协议决定下限

不同传输协议对应不同的延迟档位，选型要从业务对"实时感"的要求出发：

• RTMP：成熟稳定，延迟约 1–3 秒，适配绝大多数秀场与带货场景；
• WebRTC：亚秒级延迟，适合连麦与强互动教学，但服务端复杂度与成本明显更高；
• LL-HLS / SRT：折中方案，兼顾兼容性与较低延迟，是近年主流演进方向。

不要盲目追最低延迟。多数带货并不需要亚秒级，用 WebRTC 反而白白增加成本。先定义"可接受延迟上限"，再反推协议。

二、并发：CDN 是扛量的主力

万人同时在线，靠源站硬扛既不现实也不经济。直播架构的标准做法是"源站 + 多级 CDN"：推流到源站，源站转码后分发到 CDN 边缘节点，观众从最近节点拉流。选 CDN 时要重点看节点覆盖广度、回源策略与突发扩容能力，尤其是大主播开播瞬间的流量尖峰。

三、成本：最容易被忽视的隐形成本

带宽是大头

1080P 直播一小时、千人并发的带宽费用相当可观，码率、分辨率、并发人数直接决定账单。务实做法是按场景降档：重点场次用 1080P，日常用 720P，把带宽压在合理区间。

连麦另算账

连麦走的是实时音视频通道，单价远高于单向直播，需要单独评估使用频率，避免为偶尔的互动长期买单。

四、弹性：让资源跟着流量走

大促或头部主播开播时流量陡增数倍，架构必须支持自动扩缩容与节点预热。更聪明的做法是把转码、截图、录制等能力做成可开关的插件，平时省资源、战时拉满，做到按需付费。

五、小结：没有银弹，只有取舍

"直播平台搭建"

六、常见架构反模式

踩过坑的团队不在少数，以下三类反模式最典型：其一是"只盯带宽忽略转码"，转码集群扩容不及时，高峰会集体卡顿；其二是"不分场景一刀切高码率"，把低频内容也推 1080P，带宽费用居高不下；其三是"没有监控盲区"，故障发生半小时才被发现，损失的都是真实 GMV。架构评审时把这三条例入检查项，能避开绝大多数低级失误。

• 转码与播放解耦，各自独立弹性扩缩；
• 按内容热度动态定档，而非固定最高码率；
• 全链路埋点与阈值告警，延迟、卡顿率异常自动预警。

七、未来趋势：下沉与智能化

直播架构仍在快速演进。一方面，边缘计算把转码推到更靠近用户的位置，延迟与成本同步下降；另一方面，AI 正介入直播全链路——智能码率调度、违规内容实时识别、数字人主播补位。对技术负责人而言，保持架构的可插拔性比追某个具体技术更重要：今天流行的协议明天可能过时，但"源站加 CDN 加可插拔能力"的分层思想长期有效。把基础打牢，才能接住下一波技术红利，而不是每次被新概念推倒重来。

• 边缘转码降低延迟与回源压力；
• AI 介入内容安全与调度；
• 分层架构保持长期可演进。

没有万能方案，只有适合自己业务曲线的组合。先明确"延迟容忍度"和"峰值并发"，再反推协议与 CDN 组合，预算才能花在刀刃上。本文内容基于公开流媒体架构实践，落地时请以真实压测数据为准，不要仅凭厂商宣传做决策。