体育直播网站负载均衡搭建实战：从流量洪峰到稳定推流

做体育直播这行，流量从来不跟你商量。一场焦点战开球前五分钟，并发观看数能从日常的几千直接跳到十几万，推流端和播放端同时承压。单纯堆带宽解决不了问题，真正要处理的是请求怎么分、连接怎么保、故障怎么切。体育直播网站负载均衡搭建，说白了就是给这条随时可能决堤的流量河修一套分洪闸。

推流和播放得分开设计，别混在一个池子里

很多团队一开始图省事，把 RTMP 推流和 HTTP-FLV 播放挂在同一组后端上。平时没事，一到大赛就出问题：推流端是长连接、低并发、对延迟敏感，播放端是短连接、高并发、能容忍几百毫秒抖动。两种流量混在一起，健康检查的阈值根本没法设。我们后来拆成两个独立的负载均衡集群，推流走四层转发，播放走七层按 URL 路径分发，各自的扩容策略互不干扰。

推流侧用 LVS 做 DR 模式，后端边缘节点只改 MAC 不回包，单台调度器能扛住数万路并发推流。播放侧交给 Nginx 加一致性哈希，同一个频道的切片请求尽量落到同一台缓存节点。这点我个人更看重，跨节点回源的次数少一次，首帧时间就能稳一截。

四层和七层怎么选，看的是业务对连接状态的依赖程度

四层负载均衡只看 IP 和端口，转发效率高，适合推流这种协议固定的场景。七层能解析 HTTP 头、URL 和 Cookie，做灰度发布和按频道分流方便，代价是每连接多一次解析开销。体育直播的播放请求里，/live/ 和 /replay/ 的打散策略可以完全不同，七层才有这个灵活度。

• 推流入口：LVS DR 模式，后端健康检查用 TCP 端口探测，间隔 3 秒，连续 3 次失败摘除。
• 播放入口：Nginx 反向代理，按频道 ID 做哈希，配合 proxy_next_upstream 做故障重试。
• API 与鉴权：单独一组七层集群，和流媒体流量物理隔离，避免鉴权接口拖慢播放链路。

这里有个细节值得说：健康检查别只探端口。我们遇到过端口活着但转码进程假死的情况，后来在边缘节点加了一个 /healthz 接口，返回当前推流路数和磁盘写入延迟，超过阈值才判定异常。

会话保持不只是粘 Cookie 那么简单

体育直播有个特点：观众中途切清晰度、拖进度条，都会重新发起播放请求。如果这些请求被随机打到不同边缘节点，每个节点都要回源拉一遍切片，源站压力反而被放大。我们的做法是播放侧用 URL 里的频道 ID 做一致性哈希，同一个频道的请求尽量收敛到同一批节点，缓存命中率从六成出头提到了八成五左右。这个数字是运维那边给的监控截图，具体口径我没细问。

推流侧则相反，不能让同一路流固定绑死在一台机器上。主播网络抖动重连时，调度器要能快速把流迁到备用节点。我们给每路推流分配一个短时效的 token，重连时带 token 重新调度，旧节点上的残留连接由心跳超时清理，超时设 15 秒，再长就会占着端口不放。

故障切换的坑：DNS 和 TTL 比想象中麻烦

负载均衡层做了高可用，不代表观众端感知不到故障。调度器主备切换靠 Keepalived，VIP 漂移通常在一秒内完成，但客户端到 VIP 之间的链路如果走的是 DNS 轮询，TTL 设长了切不过来，设短了解析压力大。体育直播这种有明显开赛时间点的业务，我们提前十分钟把 TTL 压到 30 秒，开赛后恢复 300 秒，算是个折中。

另一个容易忽略的是备用源站的预热。主源站挂掉再切，备用节点缓存是空的，所有请求同时回源，很容易把备用也拖垮。现在每次大赛前两小时，我们会用低码率测试流把备用集群的缓存先灌一遍。

压测别只压播放，推流并发才是真瓶颈

拿 JMeter 压 HTTP-FLV 播放能压出很漂亮的 QPS 数字，但推流侧的并发路数才是决定比赛能不能开播的关键。我们内部用 ffmpeg 起多路测试流，模拟 500 路同时推流、每路 2 Mbps，观察调度器的连接表增长和边缘节点的 CPU 软中断分布。第一次压测就发现网卡多队列没配，单核软中断跑满，换了 RSS 配置才把流量摊开。这块经验没法从文档里抄，只能自己压出来。

负载均衡搭建在体育直播场景里没有一劳永逸的方案。赛事排期在变，观众设备在变，连推流协议都在从 RTMP 往 SRT 迁。把推流、播放、鉴权三条链路拆开，各自留出横向扩容的余量，比追求某个单点指标更实在。