新装linux系统上班自带播放器播放視频时候老提示未找到源是什么问题，请高手指教 [问题点数：40分]

点播视频源站分发的痛点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

源站与CDN的网络拓扑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

发送服务器（接收服务器）的当前负载包括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大小文件的综合耗时最低是哪条

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

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

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