分级限流、动态调整、缓存兜底，三者缺一不可。流量突增不是单纯调低阈值就能解决，而是要让源站在“扛得住”和“放得进”之间找到平衡点，下面从策略设计到具体参数配置,一步步拆开讲。
流量突增时源站为什么先顶不住
点播场景下，回源流量激增通常不是线性上涨，而是陡峭的尖峰，用户集中点击热门内容、推流事件带动回看、或者 CDN 节点缓存失效,都会让源站瞬间收到大量请求。
源站最先暴露问题的往往是两层：入口带宽和 HTTP 连接数，带宽打满后，TCP 连接堆积，请求排队，响应时间拉长，最终表现为大面积超时，更麻烦的是，点播文件体积大，单个请求占用连接时间长,连接被占满后新请求根本进不来。
行业共识认为，回源限流不是限制用户访问，而是保护源站不被瞬时流量击穿，限流做得好，源站吞吐量能稳定维持在健康水位；做得不好，回收源状态码从 200 变成 502/504，用户端表现为卡顿、黑屏、无法播放。
回源限流阈值怎么定才合理
不要拍脑袋定数字，先看源站的三个基线
设定限流阈值前，先摸清源站的实际承载能力,需要统计三个基线数据：
- 带宽上限：源站出口带宽是多少，日常峰值用了多少，还有多少余量
- QPS 基线：正常运营时段每秒请求数，突增时峰值是多少，源站 CPU/内存表现如何
- 单请求耗时：平均响应时间，特别是首字节时间，这决定了连接复用率
据行业通行经验，限流阈值建议设定在源站实测极限的 70% 到 80% 之间，留出余量是为了应对请求大小波动同样是 1000 个请求,请求大文件和小文件对带宽的消耗差好几倍。
静态阈值不够用，必须加动态调节
固定阈值在流量平稳时好用，但点播流量天生忽高忽低，上午 10 点和晚上 8 点的峰值差距可能超过三倍，静态阈值设低了，晚高峰大量请求被拒；设高了,午间低峰又起不到保护作用。
动态限流的思路是让阈值跟随源站健康度自动变化，核心指标用
源站响应时间和错误率，当平均响应时间超过 800ms 或 5xx 错误率超过 5% 时，自动降低限流阈值；恢复后再逐步放开，这个过程建议以秒为单位平滑调整,避免阈值快速抖动引起流量反复横跳。
CDN回源限流参数设置的具体操作
CDN 侧限流是第一步防线
主流 CDN 服务商都支持回源限流配置，运维人员首先应该确认自己的 CDN 控制台里有没有相关功能，不同服务商的设置项名称略有差异,但核心参数是统一的：
- 回源 QPS 上限：每秒允许回源的请求数
- 回源带宽上限：单位时间内允许回源的流量大小，单位 Mbps 或 Gbps
- 回源并发连接数：源站同时能承受的连接总数
实际操作中，先将回源 QPS 上限设为源站极限的 70%，观察一天，看源站负载和请求拒绝率，如果拒绝率过高（超过 2%），适当上调；如果源站负载一直很低,可以下调。
源站侧限流不能省，反向代理层是关键
CDN 限流出现漏网之鱼，源站前置的 Nginx/OpenResty 层要兜住,配置思路如下：
# 限制单 IP 回源请求速率
limit_req_zone $binary_remote_addr zone=cdn_back_to_source:10m rate=500r/s;
# 限制连接数
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
server {
location ~ .(mp4|flv|ts)$ {
limit_req zone=cdn_back_to_source burst=200 nodelay;
limit_conn conn_limit 200;
proxy_pass http://upstream_server;
}
}
注意 burst 参数表示允许的突发请求缓冲量，nodelay 表示不排队直接回答，点播场景建议给 burst 留一定空间，因为播放器拖动进度条会产生短时间内的连续请求，行业专家指出，限流时直接返回 503 会让 CDN 立刻重试，反而加重源站压力，所以响应头中要加上 Retry-After 字段,让回源侧知道稍后再试。
限流后的响应策略比限流本身更重要
回源限流触发后，源站返回什么状态码直接决定用户体验,三种情况：
- 返回 503：CDN 会重新发起请求，源站可能再次被冲击
- 返回 302 到其他地址：适合冷门内容，但热门内容其他节点也可能没有
- 返回 206 + 已缓存分片：这是最优解，但需要 CDN 侧有分片缓存能力
多数情况下，源站限流后返回 503 配合 Retry-After 是比较稳妥的做法，CDN 收到后不会立即重试，而是等待指定时间，这里还有一个细节：503 响应的响应头里要标明 Cache-Control: max-age=5能被短暂缓存,避免后续请求直接穿透。
缓存策略是视频点播源站保护的最佳防线
分片缓存让回源请求数量级下降
点播文件和网页不同，一个 1GB 的影片可能被拆成上千个小分片，用户播放时按顺序请求，但如果 CDN 全文件缓存，首次回源会把整个文件拉回,带宽消耗巨大。
更合理的方式是分片缓存：用户请求哪个分片，CDN 就回源拉哪个分片，这样回源请求大小从 GB 级别降到 MB 级别，带宽压力显著降低，行业实践表明，分片缓存配合合适的缓存过期时间，回源率能降低到 5% 以下，而全文件缓存通常还在 15% 以上。
缓存时间怎么设才能应对流量突增
的缓存时间不像网页那样只有几分钟的时效，热门影片的缓存时间建议至少设置 7 天以上，冷门内容可以短一些，关键在于设置分级缓存策略：
- 热度 Top 10% 的内容：缓存 30 天以上，几乎不回源缓存 7 天，过期后重新预缓存一次缓存 1 小时，根据访问量动态提升缓存时长
还有一个重要技巧是预缓存，当运营后台收到热门影片上线通知时，提前一天把预热内容主动推向 CDN 节点，这样真正热点到来时，节点已有内容,回源压力自然小了。
回源失败后的 stale 策略值得启用
如果缓存过期而源站又处于限流状态，CDN 会尝试回源，此时如果源站返回 503，CDN 节点应当启用 stale 缓存即使内容过期，也先返回给用户，保证播放不中断，对于视频播放这种连续性强、对中断极度敏感的业务来说,播放旧分片比让用户转圈好得多。
配置 stale 策略时，建议设置 stale-if-error=300，意思是源站出错时允许使用过期内容 5 分钟，5 分钟内的请求全部命中旧缓存,给源站留出恢复时间。
不同场景下的视频点播流量突增应对差异
突增原因是热点内容上线时
热点事件驱动的流量突增，特点是来得快去得也快，短视频平台的热门视频，上线 10 分钟内流量就能达到峰值，这种情况下回源限流阈值不应该调整，反而应该放宽因为源站可能本来就准备为这部分内容提供回源服务，更合理的做法是提前预缓存,把热门前几十个分片推送到边缘节点。
突增原因是 CDN 节点故障时
边缘节点故障会迫使流量转移到其他节点，而故障节点的回源请求会转移到相邻节点，这种情况下的流量不一定是真实用户访问，而是 CDN 层面的重试，建议在 CDN 侧开启 回源失败熔断，节点连续失败 10 次后暂停回源 30 秒,避免故障节点反复试探源站。
视频点播源站保护策略常见问题解答
回源限流设置后用户明显卡顿，怎么排查
先看 CDN 侧命中率是否下降多数情况下，限流导致卡顿是因为节点缓存失效后回源请求排队，而不是源站带宽打满，登录 CDN 控制台查看回源统计，若回源带宽大幅上涨且 503 增多，说明限流阈值低于正常需求，逐步调高阈值并观察源站负载即可,没必要一次性大幅调整。
点播流量突增回源限流怎么设置才能避免误杀
误杀通常来自限流粒度太粗，建议将限流策略按 URI 拆分，热门内容单独设置一个较高的阈值，非热门内容统一走较低阈值，在 Nginx 中，可以用 location 块针对 /hot/ 路径单独设置 limit_req，而其他路径保持默认配置，这样热点内容不受限流影响,冷门内容也能保护源站。
统计口径显示，多数流量突增场景下被限流的请求集中在长尾内容上，热门内容一般不会触发限流，让热门畅通、冷门排队”是一个优先级明确的策略，从源站角度保护核心业务,同时让边缘请求逐步消退。