基于 Cloudflare 的双层缓存架构实践:CDN Cache 与 Worker Cache 的职责分离设计

在使用 Cloudflare Worker 构建全球加速、灰度发布、多源站调度系统时,缓存体系设计是决定系统稳定性与可控性的核心因素

很多工程师会同时使用:

  • Cloudflare CDN 自动缓存
  • Worker 内置的 caches.default 缓存

但如果没有明确区分两者职责,很容易出现:

页面版本混乱、发布失控、缓存击穿、数据不一致

本文将从工程实践角度,系统讲清:

  • CDN 缓存和 Worker 缓存的本质区别
  • 为什么 HTML 不应交给 CDN 缓存
  • 如何设计工业级双层缓存架构
  • 完整请求流程与版本更新逻辑(Mermaid 图)

一、缓存的本质分工

在 Cloudflare 边缘网络中,请求实际会经过两层潜在缓存系统:

复制代码
用户 → Cloudflare CDN Cache → Cloudflare Worker → Worker Cache → 源站

它们并不是同一层级,而是定位完全不同的系统组件


二、CDN Cache:自动化高速公共缓存

特点

  • 位于 Cloudflare PoP 边缘节点
  • 自动命中与回源
  • 延迟极低(毫秒级)
  • 几乎无计算成本

优势

✅ 极致性能

✅ 超大容量

✅ 自动分布式

局限

❌ 缓存 Key 不可精细控制

❌ 无法感知业务版本、灰度逻辑

❌ 不适合频繁更新内容

适用场景

👉 静态资源:

  • JS
  • CSS
  • 图片
  • 视频

通常配合:

http 复制代码
Cache-Control: public, max-age=31536000, immutable

实现一年级别缓存。


三、Worker Cache:可控的逻辑缓存层

Worker 内置缓存允许开发者自定义:

  • cacheKey
  • 版本参数
  • 地区维度
  • 灰度标识

特点

  • 完全由代码控制
  • 可嵌入业务逻辑
  • 可做版本隔离

优势

✅ 高度可控

✅ 支持发布系统

✅ 支持多版本共存

局限

❌ 相比 CDN 稍慢

❌ 消耗 Worker 计算资源

适用场景

👉 HTML 页面

👉 接口聚合结果

👉 动态内容


四、为什么 HTML 不应该交给 CDN 缓存?

在现代工程实践中,HTML 通常具备:

  • 版本更新频繁
  • 灰度发布需求
  • 多源站调度
  • A/B 测试

如果 HTML 被 CDN 缓存:

  • CDN 无法识别版本参数
  • Worker 逻辑被绕过
  • 发布行为不可控

最终会导致:

❗ 部分用户看到旧页面

❗ 部分用户看到新页面

❗ 灰度失效

这在工程上被称为:

缓存失控风险


五、推荐的工业级缓存职责模型

HTML

复制代码
Cache-Control: no-store

效果:

➡ CDN 不缓存

➡ 所有请求进入 Worker

➡ 由 Worker Cache 管控


静态资源

复制代码
Cache-Control: public, max-age=31536000, immutable

效果:

➡ 浏览器缓存

➡ CDN 长期缓存

➡ 零回源


六、完整请求流程(含版本控制)

命中
未命中
命中
未命中
用户请求
CDN Cache 是否命中?
直接返回缓存
进入 Cloudflare Worker
构造 cacheKey + 版本号
Worker Cache 是否命中?
返回 Worker 缓存
回源站获取内容
Worker 处理响应
写入 Worker Cache
返回给用户


七、版本更新时的自动刷新机制

通过引入构建版本号:

ts 复制代码
_v = BUILD_VERSION

缓存 Key 变为:

复制代码
/page?_v=20260203

更新后:

复制代码
/page?_v=20260204

效果

✔ 自动绕过旧缓存

✔ 强制回源

✔ 生成新缓存

无需:

❌ 手动 purge

❌ 等待过期


八、版本更新流程图

BUILD_VERSION 变更
旧版本缓存
缓存未命中
回源获取新内容
生成新缓存
提供新页面


九、最终架构总结

复制代码
                ┌──────────────┐
                │ CDN Cache    │  ← 静态资源
                └──────────────┘
                        ↓
用户请求 → Worker(逻辑调度) → Worker Cache(HTML/动态内容) → 源站

职责划分原则:

类型 使用缓存 目的
HTML Worker Cache 可控、可发布
API Worker Cache 动态聚合
JS/CSS/IMG CDN Cache 极致性能

十、一句话工程结论

CDN 管稳定资源

Worker 管动态逻辑

或者更直观一点:

CDN 缓存"死内容"

Worker 缓存"活页面"


结语

通过将 CDN Cache 与 Worker Cache 职责彻底拆分:

✅ 发布可控

✅ 性能极致

✅ 架构清晰

✅ 易扩展

将获得一套:

🌍 支持全球调度

🚀 支持秒级更新

🧠 支持复杂业务逻辑

的工业级边缘架构体系。

相关推荐
努力努力再努力wz2 小时前
【Redis进阶系列】:从主从复制到 Sentinel,一文建立故障检测、Leader 选举与 Failover 的完整心智模型
数据库·redis·缓存
掘金泥石流2 小时前
从 Palantir AI FDE 到我们的实践:企业交付如何变成产品?
人工智能·架构·agent
掘金泥石流2 小时前
上下文即服务:AI 应用的竞争,为什么会从入口转向 Context?
人工智能·架构·agent
掘金泥石流2 小时前
AI 都能写代码了,为什么企业还需要 FDE?
人工智能·架构·agent
kisshyshy2 小时前
从Props透传到自定义Hook:系统梳理React跨层级通信与逻辑复用
前端·架构·代码规范
躺柒3 小时前
读数据架构知识体系指南01关系数据仓库(上)
数据仓库·架构·数据分析·spark·数据湖·关系数据库·企业数据仓库
程序员清风3 小时前
Java 后端如何接入大语言模型
java·spring boot·架构·aigc
liulilittle4 小时前
mock 框架架构
ai·架构·自动化·llm·mock·测试·tools
mldong4 小时前
一套审批流要写多少代码:13 个框架的接入 diff 我数了一遍,最少 422 行,最多 1798 行
后端·架构
GreenTea13 小时前
GrokBot 核心成员 Lauren Tan:每月交付 2000 个 PR 的人,是怎么用 AI 的
前端·后端·架构