把缓存命中率提上去，源站带宽压力就会跟着降下来，命中率每提升一个台阶，回源流量就会成比例收缩，这是成本与体验的平衡点。
点播系统的源站带宽成本,一直是视频平台运营的大头，行业共识认为，缓存层设计的目标不是把所有内容都塞进边缘，而是把重复请求高效截住，下文从缓存策略、命中率优化、回源保护、多级架构四个维度拆解，直接给可落地的方案。
视频点播缓存策略怎么调，才能明显降低源站带宽压力？
缓存策略不是越复杂越好,而是要在命中率、存储成本、回源频率之间找平衡，大多数视频平台的点播流量集中在少量热门内容上，这决定了缓存设计必须优先服务热点。
先把切片粒度做对，源站压力立刻减半
点播文件普遍采用HLS或DASH协议,切片大小直接决定缓存效率和回源频率，切片太大，边缘节点缓存整个文件会浪费空间；切片太小，回源请求数量暴增，源站的连接数和CPU开销反而上升。
实操上建议按以下原则调整：
- 常规视频使用6秒切片，直播回看可以用10秒，短视频建议4秒
- 码率分层文件（360P/720P/1080P）必须分开切片，避免低码率请求拖累高清缓存
- 切片索引文件（m3u8）的缓存时间要短，但切片文件的缓存时间要长，两者分开设置
按此调整后,多数场景下源站收到的回源请求数量能明显减少，带宽峰值也会被拉平。
缓存目录层级别太深，key设计决定效率
缓存key的组成方式直接影响查找速度和命中率,很多运维喜欢在key里拼上用户ID，结果同一部电影被几万个用户ID拆成几万份缓存，命中率直线下降。
正确的做法是：
- key由ID + 码率 + 切片序号”组成，不掺入用户维度
- 目录层级控制在两层以内,
/video/{contentId}/{bitrate}/seg_{index}.ts - CDN节点上关闭查询参数参与缓存key,防止
?token=xxx这类参数把缓存打散
这样改完之后,缓存存储从“按用户存”变成“按内容存”，存储利用率提升，源站压力自然也降了。
CDN缓存源站带宽的消峰逻辑，到底靠什么生效？
CDN边缘节点是源站的第一道防线,源站带宽要减压，关键在于让边缘节点承担尽可能多的流量，同时把回源流量控制在源站的带宽红线以内。
命中率多少才算健康？分场景看数字
据统计,点播平台的CDN缓存命中率普遍在85%到95%之间属于健康区间，如果低于80%，说明缓存策略存在明显问题，源站带宽会长期处于高压状态。
影响命中率的主要因素有三个：
热度分布：长尾内容占比过高，命中率必然下降
- 缓存过期时间：刷新太频繁，回源次数增加
- 边缘节点容量：节点存储不够，缓存被频繁挤出
排查命中率低的问题时,建议先看节点日志里回源请求的分布，业内专家指出，90%的命中率问题都出在key设计或过期时间配置上，不需要动架构。
边缘节点容量怎么规划？按峰值流量留余量
节点磁盘至少要能容纳3到7天的热门内容总量，如果平台每日活跃内容量约为10TB，那单节点存储设计在30TB到70TB之间比较稳妥，容量太小，缓存频繁淘汰，回源流量反而暴增，带宽省不下来。
不同规模平台的规划参考：
| 平台日活规模 | 建议单节点缓存容量 | 缓存预留时长 |
|---|---|---|
| 中小型平台（10万以下） | 5TB-10TB | 3天 |
| 中型平台（10万-50万） | 10TB-30TB | 3-5天 |
| 大型平台（50万以上） | 30TB以上 | 5-7天 |
存储规划不是越大越好,容量翻倍意味着成本翻倍，关键是保证热门内容的覆盖时长足够长。
点播系统源站带宽优化：具体配置和淘汰策略怎么落地？
缓存配置不能只停留在概念层面,要落到具体的参数和操作路径上。
Nginx层缓存配置示例，直接照抄可用
对于自建点播系统的团队,Nginx的proxy_cache模块是最常见的缓存实现，下面是一组经过实践验证的配置：
proxy_cache_path /data/cache levels=1:2 keys_zone=video_cache:10g max_size=50g inactive=7d;
server {
location /videos/ {
proxy_cache video_cache;
proxy_cache_key "$uri";
proxy_cache_valid 200 7d;
proxy_cache_valid 404 1m;
proxy_set_header Host $host;
proxy_pass http://origin_server;
}
}关键参数说明：
- proxy_cache_valid 200 7d：正常响应缓存7天，过期时间根据内容更新频率调整
- inactive=7d：7天内未被访问的缓存自动清理，防止存储浪费
- proxy_cache_key
：只用URI作为key，保证同一切片所有用户共享缓存
淘汰策略：LRU是底线，但别忽略主动刷新
边缘缓存的淘汰机制普遍使用LRU（最近最少使用）算法，但仅仅依赖LRU不够，热门内容的上新和下线有自己的节奏，需要配合主动刷新接口：
- 转码任务完成时,主动向CDN节点推送预热请求下架时，调用刷新接口清除对应缓存，避免错误内容残留版本更新时，只刷新指定目录，不要全站刷新
这样做能让缓存内容与源站实际内容保持一致,避免用户拿到旧版本，同时减少无意义的回源验证请求。
回源保护策略：把突发流量挡在源站门外
缓存命中率再高,也会有回源请求，回源激增通常发生在热点内容瞬间爆发或者缓存刚被清空的场景，如果没有回源保护机制，源站带宽可能直接被打满，接口超时、播放失败等问题接踵而至。
回源限速：给源站带宽留出安全冗余
源站带宽是按峰值付费的,回源流量必须严格限制。
- 在源站前置的负载均衡器上设置单IP回源带宽上限
- 配置回源QPS限制,超出阈值直接返回503，让CDN节点重试
- 设置回源超时时间为2到3秒,超时立即切换备用源站
举个例子,源站带宽10Gbps，回源限速设为总带宽的60%（6Gbps），剩余40%预留给管理操作、备份和突发调度，这样即使CDN出现异常，源站也不会被拖垮。
合并回源：减少重复请求，效率翻倍
多个边缘节点同时回源请求同一个切片时,源站可以合并这些请求，只回源一次然后分发，这在点播场景里非常常见，比如同一部热播剧更新后，区域内的多个CDN节点几乎同时请求新切片。
实现方式有两种：
- 源站侧开启请求合并功能，同一切片同时到达的重复回源只处理一次
- 边缘节点之间开启兄弟节点互备，优先从邻近节点拉取内容，而非直接回源
合并回源能显著降低源站的并发连接数,对带宽减压的作用仅次于命中率提升。
缓存预热与多级调度：把边缘节点用到极致
缓存设计的终极目标是让用户请求在离自己最近的节点就被完全消化,这要求内容能提前到达用户附近，而不是等用户点击后才去源站拉取。
预热策略：热门内容先上车，用户点击零等待
预热需要结合内容运营数据来做,不能无差别预热所有内容，建议按以下优先级操作：
- ：预计播放量高的新片、独播剧，提前分发到全部边缘节点
- 区域热点：根据地域用户的观看偏好，把相关内容预热到对应区域的节点
- 定时任务：每日凌晨低峰期批量预热当天待上线内容，不占用高峰带宽
预热操作要在转码完成后立刻进行,不要等到用户访问时才回源拉流。
多级缓存架构：边缘、区域、源站三层联动
大型视频平台普遍采用三级缓存架构：
- 边缘层：直接服务用户，缓存热门内容
- 区域层：汇聚区域内多个边缘节点的回源请求，提供次级缓存
- 源站层来源，只需要承担极少量的回源流量
这种架构的价值在于,边缘节点未命中的请求会先打到区域层，区域层也没有才会到源站，以热播剧为例，边缘未命中的请求在区域层有九成以上概率直接命中，源站实际承受的压力非常小。
对于自建点播系统的团队,建议至少保持两层架构，即边缘节点直接回源，同时配置内存级缓存模块作为二次缓存，让同一节点内的重复请求不穿透到源站。
Q&A：视频点播缓存设计与源站带宽常见问题
视频点播缓存命中率多少算正常？
点播平台的缓存命中率正常范围在85%到95%之间，低于80%说明缓存策略需要调整，优先检查缓存key是否掺入了用户维度参数，以及过期时间是否设置过短，命中率达到95%以上则说明缓存策略运行良好，源站带宽已经接近最优状态。
缓存key设计失误导致命中率暴跌，该怎么快速修复？
先通过CDN日志分析回源请求的URL规律,确认是哪些参数导致缓存key分散，然后在配置中删除这些参数，修改后观察一小时的命中率曲线，如果回到正常区间，再逐步清理旧的分散缓存，修复期间源站带宽可能短暂升高，建议同时开启回源限速保护源站。
源站带宽突然打满，如何快速定位是不是缓存配置问题？
登录CDN节点查看命中率曲线,如果峰值时段命中率明显下降，说明缓存配置出了问题，立即检查缓存过期时间是否被误改，如果命中率正常但源站带宽依然打满，可能是回源限速配置失效或出现恶意请求，需要检查源站访问日志中的异常IP和URL，同时确认CDN的回源链路是否出现故障导致全部请求穿透到源站。