高并发点播场景下，转码队列的调度核心在于“分级排队、动态优先级、弹性伸缩”三件事：先按业务类型分队列，再按用户权重和时效性动态调优先级，最后结合资源水位自动扩缩容。
点播转码队列为什么经常卡成“堵车现场”
视频点播平台最怕的不是上传量大，而是几十个视频同时进转码队列，后面排队的用户不断刷进度条，转码本身是CPU密集和IO密集的混合任务，一个1080P视频转成多码率HLS，可能要跑几分钟到几十分钟，如果所有任务都塞进同一个队列，先进先出,那么一个4K长视频就能把后面所有短视频堵死。
行业共识认为，转码队列调度最核心的矛盾是“吞吐效率”和“实时性”的博弈，批量转码追求高吞吐，但点播用户上传后往往希望尽快看到成片；短视频追求秒级出片，长视频则更看重稳定性，用同一个队列、同一种策略,必然顾此失彼。
转码队列调度第一步：按业务类型拆分成多级队列
为什么单队列一定不够用
假设你的点播平台同时承载UGC短视频、付费长视频、直播回放、课程录播四类业务，它们的码率规格、转码复杂度、时效要求完全不同，混在一个队列里，调度器只能按入队时间挨个处理，短视频上传后可能要等长视频跑完,用户体验会非常差。
实际拆分方法：四类队列模型
- 快速队列：负责短视频、动态封面、GIF生成，任务时长控制在1分钟内,并发数固定较高。
- 标准队列：负责常规视频转码，比如720P/1080P多码率输出,采用加权轮询调度。
- 批处理队列：负责4K、8K、HDR等重负载转码，允许排队时间较长,优先利用闲时资源。
- 紧急队列：用于VIP用户或版权限时上架的内容,可以抢占其他队列的空闲节点。
拆队列不等于简单分桶，关键在于每个队列有独立的调度参数，比如快速队列的并发线程数可以设置为核心数的2倍，批处理队列则控制在1.2倍左右,避免资源争抢。
高并发点播转码方案里的优先级怎么动态调整
拆完队列还远远不够队列内部的优先级必须能动态变化，静态优先级（比如VIP永远优先）会导致普通用户的任务无限期积压，行业内成熟的思路是“综合优先级 = 用户权重 × 等待时长系数 × 任务紧急度”。
用户权重：不能只看有没有充钱
用户权重应该参考三个维度：
- 账号等级（VIP、普通用户、内部测试号）
- 历史转码请求频率（高频用户权重适当降低,防止刷量）
- 当前并发占用（已提交大量任务的用户降低权重,避免饥饿）
等待时长系数：防止饿死
每个任务在队列里每等待10秒，紧急度增加一个档位，设计上可以这样：计算每个任务的等待得分，超过设定阈值（比如300秒）直接提升优先级，甚至跨队列迁移，比如批处理队列里等太久的短视频,自动迁移到快速队列。
任务紧急度：业务规则说了算
- 付费用户上传的“预告片”“首发剧集”紧急度最高
- 平台运营标记的活动视频，需要在指定时间前完成转码
- 普通UGC内容紧急度最低，但等待超时后也会自动升级
实际调度时，可以用一个简单的公式：调度优先级 = 用户权重×0.4 + 等待系数×0.4 + 紧急度×0.2，每10秒重新计算一次，只对队头前20个任务重排序,避免全局扫描消耗过多CPU。
转码队列优先级调整到底怎么落地
很多开发者问：转码队列优先级调整有没有现成的操作路径？ 取决于你的技术栈，如果你用开源的FFmpeg + 自研队列,通常有几种做法：
基于Redis ZSet的设计示例
用Redis的有序集合（ZSet）作为队列结构，score就是综合优先级得分,伪代码如下：
// 任务入队，score = 初始优先级 ZADD transcode_queue score task_id // 每10秒更新等待任务score，等待越久score越低（ZSet默认升序，取score最小的先出队） ZINCRBY transcode_queue -10 task_id // 调度器从队头取前N个任务分发到Worker ZRANGE transcode_queue 0 20
这种方式实现简单，能支撑每秒几千个任务入队，但如果你的并发量到了万级甚至十万级转码任务，建议改用消息队列（Kafka/RabbitMQ）配合分片队列。
消息队列里的分区调度
在Kafka里每个业务类型建一个Topic，每个Topic再分多个Partition，调度器按消费组订阅所有Partition，但对不同Partition设置不同消费并发线程数，比如紧急队列的Partition分配16个消费线程，标准队列只给4个，这本质上就是调度的“软优先级”实现。
借助容器平台自动扩缩容
如果业务量波动大，建议把队列调度和K8s HPA（Horizontal Pod Autoscaler）绑定，监控队列积压深度和平均等待时间，超过阈值就自动扩容Worker Pod。高并发点播转码方案中，弹性扩缩容比任何调度算法都有效，因为QPS再高，只要Worker充足,队列就不会成为瓶颈。
资源竞争和排队溢出怎么处理
即便调度做得再好，也会遇到突发流量把队列打满的情况,这时需要有两个兜底策略。
拒绝策略：让用户感知到“排队”
队列长度超过上限后，新任务不要直接丢弃，而是返回“排队中”状态码，客户端轮询任务状态，展示“预计等待X分钟”。这是产品层面的调度配合,不要让用户傻等。
降级转码：牺牲画质换速度
对于非核心业务，可以临时降级转码参数，比如把原本要转3个码率（1080P、720P、480P）降级为只转720P和480P，减少单任务耗时，快速释放队列,等低峰期再补转1080P版本。
下表对比了两种降级策略的适用场景：
| 策略 | 适用场景 | 优点 | 代价 |
|---|---|---|---|
| 拒绝入队+告知等待 | 重要业务、付费用户的转码任务 | 透明可控，体验一致 | 用户可能流失 |
| 降级转码参数 | UGC海量视频、批量上传 | 高吞吐，不积压 | 初始画质低，需二次补转 |
点播系统转码性能优化：从调度延伸到执行层面
调度只能解决“先做哪个”，真正提升整体吞吐还得靠执行层优化,这里给出三个立竿见影的点：
- 预设转码模板：提前在配置中心定义好各业务的码率、分辨率、编码格式模板，任务入队时直接关联模板ID,省去每次解析参数的开销。
- 分段并行转码：像FFmpeg的Segment切片，把长视频切成10秒的片段，多Worker并行转码，最后拼接,调度器只需负责分片任务的分发和聚合。
- 硬件加速：使用Intel QSV或NVIDIA NVENC做硬编，转码速度比软编快3-5倍，对于批量转码,硬编能显著减少队列等待。
视频转码排队太久怎么办？实际操作清单
很多人搜索“视频转码排队太久怎么办”，其实排查思路很固定,按以下步骤操作：
- 打开监控面板，查看当前队列积压数和Worker负载，如果Worker CPU低于70%而队列积压多,检查调度器是不是在空转。
- 确认是否有多队列抢资源，看紧急队列和批处理队列是否在互相争抢CPU,必要时用cgroup限制批处理队列的CPU份额。
- 检查单任务转码耗时是否异常拉长，用
ffprobe看源视频参数，如果源视频GOP设置过大或编码级别（profile）过高,提前做预处理优化。 - 评估存储IO瓶颈，转码过程大量读写临时文件，如果磁盘IO超过80%，再好的调度也无济于事,优先升级SSD或改内存盘。
转码队列调度怎么选型：自研还是买云服务
如果你的团队没有专职视频架构师，直接使用云厂商的点播服务会省心很多，简米云、酷番云、AWS的转码服务都内置了多队列和优先级管理，你只需要调用API传入Priority参数，百度智能云也能实现自定义转码队列，按需购买转码包和并发单元,适合中小平台快速上线。
自研适合有高并发要求且技术积累强的团队，优势在于可以精确控制调度策略，跟业务强耦合（比如根据用户地区实时调整编码码率），缺点是维护成本高，尤其是遇到高峰期扩容的时候，多数情况下，先用云服务跑通业务，等量级上来再迁移自研是性价比最高的路径。
Q&A：点播转码调度常见问题解答
转码队列的并发数和Worker数量怎么评估？
按实际业务量估算，一般规则是：每个视频转码任务在软编下约占2个vCPU，硬编约占0.5个vCPU，若高峰期同时有100个任务在转，软编需要200个vCPU，减去其他业务开销，建议预留20%余量,即250个vCPU。
队列调度算法用FIFO还是加权公平队列？
不同业务混跑时必须用加权公平队列，纯FIFO只适合同质化任务场景，因为少数长任务会阻塞短任务，加权公平队列中，长任务分配的权重低，短任务权重高，能保证整体平均等待时间最短，具体实现可以参照Linux CFS调度器的虚拟运行时间算法，用vruntime作为排序依据。
转码任务迁移到另一个队列会导致重复转码吗？
不会，前提是你把任务状态设计成多阶段，入队后立即落库，调度器只是修改任务的queue_id和priority字段，Worker真正执行时只从任务表读取转码参数，与队列无关，需要注意的是，迁移前要释放原队列占用的内存和文件句柄,防止泄漏。