第3章 客户端缓存层：浏览器缓存、App本地缓存、CDN边缘节点的作用与边界
系统边界与分层结构
客户端缓存层是离用户最近的一级存储，直接运行在用户设备或运营商边缘机房中。它的核心使命是在不经过源站的前提下，以微秒或毫秒级延迟响应用户重复请求。从系统边界看，这一层分为三个子区域：
- 浏览器缓存：运行在 Web 浏览器进程内，受同源策略和 HTTP 缓存协议控制。
- App 本地缓存：运行在移动端或桌面应用的沙箱环境中，由开发者通过 SDK 或持久化框架管理。
- CDN 边缘节点：部署在运营商骨干网或城市级机房，由 CDN 服务商统一调度。
三层共同构成“用户侧—边缘侧—源站侧”三级减速器，越靠近用户，延迟越低但存储容量和一致性保障越弱。
边界原则：浏览器和 App 缓存属于不可信环境（用户可随意清空或篡改），CDN 边缘节点属于半可信环境（由服务商控制但暴露在公网）。设计时必须按信任等级划分数据平面与控制平面。
核心组件职责
| 特性 | 浏览器缓存 | App 本地缓存 | CDN 边缘节点 |
|---|---|---|---|
| 存储媒介 | 内存、磁盘（HTTP Cache）、Service Worker Cache API | 内存（LRU Map）、SQLite、SharedPreferences、文件系统 | SSD 集群、内存（varnish/nginx cache） |
| 典型容量 | 几十 MB ~ 几百 MB | 由 App 配额决定（通常几百 MB ~ 几 GB） | TB 级（单节点） |
| 失效机制 | 强制失效（Cache-Control）、协商失效（ETag/Last-Modified） | TTL、LRU、版本号升级 | 回源验证、预热刷新、统一过期策略 |
| 应用场景 | HTML/CSS/JS/图片等静态资源 | API 响应、用户偏好、离线数据 | 静态加速、动态加速（DCDN）、音视频流媒体 |
| 信任级别 | 不可信 | 不可信 | 半可信 |
数据流与控制流
一次典型的缓存读取路径遵循“本地优先、逐级回源”策略。以浏览器请求为例：
- Service Worker 拦截：如果注册了 Service Worker，请求首先进入 SW 事件循环，SW 可返回 Cache API 中的内容。
- 内存缓存（Memory Cache）：当前页面已加载的资源，以最快速度命中。
- 磁盘缓存（Disk Cache）：持久化的 HTTP 缓存，通过 Cache-Control 和 ETag 校验新鲜度。
- CDN 边缘节点：未命中本地缓存后，请求发往 CDN 节点。CDN 节点根据分片规则查找自身缓存，若未命中则发起回源请求。
- 源站：最终数据提供方，响应后沿原路径回填每一级缓存。
App 本地缓存的流程类似，但通常由 App 的网络库（如 OkHttp、Alamofire）直接管理缓存策略，无需浏览器内核介入。
设计启示：控制流应当始终由客户端发起（拉模式），禁止 CDN 或源站主动向客户端推送数据，以规避跨域安全风险。信任链路遵循“客户端不可信 → CDN 半可信 → 源站可信”的三角模型。
客户端缓存层架构图
信任链路与安全边界
- 客户端（不可信）：数据可能被用户篡改、清除或窃读。敏感信息（如 、用户隐私）必须加密存储，且不应依赖客户端缓存做安全校验。
- CDN 边缘节点（半可信）：边缘节点由服务商维护，但暴露在公网环境。必须防范 DDoS 攻击、缓存投毒和配置泄露。HTTPS 应全程启用，回源鉴权 Header 不可缓存在边缘节点上。
- 源站（可信）：作为数据和策略的权威来源，负责签发缓存失效指令（如 Cache-Control: no-cache）和签名验证。
常见风险：CDN 配置不当导致源站 IP 泄露，攻击者绕过 CDN 直接打源站。建议源站仅放行 CDN 回源 IP 白名单，并开启 WAF 策略。
选型权衡
| 维度 | 浏览器缓存 | App 本地缓存 | CDN 边缘节点 |
|---|---|---|---|
| 延迟 | < 1ms（内存） | < 1ms（内存） | 5-20ms（区域节点） |
| 命中率 | 较低（受用户清缓存影响） | 中等（依赖 App 生命周期） | 高（共享缓存池） |
| 一致性控制 | 弱（强制失效 + 协商校验） | 弱（依赖版本号或 TTL） | 强（支持主动刷新、API 失效） |
| 成本 | 用户设备资源和流量 | 用户设备存储空间 | CDN 流量和回源带宽费 |
核心权衡点：缓存层级越多，数据一致性保障越复杂。通常图片/视频类资源可容忍分钟级不一致，适合多层缓存；而用户余额、库存数据必须穿透到源站或使用缓存失效广播。
主要风险点
- 缓存击穿：热点 key 在本地或 CDN 上失效，大量请求同时穿透到源站。解决方案：本地互斥锁（Mutex）或 CDN 层回源并发控制。
- 缓存雪崩：大量缓存同时过期，或 CDN 节点集体宕机。解决方案：过期时间加随机偏移，多级缓存降级，CDN 冗余节点。
- 缓存穿透：查询根本不存在的数据，所有缓存层都无法命中，导致源站压力巨大。解决方案：布隆过滤器或缓存空值（带短 TTL）。
- 隐私合规：GDPR / 个人信息保护法要求用户数据存储需得到授权。App 本地缓存中的用户标识必须按合规要求提供清除入口。
落地实施步骤
- 资源分级：梳理业务资源，按变更频率分为不可变资源（图片、版本化 JS/CSS）和可变资源（API 响应、HTML 页面）。
- 配置 CDN 缓存策略：为不同路径设置 Cache-Control 和回源超时时间。
- 实现 Service Worker：在浏览器端注册 SW，预缓存关键资源，实现离线可用和快速回访。
- 设计 App 缓存框架：选择本地持久化方案（如 Room、CoreData），封装统一的缓存读写接口，自动管理 TTL 和 LRU 淘汰。
- 建立监控告警：采集本地缓存命中率、CDN 回源率和延时指标，设置基线告警。
- 演练与容灾：定期模拟 CDN 降级或本地缓存清空场景，验证源站的承载能力和降级页面的正确性。
实践建议：首次搭建时，先启用 CDN 层并观察命中率，待稳定后再补充浏览器 Service Worker 和 App 本地缓存。避免一开始就叠加多层导致问题排查困难。
验收标准
- 延迟降低：静态资源加载时间减少 ≥ 60%，动态 API 响应 P95 延时 ≤ 200ms（原 ≥ 500ms）。
- 源站卸载：CDN 边缘节点承担 ≥ 80% 的静态请求，App 本地缓存命中率 ≥ 40%。
- 新鲜度合规：缓存资源在期望 TTL 内能正确响应，超时后能正确回源更新，错误率 ≤ 0.01%。
- 安全合规：客户端缓存中不包含明文敏感数据（、身份证号等），CDN 无源站 IP 泄露风险。