什么是 CDN 回源：缓存未命中与回源流量对服务器的影响

定义

CDN 回源是指 CDN（内容分发网络，通过分布在各地的边缘节点缓存网站内容、缩短用户与内容之间物理距离的网络）的边缘节点在本地没有保存请求内容或缓存已过期时，回到源站服务器重新获取该内容的过程。为什么一个配置了 CDN 的网站，源站服务器仍然可能被流量压垮？解决这个疑问的关键，就在于理解回源机制：CDN 并不会替源站承担全部请求，只有命中缓存的请求才被边缘节点直接响应，未命中的请求最终仍要落到源站头上。

这一过程涉及两个核心概念。缓存未命中（Cache Miss）指用户请求的内容在边缘节点本地不存在或已过期，节点必须向上游获取；与之相对的是缓存命中（Cache Hit），即节点直接用本地副本响应请求，全程不经过源站。回源流量则指边缘节点从源站拉取内容所产生的流量，这部分流量不计入用户访问，却真实消耗源站的带宽（服务器与外界之间单位时间内可传输的数据量）与处理能力。

详细说明：回源在什么情况下被触发

回源并非每次访问都会发生，它的触发条件决定了源站实际承受的压力。从工作机制上看，边缘节点判断是否回源主要依据以下几类条件：

首次请求：某内容第一次被访问时，节点本地没有副本，必须回源拉取
缓存过期：每个缓存对象都有 TTL（Time To Live，缓存存活时间），到期后节点会向源站验证内容是否更新，这一验证请求本身也是一次回源
缓存被驱逐：节点磁盘或内存空间有限，长期不被访问的冷内容会被逐出缓存，之后再次被请求时需要重新回源
不可缓存内容：带特定响应头（如明确禁止缓存的指令）的动态请求不进入缓存，每次都直接回源

衡量这些触发频率的核心指标是缓存命中率，即命中缓存的请求数占全部请求的比例。命中率 95% 意味着每 100 个用户请求中有 5 个要落到源站。对以静态内容为主的站点，命中率通常可以达到 90% 以上；而动态内容占比高、缓存规则配置保守的站点，命中率可能低于 50%，源站压力差距可达数倍。

回源请求的去向也有区别。CDN 节点之间通常存在层级关系，边缘节点未命中时会先向上级中间节点请求，中间节点也未命中才会真正到达源站，这种设计本身就为了减少对源站的重复请求。此外，多个节点对同一内容的并发未命中可能触发合并回源（Request Coalescing）：只放行一个请求去源站，其余请求等待结果共享，避免同一文件被重复拉取多次。

回源流量对源站服务器的具体影响

回源流量对源站的影响集中在三个层面，理解这些影响才能解释为什么有些站点接入 CDN 后源站反而更忙：

带宽消耗：大文件（安装包、视频、高清图）回源时，源站要完整输出一次该文件的全部体积。若一个 500 MB 的文件在 100 个节点各被回源一次，源站就额外输出约 50 GB 流量
连接与进程压力：每次回源都是一个完整的 HTTP 请求，会占用源站的连接数、worker 进程和内存。动态内容回源更重，因为源站需要执行完整的业务逻辑再返回结果
延迟放大：回源路径的耗时直接叠加到用户等待时间上。未命中请求的响应时间 = 节点到源站的往返时间 + 源站处理时间 + 回传时间，跨区域回源（如海外节点回源国内机房）单次可能增加数百毫秒

最需要警惕的场景是回源风暴。当缓存规则批量设置过短的 TTL，或缓存被集中刷新（例如网站更新后一键清空 CDN 缓存），大量内容在同一时间失去缓存副本，随后涌入的用户流量会以很高的并发集中回源。此时源站承受的请求形态是：突发、并发高、且每个请求都要求完整处理，这比平稳的日常流量更容易把连接数和带宽打满，严重时源站自身也变得响应缓慢，进一步拖慢回源、形成恶性循环。

源站侧的承受能力因此成为 CDN 架构中不可忽略的一环。CPU 核数、带宽上限、并发连接数限制，共同决定了一个源站能承接多大的回源峰值。当业务规模增长而源站未同步扩容时，即使 CDN 侧命中率不低，一次集中刷新仍可能造成源站过载。这也是为什么大型站点通常配合预热机制：在流量高峰或缓存刷新后，主动让 CDN 节点提前回源拉取关键内容，把回源动作从用户请求触发的突发模式改为可控的批次模式。

应用场景：哪些业务更需要关注回源

回源压力并非对所有站点同等重要，以下几类业务需要重点评估源站对回源流量的承受能力：

下载站与大文件分发：安装包、镜像文件体积大、节点覆盖面广，回源成本集中在带宽而非请求数，源站出口带宽决定了回源波峰的上限
动态内容为主的业务：API 服务、个性化页面无法有效缓存，几乎每个请求都回源，CDN 此时主要提供传输优化而非缓存卸载，源站压力与直连时接近
内容频繁更新的站点：资讯、电商价格页等更新周期短，缓存 TTL 被迫设置得较短，回源频率显著高于静态内容站
源站为单台或小规模服务器的站点：没有冗余的源站一旦被回源峰值打满，整个服务随之不可用，缓存命中率直接关系到可用性

评估时可以采用一个简单的量化思路：源站需要承接的回源带宽 ≈ 用户侧总带宽 ×（1 − 缓存命中率）。例如用户侧峰值流量为 1 Gbps、命中率为 90%，源站就要预留约 100 Mbps 以上的回源余量；命中率降到 70%，同样的用户流量下源站压力升至 300 Mbps，是前者的三倍。这个估算解释了为什么命中率从 90% 提升到 95% 的边际价值，远大于从 50% 提升到 55%。

从技术架构上看，回源还与源站的部署位置相关。源站放在国内单线机房而 CDN 节点遍布全球时，海外节点每次回源都要穿越国际线路，延迟和抖动都更大；将源站放在多线机房、或采用源站-中转两级结构（中转层聚合回源再统一回到源站），都能降低回源路径的不可控性。相关机房线路选择的背景，可延伸阅读站内词条什么是 BGP（边界网关协议）。

常见误区与边界条件

关于 CDN 回源，存在几个容易导致误判的认知偏差：

“接了 CDN 源站就不再有压力”：命中率永远不会是 100%，缓存刷新、新内容发布、动态请求都会穿透到源站，源站容量规划仍需按回源峰值预留
把命中率当作唯一指标：命中率按请求数统计，而源站压力还取决于未命中请求的内容体积与处理成本，一个未命中的大型动态请求的代价可能抵得上上百个静态未命中
清空缓存与刷新缓存的混淆：刷新（Purge）只删除指定 URL 的缓存副本，影响面小；整站清空（Purge Everything）会让全部内容回源，等于主动制造一次回源风暴，生产环境应谨慎使用
忽略回源请求头的影响：回源请求通常携带原始用户的部分请求头，源站若依赖 Cookie 做缓存差异，可能导致本应命中的内容持续未命中，命中率被无意拉低

边界条件方面，回源行为在两类情况下会明显偏离常规：一是源站返回错误（如 5xx 状态）时，部分 CDN 会短暂缓存错误响应以保护源站，另一些则立即重试，不同策略对源站的冲击差异很大；二是 HTTP 与 HTTPS 混合部署时，回源协议若与用户侧协议不一致（如用户走 HTTPS、回源走 HTTP），会在传输层引入额外开销，也可能触发安全策略告警。