，中心缓存负责兜住长尾冷门内容，两者靠热度判定、二级回源和缓存键策略打配合，才能把命中率与延迟同时压到最优。
边缘缓存和中心缓存区别：谁该存爆款，谁该存冷门
边缘缓存和中心缓存不是大小号的关系,更像便利店和区域仓库的关系，便利店离用户最近，但货架少，只放高频商品，区域仓库离得稍远，但库房大，什么都有。
- 边缘缓存节点：部署在离用户最近的城域网、运营商机房或地市节点，容量小、延迟低，只能存少量高热内容。
- 中心缓存节点：部署在区域中心或核心机房，容量大、带宽足，可存大量温冷内容，回源压力小。
- 源站：最终兜底，存全部内容，访问慢、带宽贵，尽量少被打到。
业内专家指出,两级缓存体系的核心不是“多存”，而是“存对位置”，热门内容如果只放在中心，边缘每次都要向上取，用户体感延迟会明显升高，冷门内容如果硬塞进边缘，会挤掉真正的爆款，反而拉低命中率。
| 对比项 | 边缘缓存 | 中心缓存 |
|---|---|---|
| 离用户距离 | 通常同城或同运营商 | 较近，区域级 |
| 单节点容量 | 较小，以TB级为主 | 较大，可达PB级或更高 |
| 访问延迟 | 最低，多数情况下可做到毫秒级 | 略高，但远低于源站 |
| 回源频率 | 未命中后先问中心 | 未命中后才回源站 |
| 硬件成本 | 节点多、单价低 | 节点少、单价高 |
热度分层的第一条原则就是：只有热度过了门槛的内容，才配进边缘缓存，中心缓存不挑热度，只要用户可能再来，就尽量留下。
两级缓存如何按热度切分内容：热门靠近用户，冷门留在中心
热度不是拍脑袋定出来的,它是访问频次、访问时间窗口和内容生命周期的综合结果。
热度分层不是固定标签，而是动态水位
同一部剧,上映第一周可能是高热内容，三个月后就变成长尾内容，同一个视频切片，白天可能热，凌晨就冷，所以边缘与中心的配合，需要一套自动升降级机制。
短时间大量请求，例如新发布的热门视频、突发热点新闻，优先推送到多个边缘节点，访问量稳定但不算爆发，例如经典教程、常规栏目，主要放在中心缓存，部分边缘按需保留，访问稀疏，例如归档资料、老视频，中心缓存保留，或者直接回源。
行业共识认为,比较稳妥的做法是给内容打热度分值，访问一次加分，按时间衰减，分数超过阈值，中心缓存主动把内容预热到边缘，分数降到阈值以下，边缘节点可以淘汰，中心缓存继续保留。
中心缓存如何判断要不要把内容推给边缘
中心缓存会记录每个URL或缓存键的请求次数,你可以在中心节点配置热度统计模块：
- 对每个缓存对象计数,1分钟滑动窗口统计请求量。
- 当请求量超过预设热度阈值,把该对象标记为“可下沉边缘”。
- 中心节点主动向边缘节点下发预热任务。
- 边缘节点收到预热后,从中心拉取内容并本地保存。
这套流程不需要人工干预,边缘缓存节点如何部署？关键是让节点离用户足够近，但又要保证中心与边缘之间的回源链路稳定，多数情况下，边缘节点会部署在离用户最近的运营商机房或地市级IDC，中心节点放在省会或区域核心。
CDN边缘缓存命中率低怎么解决？让中心缓存先接一次
很多CDN边缘缓存命中率低,不是边缘节点不够多，而是回源路径没理顺，用户请求到了边缘，发现没命中，边缘直接回源站，源站带宽被打满，响应变慢，命中率看着更低。
把“边缘未命中先问中心”写进调度逻辑
正确的两级配合,应当让中心缓存做“接应”，边缘没命中，不要直接回源，先问问中心有没有。
- 用户请求到达边缘节点。
- 边缘查找本地缓存。
- 命中,直接返回。
- 未命中,向上级中心缓存发起请求。
- 中心命中,返回内容，同时告诉边缘“存下来”。
- 中心也未命中,再由中心回源站取内容。
- 中心取回后写本地,再返回给边缘，边缘写本地后返回给用户。
这样做有两个好处：第一，源站压力大幅下降；第二，下次相同请求在边缘或中心就能命中。CDN边缘缓存命中率低怎么解决？多数情况下先看中心缓存有没有接住，比盲目增加边缘节点更直接。
调整缓存键和TTL，让同一个内容在两级缓存中认得出来
缓存键不一致是命中率低的隐藏杀手,边缘和中心如果对同一个视频URL生成不同的缓存键，内容就存了两份，命中率自然差。
具体检查路径：
- 确认边缘与中心的缓存键规则一致,统一去掉问号后无意义参数，比如
utm_source、timestamp。 - 统一视频分片命名,HLS的
segment_001.ts必须两端一致。 - 对图片、静态资源设置合理TTL，热内容可以长一点，冷内容短一点。
- 对HTML页面谨慎缓存,需要区分登录态、地域和终端类型时，把
Cookie、User-Agent、Region纳入缓存键。
中心缓存服务器多少钱？这个问题经常有人问，中心缓存服务器价格因带宽、盘位和内存配置差异很大，入门级节点和运营商级节点完全不在一个量级，选型时别只盯价格，容量和上行带宽才是中心节点能否接住边缘请求的关键。
视频网站如何用边缘缓存降低延迟：一个实际配合流程
视频网站对延迟最敏感,用户点开视频，画面最好立刻动起来，视频网站如何用边缘缓存降低延迟？答案就是把高热度分片提前放到边缘，冷门分片交给中心缓存兜底。
以短视频和点播场景为例,两级缓存的完整调度路径如下：
- 用户打开App,请求某条视频的HLS索引文件
playlist.m3u8。 - 边缘节点检查索引文件是否缓存,命中直接返回。
- 边缘未命中,请求中心缓存。
- 中心命中后返回索引,同时边缘保存一份。
- 用户继续请求第一个视频分片
segment_1.ts。 - 如果该视频是刚发布的热点,中心已经预热过分片，边缘大概率直接命中。
- 如果视频冷门,边缘未命中，向上问中心，中心命中后返回，边缘保存。
- 中心未命中,中心回源站取分片，再层层下发。
这个过程里,高热度分片留在边缘，延迟最低，冷门分片虽然要绕一下中心，但比直接回源快得多。中心缓存在这里充当了“流量缓冲区”，既保护源站，又给边缘兜底。
边缘缓存节点如何部署，才能覆盖不同热度的内容
边缘缓存节点不能只盯着一线城市,用户在哪，节点就该在哪，尤其视频类业务，晚高峰流量集中，跨地域回源会让延迟雪上加霜。
- 地市节点：覆盖本地用户，主要存放当地热门的短视频、热点新闻切片。
- 运营商节点：移动、电信、联通各自部署，避免跨网访问。
- 区域中心节点：作为二级缓存，存放温冷内容，向上对接源站。
部署时要注意中心与边缘的带宽比,边缘节点多、单点带宽小；中心节点少、单点带宽大，一般做法是让中心节点的上行带宽至少能扛住所有下辖边缘节点的并发回源请求，不然中心节点本身会变成瓶颈。
实操配置：把热度规则写进两级缓存调度
边缘与中心的配合不是买几台服务器就能跑通,关键是配置好调度规则、缓存参数和升降级策略。
边缘节点缓存配置关键参数
在边缘节点上,你需要配置本地缓存目录、缓存大小上限和淘汰策略。
- 缓存目录：使用SSD或NVMe盘，热内容读取频繁，机械盘扛不住高并发。
- 缓存大小：根据当地用户量估算，不要设置过大，边缘节点用不到那么大的盘。
- 淘汰策略：优先淘汰热度分低的对象，不要只按时间淘汰。
- 连接超时：边缘问中心时，超时建议控制在50到200毫秒，超时再考虑回源，避免用户等待过久。
- 健康检查：对上级中心节点做主动健康检查，及时摘掉故障节点。
中心缓存节点配置关键参数
中心节点是承上启下的关键层,配置重心在于容量、带宽和热度统计。
- 缓存键统计：开启基于URL的热度计数，建议按分钟粒度统计，太粗无法捕捉突发热点。
- 热度阈值：设定两个阈值，超过高阈值，预热到边缘；低于低阈值，从边缘淘汰。
- 预取策略：对新发布内容，可以提前从源站拉到中心缓存，中心缓存服务器多少钱不重要，重要的是盘位和带宽能不能支撑住预热流量。
- 回源合并：多个边缘同时请求同一个冷门内容，中心只回源一次，其余请求等待并复用结果，能显著降低源站压力。
- TTL分层在边缘的TTL可以短一些，方便淘汰；温冷内容在中心的TTL可以长一些，减少回源。
热度变化时，两级缓存如何自动调整
热度会随时间变化,你需要在中心节点配置升降级规则：
- 升热：某对象1分钟内请求数突然上升，中心主动向边缘下发预热。
- 降温：连续多个时间窗口请求数下降，中心通知边缘淘汰该对象。
- 突发热点：对于新闻事件、直播瞬时切片，可以人工或自动触发“紧急预热”，提前把内容推到全部边缘。
- 定期清理：中心缓存保留温冷内容，但也要设置最大TTL，超过生命周期的内容直接回源，避免缓存无限膨胀。
Q&A：边缘缓存与中心缓存配合的常见问题
边缘缓存和中心缓存配合时，可以只用边缘缓存吗？
不建议只保留边缘缓存,边缘节点容量有限，如果只靠边缘，长尾内容会频繁回源，回源延迟远高于中心缓存，源站带宽投入也更高，两级结构的意义就在于，中心缓存用较小的成本兜住大部分长尾请求，让边缘资源全部留给高热内容。
边缘缓存与中心缓存配合时，缓存击穿怎么办？
缓存击穿通常指某个热内容突然过期,大量请求同时落到中心或源站，解决思路是在中心缓存设置互斥回源，多个边缘同时请求同一个过期对象时，中心只放行一个请求回源，其余请求等待结果，回源完成后统一返回并重新缓存，同时可以给热内容设置滑动过期，访问一次就顺延TTL，减少同时过期风险。
边缘缓存与中心缓存配合时，如何设置TTL？
TTL要分两层设置,边缘节点上的热内容TTL不宜过长，便于热度下降后快速腾出空间，中心缓存的TTL可以放宽，温冷内容可以保留数天甚至更久，对于静态资源，可设置单日或数日TTL；对于HLS分片，可参考视频内容长度和生命周期；对于HTML页面，则需要结合登录态和个性化信息谨慎处理，通常不缓存或极短TTL，最终目标是让大部分重复请求都落在边缘和中心两层内。