晚上八点，某热门主播开播，弹幕刷屏，礼物特效满屏飞——突然，画面卡住，声音断续，几秒后直接黑屏。用户刷新重进，发现排队人数已破十万。后台监控显示：CDN节点带宽打满、源站CPU飙到98%、数据库连接池耗尽。这不是偶然事故，是负载测试没做扎实的典型后果。
为什么直播平台特别怕“扛不住”？
和普通网站不同，直播是实时双向高压通道：每一路推流要解码、转码、分发；每一路拉流要选路、缓冲、渲染。10万观众同时在线，背后可能是30万+并发TCP连接、每秒数GB的音视频数据洪流。流量不是均匀滴答走，而是“秒级脉冲”——预告一发，瞬间涌入5万人，系统若没压测过这个峰值，立马失守。
真实压测，不能只看“能撑多少人”
很多团队用JMeter跑个HTTP接口，标称“支持50万并发”，结果上线后推流频频超时。错就错在：直播的核心链路根本不在HTTP层。真正要测的是：
- RTMP/HTTP-FLV/SRT推流握手成功率（尤其弱网模拟下）
- 边缘节点转封装延迟（从推流到首帧拉流是否＜800ms）
- 高并发弹幕写入时Redis队列堆积情况
- 突发断流重连潮对信令服务器的冲击（如WebRTC的ICE交换）
一个接地气的压测小实验
用开源工具ffmpeg模拟100路推流，再用ffplay起500个拉流进程，观察关键指标：
ffmpeg -re -i test.flv -c copy -f flv rtmp://edge-server/live/stream_001同时在服务端跑：ss -s看socket连接数，iftop -P rtmp盯实时带宽，docker stats查转码容器内存泄漏。别迷信“全绿指标”，重点看第400个拉流启动时，首帧延迟是否从600ms跳到2.3秒——这才是真实瓶颈。
别等大促才想起压测
某次跨年晚会前，技术团队提前两周做阶梯压测：每小时加压5%，直到突破设计容量120%。过程中发现GSLB调度策略缺陷——所有新用户被分到同一组老旧边缘节点，紧急切到权重轮询模式。当晚零故障。压测不是交差文档，是给系统做“压力体检”，数据要进日常监控看板，比如把“千人平均首帧耗时”设成告警项，超过1.2秒自动触发扩容。
直播不卡，不是运气好，是每个RTMP包、每条弹幕、每次心跳都经得起“万人突袭”的底气。