CDN数据也怕丢？回源配置与源站高可用实战
去年一个客户，CDN加速配好了，缓存命中率也高，用户访问嗖嗖的。结果有一天，源站机房的光缆被挖断了。CDN节点回源失败，缓存过期的资源拉不到，用户看到一片502。更惨的是，他们只配了一个源站，没有备源。业务中断了四个小时，等光缆修好才恢复。
他们问我：“CDN不是高可用吗？怎么源站挂了，CDN也跟着挂了？”
这是很多人对CDN的误解：CDN加速的是分发链路，源站挂了，CDN也救不了你。
今天聊聊CDN回源配置与源站高可用。缓存是锦上添花，源站是根本。源站挂了，CDN再快也没用。
01 源站高可用是CDN的命根子
CDN的工作原理决定了它对源站的依赖。用户请求到了CDN节点，如果缓存没命中，节点就要回源拉取数据。节点本身不存数据，数据在源站。
这意味着，源站的稳定性和可用性，直接决定了CDN能否正常服务。
那家客户的场景：缓存命中率确实很高，静态资源基本都在边缘节点上。但业务有更新，新图片、新CSS文件需要回源拉取。源站一挂，新资源全部拉不到，用户看到的页面就是残缺的。
如果这时候有备源站，CDN节点会尝试向备源拉取资源，至少能保证服务不中断。但他们没有配，只能干等。
02 主备源站配置：最简单的容灾
几乎所有的CDN服务商都支持配置主源站和备源站。配置备源站是源站高可用最简单、最有效的手段。
工作原理：CDN节点回源时，先访问主源站。如果主源站返回4XX/5XX错误，或连接超时、协议不兼容等情况，CDN节点会自动尝试访问备源站。
配置要点：
备源站的网络环境应与主源站不同（不同运营商、不同可用区、甚至不同云厂商），避免同时故障
备源站的数据应与主源站保持同步
回源协议（HTTP/HTTPS）应保持一致，否则可能因协议不匹配导致备源也回源失败
那家客户后来配了备源站，主源在机房A，备源在机房B。再次遇到机房故障时，CDN节点自动切到备源，业务基本不受影响。
03 回源重试与超时：CDN不能干等
CDN节点回源时，如果源站响应慢或超时，CDN节点会等待。如果超时设得太长，用户端的请求也会被拖慢。
关键参数：
TCP连接超时：默认通常2-3秒。如果源站网络不稳定，可以适当调大，但不宜超过5秒。
读取超时：从源站接收数据的超时时间。动态接口响应慢时可适当调大，但静态资源保持默认即可。
重试次数：CDN节点回源失败后的重试次数。默认通常是3次。但回源重试会延长用户端的等待时间，如果源站确实不可用，重试也是徒劳，反而让用户等得更久。
配置建议：
超时时间根据源站的平均响应时间设定，不要设成固定死值
开启健康检查探测，让CDN节点提前感知源站状态，而不是等到请求来了才去尝试
那家客户之前超时没调过，源站变慢时，CDN节点等了很久才超时，用户端也跟着等。后来把超时调短，配合备源，故障时快速切走。
04 GTM联动：智能源站调度
对于多源站的场景，可以配合全局流量管理（GTM）实现更智能的源站调度。
工作原理：GTM会定期对多个源站IP进行健康检查（Ping、HTTP探测）。当某个源站IP被探测为异常时，GTM会自动从DNS解析中摘除该IP，将流量引向健康的源站。
配合CDN使用：
CDN回源地址配置为GTM的接入域名
GTM管理多个源站IP的健康检查与切换
源站全部健康时，按策略分发流量；部分源站故障时，自动隔离故障IP
这个方案适合有多个源站数据中心、对高可用要求较高的场景。
05 一个真实案例：三源容灾保大促
某电商平台，CDN回源配置了三个源站：主源站、备源站、GTM管理的第三方云源站。主源发生故障时，CDN节点会自动尝试备源和第三方源站，保证任意一个源站不可用时业务不受影响。
大促当天，主源所在机房网络抖动，回源请求开始出现超时。CDN节点自动切换到备源，用户访问基本无感知。运维负责人说：“以前一个源站出问题就手忙脚乱，现在源站挂了也没人知道——因为CDN自己切走了。”
写在最后
CDN数据怕丢吗？CDN本身不存数据，数据在源站。源站挂了，CDN再快也没用。
那家客户的运维负责人后来总结：“CDN是放大器，不是存储器。源站稳，CDN才稳。主备源配好，超时调短，GTM做智能切换——三层保障，源站再也不用担心‘丢数据’了。”
你的CDN，配了几个源站？
