边缘命中率，决定CDN加速上限的隐形金线

我见过太多人把CDN监控面板上的“回源带宽”当成生死线，一看数值高就急得跺脚，转身就去加带宽，但真正的老炮儿知道，边缘命中率才是那个最该盯着的数字，它低了，回源自然高，延迟自然大，钱自然也烧得慌，可你要是只盯着回源去调优，大概率会走偏，今天咱们就把这词拆开揉碎，说透。

首先明确概念,边缘命中率，指用户请求在CDN边缘节点上被缓存的副本直接响应、没有触发回源的比例，公式很简单：命中次数除以总请求次数，注意是请求次数，不是流量，一个巨大的视频文件和一个几KB的接口请求，在命中率统计里权重相同，所以有时候你看到命中率95%，回源带宽却依然很高——因为那5%的未命中里全是大型对象，理解这一点，是看懂指标的起点。

边缘命中率，决定CDN加速上限的隐形金线

接着拆解影响命中率的核心因素,第一是TTL，也就是缓存存活时间，TTL设短了，刚缓存就被过期，命中率上不去；设长了，内容更新滞后，用户看到旧版本，第二是缓存键（Cache Key），如果缓存键设计得过于精细，比如把用户ID、Cookie、随机参数都放进去，那么同一个资源在缓存里会被分裂成无数个副本，命中率自然惨不忍睹，第三是请求的可缓存性，POST请求、动态API、带鉴权头的请求，很多CDN默认不缓存，第四是资源的热度分布，符合二八原则，20%的热门资源扛起80%的流量，冷门资源占多数但回源频繁，会拉低整体命中率。

但这里有个常见的误区：是不是边缘命中率越高越好？不是，为了追求99.9%的命中率，你可能把动态内容也粗暴缓存起来，或者把TTL设成一个月，结果用户数据错了，业务被判死刑，边缘命中率必须服务于业务正确性。

接下来对比两种主流方案,方案A：全站缓存加速——所有内容一律进缓存，动态请求响应头里的Set-Cookie也忽略，强行缓存30天，优点是命中率极高，回源极少，带宽成本低；缺点是动态数据错乱，登录状态被串号，硬生生把一个技术指标做成了业务事故，方案B：智能分类缓存——按文件类型、请求路径、是否带Cookie等特征，把请求分成“可缓存”和“不可缓存”两类，可缓存的设合理TTL，不可缓存的直接回源，只优化静态部分，这种方案命中率没那么“漂亮”，可能只有70%，但业务零风险，如果让我选，我永远选B，别为了虚高的数字，把自己上半身的血都压到下半身去。

再说适用场景,如果做纯静态资源分发，比如图片、CSS、JS、视频点播，边缘命中率就是核心KPI，完全可以设到95%以上，如果是API网关背后的业务接口，就得小心了，面向最终用户的GET型接口，如果数据变化不敏感，可以设置短TTL，比如5秒，既缓解源站压力，又能保证基本正确，但涉及订单、库存、余额的接口，连那5秒缓存都得省了，直接回源，这是底线，至于流媒体直播，边缘命中率的意义比较特殊——由于是动态分段，往往需要CDN的流媒体缓存能力配合预推优化，不能简单套用网页缓存逻辑。

最后给选型建议：第一，别选没有“缓存键编辑”功能的CDN服务商，你至少要能按Query、Header、Cookie来拆分或合并缓存键，否则命中率优化就是空谈，第二，要选支持“缓存优先级”或“缓存策略模板”的产品，比如能够对不同目录设置不同的TTL和缓存条件，第三，如果业务里有大量含签名参数的URL，一定要开启“忽略部分Query参数”的开关，或者改成用路径区分资源，否则你那几百个不同的签名字段会让缓存碎片化到怀疑人生，第四，建立监控：用边缘命中率、回源流量、回源请求数、请求成本四个维度一起看，单独一个指标会骗人。

边缘命中率是一面镜子,照出CDN策略是否健康，别为了报表上的漂亮数字去阉割业务正确性，也别因为怕出错就拒绝一切缓存，找到那个平衡点，你的CDN才能真正跑起来，毕竟，CDN的本质是拿空间换时间，而边缘命中率，就是这个交换的最优解之间的那根金线。