CDN 基础：架构、节点、分发与缓存
聊到 CDN，很多同学第一反应就是「加速」。但背后的原理，说白了就是 内容离用户越近，响应越快。我刚开始接触 CDN 时，以为它就是个高级缓存代理，后来踩过几次坑才明白，架构设计、节点布局、缓存策略环环相扣。今天咱们把这几个核心掰开了聊聊。
CDN 的整体架构
先看一张经典的三层模型。最外层是 边缘节点，中间是 区域中心，最里面是 源站。用户请求打到边缘，边缘没有缓存就向上层要，层层回源。你可能会问，为什么不直接回源？
原因很简单——源站扛不住啊。我在项目中就见过，某活动流量突增，源站直接被冲垮，后来加了 CDN 边缘层，95% 的请求在边缘就响应了。
• 边缘节点：分布各地，存储热点内容，直接服务用户
• 调度系统：根据用户 IP 和节点负载，返回最优节点 IP
• 回源层：缓存未命中时从源站拉取内容，并同步更新
下面是 CDN 核心架构图，我习惯把调度、边缘、源站之间的数据流向画清楚。
边缘节点与内容分发原理
边缘节点为啥能加速？本质是 就近 + 缓存。用户访问时，DNS 调度返回离他最近的边缘节点 IP。如果那个节点上存了用户要的内容，直接返回，延迟通常 < 10ms。如果没存呢？节点会向上一层或源站拉取，同时把内容存下来，下次就不找了。
这里的「分发」分两种模式：
- 主动推送：源站更新内容后，直接推给所有边缘节点。适合静态图片、视频等。
- 被动回源：用户触发才拉取，第一次慢，后续快。适合动态页面或长尾内容。
我遇到过有人把所有内容都走被动回源，结果活动上线时边缘节点全部同时回源，源站 CPU 瞬间 100%。后来改为预热推送，提前把热点内容推到边缘，才稳定下来。
缓存策略：让效率翻倍的核心
缓存策略说白了就三个问题：存多久？怎么更新？一致性能接受多少？
| 策略 | 原理 | 适用场景 | 坑点 |
|---|---|---|---|
| 强制缓存（Cache-Control） | 设置 max-age，到期前直接返回本地副本 | 图片、CSS、JS 等静态资源 | 更新后用户不刷新看不到新内容 |
| 协商缓存（ETag / Last-Modified） | 每次携带标记到边缘验证，未过期返回 304 | HTML、API 响应 | 验证请求占比高时边缘成本增加 |
| 多级缓存（L1→L2→源站） | 热数据在 L1，温数据在 L2，冷数据回源 | 大流量高并发场景 | 各级缓存命中率需要持续调优 |
| 分层 TTL | 边缘短 TTL（如 5 分钟），中间层长 TTL（如 1 小时） | 新闻资讯、排行榜 | 用户可能拿到旧数据，需结合版本号 |
我曾经给某客户配置了全局 max-age=86400，结果版本更新后用户一直看到老页面。后来我们在 URL 后面加版本参数（如 style.css?v=2），强制边缘节点以为它是新资源。这是最省心的做法。
缓存刷新也是个技术活。全量刷新容易打回源，增量刷新又可能漏掉。我一般按 目录级别 + 正则 刷新，比如只刷新 /images/ 下的图片，避免影响其他文件。
代码示例：Nginx CDN 缓存配置片段
# 边缘节点缓存配置示例
proxy_cache_path /data/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m;
server {
listen 80;
location / {
proxy_cache my_cache;
proxy_cache_valid 200 302 10m; # 200/302 缓存 10 分钟
proxy_cache_valid 404 1m; # 404 只缓存 1 分钟
proxy_cache_use_stale error timeout updating; # 回源失败时使用过期缓存
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://backend;
}
}看到这里你可能会问：配置里 proxy_cache_use_stale 是什么？说白了就是当边缘节点回源出错时，允许返回过期的缓存，保证用户至少能拿到内容，而不是直接 502。这个开关在生产环境里非常关键。
小结：核心要点
- CDN 本质是 空间换时间——使用大量边缘存储换取用户端响应速度
- 缓存策略的核心变量是 TTL 时长、更新粒度、一致性容忍度
- 多级缓存可以减小回源压力，但要增加监控和命中率分析
记得我刚入行时，总想把所有内容缓存时间设得很长，后来被老板骂过才明白：缓存是双刃剑，快是真的快，脏数据也是真的麻烦。好，这一章就先讲到这里，你可以在实际项目里对照着看看自己的 CDN 配置哪里还有优化空间。