大促直播回源带宽突增，最有效的应对方式是提前预热+动态限速+多级缓存，而不是一味扩带宽。
大促直播这场仗,开场前半小时最紧张，用户疯狂点进直播间，边缘节点如果手里没货，全部回头找源站要数据，源站带宽瞬间被打满，画面卡顿、黑屏乱飞，很多团队第一反应是打电话给云厂商加临时带宽，但加带宽要时间，账单也很吓人，只要摸清回源带宽的脾气，大部分突增场景是能提前压下来的。
大促直播回源带宽突然增高怎么办？先看这三点正常不正常
回源带宽,就是用户请求打到CDN边缘节点，节点没缓存时回源站拉取直播流所占用的带宽，大促直播和普通直播不一样，热门直播间同时在线可能几十万人，如果边缘节点各自为战，每来一个请求就回源一次，源站出口直接变成赛道。
遇到带宽突增,别急着限流，先花两分钟判断这波流量正不正常。
正常突增：流量集中在热门直播间
如果回源请求的URL集中在当天主推的几个直播间,带宽上升曲线和直播时间线吻合，这就是典型的预热不足，解决办法很简单，在直播开播前把M3U8和TS分片URL主动推到CDN节点，让边缘节点提前存好内容，等用户来的时候直接在门口发，不用再跑回源站。
异常突增：请求分布散乱，IP来源杂
如果回源请求的URL分散在大量直播间,甚至包含很多不存在的路径，同时源站连接数暴增到日常几十倍，那就要警惕恶意刷量，常见的CC攻击就会伪装成正常拉流请求，把回源带宽打满。
实操上,登录源站执行 iftop -i eth0 -n，看看正在连接的IP排名，如果是CDN节点IP且数量有限，属于正常；如果出现几千个陌生IP，直接把安全策略拉满。
配置问题：缓存规则没对上直播流格式
不少团队直播推流走RTMP,拉流走HTTP-FLV或HLS，CDN缓存规则默认可能只缓存了M3U8列表，TS分片没有缓存，结果用户每次切换清晰度，边缘节点都绕不过去，建议把分片URL的缓存时间改成和分片实际时长一致，例如4秒一个的分片，缓存时间设成4秒或5秒。
直播回源带宽峰值计费与成本控制技巧
大促最扎心的不是带宽打满,而是账单出来后发现大促期间只冲高了那么几十秒，结果按95峰值计费算了整整一个月，所以应对突增，除了技术手段，计费逻辑也得懂。
CDN计费模式怎么选
主流的CDN回源计费有三种模式：按流量计费、按95峰值计费、按日均峰值计费，行业共识认为，大促直播这类突发性强的业务，如果用按95峰值计费，只要出现一次高峰，整月账单就压不下来，而按流量计费，实际用了多少就交多少钱，大促结束账单不会残留峰值后遗症。
这里有一个对比表格：
| 计费模式 | 适合场景 | 大促风险 |
|---|---|---|
| 按流量计费 | 流量曲线波动大，像直播 | 账单随实际用量走，无峰值残留 |
| 按95峰值计费 | 流量长期高位稳定 | 大促冲高一次，整月成本飙升 |
| 按日均峰值计费 | 无明显波动的业务 | 大促日均被拉高，费用上升 |
如果后台支持,大促开始前临时切到按流量计费，大促结束后再切回来，能省下相当一部分成本，操作路径一般在CDN控制台的「计费管理」里，切换后立即生效。
大促直播回源带宽价格对比：自建源站和对象存储怎么选
说到成本,很多人纠结要不要自建源站，如果源站部署在云服务器上，带宽包规格往往只能按固定峰值购买，大促前临时升带宽，用量过去了还得等到期才能降，灵活性很差，把直播切片放到对象存储，走CDN回源到对象存储的内网链路，通常不额外收流量费，只按存储和请求次数计费。如果只是大促期间才需要高回源带宽，把静态直播切片放对象存储，比自建源站顶峰值划算得多。
源站这边只负责推流和生成索引,完全可以扛住，实测下来，脚本生成切片传到对象存储的速度，足够支撑一场大促直播。
直播场景下如何利用边缘节点降低回源压力
降回源的核心,就一句话：把流量留在边缘，边缘节点不是单纯转发，它应该是一个缓冲池。
- 开播前预热：用CDN控制台的主动预热功能，把直播流的播放地址提前推到主要区域的边缘节点，大促前建议预热到全国华东、华南、华北三大区节点，能覆盖相当一部分用户。
- 分片缓存做细：直播分片不是不能缓存，是缓存时间要匹配分片时长，如果分片是2秒，缓存时间设成3秒，用户最多落后一个分片，但源站压力能降一大截。
- 协议层减少回源请求：HTTP-FLV的keep-alive连接要开大，源站Nginx配置
keepalive 128; keepalive_timeout 60s;，避免每个请求重新建连。 - 多个清晰度共用一个源：如果源站转码服务能力有限，可以给CDN配置「回源HOST」指向转码服务器，让CDN只回源拉取原始流，转码任务分发给边缘节点做协议转换。
视频直播回源带宽监控告警这样配置，大促不慌
没有监控,一切都白搭，推荐用Prometheus+Grafana搭一套源站带宽监控，具体步骤如下：
- 在源站部署
node_exporter，采集网卡流量指标。 - Prometheus配置告警规则：
rate(node_network_receive_bytes_total[1m]) > 800Mbps，持续1分钟以上就告警。 - Alertmanager接到告警后,推送到钉钉群或企微群。
- Grafana展示回源带宽实时曲线,把时间轴拉大到6小时，方便看出突增趋势。
这套环境一小时就能搭好,大促前搞定，心里有底。
大促直播回源带宽突增的应急预案
预案要写清楚操作顺序,别到时候群里的指令乱七八糟。
- 第一步：在CDN控制台开启"带宽超阈限流"或"源站保护"功能，把回源带宽限制在一个安全值。
- 第二步：通过日志分析，按去重URL统计回源比例，如果某个直播间回源请求占90%，立刻做定向预热。
- 第三步：源站带宽还是扛不住，直接启用CDN的"临时源站"功能，把回源切换到对象存储或备用机房的地址。
- 第四步：检查安全防护，如果发现异常IP，加入黑名单并启用CC防护，别手软。
整个流程下来,目标是让源站带宽峰值可控，而不是追求无限大。
Nginx限速的两种写法
在源站Nginx配置限速,是最后一道保命符，第一种是限制单个连接速率，在location块里写：
limit_rate 8m;如果一个IP同时拉多个连接,总速率会成倍增长，所以还得限制连接数，在http块定义连接数区域：
limit_conn_zone $binary_remote_addr zone=addr:10m;然后在server块里引用：
limit_conn addr 16;这样每个IP最多建立16个连接,每个连接速率8Mbps，单IP峰值就能控在128Mbps以内，注意，限速值要结合用户观看码率来设，比如清晰度最高是8Mbps，那就设成8M或10M，避免影响正常用户体验。
大促直播回源带宽突增的常见问题
问：大促直播回源带宽突然增高，是CDN故障吗？
不一定是故障,先看边缘节点的命中率，如果回源比例超过30%，大概率是预热和缓存配置的问题，可以去CDN日志后台查一下回源状态码，如果200居多，说明节点确实在正常拉流，只是来得太集中；如果出现大量502、503，才是源站压力过大导致服务不可用。
问：直播源站带宽不够用，可以只靠CDN解决吗？
CDN能分担用户侧的拉流压力,但回源部分的流量始终要经过源站，如果源站带宽上限只有10Mbps，任何策略都绕不过这个物理瓶颈，把直播切片放到对象存储，让CDN直接回源对象存储，源站只负责推流和控制逻辑，这样源站带宽需求就降到了很低，据工信部公开信息，国内主流CDN节点已覆盖全部地级市，就近回源能够显著减少跨地域带宽消耗。