9.1.6 多 CDN 调度与容灾（Multi-CDN & Failover）

9.1.3 讲过 CDN 如何把内容推到离观众最近的边缘节点，但那幅地图里藏着一个单点：CDN 厂商本身。再大的厂商也只是"很少出事"，不是"从不出事"，骨干网割接、配置事故、区域网络故障，任何一种都能让一家 CDN 在某个地区成片熄灯。千万级观众的直播产品，没法把全部身家押在"厂商很少出事"上。

多 CDN（Multi-CDN） 是指同一份内容同时由两家以上 CDN 厂商承接分发，由一层调度系统决定每个观众此刻该走哪一家。它要回答两个工程问题：平时怎么选，出事怎么切。

调度的三种姿势

DNS 调度是最古老也最透明的一种。权威 DNS 按用户的来源位置与各 CDN 的健康度，对同一个域名返回不同的 CNAME，观众无感知 [1]。它的短板刻在协议里：TTL。解析结果会被各级递归服务器与终端缓存，切换指令发出后，旧答案还要在缓存里活几十秒到几分钟，故障初期总有一批用户滞留在出事的 CDN 上。另一个细节是位置误判，DNS 看到的是用户递归服务器的地址，未必是用户本人的位置，运营商的公共 DNS 会把成千上万跨省用户糊成一团。

HTTP 302 调度把决策移到应用层。客户端先问调度网关，网关按请求特征（IP、设备、内容、实时负载）返回一个 302 重定向，指向选中 CDN 的 URL。粒度细到每一个分片请求，调度策略可以逐请求更新；代价是多一次往返，首屏时间为此多付一个 RTT。

客户端 SDK 调度把选择权交给播放器：起播时向调度接口询问最优 CDN，播放中监测失败率，必要时主动换源。这条路与 9.2 的埋点体系天然闭环，真实用户的卡顿率、首屏时间按 CDN 维度切片上报，反过来喂养调度策略。工业实践里三者常组合使用：DNS 兜住大盘，302 做精细分流，SDK 负责最后的临场自救。

容灾的两个暗坑

有了切换能力，只是拿到入场券，两个暗坑专门伏击新手上路。

其一是冷缓存风暴。主备模式（Active-Passive）下备用 CDN 平时不接流量，缓存是空的；主 CDN 故障、全量切换的一瞬间，所有请求回源，源站会在"救火"的同时被回源流量压垮。因此成熟的部署偏好 Active-Active，平时就给各家分一些流量，让每家的缓存保持温热，也让监控数据持续可比。

其二是切换的体验代价。换 CDN 意味着重新建连、重新起播，9.2.1 的首屏时间要再付一遍。所以切换讲究灰度：故障判定时先切走一小部分流量验证备用厂商的成色，确认无恙再放大；主 CDN 恢复后也不急着全量回切，而是用一小股"金丝雀"流量试探，缓慢爬坡。熔断式的全体瞬切，往往是把一次厂商事故升级成一次自家事故。

值得一提的是 HLS 与多 CDN 的天然亲和：分片化设计让每个分片请求都是潜在的切换点，播放中途换 CDN 对观众可以是无感的。这也是 7.4 的文件哲学在运维侧的意外红利。

至此，9.1 的链路地图补齐了最后两块拼图：延迟有可拆的账，分发有可切的路。地图画完，接下来要学会读图说话：链路上的体验好坏，如何变成可度量、可监控、可归因的数字？9.2，流分析与质量监控。