晚上十点, 一套 12P 的系列视频传到第 7P 突然卡住, 重试两次都停在同一个位置, 第二天只能请假在家补传。做 B 站矩阵的人对分P 上传都不陌生, 而分P 上传对代理IP 出口的要求, 比单P 视频苛刻得多——多P 视频是 B 站的特色结构, 每一P 都是独立的上传任务, 出口一抖, 整段上传就断。
分P 上传的链路结构
分P 视频的每一P 都是一个独立的上传任务, 每一P 都要走一遍「文件上传、转码、状态确认」的完整流程。上传时, 每一P 的请求都跑在当前代理IP 出口下, 出口带宽是有限的, 多P 上传等于把带宽切成好几份, 每一P 分到的带宽都变少, 上传速度整体变慢, 这是分P 视频比单P 视频更容易传一半卡住的原因之一。
各P 的状态管理
分P 视频还有一个单P 没有的问题: 各P 上传完成后, 要逐P 确认转码状态, 转码完成的P 可以单独编辑, 没完成的P 只能等。状态确认请求走代理IP 出口, 出口不稳时, 状态拉取失败, 有的P 显示转码中很久, 你以为是平台转码慢, 实际是状态通道的问题。
分P 上传的失败恢复也和单P 不同: 单P 失败重传一次就完, 分P 失败要先理清楚”哪几P 传成功了、哪几P 没传”, 理不清楚就容易整段重传, 浪费时间。建议每传完一个 P, 把状态记下来, 失败时只补失败的那几 P。
分P 上传的四步排查
- 上传前确认代理IP 出口在线: 上传开始前先验一次出口连通性, 断开就先恢复再传, 不要带着断连隐患开工
- 逐P 验证: 不要一口气传完全部P, 每传完一个P 确认状态正常再传下一个, 卡住的位置一目了然
- 观察出口切换时间点: 某P 卡住的时刻是否对应一次代理IP 出口切换, 对应上了就先稳定出口再重传
- 固定出口重传: 重传失败的分P 用原出口重试, 只重传失败的那一P, 不要整段视频从头再来
多P 与单P 上传的差别
单P 视频上传失败, 重传一次就好; 多P 视频上传失败, 要面对的是「哪几P 传成功了、哪几P 要重传」的核对。矩阵账号批量传分P 视频时, 多个账号的分P 任务叠加, 出口带宽被严重分摊, 更要把上传时段错开, 一个账号一个账号地传, 不要几个账号同时传大文件。
分P 上传还有一个时间成本问题: 多P 视频动辄几十分钟到几小时的上传时长, 上传期间一旦代理IP 出口切换, 正在传的那一P 前功尽弃。所以分P 视频的上传, 一定要在出口完全稳定的窗口里进行, 上传开始前确认出口地区与账号业务地区一致, 上传全程不切换出口, 这是分P 上传最基本的要求。
矩阵账号做系列内容, 分P 视频是常态, 一星期可能要传好几套。上传窗口要提前规划: 选在出口空闲的时段, 比如上午或下午, 避开晚高峰; 上传前把视频文件准备好, 上传过程中不做其他大流量操作, 让代理IP 出口的带宽全部留给上传。
把分P 上传当成一个小工程来安排, 代理IP 出口的规划就顺了: 上传窗口固定、出口全程稳定、逐P 确认状态、失败只重传单P, 四条做到, 12P 的视频也能一次传完。
还有一个小细节: 分P 视频的每一P 可以单独设置标题和封面, 这些编辑操作是写操作, 也要走代理IP 出口。整段视频传完后, 逐P 编辑标题封面时, 出口同样要稳住, 别在编辑到一半的时候切出口, 保存失败要重新编辑。