CDN 缓存刷新与预热实践：Purge 与 Preload 自动化

CDN 缓存刷新与预热实践：Purge 与 Preload 自动化流程

缓存是 CDN 加速的引擎，但缓存也是一把双刃剑：内容更新后，如果边缘节点还保留旧副本，用户就会看到过期内容。缓存刷新（Purge）与预热（Preload）就是解决"更新如何快速生效"的两把钥匙。

一、为什么要刷新与预热

1.1 缓存的"过期陷阱"

静态资源设置长 TTL 能大幅提升命中率、降低成本，但代价是内容更新后无法即时生效。尤其在发布新版本、修复线上 bug、上线活动页时，用户看到旧页面会直接影响体验甚至造成事故。

1.2 两种手段的分工

刷新（Purge/Invalidation）：把边缘节点上的缓存副本作废，下次请求回源拉取最新内容；
预热（Preload/Preheat）：提前让边缘节点回源拉取并缓存热门内容，用户在真正访问前内容已就绪，规避"回源尖峰"。

刷新解决"旧内容"问题，预热解决"新内容冷启动"问题，两者常搭配使用。

二、缓存刷新的方式

2.1 按 URL（单文件）

最精准的刷新方式，只作废指定 URL。适合修正单张图片、单个页面等场景。Cloudflare 提供按 URL、按域名（Hostname）、按标签（Cache Tags）、按前缀（Prefix）以及全站刷新多种粒度。

2.2 按标签与按前缀

按标签（Cache Tags）：给响应打上标签（如 product-123），发布时按标签批量刷新，适合"一次刷新一批相关资源"；
按前缀（Prefix）：按 URL 前缀刷新，例如 /api/v1/*，适合版本化路径的批量更新。

2.3 全量刷新

刷新整个站点或整个环境的缓存。简单粗暴，但回源压力大，通常只在重大改版或配置错误时使用。

2.4 通过 API 自动化

生产环境应通过 API 执行刷新，而非人工在控制台点选。例如调用 CDN 的 purge API 提交 URL 列表，把刷新动作接入发布流水线。以 Cloudflare 为例，用 curl 就能完成一次按 URL 的刷新：

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/index.html","https://example.com/app.a1b2c3.js"]}'

把这段脚本封装进 CI/CD 的发布步骤，发布成功后再调用它，缓存更新就和上线动作绑定在一起。注意各平台的速率限制：如 Cloudflare 免费版为每分钟 5 次请求、单次最多 100 个 URL 等，批量刷新时要按 100 个一组循环提交，并记录失败项以便重试。

三、版本化文件名 vs 刷新

在 AWS CloudFront 等平台中，官方建议优先使用版本化文件名而非刷新：给静态资源文件名加上内容哈希（如 app.a1b2c3.js），文件名变化即视为新资源，无需刷新即可自然淘汰旧版本。这样做更便宜（无需支付 invalidation 费用），也能让浏览器本地缓存同步更新，效果优于刷新。两者对比详见下表：

维度	版本化文件名	刷新/失效
成本	无需额外费用	部分平台按条计费
生效速度	立即可用	需等节点逐条处理
浏览器缓存	同步更新	可能仍命中本地旧缓存
适用场景	长期不变的静态资源	动态更新、修复类资源

四、缓存预热的最佳实践

4.1 何时预热

新上线活动页、专题页，预期流量大；
大促、秒杀、新品发布前的热门资源；
回源带宽有限的场景，提前把内容推到边缘。

4.2 预热注意事项

只预热确定会被大量访问的资源，避免无谓回源成本；
预热走专用接口或批量提交，避免模拟真实请求造成日志污染；
与刷新配合：发布时先刷新旧内容，再对新版本做预热，实现平滑切换。

4.3 一个发布案例：大促页的上线流程

假设周五晚 8 点要上线一个秒杀活动页，页面引用了新的 CSS/JS 和一批商品图。比较稳妥的流程是：

提前半天用预热的专用接口把活动页及其子资源推到主要节点，让回源压力平摊到低峰时段；
上线前 10 分钟对该活动页及其依赖资源做一次按 URL 刷新，确保边缘没有残留旧版本；
放量时分三批：先放 10% 的流量观察，确认无误再逐步放大；
活动结束后用命中率报表确认预热资源的命中情况，为下一次发布积累数据。

这套流程里，刷新解决「旧版本残留」，预热解决「冷启动回源尖峰」，两者各管一段、配合发布节奏而不是事后补救，才能真正把缓存变成可控的加速器。

五、16IDC 观察：把缓存生命周期做成流程

在 16IDC 我们建议把缓存生命周期纳入发布流程管理，而不是当"救火工具"：

建立清单：哪些资源用长 TTL + 版本化文件名，哪些用短 TTL + 刷新，先在缓存策略里定清楚；
刷新脚本化：把按 URL/标签刷新封装进 CI/CD，发布即自动触发；
先预热后放量：高流量发布先预热，再逐步放开流量；
监控生效：用命中率监控确认刷新/预热后的状态符合预期。

刷新与预热是CDN 加速运营中的高频操作。做得规范，缓存就是"快且准"的加速器；做得随意，缓存就成了"看得见摸不着的坑"。建议结合CDN 缓存优化实践一起阅读。

原文来源：https://developers.cloudflare.com/cache/how-to/purge-cache/；AWS CloudFront Invalidation：https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

CDN 缓存刷新与预热实践：Purge 与 Preload 自动化流程