晚高峰点播平台卡顿，答案很明确：先查调度，再查带宽，绝大多数卡顿事故，根源不在带宽不够，而是调度系统没把用户引到最优节点。
为什么这么说？因为带宽是"存量"，调度是"效率"，你带宽再大，调度把用户分到了拥堵链路或故障节点，体验照样崩塌，反过来，调度精准的情况下，即便总带宽没有冗余，用户也会被分散到多个健康节点，卡顿概率大幅下降，这个逻辑，所有做过CDN调优的人都懂，但很多运维新人一遇到卡顿就慌着找运营商加带宽，方向从一开始就偏了。
晚高峰视频卡顿是什么原因？先分清两个角色的分工
要搞清楚先查什么,得先弄明白带宽和调度各自管什么。
什么是调度它是整个系统的"交通警察"
调度的核心职责,是把用户请求分配到最优节点，这个"最优"包含很多维度：节点负载、链路质量、物理距离、缓存命中率、节点健康状态，晚高峰的流量洪峰，考验的正是调度系统在极端负载下的决策能力。
行业共识认为,调度系统在晚高峰面临的主要挑战有三个：
- 节点负载不均集中在少数节点，调度未能及时将流量引导至空闲节点
- 链路探测失真：动态探测间隔过长，调度依据的是几分钟前的网络状态
- 故障节点未摘除：某个节点已经处于半死状态，调度还在往里面派流量
什么是带宽它是系统的"道路宽度"
带宽是物理资源,决定了单位时间能传输多少数据，晚高峰的带宽瓶颈往往表现为：总出口带宽打满、源站带宽被打爆、某条长途链路拥塞。
这里有一个容易被忽略的事实：晚高峰卡顿，相当一部分情况是调度问题伪装成带宽瓶颈，怎么识别？看带宽利用率曲线，如果带宽利用率还有余量但用户仍然卡顿，问题几乎可以断定在调度侧。
怎么判断晚高峰点播卡顿是调度问题还是带宽问题？看这三个特征
不需要复杂的工具,先看现象就能有个七成判断。
卡顿是全局性的还是局部性的
全局卡顿,所有用户、所有地区都卡优先查源站带宽和总出口带宽，局部卡顿，某个省份、某个运营商的用户卡，其他地区正常先查调度策略。
实操方法：打开监控后台，按省份、运营商筛选卡顿率，如果只有某个运营商的所有用户都卡，十有八九是跨网调度策略出了问题，如果只有某几个城市卡，再看是节点故障还是链路拥塞。
卡顿的时间点是"准时"还是"随机"
准时卡顿,比如每晚8点准时开始、10点自动恢复，调度问题的嫌疑更大，因为流量增长曲线是平滑的，调度系统如果响应不及时，会在流量达到某个阈值时突然劣化。
随机卡顿,比如白天也偶尔卡，晚高峰只是更频繁，则可能是带宽或链路质量问题，这种情况通常在晚高峰被放大，但根源在白天就已经存在。
画质档位的变化模式
点播平台普遍有自适应码率机制,用户自动降到标清且无法恢复回高清说明调度分到的节点虽然能播，但不足以支撑高清码率，用户手动切到高清后一直转圈说明节点本身容量不足或链路拥塞。
这个区别很关键,前者是调度分配保守了，后者是节点或链路真的扛不住。
点播平台CDN调度策略怎么排查？一个老运维的实操顺序
第一步：确认调度配置有没有被改动
任何卡顿排查,先看变更记录，调度策略的权重大小、回源比例、节点上下线操作，任何一项改动都可能引发连锁反应，特别是晚高峰前两小时内改过配置的，直接回滚再看效果。
第二步：核对节点健康状态
进入调度管理后台,逐个检查节点状态，重点关注两类节点：
- 处于"已下线"但仍在接收流量的节点这说明摘除操作没生效或延迟生效
- 负载超过80%但权重没调低的节点调度系统没有根据负载动态调整分配比例
第三步：看调度命中率和回源压力
调度命中率这个指标,反映的是"客户端最终是否请求了调度系统指定的节点"，注意，不是缓存命中率，是调度指令的落实率。
调度命中率低于一定水平,就会触发"羊群效应"大量用户回源，源站带宽被打爆，然后表现为全局卡顿，此时你查带宽一定显示源站带宽打满，但问题本质是调度指令失效。
第四步：对比不同地区调度结果是否均衡
整理一份按省份统计的"用户实际接入节点分布表"，和预期调度结果做对比，如果浙江的用户被调度到了北京节点，而离浙江更近的上海节点负载很低，这就是调度策略的明显异常。
点播平台带宽费用太高怎么优化？当带宽确实不够时的正确做法
如果排查完调度没问题,带宽也确认打满了，这时候才轮到带宽扩容，但扩容之前，先做这三件事：
削峰填谷，把晚高峰流量摊平
点播场景有一个天然优势：用户对内容的容忍等待时间比直播长，利用这个特性，可以做预加载和边下边播的协同优化，在流量低谷期（比如凌晨）将热门内容预热到边缘节点，减少晚高峰的实时回源流量。
热度，差异化分配带宽资源
热门剧集新上线）和长尾内容（老剧、冷门纪录片）的带宽策略要分开，头部内容做全节点覆盖、冗余保障；长尾内容集中存储在区域中心节点，边缘节点按需回源。
很多平台在这一点上做反了所有内容同等对待，结果热门内容频繁打爆节点，冷门内容白白占着空间。
跟CDN服务商重新谈带宽计费模式
付费模式选择上,点播平台晚高峰卡顿问题往往和计费模式有间接关系，如果你签的是按月95计费或按流量峰值计费，运营方会倾向于保守调度把用户尽量往少数优质节点集中，来降低带宽成本，这种策略在平时没问题，但晚高峰流量洪峰时，节点很容易被打满。
改用按请求数计费或按实际流量计费的模式,配合更激进的动态调度策略，相当于用更低的成本换取更大的调度空间。
常见误区和避坑指南
卡顿就开临时带宽
临时带宽的开通需要时间,等你联系完运营商、走完流程，晚高峰早就结束了，而且临时带宽只解决当下问题，不解决调度策略的长期缺陷，多次开启临时带宽，说明系统核心问题一直没被正视。
只盯平均带宽利用率
调度系统做容量规划时,要把目光放在P99带宽利用率而非平均值上，平均利用率60%看起来安全，但P99可能已经打到95%，意味着有1%的节点在极限运行，晚高峰流量波动加大，这1%会被放大成全局卡顿。
忽略运营商之间的互联互通
同一地区,联通用户不卡、移动用户卡，这是跨网调度问题的典型表现，调度策略需要针对不同运营商做差异化配置，不能一视同仁。
一张表看懂先查什么后查什么
| 排查顺序 | 检查对象 | 关键指标 | 异常判定标准 | 处理优先级 |
|---|---|---|---|---|
| 1 | 调度配置变更记录 | 最近2小时是否有改动 | 有改动 | 立即回滚 |
| 2 | 节点健康状态 | 在线率、负载率 | 负载>80%且仍有流量进入 | 调整权重或摘除 |
| 3 | 调度命中率 | 实际接入节点和调度指示是否一致 | 命中率显著低于历史水平 | 排查客户端SDK和调度接口 |
| 4 | 各地区调度均衡度 | 用户分布和节点容量是否匹配 | 出现明显的"舍近求远" | 更新调度策略 |
| 5 | 带宽利用率 | 出口带宽、源站带宽 | P99>95% | 考虑扩容或优化 |
按这个顺序排查,动作最快、损耗最小、定位最准确。
晚高峰卡顿问题会和调度系统一起解决
回到最初的问题：先查调度还是先查带宽？顺序不只是排查路径的选择，更是一种思维方式先优化系统效率，再考虑加资源，调度系统优化到位，很多"看起来需要带宽"的场景其实根本不需要，据统计，多数点播平台在完成调度策略优化后，带宽成本降低的同时卡顿率也显著下降，这足以说明问题。
下一次晚高峰再出卡顿,别急着给运营商打电话，先打开调度后台，看一眼节点负载和调度命中率，答案往往就在这里。