如何使用机器学习算法优化分发链路（上）

本文作者

点播视频源站分发的痛点

1

点播视频观看的流程与源站定义

点播是相对于直播而言的，英文命叫VOD

（Video on Demand），顾名思义，某个观众demand了，才有video看，看到的内容是视频的开始。

而直播呢，是不管有没有观众去看的，视频一直在往前走，某个观众进来时看到的，是当时的视频。

点播视频的内容非常多样化，有连续剧、电影、体育录像、自媒体制作的视频，甚至包含现在非常火爆的短视频。

大家有没有想过，每次打开一个点播视频的时候，背后的操作是什么样子的呢？简单的一种观点是下图这样：

视频网站提供点播资源，比如说PPTV新上了一个连续剧，一个电影，或是短视频网站新提供了一个新的短视频。

观众通过网页、app等访问网站，进行视频的观看。

实际上，情况没有这么简单。视频网站的提供的点播资源，也就是文件，是放在自己公司的服务器上面的，这个服务器可能是买的，也可能是租的。存储这些文件的服务器集群，就叫做源站。

这些视频文件，实际上不会直接给用户访问，而是通过cdn逐级分发出去的，所以这些存储集群，还要负责对接CDN。所以源站的作用是负责存储和对接CDN，这里有个分工，视频网站拥有视频版权，CDN擅长分发。

下面我们来看看点播、包括短视频的视频网站的处理流程：

内容生成（这一点是在视频网站之外就可以做的）：视频网站采购版权，或者是自媒体作者制作好视频，短视频作者在手机端录制好视频。

把内容上传到视频网站的源片存储：视频网站的编辑上传采购的版权视频，自媒体和短视频作者上传自己制作的视频。

选择是否压制（根据特性）：视频网站根据视频的特性，选择是否对视频进行压制处理， 例如短视频一般不需要压制即可在手机播放，而电影连续剧一般会压制多档码率。

成片存储：压制好（或不用压制）的视频，叫做成片，存储起来。

回源：CDN从成片存储回源下载这些视频，给观众看。

2

源站与CDN的网络拓扑

我们知道有以下事实：

一个视频网站的（成片）视频，一般不会只放在一个机房内。例如PPTV的视频，体育类的会放在上海的机房，原因是体育演播室在上海，本地录制方便且无需互联网带宽；影视类的都放在武汉的机房，原因是编辑中心在武汉。

一个视频网站会对接多个CDN，也可能自己建设CDN。又如PPTV，在自己CDN的基础上，和国内外各大知名CDN厂商都有深度的合作。

每个CDN（包括自建）供应商对应的网络接入点位置，质量都有很多区别。

另外，对于视频网站来说，一个视频文件，只用保存一两份（当然，视频公司会做冷热备份等等操作，所以，实际上落盘的存储不只这么少，这个细节属于存储高可用的范畴，就不深究了）。

为了存储在不同机房，唯一的一份数据同时发到多个CDN，源站内部需要使用多级缓存的结构。

在视频源站内部的多级缓存之间，也就是多个机房之间的分发，叫做内部分发；视频源站（L2集群）到CDN接入点间的分发，叫做外部分发。一般L2集群对接CDN接入点，在与CDN联调对接时，就会选好优质线路，甚至在一个运营商的机房。

所以，我们介绍的重点还是，如何把视频文件从N个成片存储集群，通过K个L1集群，分发到M个L2集群中。

3

源站分发过程中存在的问题

点播视频从中央集群向L1，L2集群（机房）分发时，采用树状分发（这个树的建立，会根据经验或者网络本身特性），每个中央节点到不同的L1机房线路质量差距很大，不同的L1机房到L2机房质量也差异很大。

分发过程走的是互联网线路（专线太贵），互联网线路的稳定性不可预期，有时网络抖动，会造成分发失败，甚至挖断光缆导致某条干网不可用的事故也经常出现，某条线路或者某个机房的问题，可能会造成区域性的不可用。

不同集群（机房）在规划和建设时，服务器（计算、存储、IO）能力、出入口带宽不一样，不同集群向下分发时对应的节点数也不一致，会出现不同集群间的负载差异较大的情况，俗称忙的忙死闲的闲死，忙的节点，很可能成为瓶颈。

4

点播视频源站分发链路优化的意义

如何解决上面说的问题呢，我们自然的会想到，如果每个文件的分发过程，都能自动选择一个最优秀的链路，而不是根据那个配置死的回源树，那么分发的过程将会带来这些优势：

更加高效和稳定。

避免区域性的故障。

不同集群（机房）的负载更加合理和平均。

节点间数据分发质量的评估

1

两个服务器节点间的分发质量评估

前面提到了优化的办法是选择好的分发链路，那么，到底怎样分发链路才是一个好的链路呢？我们先来看以下事实，决定了首先研究两个服务器节点间传输质量的情况：

链路是由数据通过的服务器节点构成的。

链路中，相邻的服务器节点传输质量的最差值，决定这条分发链路的质量上限。

那么，用什么的来评估两个服务器节点间的传输质量呢，我们自然希望有一个量化的数据，一个简单的想法就是“文件下载耗时”。影响两个服务器节点间的传输质量（下载耗时）的因素有这些：

文件大小，文件越大，下载越慢，耗时越长。

发送服务器（接收服务器）的当前负载，包括CPU负载，内存用量，IO负载，当前带宽，存储用量。

CPU负载：CPU负载在不大的时候，对下载影响不大，当CPU负载超过一定值时，会严重影响下载的效率

内存用量：内存用量在不高的时候，对下载影响不大，当内存用量过一定值时，会严重影响下载的效率

IO负载：IO负载在不大的时候，对下载影响不大，当IO负载超过一定值时，会严重影响下载的效率（下图top指令看到的当前机器负载）

当前带宽使用情况：当前带宽在不接近最大带宽的时候，对下载影响不大，当它接近最大带宽时，数据包传输阻塞，会严重影响下载的效率

服务器之间网络线路的情况，包括数据延迟、丢包率、跃点数等等。

延迟:下图中的ping指令，可以测试出两个服务器间的延迟信息，对于数据传输来说，延迟越小越好

MTU（Maximum Transmission Unit）:是指一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位）。最大传输单元这个参数通常与通信接口有关（网络接口卡、串口等），如下方图中所示，传输3000字节，如果mtu设置成1500，需要打成两个包，而当mtu设置为1492，则需要打成3个包，传输3个包当然要比2个耗时更多

丢包率：下图中的ping指令，测试出当前丢包为0个，在网络出现问题时，这个数据可能不为0，视频下载基于HTTP，底层是TCP协议，丢包后要重传，丢包率越低会越好。

跃点数：跃点数代表两个服务器间通信时经过的路由设备数目，数据通过路由器时，路由器中会有数据包队列，队列过满，数据有被丢弃的风险；路由器在计算数据包下一跳的时候，也会有一定的耗时

服务器的最大带宽：服务器最大带宽，当然是越大越好（当然成本也越高），例如家里装宽带，500M的肯定比100M的好（也更贵）

当前时间

以上提到的数据，都是随着时间抖动的，例如说带宽数据，视频网站早上看的人少，晚上看的人多，工作日看的人和周末又不一致，而遇到一些节假日，又有新的特点，整体互联网的使用趋势是向上的，所以从一个长期时间来看，带宽数据应该是波动向上的。

这里要提一个问题，正是由于相同尺寸、相同链路的下载速度，在不同时间点的表现差异巨大，才需要引入一个动态的预估机制

例如，一个文件2G大小，我们在开始下载前，觉得链路A是最好的，但是实际上下载了300M后，链路的A的质量已经不好了，这是链路B可能反倒更好，我们想要达到的目的是，计算出下载完2G大小文件的综合耗时最低是哪条

2

两个节点间数据传输质量模型设想

度量两个节点间的分发质量，我们可以用一个数值，下载时长（Download Time，缩写为DT）来表示，这个数据受到很多具体的、随时间呈现一定规律的因素（变量）影响。

那么我们可以有一个美好的设想：用一个模型，或者说是一个函数，来描述这些因素与DT间的关系，后续新的文件下载时，使用这个模型，输入当前这些变量，预测文件下载的耗时。

假设函数如下：DT=Func(file_size,current_time,defer,cpu_load,mem_load，io_load, …….）我们知道一个文件大小为100M，当前时间点已知，节点间这些变量已知，我们可以根据这个函数算出时长来。