上个月在一家装备制造企业做年度供应商大会，甲方问了个很实在的问题：我们内网最多能扛多少人同时看？我当时没急着报数，因为私有化直播并发这个数，拍脑袋给只会事后翻车。摄行科技进场前先要了他们的交换机型号和服务器清单，才敢开口。那次他们自己估了两千，我们压测下来实际稳在 1340，差出来的六百人就是事故的温床。后来他们 IT 主管跟我说，以前从来没人算过这个数，都是凭感觉加机器，加少了开播卡，加多了又浪费预算，两头不讨好。
私有化直播并发和公网并发不是一回事
先说清楚，私有化和公网办一场直播，压根两套算法。公网有 CDN 帮你分摊，边缘节点一铺，十万人和一千人差别没那么大。私有化不一样，观众全挤在你自己的机房和交换机上，每一路都吃你自己的带宽和 CPU。公网那套，CDN 厂商帮你扛了绝大部分分发，你只管推一路上去；私有化是你自己从头扛到尾，所以算法天然不同。把公网的经验直接搬过来，等于拿自行车的油耗标准去管卡车，怎么算都拧巴，参数对不上号。
2024年3月我们给一家化工企业做内训，他们一开始按公网经验估，说两千人没问题。结果真压测，到 1370 人时内网核心交换机就红了。私有化直播并发得从你自己的硬件出发算，不能套公网的公式，这是很多人栽跟头的地方。他们网管后来承认，交换机还是五年前的老型号，端口会话上限早该换了，只是没人动，平时小会看不出，一上规模就露馅，红灯一亮全场掉线。
私有化直播并发的瓶颈在哪儿
瓶颈一般三个地方：出口带宽、转码算力、连入交换机的会话数。很多人只盯带宽，其实转码更狠。一路 1080p 转码大概吃 0.7 个 CPU 核，如果你要同时出 720p、480p 两路，翻倍。还有个常被忽略的，是单台机器的文件描述符上限，Linux 默认有时候才一千出头，并发一上来直接报 too many open files。我们每次进场第一件事就是把 ulimit 调上去，不然前面算得再准，这一关先挂，服务器自己先躺了。还有存储 IO 这一项，转码时疯狂读写，机械盘直接跪。我们进场都要求上 SSD 或者至少万转盘，不然转码机算得动，盘拖后腿，并发照样上不去。这点甲方往往想不到，以为 CPU 够就万事大吉，结果瓶颈在盘上，查了半天才发现。
一家车企的培训直播，我们当时上了 8 台转码服务器，每台 16 核。粗算下来纯转码能撑 180 路同时转，但接入交换机只认 1500 个并发会话。所以私有化直播并发的天花板，往往是你最短那块板，不是你最强的那块，盯着带宽看是看不出真相的。那家车企的网管一开始只报带宽，我们让他把交换机会话表拉出来，他才发现问题在另一头，带宽其实还剩一大截，会话数早满了，典型的被忽视的瓶颈。
算并发先数清楚三股流量
别一上来就算总人数。先把流量拆三股：推流上行、内网下行、回看录制。上行一般就几路，不用怕。真正吃人的是内网下行，每个观众一路。回看录制这一股最阴，它不在开播时吃，而在开播后悄悄吃你存储和转码。不少人只算直播时的并发，忘了录下来的片子还要转码成点播，那波算力往往在散场后才爆发，把夜里的机器拖垮，第二天运维上班看到报警邮件一脸懵，还以为半夜被攻击了。
观众分布也决定并发形态。如果都在同一个楼层同一个交换机下，那台交换机会先红；如果分散在多地分支，压力被分摊但回传链路成瓶颈。我们做测算前会画一张终端分布图，把热点标出来，比单纯数人头靠谱得多。一家电子厂，车间大屏有 23 块集中播，看起来 23 人，实际每块带 30 人围观，折算下来近 700 个并发点。这种隐性并发最容易被漏掉，等开播才爆发。那次我们提前两天去车间数人头，才发现大屏后面站着一整排操作工，名单上一个没写，要不是提前踩点，开播准爆，厂长得追着问为什么又卡。
一台服务器的并发上限怎么估
给个笨办法。假设单路码率 2.5 Mbps，服务器网卡 10 Gbps，理论能跑 4000 路纯转发。但别信理论值，留 35% 余量给抖动和突发。摄行科技一般按 2600 路做上限规划，剩下的留给系统本身和系统调用。这数看着保守，真到开播那半小时，突发流量能把保守都吃光。补充一句，网卡别只看标称，很多服务器标 10G，实际跑满受驱动和中断配置影响，我们实测稳定跑到 7G 就谢天谢地了。所以 4000 路的理论值，落到现实可能只剩 2800，再砍 35% 余量，跟我们 2600 的规划线对得上，差的不多。再说内存，转码是吃内存的活，一路 1080p 转码占内存随分辨率浮动，我们按每路 1.5G 预留，宁可多给，别让 OOM killer 半夜把你转码进程杀了，第二天发现回看全是断的，客户还以为没录上。
转码的情况另算。上面说的 0.7 核一路，一台 16 核服务器去掉系统占用剩 13 核，撑 18 路转码。私有化直播并发如果要求多码率，转码机得单独列一笔，别和转发混在一张表，混了你自己都算不清。我们见过有人把转码和转发塞同一台机器，结果转码一满载，转发也跟着抖，全场卡成幻灯片，观众还以为网络坏了，其实是自家人把机器挤死了，运维背了锅。
我们给车企算过的一张表
直接上表，这是真实项目的倒推，不是教科书数字。摄行科技拿它当内部基准线。这张表我们内部叫"基准线 v3"，前面两版都因为太理想被推翻了，v1 没算回源延迟，v2 没算双码率，都是真项目里撞了墙才改的。现在这版跑了一年，没再出过大岔子，新人照着填数就能出方案。
- 纯转发场景，千兆网卡服务器：约 320 路稳定并发。
- 加一路转码，同配置：降到 110 路左右。
- 双码率转码：再砍到 60 路。
- 上回源鉴权且内网隔离：并发能力基本不变，但延迟多 0.8 秒。
这张表背后是那家车企 6.3 万峰值项目的经验，和直播房间的并发人数是怎么统计出来的里的方法对得上。每次新客户来，我们都先拿这张表对，再压测校准，绝不拿理论数糊弄人，宁可多花半天压测，不赌开播不出事。
压测到底该怎么压才不糊弄
压测不是点一下"开始"就完事。我们一般分三档打：先打七成预估看稳不稳，再打满预估看极限，最后超两成看怎么挂。很多人只打一档就收工，结果真实观众一上来分布不均，某台机器先爆，别的还闲着。还有个细节，压测要用真实码率和真实终端，别拿低码率糊弄自己，低码率过了高码率照样跪。还有，压测脚本要模拟真实分布，别让流量均匀打在每台机器上，真实观众从来不均匀，总有几台先红，均匀压测测不出这种局部热点。
另外压测时间别太短，至少跑满一场会的时长。我们吃过亏，十分钟压测全绿，真开播到第二小时机器积热降频，并发掉了三成。现在我们的压测脚本默认跑满客户给的时长再加半小时，把积热、内存泄漏这些慢性问题也逼出来。说白了，压测偷的懒，开播都加倍还。
机房断电这类黑天鹅怎么算进去
算并发时没人愿意想最坏情况，但坏事专挑大意的人。我们给关键客户做方案，会额外算一笔"降级容量"：主干一断，剩下能保多少核心观众。比如双机房热备，单机房挂了，另一机房至少扛得住六成并发，核心分会场不断就行。这笔账不算，真出事就是全场没信号，比卡严重十倍。去年一家客户的市电跳闸，靠我们预留的柴油机加备机房，主会场撑住了，分会场晚了两分钟才恢复，甲方说这两分钟值一年的服务费。所以容量表里我们都单列一行"故障降级"，不写进方案里我们不打勾。
弹性扩容：私有化直播并发怎么不爆
临时加人怎么办？两个路子。一是横向加转发节点，靠堆机器最稳，提前在虚拟化平台备好模板，半小时拉起一台。二是限流，超了就降码率或者排队，保住核心人群。限流那招要慎用，降码率观众能感觉到糊，排队观众会骂人。我们一般只在真的超预估 20% 以上才动，平时靠预留节点顶。说白了，私有化的好处就是你能自己决定怎么取舍，不用看供应商脸色。
摄行科技在那场留了 30% 的空闲节点，开播前 40 分钟突然加了两百个车间终端，直接起节点顶上，没掉一帧。反常识的一点是：私有化看起来死板，其实比公网更可控，因为机器和带宽全是你自己的，扩不扩你说了算，公网反而要等供应商排期。那回甲方原本担心扩不了，看到节点秒起，当场就松了口气，连说早知道多留点。补充一句，预留节点别只留同配置，最好留一台更高配的兜底，万一主力机型缺货或故障，高配机能顶更久，给你争取抢修时间。这是我们在一次机房断电后长记性的结果，那天要是没那台高配兜底，主会场也得黑。
选方案前先盘清自己的家底
要算准并发，先把三样东西拍在桌上：现有交换机型号和会话上限、服务器空闲算力、观众是固定名单还是开放报名。这三样不齐，任何数字都是猜。清单里最容易漏的是"历史峰值"，不是预估，是真实跑过的最高值。很多客户报预估，结果大促一来翻三倍，预估全废。我们只要历史峰值加增长系数，不要拍脑袋的预估，这样算出来的数才站得住。还有预算这道关，算出来的容量往往需要加机器，甲方一听报价就砍，砍完又问为什么卡。我们的经验是，容量和预算先对齐，宁可分批上，也别一次砍到极限，极限就意味着开播即事故，省下的钱不够赔一次翻车。
我们进场前必做一件事，就是拿客户的真实终端压一遍。摄行科技吃过亏，早年信了甲方给的"大概八百人"，到场发现实际一千三，连夜加机器才没崩。那次之后我们定的规矩是，凡是不给真实清单的，先压测再报价。说句实话，容量这活真不是点一下鼠标那么简单，光看 PPT 上的峰值数字会吃大亏，真机器跑出来的数才作数，纸面好看不等于线上稳。
几个避坑的实在话
- 私有化直播并发别套公网公式，硬件是你自己的。
- 转码和转发分开算，混一起必翻车。
- 交换机会话数常常比带宽先到顶。
- 隐性并发（大屏围观）一定折算进去。
- 留 30% 余量，别把机器压到满负荷。
这些点我们基本都是交过学费才记牢的，写出来省的你再踩一遍。如果你也想给自己这场私有化直播摸个底，把现有设备和预计观众数发来，摄行科技帮你算一张贴合你机房的实际并发表，别等开播才发现问题。相关参考可看WebRTC在企业直播里到底能不能扛住万人并发与私有化部署直播系统的取舍，带宽口径可对照直播前的带宽预估怎么做才不翻车。合规层面可查市场监管总局与W3C 标准的相关要求。
#摄行科技
