2026-11-13 19:28:53 k73游戏之家 作者：testai
开播前都觉得推流不就是把画面送上去吗，真跑起来才发现麻烦一堆：推流端一断观众那边直接黑屏，转码队列一长延迟就飙上去，弹幕和连麦一进来机器就开始喘。手上这台机器到底撑不撑得住，要不要专门买一台只做推流，是很多人真正卡住的地方。这篇按推流这条链路从头捋一遍，把资源怎么吃、带宽怎么估、故障先查哪里，以及七百五和三百九这两档怎么挑，都摆开说清楚。
推流这条链路里，机器干的活分成三块：接流、转封装、分发。接流是持续的网络写入，单路看起来不重，几十路叠起来对网卡和中断处理就是实打实的压力，端口跑满时第一个报警的通常是网卡，不是 CPU。转封装把 FLV 拆成 HLS 分片，靠的是磁盘持续写入和多线程调度，切片时长越短写得越密，磁盘压力跟着上去。
内存这一项最容易被低估。每路连接都要占缓冲区，切片在落盘之前也会在内存里过一手，路数一多，内存涨得比 CPU 快得多。判断够不够别只看当前空闲值，要接上真实路数跑一个小时，再看还剩多少余量，一小时后的数字才有参考价值。
CPU 的用法和建站完全不同。建站是短请求、快返回，推流是长连接、稳定占用，一路 1080p 的转码能吃满两三个核，纯中转只占零点几个核，两者差一个量级。把这两种负载混在同一台机器上，最先崩的往往是转码时间。要判断该买几核，按\"实际路数×每路占用\"算出来，比看参数表靠谱。
带宽得按上行算。推流是往服务器送数据，一路 1080p 大概 4 到 6 Mbps，五十路就是两三百兆的持续上行。端口标称值和跨境链路实际能跑多少是两件事，国际出口在晚高峰会明显缩水，按七成估算更接近真实情况。
磁盘不用追容量，要追随机写性能和寿命。切片文件写完就被读走，同一个小区域反复擦写，机械盘在几十路并发下延迟会抖得很厉害，固态是起步配置。真要长期存档回看，另挂一块大盘放历史文件，别让回看写入影响正在播的切片。
单机全包的好处是省事，接流、切片、分发都在一台机器上，配置简单，排查路径也短，出问题只有一台要看。坏处是转码一旦占满 CPU，接流就开始丢包，观众端表现为集体卡顿，一个负载问题被放大成所有人的体验问题。
分开做的思路是把接流和转码拆到两台机器，接流那台只做转发和切片，转码那台专心吃 CPU，任何一边吃紧都不影响另一边直播的连续性，代价是一台机器的故障不会直接变成全员黑屏。代价是多一跳内网传输和多一套配置，两台之间的带宽要留够，不然拆分带来的隔离效果会被传输瓶颈吃掉一半。内网这一跳如果不稳，转码端拿到的流会带上花屏，比单机还难查。
判断标准其实就看两个数：同时在线推流的峰值路数，以及需要输出的清晰度档数。十路以内、只输出一个码率，单机足够应付；这点路数对 2Gbps 端口来说带宽也留得很宽；超过二十路或者要同时输出三四个码率，转码迟早把机器吃干，拆开更省心。拆开之后另一个好处是故障面变小，接流那台重启不影响正在跑的转码任务。
另一层考虑是扩容颗粒度。分开做之后加机器只是加转码节点，接流那台不动，扩容的粒度更细，运维压力也小一些。如果业务有明显的波峰波谷，比如只在大促那几天多开几十路，拆分能让扩容的钱花得更精准。
算法其实很简单：码率乘以时长乘以路数。一路 1080p 按 5 Mbps 算，一小时大概 2.25 GB；十路每天播六小时，一天就是 135 GB，一个月四千 GB 出头，四十 TB 的额度有十倍左右的余量。这个数字算清楚，就不会被\"流量会不会不够\"这种模糊担心牵着走。
上行和下行要分开看。推流是上行，观众拉流是下行或者回源，很多人只按上行算，结果分发那一段把额度吃光。走了 CDN 的话，回源流量按实际拉取算，热门时段集中在一个小时里，峰值比平均值高一截，额度要按峰值日来估而不是按平均日。
端口大小决定的是一瞬间能跑多快，流量额度决定的是一整个月能跑多少，两者不能互相顶替。2Gbps 端口意味着理论上行能到 250MB/s，实际上跨境链路很难跑满，能稳定到一半就算不错。给单机配大端口的意义，是把突发撑住，不是让日均跑得更快，日常跑量靠的是稳定而不是峰值。
码率不是越高越好。1080p 五兆在移动端已经很够看，硬推到八兆只会让弱网用户卡得更厉害，自适应多码率比单纯拉高码率有用得多。同一路流输出三档码率，观众按网络自己挑，总体验比统一给高码率好。
场景差异也要算进去。活动直播集中在一两个小时，峰值高但总量小，端口比额度重要；电商日播是长时间低峰值，总量反而更大，额度比端口重要。两种模式对配置的偏好完全相反，先弄清自己属于哪种，再谈买什么。
提前算一笔账比事后限流省事。把每天时长、路数、码率三件事列出来乘一遍，再留三成余量给突发和回源，选档位时就不会出现月末被限速的尴尬。算完之后如果发现额度还剩一大截，说明仍有余量可以加路数，可以把这部分余量换成收入。
业务里有录播和回看的，存储与分发都要再多算一层。回看的拉流往往比直播更分散，长尾拖得很长，额度消耗更持久，而且对磁盘容量有要求，这部分和直播的资源账要分开记，混在一起很容易低估总成本。
排查顺序很关键，第一步是分清个别人卡还是所有人卡。个别人卡多半出在观众本地网络或者线路绕行这一侧，问一句他在哪个城市、用什么网络接入，问题基本能定位到他那一侧，剩下的只需确认是不是所有人都同一时间卡；所有人卡基本可以确定在服务端，这一步判断错了，后面查什么都是白做。判断方法也简单，找三五个不同地区的观众同时反馈，看卡的时间点是否一致。
服务端先看三个地方：接流那台的网卡是否打满、转码进程的 CPU 是否长期贴着满值、切片写盘的延迟有没有出现尖峰。这三个指标放在同一个监控面板里并排看，一眼就能看出瓶颈落在接流、转码还是存储哪一段，比逐个登录机器翻日志快得多。养成开播前先看一眼的习惯，很多问题在观众发现之前就能处理掉，等到弹幕刷屏再动手就晚了。
观众端的问题是另一套逻辑。播放器缓冲设置过小、分片时长过长、首个分片生成太慢，都会让起播变慢，观众感知就是点了没反应。另一种情况是 CDN 回源跟不上，切片生成了但拉不到，表现出来和本地卡顿一模一样，得看回源日志才能分清，两边日志对一次时间戳就明白了。这些改动都在推流端之外，改起来成本低但对体验影响明显，分片时长从十秒压到四秒，起播时间通常能缩短一半以上。两端一起优化，比只加机器更有效。
两档差的不只是钱。七百五那档用 6248 单颗二十核四十线程，主频 2.5GHz，64GB 内存，1TB 固态，2Gbps 端口，四十 TB 月流量；三百九那档是 4114 十核二十线程，32GB 内存，800GB 固态，1Gbps 端口，十 TB 流量。想按预算和路数自己比一遍，可以直接在这两档的香港独立服务器机型页上对照着看。
转码最看重主频和核数。6248 的单核性能比 4114 高一截，同样一路 1080p 占用更少，路数上去之后，多出来的核心直接换成并发路数。只做中转不做转码的业务，两档的差距没有想象中那么大，核数够跑网络线程就行。
内存差别体现在缓冲和并发连接上。64GB 能撑的接流路数和切片缓存比 32GB 宽得多，路数一多，32GB 那台会先碰到内存红线，表现为进程被系统杀掉而不是报错。这一点在监控里不容易发现，得看系统的回收日志。
端口和流量是另一条分界线。1Gbps 加十 TB 适合总量不大的活动直播，2Gbps 加四十 TB 更适合日播和长期跑量的场景。按上一节那笔账算一遍，日均超过两百 GB 的业务，十 TB 一个月就不太够用了。
预算有限的起步阶段，三百九那档完全能把整套链路验证掉，跑通之后再上七百五那档承接正式流量。两台的系统环境可以做得一样，迁移只是换 IP 和改配置，不用重新搭一遍，试错成本很低。
已经在跑多路转码、又不想频繁扩容的团队，直接上七百五那档更省事。省下来的运维时间比机器差价更值钱，尤其是那种一到大促就要临时加机器的场景，提前买宽一点比临时折腾划算。挑档位说到底是在买确定性，不是买参数。
第一项是持续上行。用推流工具连续推两小时，观察网卡出包速率和丢包计数，短时间测速看不出长连接的稳定性。两小时里如果丢包数一直为零，这条链路才算过关；中途出现尖峰，就要查是不是国际出口在换路径。
第二项是转码压测。故意多开几路高于实际需求的流，看 CPU 什么时候到拐点，把拐点路数记下来，实际排播按七成来定。七成这个比例不是保守，是给突发和系统进程留出空间，跑到十成才停的业务，基本每次大促都要出事。
第三项是切片落盘。观察切片目录的写入延迟和磁盘队列，特别是并发路数上去之后有没有突然的抖动。固态盘在顺序写的时候很稳，并发随机写就容易露底，这一项测出来才能判断要不要把切片目录单独分盘。
第四项是断流恢复。手动断开推流再重连，看播放端多久恢复画面，这个时间决定了事故时观众的流失量。超过三十秒还没恢复的，得考虑在推流端加自动重连和本地缓存兜底，别指望观众愿意干等。
四项测完再决定买哪档，比对着参数表猜要靠谱得多，测出来的数字才是自己业务真实的边界。测试用的机器直接用三百九那档入门配置就行，正式跑量时按实测拐点选型，钱的去处才对得上。测试那几天顺手把监控和告警配好，后面每一次异常都能变成可复用的经验，而不是重新猜一遍。
