直播推流服务器的配置

直播推流的瓶颈，永远在上行带宽。主播端把画面推给服务器是一路流，观众从服务器拉流是一人一路，两笔账要分开算。 一、上行带宽的账 推流码率决定基础需求：1080P 直播常设 4 到 6Mbps，服务器要能稳定接收这一路，还要留出富余。带宽宁大勿小，推流一旦断流，观众看到的就是黑屏加转圈重连，体验直接归零。主播端用 OBS 这类推流软件时，码率按本地上行带宽的七成设置，给网络波动留缓冲，编码器选硬件编码能降低电脑本身的占用。 二、转码开销 观众的网络参差不齐，通常要转出多档清晰度：高码率给宽带用户，低码率给手机流量用户。软件转码（FFmpeg 这类工具）每一路 1080P 吃掉一到两个核，三档清晰度就是三到六核的持续占用，这是直播服务器 CPU 配置普遍偏高的原因。云服务器普遍不带 GPU（图形处理器），按软件转码规划更稳。转码队列要设上限，转不过来时宁可降档输出，也别让机器内存被打满。 三、并发拉流 观众数乘码率就是出口带宽需求：一百人看 4Mbps 的流，就是 400Mbps 的持续输出。这个数字比推流端大得多，规模一上来就得靠 CDN（内容分发网络）分发，源站只服务各边缘节点的回源请求。协议选择也有讲究：HLS 切片比 RTMP 的延迟高出几秒，互动性要求高的直播选低延迟协议，纯观看场景用 HLS 更省心。拉流端做卡顿统计，卡顿率超过百分之一就该回头查带宽或协议。 四、机型与建议 几十人观看的中小规模自用场景，高防云服务器 S4 配大带宽能撑住；认真做直播平台，转码加分发是标准架构，源站选顺云的裸金属 B4 跑转码更稳。上线前用 ffprobe 检查流参数是否达标，再从外地网络拉一路流实测卡顿点，数字对上了才正式开播。