把CDN节点放到离用户最近的地方，只能省去一半时间；真正决定加速上限的，是地理就近调度与缓存亲和性是否被放在同一个优化闭环里协同设计，否则节点再近也会被反复回源的请求拖垮。
CDN边缘节点如何选择？先分清调度和缓存的职责
很多团队在选CDN边缘节点时，习惯把“就近调度”和“缓存命中率”当成两件事来做，前者交给智能DNS，后者靠缓存系统自己折腾，结果就是调度层觉得“我分得很近”，缓存层却在后台疯狂回源，要解决这个问题,得先把这两者的职责边界划清楚。
地理就近调度负责“把人带到门口”
调度器的任务，是基于用户IP、运营商归属、地理位置等信息，把请求导向“距离最近”“链路质量最好”的边缘节点，日常用的是DNS解析，也有部分业务切到HTTPDNS或Anycast BGP，所谓“，不只是直线距离，更看重RTT往返时延、丢包率、跳数这几个指标综合打分，比如华东用户访问华东节点，RTT通常在10ms以内，但如果你只按IP归属地硬分，忽略了某个节点正在遭受DDoS攻击或者出口带宽打满,用户实际体验依然很糟。
近些年主流的调度策略，早已从“单一距离优先”进化到“多维加权打分”，节点的CPU负载、带宽余量、健康检查状态，都会被纳入综合判断，但这里有一个容易被忽略的事实：调度只负责把人带到“门口”,不负责门后有没有货。
缓存亲和性负责“让门后面有货”
缓存亲和性，通俗讲就是让同一个用户、同一类内容的请求，尽量稳定落到同一台边缘节点上，这样做的好处很明显：同一个URL的头像、图片、JS文件只要第一次回源拉到节点，后续请求就能直接命中,延迟从几百毫秒降到十几毫秒。
实现缓存亲和性的常见手段，是hash调度，把URL或者用户标识做哈希运算，映射到一个固定节点、一组缓存分片，或者一个一致性哈希环上，设计合理的hash策略，能让命中率保持在比较稳定的高位，而设计不合理的，例如哈希key拼接时把随机参数也带进去，或者缓存分片粒度太细导致热点分散,命中率就会断崖式下跌。
两者分开看会出什么问题
业内专家指出，相当一部分CDN加速效果不佳的案例，问题不是出在延迟上，而是出在“请求被调度到了近节点，但该节点缓存里没有内容”，想命中就得回源，一回源就慢,距离优势被完全抵消。
另一个常见情况是调度不稳定，用户第一次请求被分到A节点，缓存了内容；第二次请求因为调度策略抖动，被分到了B节点，B节点没有缓存，只能再次回源，来回两次，用户感受到的就是“时快时慢”，同一用户反复在几个节点之间“流浪”,会显著拉低整体命中率。
直播加速和网页加速场景下，协同逻辑有什么不一样
不同业务对“近”和“亲”的权重需求完全不同,不能拿一套配置通吃所有场景。
直播场景：节点距离优先于缓存分组稳定
直播流讲究实时性，推流和拉流链路需要尽量短、尽量稳，边缘节点需要在靠近观众的地方拉取上游流，再分发给当地用户，这种场景下，地理就近调度是绝对优先级的，缓存亲和性反而要往后放，如果为了追求缓存分组稳定而把一部分观众调度到更远的节点,直播卡顿率会立刻上升。
直播的“缓存”其实是流切片，节点会保留最近几秒的切片，供追播、时移使用，设计时一般会给节点配置较小的切片缓冲窗口，并且优先保证节点网络质量在线，如果节点故障，新调度进来的用户很难从旧节点拿到已有切片，此时跨节点状态同步的意义不大,直接重新拉流反而更快。
网页与下载场景：命中率决定体验下限
网页静态资源、文件下载、App更新包这类业务，文件可缓存，并且用户对首字节时间和下载速度都极其敏感，这类场景下，缓存亲和性应该和地理就近调度平起平坐,甚至前者的权重更高。
典型的设计是：先把用户按地理位置分组，组内再按资源URL哈希到固定节点，这样既做到区域就近，又保证同一批资源稳定落盘在特定节点上，下载大文件时，分片被均匀打在同一组节点上,断点续传也不会跨节点反复跳转。
视频点播场景需要均衡设计
点播比直播宽容，比网页下载严格，热门剧集可以提前预热到全国各区域节点，冷门内容则可以通过一层中心缓存中转，行业共识认为，点播业务最适合“地理就近为主，缓存亲和性兜底”的均衡模式。
| 业务场景 | 调度权重侧重 | 缓存亲和性定位 | 核心指标 |
|---|---|---|---|
| 电商网页 | 距离 + 运营商链路 | 高，稳定返回缓存 | 首字节时间 |
| 视频点播 | 距离优先 | 中，结合预热策略 | 卡顿率 |
| 文件下载 | 距离 + 带宽余量 | 高，分片亲和 | 平均下载速度 |
边缘节点缓存命中率低是什么原因？排查思路可以这样走
如果监控面板上看到命中率数字不好看，先别急着调缓存参数，按下面的路径排查,能少走不少弯路。
调度层的两个典型瓶颈
- 节点健康检查失效，有些节点负载已经很高，但健康检查接口没把负载率算进去，调度器继续往里塞流量,导致新请求进节点后连缓存查询的资格都没有。
- 运营商互联互通被忽略，跨运营商访问时，虽然地理距离近，但实际链路的RTT可能比跨省还高，没有按运营商维度拆分调度策略，请求就会在物理上很近、网络上很远的节点之间打转。
缓存层的三个常见陷阱
- 缓存key设计粗糙，URL里带时间戳、带utm参数、带随机token，都会导致缓存永远无法命中,这是最基础但最高频的错误。
- 淘汰策略过于激进，有些团队为了省内存，把LRU的淘汰周期设得很短，热门资源刚缓存几秒就被挤出，后续请求只能回源,缓存命中率自然上不来。
- 缓存分层缺失，边缘节点和上层节点之间没有分级缓冲，边缘一旦未命中，直接穿透到源站,整个加速链路形同虚设。
一条从调度到缓存的排查路径
先在CDN控制台或自建系统里拉取最近的调度日志，看相同IP是否频繁切换节点，再统计各节点的写回源量和读命中率，把回源量Top节点的用户IP和缓存key拿出来对比，如果某节点的回源集中在一批特定URL上，是缓存key设计问题；如果分散在大量URL上,则是调度把热点引流到了没有预热的冷节点。
协同设计落地的四个关键动作
把原理落实到配置和代码层面,靠的是以下几个动作。
把缓存状态纳入节点健康评分
节点健康评分不能只看RTT和丢包率，还要看节点当前的缓存热点覆盖率，如果一个节点缓存命中率已经掉到40%以下，即使它离用户最近，也应该暂缓分配新流量，实现上可以在调度器里增加缓存层的状态上报接口，每5秒同步一次命中率和待回源队列长度，评分公式可以简单写成：最终分 = 网络分×0.4 + 缓存命中率×0.3 + 负载分×0.3。
用跨区域同步降低故障切换时的回源压力
边缘节点宕机后，原本分给它的流量会切到相邻节点，如果相邻节点没有对应缓存，回源风暴会瞬间打满上层带宽，设计上要提前做区域缓存拓扑：在每个调度区域维护一个备用节点池，定期把主节点的热门资源预热到备用节点，切换时，备用节点能直接接管大部分流量,回源比例控制在可接受范围内。
热点事件触发链路级预热
遇到大促、节假日抢购、新游戏开服这类可预知的流量高峰，不要纯靠调度自然升温，提前2小时把热点资源推送到预计承担流量的边缘节点集群，同时在调度策略里将这部分流量锁定在已预热的节点上，配合限流降级规则,让缓存亲和性在高峰期不因节点扩容而被破坏。
让成本预算也参与设计决策
国内CDN带宽价格因地区差异并不算大，真正的成本大头是回源流量，回源带宽通常是CDN带宽价格的数倍以上，缓存命中率每提高一点，财务成本都会实打实地下降，边缘节点如何选择才划算？答案很简单：优先选能跟缓存策略协同的节点，而不是单纯看谁的带宽报价低，华东、华北这类流量密集区，宁可多配置两个小节点做缓存分组，也别把所有流量压在一个大节点上,否则故障半径和回源成本都会失控。
按地理就近调度与缓存亲和性协同设计常见问题解答
边缘节点频繁回源，优先查调度还是查缓存？
先查调度稳定性，再看缓存key是否统一，如果同一个IP在短时间内被调度到多个边缘节点，说明调度策略里缺少“用户会话保持”机制，需要调整会话保持时间或者改用一致性哈希调度，如果调度稳定但回源量依然高，多半是缓存key里混入了动态参数，或者缓存淘汰策略设置过于频繁，两张对比图摆出来后,问题归属一般能一目了然。
缓存亲和性会不会导致某台节点压力过大？
会，亲和性策略本质上是把相同的流量引向相同的节点，如果资源分布极度不均衡，一台高热度节点可能承载超过平均值的压力，解决办法是引入“虚拟节点”技术：将物理节点拆成多个虚拟分组参与哈希环，流量会均匀分散在虚拟分组上，同时保持相同内容仍然落在同一虚拟分组内，再配合节点水位监测，超过阈值时自动调低该节点的调度权重,让溢出的流量去次优节点。
全国性业务要不要强制地理就近？
不建议全量强制就近，跨区域调度在部分场景下反而是更好的选择：源站服务器集中在华南，而华北用户的访问需要经过长途骨干网；此时如果强推华北边缘节点，节点与源站之间的回源链路很长，反而拉低了访问速度，更务实的做法是，把全国分成若干调度域，在每个域内执行地理就近和缓存亲和性协同，超过阈值才触发跨域调度，并按“同运营商优先”原则决定迁移目标，设计目标只有一个：让大多数请求在网络路径和缓存路径上都拿到最短链路。