一、什么是直播回源风暴（回源雪崩）
做 HLS 直播业务，很多人上线之后遇到：直播刚开播瞬间，大量用户同时进来观看，大量 CDN 边缘节点同时向源站请求同一份直播 M3U8 清单，瞬间把源站打垮，CPU、带宽打满，源站直接响应超时。这个现象就是回源风暴，也叫回源雪崩。
点播业务很少遇到这个问题，点播文件生成之后长期不变，CDN 可以长时间缓存。但是直播 M3U8 是动态清单，每隔几秒就要更新，不能长缓存。成千上万 CDN 边缘节点，每一个节点都要回源拉取最新 M3U8，用户量一上来，源站压力瞬间暴涨。
很多新手运维一开始没有意识到这个风险，直接上线，大流量开播直接源站被打挂。故障发生之后，不知道问题根源，一味升级源服务器配置，但是治标不治本。
遇到直播 CDN 相关疑难问题，我会把对应 M3U8 地址放到 m3u8live.cn 网页调试工具，观察 M3U8 清单的更新行为，结合 CDN 控制台回源监控指标，定位回源相关问题。
二、回源风暴产生的简单原理
- HLS 直播 M3U8 动态清单，不能设置很长 max‑age 缓存；
- 大量不同地域 CDN 边缘节点，每个节点都要向源站回源获取最新 M3U8；
- 直播开播瞬间，大量用户涌入，成千上万个边缘节点同时回源请求 M3U8，源站瞬间收到海量请求；
- TS 分片一旦生成之后内容不会改变，TS 分片可以长缓存，不会带来严重回源压力；压力主要集中在 M3U8 直播清单。
重点：压力集中在直播动态 M3U8 清单，而不是 TS 分片。
三、回源风暴常见触发场景
场景 1：直播刚开播，大量用户同时进入直播间
开播瞬间，很多用户打开页面，各个 CDN 节点同时回源拉 M3U8，源站请求量瞬间飙升。
场景 2：直播断流之后重新推流恢复
推流断开之后恢复，大量 CDN 节点同时回源刷新 M3U8 清单，再次产生回源高峰。
场景 3：CDN 刷新全部节点缓存
人为操作刷新 CDN 全部缓存，所有边缘节点同时回源源站，直接压垮源站。
场景 4：M3U8 清单 max‑age 设置过小
max‑age 设置 1 秒甚至更小，CDN 节点每秒都要回源，放大回源请求数量。
四、缓解回源风暴常见可行方案
方案 1：CDN 开启直播清单的回源合并（聚合回源）
CDN 厂商提供聚合回源功能，多个 CDN 边缘节点，合并为少量回源请求向源站拉 M3U8，而不是每个节点都独立回源。这个是最有效的手段，优先开启。
方案 2：合理设置直播 M3U8 的 max‑age
不要设置过小，一般设置 2‑3 秒。兼顾直播实时性，同时降低回源频率。不能设置几十秒，会造成直播画面卡顿不更新。
方案 3：源站前面增加一层中间缓冲层（二级源站）
CDN 不直接回源业务源站，回源到中间缓冲服务器，中间层再去请求真实业务源站，用来承接 CDN 海量回源请求，保护后端真实推流切片源站。
方案 4：避免直播业务随意执行全局 CDN 缓存刷新
直播业务尽量不要做全部节点刷新操作，刷新操作会触发大规模回源风暴。
五、新手运维避坑提醒
❌误区：只升级源服务器 CPU、带宽配置，不解决回源风暴根源。机器配置再高，海量回源请求依旧会打挂源站。 ✅正确思路：优先 CDN 侧聚合回源，合理配置 max‑age，必要的时候增加中间缓冲层，从 CDN 链路层面降低回源请求数量。
排查的时候，看 CDN 监控面板，观察回源 QPS 指标，如果直播 M3U8 的回源 QPS 远大于实际在线用户数，大概率存在回源风暴问题。同时可以借助网页调试工具，确认 M3U8 清单更新行为是否正常。
六、总结
HLS 直播动态 M3U8 清单不能长缓存，大量 CDN 边缘节点同时回源，容易产生回源风暴，瞬间压垮源站。单纯升级源服务器硬件治标不治本。优先开启 CDN 聚合回源，合理配置 M3U8 清单 max‑age，必要搭建中间缓冲层，减少源站回源请求量。遇到直播 CDN 异常，结合网页调试工具确认 M3U8 更新行为，再对照 CDN 回源监控，定位回源风暴隐患。