视频直播已经从“能看就行”进入“高清、低延迟、不卡顿”的体验竞争阶段。无论是企业内训、电商带货，还是在线教育、赛事转播，背后都离不开流媒体服务器的支撑。很多团队在起步阶段会直接采购云服务，但当并发量上升、成本失控或需要深度定制时，自建流媒体服务器就成为必须面对的课题。本文从实际落地角度出发，梳理流媒体服务器选型的核心维度，并给出从零搭建高并发直播平台的完整思路。
一、先明确：你的直播场景决定选型方向
流媒体服务器没有“万能解”，不同协议和架构适合不同场景。选型前必须先回答三个问题：
- 延迟要求：是追求秒级延迟的互动直播，还是允许10秒以上延迟的秀场/监控？
- 并发规模：百人、千人还是十万级同时在线？这直接决定是否需要分布式架构。
- 终端覆盖：只做Web端，还是需要覆盖iOS、Android、智能电视和机顶盒？
举例来说，在线教育中的连麦互动需要WebRTC或SRT，延迟控制在500毫秒以内；而大型赛事直播可以采用HLS或DASH，利用CDN分发，延迟容忍度更高。明确场景后，才能进入技术选型。
二、主流流媒体服务器软件对比
目前开源和商业流媒体服务器各有代表，以下是比较常见的几款：
- Nginx + RTMP模块：最经典的入门方案，配置简单，适合RTMP推流和HLS分发。缺点是原生不支持WebRTC，高并发下需要额外优化。
- SRS（Simple Realtime Server）：国产开源项目，支持RTMP、HLS、FLV、WebRTC、SRT，文档友好，社区活跃，适合从零搭建且需要多协议支持的团队。
- MediaMTX（原rtsp-simple-server）：轻量级，支持RTSP、RTMP、HLS、WebRTC，适合物联网和监控场景。
- Wowza Streaming Engine：商业软件，功能全面，稳定性高，但授权费用不低，适合预算充足的企业。
- Ant Media Server：主打WebRTC低延迟，支持自适应码率，社区版功能有限，企业版按实例收费。
对于大多数从零起步的团队，SRS + Nginx + CDN 是性价比最高的组合。SRS负责接入和转码，Nginx负责HLS切片和HTTP分发，CDN承担大规模并发。如果预算允许且需要开箱即用的低延迟，可以考虑Ant Media或Wowza。
三、高并发架构的核心设计原则
单台流媒体服务器无法支撑高并发，必须从架构层面解决问题。以下四个原则是搭建高并发直播平台的基础：
1. 接入层与分发层分离
推流端统一接入到边缘接入服务器，接入服务器只负责接收流并转发到核心集群，不直接面向观众。观众请求由分发层处理，分发层通过CDN或边缘节点回源。这样接入层压力可控，分发层可以水平扩展。
2. 使用边缘计算降低回源压力
当并发达到数千以上时，所有观众请求都回源到中心服务器会导致带宽和CPU瓶颈。引入边缘节点（可以是自建边缘机或CDN）后，边缘节点缓存直播流，观众就近拉流，回源比例可控制在5%以下。
3. 协议自适应与转码分层
不同终端和网络环境需要不同码率。建议推流端推送一路高码率流，服务器转码出多档码率（如1080p、720p、480p），并通过HLS或DASH的master playlist让播放器自适应切换。转码是CPU密集型操作，高并发下建议使用GPU转码或独立转码集群。
4. 无状态化与水平扩展
流媒体服务器本身是有状态的，但可以通过“流注册中心”实现协调。例如使用Redis记录流的路由信息，当某台服务器故障时，调度器将推流和拉流请求迁移到其他节点。结合Kubernetes或Nomad，可以实现自动扩缩容。
四、从零搭建的实操步骤
下面以SRS为例，给出一个可落地的最小高并发架构搭建流程：
- 环境准备：准备至少3台服务器——1台接入服务器、1台转码服务器、1台边缘分发服务器。操作系统推荐Ubuntu 22.04 LTS。
- 部署SRS：在接入服务器上编译安装SRS，配置RTMP监听1935端口，开启HLS切片，并设置forward到转码服务器。
- 配置转码：在转码服务器上使用FFmpeg或SRS内置转码，输出多档码率。建议至少输出720p和480p两档，码率分别为2500kbps和1000kbps。
- 边缘分发：边缘服务器配置SRS的edge模式，回源到转码服务器。观众通过边缘服务器拉取HLS或HTTP-FLV流。
- 接入CDN：如果并发超过单台边缘服务器承载能力，将边缘服务器作为CDN的回源，CDN负责最后一公里分发。
- 监控与告警：部署Prometheus + Grafana监控推流数量、带宽、CPU、内存和延迟。设置阈值告警，及时发现瓶颈。
经验提示：在正式上线前，务必用压测工具（如srs-bench或FFmpeg循环推流）模拟目标并发量，观察服务器在峰值时的表现。很多问题只有在压力下才会暴露。
五、常见坑与优化建议
即使架构设计合理，实际运行中仍会遇到各种问题。以下是最常见的几个坑：
- GOP设置过大导致首屏慢：推流端GOP建议设置为1-2秒，否则HLS切片等待时间长，首屏加载慢。
- TCP拥塞控制未优化：高并发下建议开启BBR拥塞控制算法，提升弱网环境下的传输效率。
- 磁盘I/O成为瓶颈：HLS切片频繁写盘，建议使用SSD或内存文件系统（tmpfs）存放切片，并定期清理旧文件。
- 时间戳同步问题：多路流转码时容易出现音视频不同步，推流端应确保时间戳连续，服务器转码时使用-fflags +genpts重新生成时间戳。
流媒体服务器选型不是一次性工作，而是随着业务规模不断调整的过程。从单机RTMP起步，逐步引入转码集群、边缘节点和CDN，每一步都对应着并发量和体验要求的提升。建议团队在初期就建立完善的监控体系，用数据驱动扩容决策，而不是等到用户反馈卡顿才被动应对。
最后，不要忽视协议演进。SRT和WebRTC正在逐步替代传统RTMP在推流端的地位，选型时优先选择支持多协议、社区活跃的流媒体服务器，可以为未来的技术升级留出空间。