乐闻世界logo
5月28日 09:23

什么是CDN回源？如何减少回源请求？

CDN 回源是什么？

回源（Origin Pull）是指 CDN 边缘节点没有缓存用户请求的内容时，向源站（Origin Server）请求资源的过程。简单来说：用户请求 → CDN 没有缓存 → CDN 去源站拿 → 缓存一份再返回给用户。

回源是 CDN 机制中不可避免的环节，但回源率过高会直接拖慢响应速度、压垮源站、推高成本。面试中考察这个点，核心是看你能不能从"理解机制"到"控制回源"形成完整闭环。

回源在什么情况下触发？

缓存未命中

最常见的回源原因，包含三种典型场景：

  • 首次访问：资源从未被任何边缘节点缓存过，冷启动必然回源
  • 缓存过期：资源超过 TTL（Time To Live）过期时间，CDN 必须重新验证或拉取
  • 缓存被清除：主动刷新（Purge）或被动淘汰（LRU 内存不足）导致缓存消失

缓存键不匹配

URL 相同但参数不同，CDN 可能将其视为不同资源：

shell
https://example.com/api/data?version=1
https://example.com/api/data?version=2
// 若未配置忽略 version 参数，两次请求各自缓存，回源翻倍

生产环境中，UTM 参数、时间戳、随机 token 是导致缓存键膨胀的三大元凶。

请求类型或头部触发回源

  • POST/PUT/DELETE：写操作通常不缓存，直接回源
  • 携带 Authorization/Cookie：CDN 默认不缓存带鉴权头的响应
  • 动态内容：业务规则标记为不可缓存的路径（如 /api/、/user/）

回源对系统有什么影响？

延迟：从毫秒到秒级的跨越

  • 缓存命中：用户 → 边缘节点，通常 < 50ms
  • 回源请求：用户 → 边缘节点 → 源站 → 边缘节点 → 用户，延迟 200ms~1s+

回源率每升高 10%，P99 延迟可能翻倍。高并发场景下，回源还会引发排队效应，延迟雪崩式恶化。

源站压力：回源风暴的风险

当热点资源同时过期，多个边缘节点会同时向源站发起请求，这就是回源风暴（Thundering Herd）。极端情况下，10 个边缘节点 × 每秒 1000 次 = 源站瞬间承受 10000 QPS，可能导致源站宕机。

成本：回源带宽是真金白银

  • CDN 回源流量通常按带宽计费，价格高于普通 CDN 出流量
  • 源站需要更高配置承受回源压力
  • 超出套餐配额的回源流量费用更高

如何减少回源？六大核心策略

策略一：合理设置缓存 TTL

不同类型资源设置不同的过期时间：

shell
// 静态资源：长 TTL + immutable
Cache-Control: public, max-age=31536000, immutable

// 半静态内容：中等 TTL
Cache-Control: public, max-age=3600

// 动态 API：短 TTL + stale-while-revalidate
Cache-Control: public, max-age=10, stale-while-revalidate=60

stale-while-revalidate 是一个容易被忽视的关键指令：它允许 CDN 在后台异步刷新缓存的同时，先返回过期的旧内容给用户。既保证响应速度，又保证内容最终一致。

配合 URL 版本化更新静态资源，彻底避免因内容更新导致的缓存失效：

shell
// 版本化文件名，内容变更即更换 URL
/app.v1.a1b2c3.js
/app.v2.d4e5f6.js

策略二：缓存预热（Prefetch）

在用户访问前，主动将内容推送到 CDN 节点：

bash
# 通过 CDN API 预热 URL
curl -X POST "https://cdn-api.example.com/prefetch" \
  -H "Authorization: Bearer <token>" \
  -d "{\"urls\": [\"https://example.com/new-page.html\", \"https://example.com/bundle.js\"]}"

预热适用场景：

  • 新版本发布前预热静态资源
  • 大促活动前预热商品页面
  • 热门内容预测性预热（基于历史访问模式）

策略三：配置缓存键优化

忽略无关查询参数，让更多请求命中同一缓存：

shell
// 配置忽略 utm_source、timestamp 等参数
https://example.com/data?utm_source=wechat&ts=123
https://example.com/data?utm_source=weibo&ts=456
// 忽略参数后，两个请求命中同一份缓存

规范化请求头：统一 Vary 头，避免因 Accept-Encoding 差异产生重复缓存。

策略四：多级缓存架构

CDN 本身就有多级缓存结构，合理利用可以大幅减少回源：

  • 边缘缓存（L1）：离用户最近，容量小，响应最快
  • 区域缓存（L2）：覆盖一个地理区域，容量中等
  • 中心缓存 / Origin Shield（L3）：所有边缘节点的回源汇聚点

Origin Shield 是 AWS CloudFront 的叫法，Akamai 称为 Origin Shielding，阿里云叫集中回源。核心原理：在源站前再加一层缓存，即使所有边缘节点都 miss，也只需一次回源到 Shield 层，避免多节点直接打源站。Akamai 的数据显示，Origin Shield 可以减少 95% 的源站请求。

策略五：请求合并（Request Coalescing）

当多个用户同时请求同一份未缓存的资源时，CDN 只向源站发一次请求，其余请求排队等待同一份响应。这个机制叫做请求合并或 Request Collapsing。

这是解决回源风暴的核心手段。没有请求合并，1000 个并发 miss 请求 = 1000 次回源；有了请求合并，= 1 次回源。

策略六：边缘计算

将简单逻辑下沉到 CDN 边缘节点执行，避免回源：

  • A/B 测试分流：在边缘节点根据 Cookie 分配实验组
  • URL 重写：边缘节点直接改写 URL，无需回源
  • 简单 API 聚合：边缘节点拼接多个缓存片段返回
  • 地理定向：根据用户 IP 返回不同区域的缓存内容

面试追问与回答

追问 1：缓存穿透、缓存击穿、缓存雪崩分别是什么？和回源有什么关系？

  • 穿透：请求的数据源站也不存在，每次都回源且永远无法缓存。解决：缓存空值或用 Bloom Filter 拦截
  • 击穿：热点 key 过期瞬间，大量请求同时回源。解决：请求合并 + 互斥锁回源
  • 雪崩：大批 key 同时过期，回源量暴增。解决：TTL 加随机偏移 + stale-while-revalidate

追问 2：如何监控回源率？合理范围是多少？

核心指标：

  • 回源率 = 回源请求数 / 总请求数，目标 < 5%
  • 回源带宽占比 = 回源流量 / 总出流量
  • 回源延迟 P99

通过 CDN 控制台或日志分析工具（如 ELK）监控，设置回源率 > 10% 的告警阈值。

追问 3：CDN 回源和源站宕机如何处理？

  • 配置 stale-if-error 指令，源站不可用时返回过期缓存
  • 设置源站健康检查，自动切换到备用源站
  • 多源站负载均衡 + 故障自动摘除
  • 关键业务配置 Origin Shield 作为缓冲层
标签：CDN