随着人工智能、云计算等技术的快速发展，工业互联网、元宇宙等新模式不断涌现，算力成为重要生产力并开始与网络深入融合，“算力网络（computing power network）”应运而生. 它通过将各种计算节点互联统筹调度，提供算力分布在全部网络节点的一体化信息基础设施，能够实现计算和网络资源的优化和高效利用^[1-2]. 近几年，算力网络相关技术的发展在全球被普遍关注. 例如，美国计划建造各种算力设施构成的国家级计算生态系统^[3]；欧盟提出大力发展云计算、构建安全高效可持续数字基础设施的指南^[4]；而我国为了推动“新基建”战略实施，由四部委联合发布文件启动 “东数西算”和大数据枢纽节点建设工程^[5]. 尽管当前国内外对于构建和运营国家级算力网络的基础设施刚起步，这些政策正在有效推进网络运营商和云服务商探索算力网络应用于各领域业务场景^[6-9].

算力网络主要适用于计算密集型业务，目前最常见的是大规模数据处理场景，例如超级计算、人工智能训练、区块链应用等. 而各种流行的智能应用（智能驾驶、智能制造）和泛视频类业务（视频直播、VR/AR、云游戏等）在高性能算力需求的基础上，要求网络提供实时性和可靠性保障. 在超高清视频（4K/8K）直播时，连续数据流传输还会对网络带宽提出很高需求. 由于互联网无法保证算力节点间传输时延和带宽确定性，将算力网络应用于这类对时间敏感的计算密集型业务存在巨大挑战. 对此，当前国内三大网络运营商和阿里巴巴集团控股有限公司、腾讯计算机系统有限公司等云服务商都在构建视频业务专网，中国移动还进一步发布了算力网络视频应用白皮书^[10]. 这些初步探索为基于算力网络的视频传输指出发展方向，然而并未对“如何有效协同服务商间异构算力节点进行高效视频分发”这个关键问题进行充分研究和系统验证.

在典型的视频直播场景，视频流从直播源上传到一个摄取服务器（ingest server），再通过视频应用商部署的内容分发网络（content delivery network，CDN）传输到位于不同地理区域的服务器节点，方便终端用户就近获取视频流以减少播放时延. 为了根据用户网络带宽状况适配性调整码率，需要在传输过程中完成实时视频转码（transcoding）. 当CDN服务器节点普遍具有足够算力时，原本由摄取服务器负责的转码工作可以卸载（offloading）到视频分发阶段. 由于不同云服务商提供的节点所在区域和性能变化趋势有不小差异，利用多云节点协同处理视频分发能够有效增加区域覆盖并提升服务可用性，有助于保证视频直播的高实时性. 然而，各云服务节点的架构和性能配置有所不同，使得对应的算力也各不相同；同时节点间网络链路状况也经常变化不定，特别是不同云的异地节点间难以达成专网连通. 因此为了克服这些节点计算、网络的异构性和动态性，始终选择传输和转码综合性能最优的一组节点以实现低时延、高带宽的视频分发具有很强的挑战性.

针对上述需求和挑战，本文设计一套基于异构算力节点协同的高效视频分发方案：首先，为了合理规划直播源到目标用户的传输路径并选择处理视频转码的节点，通过在线获取分析各云服务节点的算力资源情况和节点间的链路状态，并结合视频流的实时传输流量变化，基于强化学习（reinforcement learning，RL）模型快速决策选取各视频块传输和转码节点集合. 相比于当前常用的由摄取服务器处理转码以及随机或轮询（round robin）选择传输节点等方案，这样可以尽可能使用性能最优的节点以最大化视频分发效率. 在此基础上，针对同时分发的不同视频间对计算和网络资源的竞争，通过采用优先级排队并自适应调整资源的调度机制来降低突发流量峰值导致的节点资源容量不足的风险. 此外，对于云服务节点设计分层日志同步容错机制，保证节点故障后快速恢复数据一致性. 这2个机制能够有效提升方案在实际环境中执行的弹性和可靠性.

为了验证方案的实际效果，本文部署多个云服务商全球分布式的异构算力节点，基于它们构建的CDN实现一个完整的视频分发系统. 大量超高清视频直播实验表明，采用此方案的视频分发性能相比常用的视频分发方案有明显改进（视频传输码率平均提升18.3%，视频块处理时延平均降低25.2%）. 该方案不仅满足高实时性需求的视频直播，也适用于视频点播（video on demand，VoD）、泛视频类应用（如VR/AR和云游戏）等涉及视频分发过程的场景.

本文的主要贡献包括3个方面：

1）通过全面测量和调研，发现各云服务节点间网络链路状态存在不稳定性，并且这些异构的节点在算力上有很大不同，它是基于算力网络的视频分发面临的主要挑战（见第2节）；

2）设计基于异构算力节点协同的高效视频分发方案，利用强化学习决策出性能最优的传输和转码节点来最大化分发效率，通过对不同视频分发任务采用优先级排队调度并自适应调整节点资源，在节点间进行分层日志，同步保证在实际环境执行的弹性和可靠性（见第3节）；

3）基于多云服务分布式节点构建CDN，实现视频分发系统.通过大量视频直播实验，验证方案在平均传输时延、视频直播码率的传输性能明显优于常用视频分发方案（见第4节）.

1.   相关工作

针对本文的研究主题，本节对算力网络和视频应用这2方面的研究进展简要描述.

1.1   算力网络研究

算力网络从云网融合发展而来，更注重网络控制对云边端异构资源的管理和不同集群的协调，实现广泛的算力资源动态调度. 在国家最新发展规划^[11]的引领下，目前业界正积极推进算力网络的研究和发展，其中三大网络运营商作为主力军致力于相关产业布局和技术推广. 中国联通和中国移动分别发布《算力网络白皮书》^[6-7]，对算力网络的概念、架构等方面进行讨论，并提出发展愿景和演进策略. 中国电信确立了“云网一体”的战略方向，希望整合云网资源构建新型信息基础设施^[8]. 国内外标准组织也在积极制定相关标准. 如国际电信联盟电信标准分局在2021年通过算力网络框架与架构标准Y.2501^[12]. 中国通信标准化协会批准于同年设立工作组讨论算力网络技术及其应用，编制了系列行业标准，包括算力路由、算网编排等多个方面^[13].

算力网络的技术方案从网络架构角度可以分为集中式架构和分布式架构. 其中集中式架构方案分离控制平面与数据平面，在控制平面进行全局统一算网编排调度^[6-7]. 而分布式架构方案通过相邻路由节点间交互同步算网状态信息，采用网络层协议扩展方式实现路由节点决策计算任务控制转发^[14]. 目前学术界正在围绕算力网络前沿技术开展研究. 如确定性算力网络^[2]利用确定性网络技术实现计算任务的实时传输和计算. NSACS-PS^[15]借鉴命名数据网络的命名机制，实现算力服务的接入控制优化. 新型可扩展互联网^[16]支持网内泛在计算与内容就近响应，可以实现算网资源的融合利用.

1.2   视频应用研究

尽管算力网络当前被业界广泛关注，但目前相关视频应用的研究刚刚起步. 中国移动在算力网络通用架构的基础上针对泛视频业务设计了一种算力网络视频应用架构^[10]. 中兴通讯也推出面向全场景视频应用的视频算力网络架构和解决方案^[17]. 此外，当前业界普遍在构建视频专网，旨在为算力网络视频应用提供基础设施，如中国电信的天翼视联网、中国移动的公共服务视频网以及腾讯会议、Zoom等实时互动视频服务的网络支持.

除此之外，近年来学术界有很多视频应用研究工作. 其中最热门的研究集中在视频适配码率传输的优化. Pensieve^[18]、NAS^[19]等工作采用机器学习技术根据网络链路带宽情况决策传输使用的码率，然而这些研究主要应用于从服务器端下载整个视频的视频点播服务. Salsify^[20]、LiveNAS^[21]等工作提出针对视频直播场景的传输码率优化策略，但它们都未对直播过程中视频分发阶段给出优化方案. VDN^[22]提出一种集中式控制算法来优化CDN用于直播视频的分发性能. MP-DASH^[23]和XLINK^[24]分别基于多路径TCP和多路径QUIC技术增加视频传输到目标用户的路径数目进而改善用户体验质量，不过这些研究难以满足超高清视频直播的实时编码和传输需求. 此外，Jigsaw^[25]和Rubiks^[26]都设计了分层编码方式分别降低4K和360°视频的传输流量，但它们并未考虑编码和传输开销. 与上述研究工作不同，本文面向超高清视频直播场景，集成不同云服务的节点构成算力网络用于视频分发，基于强化学习、优先级调度、日志同步等技术协同异构算力节点进行高效传输和转码，有效提升现有视频分发方法的性能.

2.   视频分发中的算力网络应用

本节探索将算力网络引入视频直播的视频分发过程，调研和测量可用作算力节点的主流云服务节点在计算和网络上的性能情况.

2.1   视频分发的节点部署

图1描述了一个典型视频直播场景的端到端工作流程，它主要包括视频摄取和视频分发2个部分. 其中视频摄取是指从直播源（手机、电脑、网络摄像头等）将当前正在录制的视频流实时上传到摄取服务器的过程. 这里直播源和摄取服务器间一般采用专用的流传输协议，如实时流传输协议（real time streaming protocol，RTSP）或实时消息传输协议（real time messaging protocol，RTMP）等. 在目前流行的网络架构中，摄取服务器通常需要部署在具有充足计算资源的云服务节点上，负责将直播源上传的原始视频流按2~10 s的块转码成多种分辨率等级（如最常用的包括720p、1080p、4K等），以便后续根据观看直播的用户侧网络状况适配性调整播放码率，例如采用基于HTTP的动态自适应流传输（dynamic adaptive streaming over HTTP，DASH）技术^[27]. 在接下来的视频分发过程中，摄取服务器将转码后不同分辨率的视频块都通过CDN推送到服务用户的各分布式节点，用户按就近原则从访问时延最小的服务节点获取视频流，以尽量减少播放时延.

图  1  典型视频直播场景的端到端工作流程

Figure  1.  End-to-end workflow for a typical live video streaming scenario

下载: 全尺寸图片 幻灯片

设想如果CDN服务器节点都具有足够的计算资源，那么视频转码将不再局限于在特定的摄取服务器上完成，而是可以在视频分发的过程中卸载到相对闲置的服务节点；与此同时，摄取服务器不再有特殊的高资源配置要求，可以利用靠近直播源的云服务节点完成视频摄取，也为进一步降低整体传输时延提供机会. 为了实现这种设想，可以将算力网络用于视频分发过程，即部署一批具有一定计算能力的算力节点用作图1中CDN服务器节点. 对于视频服务商，按需租用云服务商的计算虚拟机实例相比购买物理服务器分布式部署有更高性价比.

事实上，国内主流云服务商（如阿里云、腾讯云和华为云）都提供不同大洲多个地理区域的计算节点实例（instance），特别有助于国内视频服务商支持全球直播. 表1给出了3种主流云服务商在国内外不同区域提供计算节点的情况. 从表1中可以看出，各云服务商计算节点位置分布呈国内密集、国外稀疏，且主要大城市（上海、新加坡）重合、某些大区域（非洲、南美洲）缺失的态势. 考虑到单个云的计算节点区域（特别是国外）有限，显然将不同云的节点集成使用可以有效增加覆盖密度，进而降低访问时延并提升服务可用性（例如集成上述3个云的节点以避免缺失大区域内邻近服务）.

表  1  3种主流云服务商在全球提供的算力节点的区域分布

Table  1.  Region Distribution of Computing Nodes Worldwide Provided by Three Mainstream Cloud Service Providers

云服务商	区域类别	节点位置集合
阿里云	国内	（华北）青岛、北京、张家口、呼和浩特、乌兰察布；（华东）杭州、上海、南京、福州；（华南）深圳、河源、广州；（西南）成都；（中国特区）香港
	国外	（亚洲）新加坡、吉隆坡、雅加达、马尼拉、曼谷、东京、首尔、迪拜、孟买；（欧洲）法兰克福、伦敦；（北美洲）硅谷、弗吉尼亚；（大洋洲）悉尼
腾讯云	国内	（华北）北京；（华东）上海、南京；（华南）广州；（西南）成都、重庆；（中国特区）香港
	国外	（亚洲）首尔、东京、新加坡、曼谷、雅加达、孟买；（欧洲）法兰克福、莫斯科；（北美洲）硅谷、弗吉尼亚、多伦多；（南美洲）圣保罗
华为云	国内	（华北）北京、乌兰察布；（华东）上海；（华南）广州；（西南）贵阳；（中国特区）香港
	国外	（亚洲）曼谷、新加坡、雅加达；（非洲）约翰内斯堡；（北美洲）墨西哥城；（南美洲）圣保罗、圣地亚哥

下载: 导出CSV 

| 显示表格

然而，一个重要问题是如何整合这些不同云节点的算力，协同用于视频分发服务. 表2给出了上述3种云服务商计算节点的几种入门级CPU、内存及GPU配置（对于普通计算型选择相同的CPU 4核内存8GB配置，对于GPU计算型选择各自的最低配置），可看出比较明显的CPU主频、GPU型号和单位价格差异. 值得注意的是，对于一个云服务而言并不是所有区域都有其全部节点配置类型可选. 事实上，各云服务不仅资源配置多样，在系统架构上也有很大不同，因此这些计算节点对应的算力也会各不相同. 此外，尽管一些云服务商内部设计了不同区域节点间的专网连通机制，如腾讯云联网（cloud connect network，CCN），然而这些云内专网的实际效果，以及更难以确定的不同云的节点间网络状况都有待进一步测试.

表  2  3种主流云服务商的几种典型资源配置

Table  2.  Some Typical Resource Configurations of Three Mainstream Cloud Service Providers

机型	实例规格	资源配置	按量价格/(CNY·h−1)
普通计算型	阿里ecs.c6.xlarge	4核vCPU@2.5GHz，8GB内存	0.78
	腾讯c6.large8	4核vCPU@3.2GHz，8GB内存	0.73
	华为s6.xlarge.2	4核vCPU@2.6GHz，8GB内存	0.73
GPU计算型	阿里ecs.gn5i-c4g1.xlarge	4核vCPU@2.5GHz，16GB内存，1*NVIDIA P4	9.69
	腾讯gn7.large20	4核vCPU@2.5GHz，20GB内存，1/4*NVIDIA T4	3.39
	华为g6.xlarge.4	4核vCPU@3.0GHz，16GB内存，1*NVIDIA T4	6.33

下载: 导出CSV 

| 显示表格

2.2   云服务节点性能测量

为了检验云服务计算节点实例的实际网络性能，这里选取国内最流行的2种云服务：阿里云和腾讯云，它们各在全球5个不同区域部署配置近似的节点实例（表2 中“阿里ecs.c6.xlarge”和“腾讯c6.large8”），对于节点的出入带宽都不设额外限制（最高可达各云服务提供的最大带宽）. 对于部署的各节点，采用Internet包探索工具（packet Internet groper，PING）在一周内不同时段测量两两之间往返时延（round-trip time，RTT）100次. 图2展示了具有代表性的8组节点间平均、最大、最小RTT的对比情况（按平均值由小到大排序，各节点标识中“A”和“T”前缀分别代表阿里云和腾讯云，后面的位置简称“SV”“SH”“NJ”“GZ”“HK”“VA”“BM”“FR”“SP”，分别表示硅谷、上海、南京、广州、香港、弗吉尼亚、孟买、法兰克福、圣保罗）. 需要说明的是，由于任意两个节点之间双向PING测量出的RTT基本一致，因此作为一个度量统计.

图  2  代表性云服务的算力节点间往返时延

Figure  2.  RTTs of representative cloud services’ computing nodes

下载: 全尺寸图片 幻灯片

从图2中可以观测到，部署在不同大区域的节点间时延很大且表现出高度不稳定性，如阿里云广州节点与腾讯云弗吉尼亚节点间（图2中“AGZ-TVA”）平均RTT超过300 ms且波动接近25 ms，与此前对AWS、Azure等国外云服务的测量结论^[28-29]一致. 除此之外，不同云在同一地理位置部署的节点间时延非常短，如阿里云和腾讯云硅谷节点间（图2中 “ASV-TSV”） RTT仅为3 ms；而各云内部临近区域部署的节点间时延也比较短，如腾讯云上海和南京节点间（图2中“TSH-TNJ”） RTT为10 ms. 对于某些节点间RTT较大的情况可以通过第三方节点中转数据有效降低时延，如通过腾讯云硅谷节点中转可以降低阿里云广州节点和腾讯云弗吉尼亚节点间RTT约26.2%. 考虑到这些测量中节点间都是通过公网连接，进一步将腾讯云节点通过内网IP配置云联网（仅支持国内节点连接）测试专网连通效果，最终发现，尽管搭建云联网的节点间的路由不同于此前公网连接路由，但所有这些节点间的RTT都并没有明显变化. 由于到云服务内部专网支持的节点有限且实际效果不理想，因此后面仅考虑节点间通过公网传输.

考虑到云服务节点需要在视频直播中用于转码，接下来考察不同配置节点处理视频的性能. 具体地，参考表2列出的节点资源配置，采用阿里云普通计算型和GPU计算型2种配置. 这里从Xiph视频库^[30]获取2个不同信息丰富度（information richness）的30帧4K视频（根据Jigsaw^[25]的判断方法区分为高丰富度和低丰富度），采用当前最常用的H.264编码技术^[31]进行视频编解码（转码实际是解码再编码的过程）. 为了减小误差，2种配置节点在不同时间对2个视频各进行20次编解码. 图3给出了这4个测试用例的平均单帧编码和解码用时，其中“普通”和“GPU”分别代表2种配置类型.

图  3  4种配置和信息丰富度组合下单帧编解码用时

Figure  3.  Per-frame encoding and decoding time for four pairs of configuration and information richness

下载: 全尺寸图片 幻灯片

从图3中可以看出，视频编解码用时受其信息丰富度影响而不固定（丰富度越高用时越长），而使用GPU处理可以明显减少编解码用时. 然而GPU配置显著增加了节点成本，例如阿里云近似常规资源配置（CPU核数和主频完全相同，内存容量相差1倍）情况下，添加GPU与否的每小时租用价格相差超过12倍. 因此在选取节点时应该综合考虑其性价比（后面将定义“单位价格处理速率”用于区域节点确定）. 不同类型云服务节点难以估计对比的算力与前述的节点间变化不定的网络状况使得将这些节点构建成算力网络用于视频分发过程存在很大挑战，亟需克服不同节点在计算和网络上的异构性和动态性来设计视频分发方案.

3.   高效视频分发方案设计

在观测结论的指导下，本节设计一套基于异构算力节点协同的高效视频分发方案. 首先基于强化学习模型决策用于各视频块的最优传输和转码节点，以最大化分发效率；在此基础上对不同视频块通过优先级排队调度提升节点弹性，并设计分层日志同步容错机制保证节点故障后快速恢复.

3.1   视频分发节点决策模型

用于视频分发的云服务节点需要持续响应海量直播视频处理和传输请求，此外，为了降低运营成本需要合理利用各节点资源，因此保证视频传输实时性并提升节点资源利用率是选取分发（传输和转码）节点的主要考虑因素.

首先确定用于视频分发的算力网络节点集合. 如2.1节所述，协同多云节点能够提升服务可用性，因此可以在所有合作云服务商全部可用地理位置（如表1所示）部署节点实例. 考虑到国内云服务商普遍在国内提供较为密集的候选节点位置，可以去除包含候选节点位置较多的一些区域（如华北、华东等）的部分节点位置. 具体来说，先测量所有候选节点位置两两之间的RTT，设$n$个候选节点位置间的测量集合为$\left\{{RTT}_{ij}\right\}(i,j={1,2},… ,n)$，取各节点位置到其它节点位置中最小的RTT值（即$\mathop {\min }\limits_i \left\{{RTT}_{ij}\right\}$），在各区域内根据该值进行排序并去除其中1/3值较大的节点位置. 这样减少部署性能较差的冗余节点，既可以降低视频分发过程中的故障风险又能节约资源成本. 接下来对选定的节点位置各部署一个节点实例. 对于云服务商在各节点位置提供的不同类型的实例配置，这里选取其中单位价格处理速率最高的配置. 具体来说，使用所有$m$个类型配置的实例分别对同一代表性视频进行编解码，记录其各自总用时$\left\{{t}_{k}\right\}(k=1, 2,… ,m)$，并查询各种配置的价格$\left\{{c}_{k}\right\}$，通过1/（${t}_{k}{c}_{k}$）计算单位价格处理速率对所有实例配置排序，最终按结果值最高的配置进行实例部署.

为了有效调度所有部署的节点，还需要从这些节点中选举出1个节点作为控制器，以便统一编排所有节点的资源，响应视频直播应用请求向各节点分配视频传输和转码任务，并实时维护各节点的数据处理状态. 为了减少控制器与其它节点频繁交互消息的时延，需要最小化其到其它节点的最大时延. 因此同上操作，测量所有部署节点两两之间的往返时延$\left\{{RTT}_{ij}\right\}(i,j=\mathrm{1,2},… ,n)$ ，与前面不同的是这里取各节点到其它节点的最大RTT进行排序，取该值最小的节点（即$\mathop {\arg\min }\limits_i \left\{\mathop {{\rm{max}}}\limits_{i}\{{RTT}_{ij}\}\right\}$）作为控制器. 考虑到各节点间网络状况不稳定，同时全局控制节点负载过大易出现单点故障，因此将采取根据节点间最新RTT周期性按上述方式重新选举（周期一般可设置为1 h）.

控制器需要持续获取各节点当前的资源使用情况，以便将视频传输和转码任务在线分配到合适的节点执行（每次执行任务后获取节点资源使用情况）. 对于计算和存储资源，可以直接调用节点设备自带的监控工具获取CPU和内存利用率. 而对于网络带宽资源，可以基于“网络状况通常在短时间尺度上保持稳定”这一科学发现^[32]，根据最近数据传输平均速率的调和平均数（harmonic mean）估算所有节点间以及节点与邻近的直播源或用户间的链路带宽. 具体来说，某链路$x$最近一小段时间（如1 min）内有$l$次数据传输，各次数据大小和传输用时分别为$\left\{{s}_{xi}\right\}$和$\left\{{t}_{xi}\right\}(i=\mathrm{1,2},… ,l)$，即对应的传输平均速率为${r}_{xi}={s}_{xi}/{t}_{xi}$，则根据调和平均数计算公式，该链路估算带宽为

通过计算所有链路带宽之和与节点额定带宽的比值可以近似获得节点带宽利用率.

考虑到强化学习能够根据状态反馈实时更新决策，非常适合在线追踪异构节点的计算和网络资源变化，相比于当前由摄取服务器处理转码、随机或轮询选择传输节点的方案能够更合理地选择最大化视频分发效率的传输和转码节点，因此控制器维护一个RL智能体，利用从各节点收集的计算、存储和网络带宽资源使用情况，为每个划分好的视频块决策传输和转码的最优节点（视频流的分块和调度过程见3.2节）. 具体来说，RL智能体以收集的节点资源使用情况为状态（state）${{\boldsymbol{S}}}_{i}$进行学习，确定传输和转码节点集合向量为需要决策的动作（action）${{\boldsymbol{a}}}_{i}$. 这里的状态${{\boldsymbol{S}}}_{i}$包括5个元素，分别为当前分发的视频块大小、直播源和目标用户所在区域组合、各节点CPU利用率集合、内存利用率集合和链路带宽利用率集合. 注意当需要服务不同区域多个目标用户时，则对不同目标分别做传输和转码决策. 决策动作向量${{\boldsymbol{a}}}_{i}$应该包括分发源邻近节点（即用作摄取服务器的节点）、目标邻近节点（用户邻近的节点）、中转节点以及转码节点这4个编号元素，这里允许在分发过程中进行一跳中转（前面测量表明中转有机会降低时延），如无需中转则设置为0. 转码节点是从源邻近、目标邻近和中转节点中选取的用于转码的合适节点.

每次执行动作${{\boldsymbol{a}}}_{i}$后会产生新状态${{\boldsymbol{S}}}_{i+1}$，从而启动新一轮的学习和决策. ${{\boldsymbol{S}}}_{i}\to {{\boldsymbol{a}}}_{i}$映射由模型的控制策略$\Pi ({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$决定，在状态观察和动作执行的迭代过程中更新. 为了让RL智能体从过去的经验中学习，每个动作都与一个奖励（reward）函数相关联，该函数主要考虑视频直播的实时性，以最小化正在分发的所有视频流$\left\{{v}_{x}\right\}$在传视频块的最大传输完成时间（即尾时延）为目标. 这里视频块传输总用时$t_{{\rm{OT}} }$包含各段节点间传输用时以及转码计算用时，即

其中$s$为视频块大小，${BW}_{op}$、${BW}_{pe}$、${BW}_{eq}$、${BW}_{qd}$分别依次为直播源$o$、源邻近节点$p$、中转节点$e$、目标邻近节点$q$、目标用户$d$之间的链路带宽（当没有中转节点时$s/{BW}_{pe}+s/{BW}_{eq}$用 $s/{BW}_{pq}$替代），${t}_{{\rm{C}}}$为确定的转码节点的计算用时. 因此奖励函数设置为当前状态相比上一个状态在所有在传视频块传输尾时延上的降低情况，即

其中${t}_{{\rm{OT}}}^{xi}$表示视频流${v}_{x}$当前在传视频块的传输用时. 需要注意的是，动作${{\boldsymbol{a}}}_{i}$的奖励值${r}_{i}$是在下一个状态${{\boldsymbol{S}}}_{i+1}$产生时计算的，此时可以准确获取各节点在执行视频分发过程中资源使用情况用于式（2）传输用时计算.

在此基础上，RL智能体利用神经网络（neural network，NN）来表示其控制策略${\Pi }_{\xi }({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$（$\xi$为一组参数）. 如图4所示，状态${{\boldsymbol{S}}}_{i}$的各元素分别输入2个相似的多层神经网络，其中一个称为Actor，它基于提取的特征输出动作${{\boldsymbol{a}}}_{i}$，另一个称为Critic，它用于判断动作价值（NN具体层数和每层单元数根据实际情况调整）. 每个神经网络的输入层都采用一维卷积神经网络（1-dimensional convolution neural network，1D-CNN）来提取集合序列的特征，而图4描绘的全连接（FC）层都采用tanh激活函数来增强学习能力，Actor网络的输出层以softmax作为激活函数，生成选择每个动作的概率分布（提供概率最大的动作）；而Critic 网络的输出层是一个线性神经元，它估计从当前状态开始的预期总奖励. Actor网络根据Critic网络计算出的最优价值${V}_{\Pi }\left({{\boldsymbol{S}}}_{i}\right)$迭代更新策略函数，最终决策出视频传输和转码的最优节点.

图  4  用于决策传输和转码节点的强化学习模型

Figure  4.  A reinforcement learning model for deciding transmission and transcoding nodes

下载: 全尺寸图片 幻灯片

为了保证视频传输的实时性，RL模型需要适应在线决策，尽快收敛（即稳定地生成合理的决策），训练目标是最大化模型获得的总累积奖励. 策略梯度（policy gradient）^[33]是实现这一目标的有效方法，但它可能会遇到由于大量策略变化导致的收敛困难问题. 鉴于此，我们使用邻近策略优化（proximal policy optimization，PPO）^[34]这种快速收敛算法来训练模型，以避免在每一步中过多地更改策略的参数更新. 具体来说，用优势函数（advantage function）${A}_{\xi }({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$制定累积折扣奖励的梯度，其表示状态${S}_{i}$中特定动作${{\boldsymbol{a}}}_{i}$的预期奖励与从策略${\Pi }_{\xi }$中提取动作的平均预期奖励的差异. 在实践中，Actor网络参数$\xi$的每次更新都遵循策略梯度

其中$\alpha$是学习率. 对于给定的四元组$({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i},r,{{\boldsymbol{S}}}_{i+1})$，通过奖励函数和价值估算${A}_{\xi }({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$（后面简写为${A}_{\xi }$）

为了帮助模型快速收敛到一个好的策略，限定新旧策略${\Pi }_{\xi }({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$和${\Pi }_{\xi }'({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$之间的差异，并用它们的比率${r}_{\xi }={\Pi }_{\xi }({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})/{\Pi }_{\xi }'({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$替换式（4）中的${\Pi }_{\xi }({{\boldsymbol{S}}}_{i},{{\boldsymbol{a}}}_{i})$. 在此基础上，模型的损失函数设计为

其中比率${r}_{\xi }$被函数$c\left(·\right)$限制在区间$[1-\varepsilon , 1+\varepsilon ]$，模型将平滑更新策略参数避免决策跳跃.

使用快速收敛的训练算法，RL智能体在最初仍然需要经过一段时间学习才能做出合理决策. 此时可以采用轮询的方式选取传输中转节点和转码节点，但无法保证视频分发和节点资源利用效率. 为了避免冷启动，可以让RL智能体利用历史节点选取的学习经验. 已有工作表明，在多个NN模型中对相同神经元的参数进行平均可以实现聚合这些模型的经验^[35]. 因此，这里通过融合先前对象模型的NN参数来进行多模型聚合. 具体来说，假设总共有${n}_{m}$个决策模型，每个模型包含${n}_{c}$个单元（所有模型的NN结构都相同）. 所有的NN参数可以用一个矩阵${\boldsymbol{\Xi }}_{{i}{j}}$表示，其中每个元素${\xi }_{ij}$表示第$i (i=1,2,…,n_m)$个模型中第$j(j=1,2,…,n_c)$个单元的参数. 接下来按照联邦学习的原理进行加权平均运算来计算聚合模型中的每个元素

其中${\rho }_{i}$代表模型$i$的经验权重. 通常对同一直播源历史传输视频块进行的决策有更多可供借鉴的经验，因此为相应模型设置优先权重.

3.2   多任务调度与可靠通信机制

由于算力网络节点需要面向多直播源提供视频分发服务，当不同视频流同时发起分发任务处理请求时，需要设计合理的调度机制以缓解它们对计算和网络资源的竞争. 首先确定每次请求处理任务的划分. 为了使各任务视频块可以单独在不同节点进行转码，在划分时视频块间不能有编解码依赖. 考虑到视频编码过程同时涉及帧内编码（intra-frame coding）和帧间编码（inter-frame coding），显然不能以视频帧为分块单位. 事实上，主流视频编码技术（如H.26x、VPx）的编码序列中都包含一系列帧间编码单元，称为图片组（group of pictures，GOP），不同的GOP之间不存在任何帧编码依赖，适合作为划分任务的视频块.

如图5所示，直播源通过消息队列遥测传输（message queuing telemetry transport，MQTT）协议向控制器发送视频分发请求，并按GOP划分视频块. 对于每个视频块，在实际执行任务前可以保守估算分发和编码完成用时，定义虚拟完成时间${t}_{{\rm{VT}}}$，

图  5  多视频流分发请求排队调度过程

Figure  5.  The input-queued scheduling process for distribution requests of multiple video streams

下载: 全尺寸图片 幻灯片

其中$s$为视频块大小，${BW}_{op}$、${BW}_{pq}$、${BW}_{qd}$分别为对源、目标以及之间链路此前测量的带宽，${t}_{{\rm{C}}}^{s}$为在源邻近节点（摄入服务器）处转码的计算用时，易知${t}_{{\rm{VT}}}$为执行该任务的最大用时（中转或更换转码节点若降低该用时则在实际中采用）. 此外，直播中各视频块都有一个需要播放期限${T}_{d}$，设当前时间为${T}_{c}$，据此计算各视频块的允许等待时间${t}_{{\rm{W}}}$为

为了使视频流畅播放，这里采用优先级排队调度机制，即在一个优先队列中根据允许等待时间${t}_{W}$对请求视频块进行排序（注意每次有请求到达时需更新队列中视频块的${T}_{c}$为当前时间再进行计算比较），${t}_{{\rm{W}}}$小的视频块将插队优先处理，以尽量保证临近期限的视频块能按时播放.

在此基础上，为了降低突发流量峰值导致资源容量不足的风险，进一步设计节点资源配置自适应策略，对视频分发请求“削峰填谷”提升节点的弹性. 这里以各节点实例部署时确定的初始资源配置（包括表2描述的CPU和内存配置，加上设定的网络链路最大带宽）为1个资源单元，作为它们此后增减资源的最小单位（注意不同节点的资源单元对应的具体资源配置可以不同）. 对于使用中的任意节点实例$z$，定义主控资源利用率${U}_{D}^{z}$为计算、存储和网络带宽资源利用率$\{{U}_{{\rm{C}}}^{z},{U}_{{\rm{M}}}^{z},{U}_{{\rm{B}}}^{z}\}$中的最大值，即

每次处理请求在给定区域选取用于传输或转码的节点实例时，都选择其中主控资源利用率${U}_{{\rm{D}}}^{z}$的最小的节点，以此始终保持均衡利用不同节点的资源，使它们能应对各种程度的流量峰值压力. 当同一区域内所有节点实例的主控资源利用率${U}_{{\rm{D}}}^{z}$都大于一个特定的拥塞阈值${\theta }_{c}$（即$\mathop {\max }\limits_z \left\{{U}_{{\rm{D}}}^{z}\right\} > {\theta }_{c}$）时，需要为其中${U}_{{\rm{D}}}^{z}$最大的节点实例增加一个资源单元；而当同一区域内各节点实例主控资源利用率${U}_{{\rm{D}}}^{z}$都小于一个特定的空闲阈值${\theta }_{l}$（即$\mathop {\min}\limits_z \left\{{U}_{{\rm{D}}}^{z}\right\} < {\theta }_{l}$）时，则回收所有节点实例的额外资源单元（注意${\theta }_{c}$和${\theta }_{l}$取值需要根据实际节点实例资源配置和处理数据大小分布确定）.

考虑到节点间网络状况不稳定，还需要设计良好的容错机制以减少节点断连故障恢复时间. 首先，为了预防控制器发生故障，可以按照3.1节所述控制器选举方法从剩余部署节点中选出1个节点作为备用控制器. 一旦当前控制器发生故障宕机，将备用节点作为新的控制器，用于与各节点继续交互分配处理任务. 当前分发视频块的各源邻近节点在收到控制器更换的广播后将备用控制器信息附带在向对应直播源发送的完成分发响应里，此后直播源仍通过MQTT协议发送视频分发请求到备用控制器. 此后周期性重新选举的控制器通知备用控制器，备用控制器同样将消息附带在对请求的响应中传递给直播源. 备用节点处理完当前收到请求后，停止作为控制器，而直播源此后将请求发给新选举的控制器处理. 而对于其它节点发生故障，可以从控制器复制日志来恢复数据一致性. 这里基于Raft共识协议^[36]的日志同步机制，当有新的数据处理请求到达时，在日志中追加条目，并通知其它节点在日志中复制该条目后更新状态机. 采用这种机制可以保证在少于半数节点宕机时节点网络仍可以正常处理数据.

当前采用日志同步的主流的分布式存储框架（如OpenStack Swift）一般直接在节点间同步整个日志，然而这样会消耗很大带宽资源，影响数据处理任务的传输时延. 为了解决这一问题，本文设计一种分层日志同步机制，利用Merkle树^[37]来组织相关日志条目和目录的散列值. 具体来说，如图6所示，根据日志条目内容和完整路径为每个日志条目生成一个MD5散列值. 在此基础上，一个目录的散列值可以通过连接其下一层所有日志条目和子目录（非级联的方式）散列值计算得出. 例如，目录$d$中有$n$个日志条目$\left\{{f}_{i}\right\}(i=\mathrm{1,2},… ,n)$和$m$个子目录$\left\{{d}_{j}\right\}(j=\mathrm{1,2},… ,m)$，散列值分别为$H\left({f}_{i}\right)$和$H\left({d}_{j}\right)$，则可以递归计算目录$d$的散列值为

图  6  基于分层日志同步的数据一致性恢复

Figure  6.  Data consistency recovery based on layered log synchronization

下载: 全尺寸图片 幻灯片

其中“$+$”表示字符串连接操作，而$H'\left(d\right)$表示目录$d$完整路径的MD5值（如果$d$为空目录，则$H\left(d\right)=H'\left(d\right)$）. 通过这种方式，所有日志条目和目录的散列值可以按照目录树（directory tree）结构被记录在一个特殊的文件中. 注意每次更新一个日志条目时，其在目录树中所有祖先节点的散列值都将随之变化，因此它们需要被重新计算.

4.   系统验证分析

本节根据第3节设计的高效视频分发方案实现面向视频直播场景的系统，通过在真实环境下部署算力网络进行测量及利用仿真实验对其性能进行评估.

4.1   系统实现与实验设置

视频分发原型系统包括视频源和用户客户端、一组云服务节点构建的算力网络，以及选举出的控制器节点，所有平台均采用Python实现. 控制器通过心跳报文与各节点保持长连接，收集节点资源使用情况并发送视频分发节点决策结果，其实现基于远程过程调用框架gRPC. 对于维护节点间日志同步的Raft共识协议，系统引入一个开源程序^[38]实现. 视频转码过程采用主流的视频编码技术H.264及音频编码技术AAC，这里基于FFmpeg工具实现. 系统中的RL智能体使用TensorFlow构建神经网络模型. 具体来说，基于网格搜索（grid search）^[39]设置FC层的层数为2，每层单元数为32，学习率$\alpha$和折扣因子$\gamma$分别为0.1和0.95；使用Adam优化器^[40]来更新梯度下降.

为了对这些实现的系统进行性能评估，接下来在3种不同云服务（阿里云、腾讯云和华为云）提供计算虚拟机实例的全球各区域按3.1节的规则选取节点位置，并部署单位价格处理速率最高的节点实例. 其中3种云服务使用节点最多的实例配置分别为阿里云ecs.c6.xlarge（CPU 4核2.5 GHz，内存8 GB）、腾讯云gn7.large20（CPU 4核2.5 GHz，内存20 GB，GPU 1/4*NVIDIA T4）和华为云s6.xlarge.2（CPU 4核2.6 GHz，内存8 GB）. 面向视频直播这一应用场景，系统主要关注视频传输码率这个指标. 接下来将采用现有视频分发的基本方法和一种直观改进方法作为比较基线，前者是在确定的摄入服务器进行视频转码，此后直接传输视频块到用户邻近的CDN服务器节点；后者与本文方案类似，采用分布式算力网络并根据RTT选取离直播源和目标用户附近节点作为源邻近节点和目标邻近节点；而中转节点以及转码节点都采用轮询选取方式（其中中转节点可以轮空不选而在源和目标间直接传输）.

与2.2节测量类似，这里从Xiph视频库^[30]获取的10个不同信息丰富度的30帧4K视频（高丰富度和低丰富度各5个，都经过H.264编码）用作实验测试视频源. 不同于实际运行时由直播源实时录制每次随机生成的视频流，本实验采用记录重放（trace replay）并通过视频拼接方式使所有测试视频都播放相同时间（10 min），以此保证不同测量环境的一致性和确定性. 此外，为了评估在线调度算法的可扩展性，收集1个云服务处理请求的大规模数据集，选取其中1个处理请求的突发期共2003个数据的请求时间. 从Xiph视频库下载视频并按3.2节方法划分出足够数量的视频块（大小在10~100 MB），用以搭配上述突发期请求时间，模拟多视频分发请求竞争环境.

4.2   性能评估实验

首先测量系统的端到端性能，以视频传输码率作为评估指标. 这里将本系统方案（“模型决策节点”）和4.1节描述的2种比较基线（“默认视频分发”和“轮询选取节点”）分别用于分发上面提到的高低信息丰富度各5个视频. 为了测试性能稳定，在一天的不同时间分别运行每个测试用例10次. 图7描述了3种方案的平均、最大、最小视频传输码率在2种信息丰富度下的比较情况. 由图7可见，由于涉及更多视频转码用时，高丰富度视频在各种方案下传输码率均小于低丰富度视频. 不过相对2种比较基线，模型决策节点能够有效选取适合转码和传输的节点，在视频传输码率上有明显提升（相比基线中性能较好的“轮询选取节点”方法，在低、高丰富度情况下可以分别增加20.9%和15.6%）.

图  7  模型决策节点方案和两种比较基线在不同信息丰富度情况下视频传输码率对比

Figure  7.  Comparisons of video transmission bitrates achieved by the model-deciding-node approach and two baselines with different information richness

下载: 全尺寸图片 幻灯片

进一步以视频块处理时延（即将视频块从直播源同步到目标用户的端到端时延）作为评估指标. 这里选取实验中传输码率最低的高信息丰富度视频（按3.2节描述方法划分为124个视频块），测量 “模型决策节点”和2种比较基线（“默认视频分发”和“轮询选取节点”）用于该视频分发过程中各视频块处理时延变化情况，实验结果如图8所示. 从图8中可以看到，由于视频码率在分发中不断变化，同时不同视频块的大小具有差异（10~20 MB），几种方案产生的时延都有较剧烈的变化. 不过模型决策节点时延相比其他2种比较基线明显更低（平均分别减少21.2%和29.3%），且在视频分发过程中没有出现卡顿或丢包（视频块处理时延过大或为零）等情况，因此可以有效满足高实时性需求的超高清视频直播场景.

图  8  模型决策节点方案和两种比较基线用于典型视频分发过程中视频块处理时延变化情况

Figure  8.  Comparisons of video chunks’ processing latency variations achieved by the model-deciding-node approach and two baselines

下载: 全尺寸图片 幻灯片

事实上，模型决策节点方案对于涉及视频分发过程的视频点播和泛视频类业务同样适用. 这些场景下视频提前从直播源上传到某个云服务节点，模型决策节点方案和比较基线在响应用户获取请求的视频分发过程中无需考虑直播源与源邻近节点间的传输（相当于式（2）中第一项$\dfrac{s}{{B{W_{op}}}}$=0）. 显然此时包括视频传输码率和视频块处理时延在内的端到端性能对比情况都与上述实验结果近似，这里不再赘述.

接下来具体评估方案中4个重要机制. 对于RL模型决策机制，主要关注其收敛速度以及训练算法和模型聚合机制对其的影响. 这里采用策略梯度算法进行训练和采用PPO算法进行无模型聚合的训练作为比较方法，将连续10个决策中本方案性能都优于比较基准作为模型收敛的信号. 基于这个设定，图9绘制了在分发上述视频过程中，本系统的RL模型和2种对比方法的收敛时间（产生第1个决策的时间）的累积分布函数（cumulative distribution function，CDF）. 显然，图9中对比情况验证了本系统模型在实际环境中的快速收敛性.

图  9  模型训练算法和模型聚合机制对收敛时间的影响

Figure  9.  Effect of model training algorithm and model aggregation mechanism on the convergence time

下载: 全尺寸图片 幻灯片

对于多任务优先级排队调度机制，以“平均数据传输用时”指标评估其在处理突发请求时的时效性. 这里将其与2种常用的调度算法“先入先出算法”和“分组公平共享”用4.1节描述的数据集进行对比，其中“分组公平共享”是指同时调度一组（最多10个）任务来共享链路带宽资源. 注意本系统计算虚拟完成时间采用各链路实际带宽（一般为100~200 Mbps）. 图10描述了多任务优先级排队调度机制与其他2种对比算法的传输用时比率随着处理视频请求数量增加的变化趋势. 从图10中观察到，2个比率都会很快收敛到0.5左右，并在之后保持稳定. 这个提升效果表明本系统的调度机制能保证大量同时到达的视频处理请求的及时性.

图  10  多任务调度机制和两种常用调度算法的性能对比

Figure  10.  Performance comparison between the multi-task scheduling mechanism and two common scheduling algorithms

下载: 全尺寸图片 幻灯片

对于节点资源配置自适应机制，采用同样的数据集进行仿真来评估其有效性. 这里统一设定节点资源单元（见3.2节定义）的配置为最多节点实例的初始资源配置（CPU 4核2.5 GHz，内存8 GB，网络链路最大带宽100 Mbps）. 根据对资源变化情况和视频的数据分析，拥塞阈值${\theta }_{c}$和空闲阈值${\theta }_{l}$可以分别设置为60%和20%. 图11描述了资源使用波动最大节点的资源单元数量在执行视频处理任务过程中的变化情况. 从图11中可以看出，在整个过程节点使用的资源单元数量都相当少（平均少于2个，短时间内最多需要3个），同时数量变化总体呈现稳定趋势. 与每个节点仅使用单一资源单元相比，节点资源配置自适应机制可以使视频数据的整体处理用时减少35.9%.

图  11  资源单元数量自适应变化和视频处理降低用时

Figure  11.  Adaptive change of resource unit number and the corresponding reduction of video processing time

下载: 全尺寸图片 幻灯片

对于分层日志同步机制，通过测量日志同步时延来评估其是否具有给故障节点带来快速恢复数据一致性的能力. 主要将其与主流框架OpenStack Swift的方案（即“日志整体同步”）在故障节点数${n}_{f}=1,2,3$时的同步性能进行对比. 图12描述了2种同步机制的时延随着日志条目数量呈数量级增加（10³~10⁷）的变化趋势. 从图12中观察到，分层日志同步机制的日志同步时延随着日志条目数量增加而趋近平缓，同时随着故障节点数量增加，相比于对比方案的时延降低幅度明显增大. 当有3个节点发生故障时，采用本系统机制同步10⁷条日志仅需10 min左右，与对比方案相比能够降低68.5%的同步时延. 该实验结果表明分层日志同步机制能够满足故障节点快速恢复数据一致性的需求.

图  12  不同故障节点数${n}_{f}$时分层日志同步机制降低时延

Figure  12.  Reduction of delay brought by the layered-log-synchronization mechanism with different fault node numbers ${n}_{f}$

下载: 全尺寸图片 幻灯片

最后监测作为系统核心的控制器在一段时间内各种资源使用率的变化情况. 如3.1节所述，在运行过程中控制器周期性选举产生，大多数时间的资源配置为最多节点实例采用的CPU 4核2.5 GHz，内存8 GB，网络链路最大带宽100 Mbps. 将4.1节描述的各种视频随机拼接成一个60 min视频，其中划分的各视频块的分发请求由控制器决策处理. 图13描述了控制器在处理视频块过程中CPU、内存和网络带宽（包括出入流）使用率的变化. 从图13中可以观测到，在面对密集的处理任务时，控制器各种资源使用率仍平稳地维持在很低程度（6%以下）. 单一控制器即可满足大规模的视频分发应用. 配置相近的备用控制器的资源使用率情况基本一致，也能够稳定处理相当规模的视频分发请求，这里不再赘述.

图  13  控制器在处理视频分发过程中资源使用率变化

Figure  13.  Variations of the controller’s resource utilization rate during processing video distribution

下载: 全尺寸图片 幻灯片

5.   结　　论

本文提出了一种基于异构算力节点协同的高效视频分发方案，通过设计强化学习模型规划视频传输路径并合理选取处理转码节点；采用优先级排队对不同视频任务进行调度并自适应调整节点资源以降低对计算和网络资源的突发竞争；设计分层日志同步容错机制在节点故障后快速恢复数据一致性，在多云服务分布式节点实现高效视频分发. 大量超高清视频直播实验证明，与现有视频分发方法相比，本方案性能有明显改进. 未来的工作一方面是结合云原生技术来提升多资源编排弹性，另一方面是构建算力网络内生的可信安全机制.

作者贡献声明：鄂金龙设计方案、完成实验并撰写论文；何林提出意见并修改论文.