9.0 CDN 全景：它到底是什么
一句话
CDN 不是 “一堆缓存服务器”，而是三层系统的组合：调度层（DNS / GSLB / anycast）决定 “去哪个节点”，边缘层（PoP + 缓存 + 回源）决定 “内容怎么出去”，控制面（配置、预热、刷新、日志、计费）决定 “谁能改、改完多久生效”。
为什么需要它：四个物理事实
| 事实 | 后果 | CDN 怎么解 |
|---|---|---|
| 光速有上限（约 5μs/km 单程） | 跨洲 RTT 150–250ms，首包就慢 | 把内容搬到离用户一跳以内 |
| 运营商互联质量不均 | 跨网访问丢包、抖动 | 多线节点 + 就近接入 |
| 带宽成本随流量线性涨 | 回源带宽是最大成本项 | 边缘命中，减少回源 |
| 流量有突发（热点、直播、大促） | 源站扛不住瞬时峰值 | 边缘吸收，源站只承受回源 |
所以 CDN 的价值可以写成一句话：用 “边缘存储 + 调度” 换延迟、换回源带宽、换突发承受力。
五个组成部分
| 层 | 组成 | 它决定什么 | 出问题时的表现 |
|---|---|---|---|
| 调度 | DNS / GSLB / anycast / HTTP 302 | 用户被分到哪个节点 | 被调度到远端节点，延迟反而更高 |
| 边缘 | PoP 机房、缓存进程、TLS 终结 | 命中率、首字节时间 | 命中率低 → 回源打满 |
| 回源链路 | 回源 HOST/协议、专线、多源 | 源站压力与一致性 | 回源风暴、源站被打挂 |
| 控制面 | 配置下发、预热、刷新、证书 | 变更生效速度与正确性 | 配错规则全站 404、刷新不生效 |
| 计费与观测 | 流量/请求计费、日志、报表 | 成本与排障能力 | 账单不可解释、故障无法定位 |
产品形态：先分清你买的是哪一种
| 形态 | 加速对象 | 关键能力 | 典型场景 |
|---|---|---|---|
| 静态加速 | 图片、JS/CSS、下载包 | 缓存命中、压缩、图片处理 | 站点、App 资源 |
| 下载分发 | 大文件（GB 级） | 分片回源、断点续传、限速 | 安装包、视频文件 |
| 动态加速 | API、HTML（不可缓存） | 路由优化、连接复用、协议优化 | 全站加速、跨境 API |
| 流媒体 | 点播 / 直播 | 切片、转码、低延迟协议 | 视频平台 |
| 边缘计算 | 轻量逻辑 | 边缘函数、KV | A/B、鉴权、重写 |
| 安全 | 攻击流量 | WAF、DDoS 清洗、BOT 管理 | 对外门户 |
选型时常被忽略的一点：同一家厂商的不同产品，调度与回源是两套系统。静态加速的节点未必适合动态加速，动态加速的链路也未必走静态节点。
五个指标，决定 “值不值”
| 指标 | 定义 | 目标量级 | 说明 |
|---|---|---|---|
| 命中率 | 边缘命中请求 / 总请求 | 静态 90%+ | 由缓存键、容量、分布决定（见 9.1 边缘缓存原理） |
| 回源率 | 回源请求 / 总请求 | 静态 < 10% | 直接决定源站带宽（见 9.2 回源策略与回源率） |
| 首字节（TTFB） | 边缘到用户首字节 | 静态 < 100ms | 含 TLS 与调度 |
| 可用性 | 边缘可用 / 总时间 | 99.9%+ | 多厂商时看 “整体” 而非单家 |
| 单位成本 | 元 / GB 或 元 / 万请求 | 随量下降 | 计费模式差异极大（见 5.6 云成本结构） |
计费：三种模式，算出来的数不一样
| 模式 | 怎么算 | 适合 | 陷阱 |
|---|---|---|---|
| 按流量 | GB × 单价（阶梯） | 流量平稳 | 突发时账单不可预测 |
| 按峰值带宽 | 95 分位峰值 × 单价 | 大流量、可预测 | 一次尖峰抬高整月账单 |
| 按请求 | 万次请求 × 单价 | 小文件多请求 | 命中率高时请求数才是主成本 |
比价时必须换算到同一个口径：静态小文件按请求计费可能比按流量贵得多，大文件反之。
本章地图
| 节 | 回答什么 |
|---|---|
| 9.1 边缘缓存原理 | 命中率由什么决定（缓存键 × 容量 × 分布） |
| 9.2 回源策略与回源率 | 回源怎么配、回源率怎么降 |
| 9.3 缓存键设计 | 键里放什么、怎么规范化 |
| 9.4 预热、刷新与失效 | 发布时怎么让新内容立刻生效 |
| 9.5 动态加速 | 不能缓存的东西怎么加速 |
| 9.6 边缘计算模型 | 什么时候把逻辑放到边缘 |
反模式
| 反模式 | 后果 |
|---|---|
| 把 CDN 当 “便宜带宽”，不看命中率 | 回源率没降，账单反而多一份 |
| 只比单价，不比调度与回源 | 便宜但调度到远端，体验更差 |
| 认为 “上了 CDN 就安全” | WAF/DDoS 是独立能力，不是缓存附赠 |
| 不做多厂商/多线 | 单家故障 = 全站静态资源不可用 |
| 不接入日志与命中率监控 | 出问题时无法判断 “是源站慢还是边缘慢” |
| 把动态接口也缓存 | 用户看到别人的数据（最严重的一类事故） |
三条铁律
🔑 CDN 的收益 = 命中率 × 流量；不谈命中率的加速方案都是猜。
🔑 调度决定体验下限：节点再近，调度错了也白搭。
🔑 缓存是 “按 URL 的承诺”：键设计错，等于把不同用户的内容混在一起。
自检
Q1 上了 CDN，源站带宽只降了 10%，最可能的原因是什么？
▸ 答案：命中率没起来。常见原因有三：① 缓存键里带了随机参数或全量 Cookie（每次都是新键）；② TTL 太短或内容本身不可缓存（动态接口）；③ 请求分散在大量不同 URL 上（长尾），单 URL 命中率天然低。诊断顺序：先看命中率与回源率，再看键的构成，最后看 TTL 与内容类型。
Q2 为什么 “按峰值带宽 95 分位” 计费可能比按流量更贵？
▸ 答案：因为它惩罚尖峰：一小时内因为一次直播或热点把带宽顶到 10Gbps，95 分位会把整月的计费带宽抬高，即使总流量不大。按流量则只付实际传输量。判断依据是 “流量是否平稳”：平稳选峰值带宽（通常更便宜），突发多选按流量或提前买保底。
Q3 选 CDN 时，为什么 “节点数量” 不是最重要的指标？
▸ 答案：因为体验由调度准确性 + 到源站的链路质量决定，而不是节点总数。节点多但调度到远端、或回源链路绕路，体验依然差。更该问的是：目标用户所在运营商/地域的覆盖质量、回源是否走专线、命中率与刷新时效、以及故障时的切换能力。
Q4 静态资源放 CDN 后，为什么还要在源站保留一套？
▸ 答案：因为 CDN 是缓存，不是存储：未命中、刷新、回源失败时都要回源站取。源站不存在 = 边缘也无法提供（除非开启了 “源站不可用时返回旧副本”）。同时发布流程也需要源站作为 “唯一真相”，由它推送/预热到边缘。
Q5 什么情况下不该用 CDN？
▸ 答案：三类：① 用户高度集中且离源站很近（收益趋近于零，只剩成本）；② 内容几乎全部不可缓存且没有链路问题（动态加速可能不划算）；③ 数据合规要求内容不得出特定区域（需先确认 CDN 节点与日志的落地区域）。判断标准始终是 “命中率 × 流量 × 单位成本” 这笔账，而不是 “别人都用了”。
跨篇相关：命中率的数学与缓存键的相互作用见 9.1 边缘缓存原理；回源链路与回源率见 9.2 回源策略与回源率；键设计见 9.3 缓存键设计；发布时的预热与刷新见 9.4 预热、刷新与失效；不可缓存内容的加速见 9.5 动态加速；边缘逻辑见 9.6 边缘计算模型；计费结构见 5.6 云成本结构。