视频点播卡顿时应优先扩容存储还是计算？

视频点播出现卡顿，优先扩容存储还是计算，不能只看磁盘剩余容量。视频点播存储与计算分离后，视频文件保存在对象存储，转码、切片、鉴权等任务运行在独立的计算资源上；两者可以分别扩容，但卡顿也可能来自网络、缓存命中率、播放器缓冲策略或源站连接数。

因此，正确顺序是先定位瓶颈，再做针对性扩容。把“存储不够”和“计算不够”混为一谈，可能只增加成本，却无法改善观看体验。

先判断卡顿发生在哪个环节

一段视频从上传到播放，通常要经过文件写入、转码处理、分发读取和终端缓冲。不同环节的异常，表现并不相同。

如果播放器已经拿到连续片段，但解码或转码任务仍在排队，扩容计算更有价值；如果转码早已完成，播放请求却频繁等待数据，则应关注存储吞吐和分发路径。

什么情况下应优先扩容计算

典型信号

转码集群适合处理多清晰度输出、音视频封装、截图和切片。出现以下信号时，计算资源通常是第一嫌疑：任务排队时间持续升高；CPU长时间接近满载；单个视频处理时间明显超过视频时长；失败任务集中在高峰时段；新内容完成上传后，较长时间仍没有可播放版本。

例如，一个在线课程平台在晚间集中上传讲座，源文件需要生成适合网页、移动端和低带宽网络的多个版本。如果对象存储写入正常，但转码队列从几分钟扩大到几十分钟，增加计算实例、并行任务数或采用独立的转码队列，比扩容存储容量更直接。

计算扩容的优缺点

• 优点：可以缩短转码等待时间，减少处理任务互相排队，适合上传高峰和批量内容生产。
• 缺点：计算实例通常按运行时间或资源规格产生费用；若卡顿实际来自回源或带宽，扩容后观看端问题仍然存在。
• 适用条件：监控能够证明CPU、内存、任务并发或处理队列达到瓶颈，并且播放所需文件尚未及时生成。

什么情况下应优先提升存储能力

存储问题不等于“容量快满”。对象存储还有请求频率、单连接吞吐、并发读取、跨区域访问和小文件数量等限制。视频点播存储与计算分离的价值之一，就是让存储读取性能不必与转码任务共享同一块本地磁盘；但分离后仍需确认存储服务是否能承受播放高峰。

当转码任务已经完成，视频索引和播放清单也能正常返回，而播放器在加载后续片段时反复等待，通常应检查对象存储读取延迟、源站出口、缓存命中率和回源并发。冷门视频首次播放慢、热门视频稳定播放，往往说明缓存策略或回源路径比存储容量更值得优先处理。

存储扩容与优化的边界

• 扩容容量：适用于容量接近配额、备份副本增长或版本文件长期保留的场景，但不会自动提高读取速度。
• 提升吞吐：适用于大量用户同时读取不同视频，需调整对象存储规格、分区策略或并发配置。
• 优化分发：适用于重复观看明显的内容，可通过缓存热门片段、减少不必要回源来降低源站压力。
• 减少小文件压力：切片过短会增加请求次数；切片时长需要在首屏速度、拖动体验和请求开销之间平衡。

视频点播存储与计算分离的排查步骤

1. 复现并分层记录：分别记录上传完成时间、转码完成时间、首片段返回时间和播放中断位置，同时区分高峰与低峰。
2. 检查计算侧：查看任务队列、CPU、内存、并发数和失败重试。若排队持续增加，先增加转码工作节点或限制单任务占用。
3. 检查存储侧：查看读取延迟、吞吐、请求错误率和并发连接。容量正常但读取慢时，不要只购买更大容量。
4. 检查分发侧：对比缓存命中和回源请求，确认是否存在跨区域读取、源站连接耗尽或出口带宽不足。
5. 小范围验证：先为一组视频增加计算节点或调整存储、缓存参数，观察一个完整高峰周期，再决定是否全面扩容。

一个更稳妥的决策原则

若“视频还没准备好”，优先扩容计算；若“视频已经准备好但拿得慢”，优先优化存储读取和分发；若两者都正常而终端仍卡顿，则检查网络质量、播放器缓冲和设备解码能力。对于长期运行的平台，建议把转码集群、对象存储和分发服务设置独立告警，避免用单一的磁盘容量指标判断整体健康度。

最终，视频点播存储与计算分离并不是要求永远只扩容一侧，而是让每次扩容都对应明确的性能证据。先定位，再扩容，通常比同时堆叠资源更节省成本，也更容易验证效果。

常见问题

1. 存储容量不足会直接导致播放卡顿吗？

可能会，但通常先表现为写入失败、转码输出无法保存或新内容不可用。容量充足而读取延迟高时，原因更可能是吞吐、请求并发或分发链路。

2. 增加转码服务器能解决所有卡顿吗？

不能。它主要解决处理排队和输出生成慢的问题，对已经完成转码的视频回源慢、网络抖动或播放器缓冲不足没有直接作用。

3. 什么时候应该先优化缓存？

当热门视频重复播放较多、缓存命中率偏低且源站回源请求集中时，应先优化缓存和回源策略，再考虑购买更多存储或计算资源。

4. 分离架构是否一定更便宜？

不一定。它提高了独立扩容和故障定位能力，但对象存储请求、跨区域流量、转码计算和备份都会产生相应成本，需要结合访问模式核算。