直播 Multi-CDN 如何做 failover，才不会压垮源站？

在前面的文章中，我们讨论了三个问题。

第一个问题是：HTTP 200 不等于 QoE。CDN 返回 200 OK，并不代表用户真的获得了稳定的播放体验。

第二个问题是：接入第二家 CDN，并不等于系统自动获得高可用。如果没有统一的监控、切流策略和回源保护，Multi-CDN 反而可能让系统变得更复杂。

第三个问题是：生产级 Multi-CDN 的核心不是“切换按钮”，而是控制平面。系统需要知道什么时候切、切多少、切到哪里，以及切换失败时如何 freeze 或 rollback。

那么，接下来的问题就是：在真实生产环境中，failover 应该怎么做，才不会把一个局部 CDN 问题放大成 origin storm？

我的观点是：好的 failover 应该很“无聊”。它不是一次性全量切换，而是小步、观察、保护源站，并且随时可以回滚。

1. 为什么糟糕的 failover 会制造更大的故障？

很多团队在设计 Multi-CDN 时，会把 failover 想得过于简单：

CDN A 出问题，就把流量切到 CDN B。

这个思路在概念上没有错，但在生产环境中非常危险。

因为 CDN B 虽然可用，但它的缓存状态不一定准备好了。如果大量用户突然从 CDN A 切到 CDN B，CDN B 的边缘节点可能还没有缓存相关的 playlist 和 segment。

结果是，大量请求会绕过 CDN cache，直接打到 origin 或 packaging tier。

这样，原本只是某个 CDN、某个区域或某个 ISP 的局部问题，可能被放大成全局源站压力问题。

用户看到的结果可能是：

• 起播变慢；
• segment 加载超时；
• 播放中频繁卡顿；
• 部分请求返回 5xx；
• origin 或 packaging tier 负载突然升高；
• 原本健康的路径也被拖慢。

这就是 Multi-CDN 中很典型的一类风险：为了绕过一个故障，反而制造了一个更大的故障。

2. failover 不应该从“全局流量”开始

安全 failover 的第一条原则是：不要从全局流量开始。

生产环境中的问题通常不是均匀发生的。一个 CDN 可能在全局看起来正常，但在某个地区、某个运营商、某个 ASN、某类设备或某个 player version 上已经开始退化。

因此，failover 的对象不应该是“所有用户”，而应该是一个具体的 cohort。

例如：

• 某个地区；
• 某个 ISP / ASN；
• 某类设备；
• 某个 player version；
• 某种协议；
• 某条 CDN pathway；
• 某个直播流或某组频道。

也就是说，系统不应该只问：

“要不要从 CDN A 切到 CDN B？”

而应该问：

“对于这个具体 cohort，把一小部分新会话从 CDN A 切到 CDN B，是否能改善 QoE，并且不会增加源站风险？”

这个问题更慢，但更安全，也更接近 production 真实需求。

3. 先切新会话，不要急着切正在播放的会话

在直播和 OTT 场景中，正在播放的会话比新会话更敏感。

如果用户已经开始播放，系统在 midstream 中频繁切换 pathway，可能会带来新的不稳定因素：

• playlist host 变化；
• segment host 变化；
• token 或签名逻辑变化；
• player buffer 行为变化；
• cache 状态变化；
• QoE 数据归因变复杂。

所以，一个更安全的初始策略是：优先切新会话。

例如，当某个 cohort 出现明显退化时，不要立刻把所有正在播放的用户切走，而是先让新的 playback session 使用备用 CDN pathway。

这样做有几个好处：

第一，对正在播放的用户影响更小。

第二，新路径可以逐步获得真实流量，缓存也可以慢慢变热。

第三，团队可以观察 QoE 是否真的改善。

第四，如果效果不好，回滚成本更低。

Midstream switching 不是不能做，但它应该是后续能力，而不是第一步默认动作。

4. 好的 failover 应该小步执行

安全 failover 的第二条原则是：小步执行。

一个比较保守的起点可以是：

• 先切 5% 到 10% 的 cohort traffic；
• 只切新会话；
• 等待一个或两个观察窗口；
• 检查 QoE 是否改善；
• 检查源站风险是否升高；
• 如果效果不好，rollback 或 hold；
• 如果数据不足，进入 shadow mode 或人工复核。

这里的关键不是具体数字，而是方法。

failover 不应该是一个“按下按钮之后全局生效”的动作，而应该是一个可以逐步推进、逐步观察、逐步扩大或随时停止的过程。

在生产环境中，快不一定等于安全。很多时候，真正安全的动作看起来很慢、很无聊，但它能避免把局部问题变成全局事故。

5. 每次切流前都要检查源站风险

安全 failover 的第三条原则是：切流之前先保护源站。

很多 Multi-CDN 事故的根本问题不是“没有第二家 CDN”，而是“第二家 CDN 的缓存还没有准备好”。

当冷缓存遇到大规模切流时，源站会成为所有问题的集中点。

因此，在自动或半自动 failover 之前，系统至少应该检查几个信号：

• back-to-origin QPS 是否已经升高；
• origin fill timeout 是否增加；
• shield offload 是否下降；
• cache hit ratio 是否明显下降；
• stale served ratio 是否异常；
• packaging tier 是否接近容量上限；
• license / auth plane 是否有异常。

如果源站风险已经升高，系统就不应该继续扩大切流。

简单说，failover 的目标不是把压力从 CDN A 转移到源站，而是把用户流量安全地迁移到另一条可承受的 delivery path。

6. 源站保护应该是前置条件

为了避免 failover 变成 origin storm，Multi-CDN 系统需要提前设计源站保护。

至少应该考虑几类机制。

第一，shield / tiered cache。

所有 CDN pathway 最好不要直接打到源站，而是通过上层 shield 或 tiered cache，减少源站暴露面积。

第二，request collapsing。

当大量用户请求同一个过期对象时，系统不应该让每个请求都打到源站，而应该合并请求，避免瞬间放大源站 QPS。

第三，stale-while-revalidate。

在对象短时间过期或上游短暂抖动时，可以先返回 stale cache，再异步刷新，避免用户请求被阻塞在源站上。

第四，stale-if-error。

当源站短时间不可用时，如果业务允许，可以继续提供旧对象，降低用户侧播放失败率。

第五，cache warmup。

在扩大切流之前，可以提前让备用 pathway 获得少量真实流量，或者预热关键 playlist / segment 请求。

这些机制并不是“优化项”，而是生产级 Multi-CDN 的安全边界。

7. freeze 和 rollback 必须随时可用

安全 failover 的第四条原则是：必须能随时停止。

一个没有 freeze 和 rollback 的自动切流系统，本身就是新的风险源。

当系统发现以下情况时，应该立即 freeze 或 rollback：

• QoE 没有改善；
• rebuffer ratio 上升；
• startup failure 增加；
• origin fill timeout 上升；
• back-to-origin QPS 超出安全区间；
• 403 / 401 异常增加；
• license request error 增加；
• CDN B 的 cache hit ratio 低于预期；
• 数据样本不足，无法确认收益。

特别是在 Multi-CDN 场景中，rollback 不能只从 control plane 的角度验证，也要从 player perspective 验证。

也就是说，系统不能只知道“路由规则已经改回去了”，还要知道用户侧 QoE 是否真的恢复。

8. 一个最小可用的 failover checklist

在生产环境中，可以从一个简单 checklist 开始：

• 是否确认问题发生在哪个 cohort？
• 是否区分了新会话和正在播放的会话？
• 是否知道备用 CDN 的缓存状态？
• 是否检查了 back-to-origin QPS？
• 是否检查了 shield offload？
• 是否设置了单次切流比例？
• 是否设置了观察窗口？
• 是否定义了 freeze trigger？
• 是否定义了 rollback 条件？
• 是否能从播放器侧验证 QoE 改善？
• 是否能看到 401 / 403 / license error？
• 是否有人可以人工 override？
• 是否记录了本次切流原因和结果？

这个 checklist 不复杂，但它能防止很多危险的“直觉式切流”。

Multi-CDN 最怕的不是没有按钮，而是按钮太容易按。

9. 结论

Failover 不是把流量从 CDN A 切到 CDN B 这么简单。

在直播和 OTT 场景中，错误的 failover 可能会把局部 CDN 问题放大成 origin storm，甚至影响原本健康的用户。

更安全的做法是：

• 按 cohort 判断问题；
• 优先切新会话；
• 小步切流；
• 等待观察窗口；
• 检查 QoE 是否改善；
• 检查源站风险是否升高；
• 必要时 freeze 或 rollback；
• 在整个过程中保护源站。

生产级 Multi-CDN 的 failover 应该很“无聊”。

它不追求看起来动作很大，而是追求系统始终可观测、可控制、可停止、可回滚。

只有当系统能安全地移动一小部分具体 cohort 的流量，并证明 QoE 改善、源站没有被压垮、auth / license plane 没有被破坏时，failover 才真正成为一种架构能力，而不是一次危险的手工操作。