扶凯：海量视频和用户时代的CDN

在视频行业我们需要应对一系列问题，例如架构问题、存储问题、分发问题、转码问题等等。这些问题归根结底是什么术/span>

在解决以上两个问题之前，需要追根溯源，首先明确视频在整个 站架构中是如何处理的，并对每一环节的成本有清晰的理解。

1、 存储与访问

当用户将视频文件上传完毕后，会将文件存储在至少三个上层机房中的一个，而每一个文件可能存储在不同的几个上层中。一般的超大型视频 站会使用推送机制将至少6份文件拷贝存储在全国所有的机房当中。例如上图A、B、C三个存储中心分布在全国各地，简而言之这就是一个超大的对象分布式文件系统。

关于访问，采用的是冷热分层的访问逻辑。既然边缘节点无法存储太多数据，那么必须采用一种高效的访问机制以分担存储的压力。我们会直接将冷门的文件调度至上层，而在边缘将热门的文件直接传送给最近的用户；直接从上层获取一部分完整的冷门文件，而热门文件则从边缘获取。这样我们便妥善解决了存储与分发问题，也就解决了存储空间和用户访问速度的二难问题。

但此时还需要解决的是推送热门文件的选择与数量。这是一个比较麻烦的问题，推送的文件， 因为不是全量， 所以无论我怎么样推送的热门算法，其实都有部分请求访问到上层，上层可能是异地，所以用户的访问体验质量可能不好。 例如小的运营商，象歌华都得透穿出来访问到上层。 原因二是用户喜好的地理差异性，例如北京的用户喜欢看的内容与上海的用户喜欢看的内容存在明显差别，而使用通用算法得出的热门是大家普遍喜欢的，无法针对不同地域特点进行个性化精准调整。之前使用了推的机制，那这里能否反向思考，使用拉的机制来妥善解决以上问题，而CDN的出现可以说很好地解决了这个问题。

2、 用户体验：大视频时代

2.1 标准CDN结构与补充

我们通过使用商业CDN进行补充的方式解决了存在地域特点的视频文件分发难题，现在主流的超大型视频 站都是基于以上方案。既然谈到了CDN的整个结构，那么下面就看看如何使用CDN的单节点（边缘节点）结构来解决存储与速度的问题，这也是与之前提到的存储和体验直接相关的两个关键性问题。

2.2 CDN边缘节点结构

接下来详细介绍文件系统。传统文件系统的一台机器连接多个硬盘，一般为12个。如果一个热门视频文件访问量非常高，那么存储这个文件的当前硬盘，的使用率可达到100%，而其它几个硬盘则处在空闲状态，使得文件的访问性能十分低下。因此我对整个文件系统进行调整，将文件分成多个很小的块，以这种方式将所有文件分块存储至文件系统中，使得每个硬盘中存储的是一个孤立的文件分块，所有文件按照逻辑一体，物理上分块来进行存储与读取。这种方块存储具有以下优势：一、没有大量的I/O分布在一个盘上。因为一旦一个文件块访问量高，便意味着整个系统访问会慢，分块后此时所有磁盘的I/O是一致的一样高；二、一旦其中某个硬盘坏掉，受影响的只是文件的某一小部分的分块， 而不会是所有的整个文件，此时只需要从上层服务器重新读取文件并放置在其他正常运行的硬盘上，而不用对所有文件进行重新回源。三、如果用户在访问时需要跳过视频文件的片头片尾，那么分块存储可不存储开头与结尾，并在处理时可以按分块进行并发：例如在浏览视频时我们拖动视频至某一特定进度，正常情况下如果不将整个文件加载完成，视频服务器便无法实现正常播放；而如果使用分块存储那么只需获取文件第1MB的Meta信息，重新跳转至需要的视频进度位置并立即合成一个新的文件，极大提高视频的拖动效率。四、当删除一个文件时只需要将文件从内存列表中删去而不需要调整I/O。综上所述，自主开发文件系统可以为我们在CDN领域的开发节省很多成本。以目录刷新为例，目录刷新一直是CDN界的难题。假设需要对一百万个文件进行目录刷新，这里便存在两个问题：

1、如何找到这些URL文件/span>

2、如何高效处理数百万个URL文件/span>

解决方案是对每个文件确定一个版本 ，假设所有文件目录的版本 为0，当有某个刷新请求提交过来时把此路径下所有文件的请求标成一个新的版本 ，假设为1；这样当此请求发送至刷新系统中时系统便知道这个请求对应需要版本 为1的文件。此时所有的刷新操作不需要存储任何的URL到内存中， 并用删除时也不会出现集中的I/O的占用，因为仅当用户访问时系统才会进行I/O操作。

2.5 定制的业务语言

以上描述了在多种功能下如何实现有效配置，方案便是分离配置并对每一项设定专门的逻辑语言。在 CDN 的应用场景中，用户的逻辑千奇百怪，为了提高开发效率我们开发了一套定制的业务语言。此语言可实现通用的基本操作，如对URL与一些基本参数的调整操作。由于此语言的存在，运维人员不需要单独开发而只需要根据描述文档就能实现多项功能。这便相当于一个配置文件，当提交此文件生成操作之后，会进行一次编译并生成一个二进制代码，此代码会被直接传输至所有机器中，便实现了所有功能在边缘的生效。此语言还可以保证良好的性能，例如可在进行编译时将多个执行点相同的文件合并为同一个文件，或把多个路径前缀/后缀相同的文件合成为同一个文件；也可基于编译器对开发过程与业务流程进行优化，例如将多个域名相同处理流程进行合并等。

2.6 流量调度

一般厂商会选择使用中心节点/调度处理，在此模型下所有用户必须先请求调度才可得到目标地址，而这种动态请求需要中心中央服务器实时处理，无法在边缘对其进行配置，并且服务器的机位与处理能力有限，如果有攻击，和高并发流量，极易造成调度的宕机。所以我们尝试了新的思路，即边缘化调度：不设立调度中心服务器，将边缘作为调度服务器。采用本地就近处理的方式让用户访问就近的调度器，而调度器会区分调度请求与用户访问请求并反馈不同的操作。

2.8 其他常见问题

2.8.1 回源

这是一个经典场景，边缘的用户请求最近的节点并回源。在此过程中， 如果本地的服务器异常， 络不通，这时周边没有服务怎么办们的结构中， 上层和下层基本是一样的，任何一个边缘节点都可作为上层与下层，并且程序， 访问， 计费本身是抽象出来，并不需要区分上下层来单独处理。只需在后台对流量进行调整或自动识别某个流量是边缘流量还是回源流量。

2.8.2 安全体系

众所周知，CDN的成本越来越低，如果想把CDN做得更好，或者想进一步挖掘CDN的潜能，必须寻找差异化路线。例如P2P解决方案；另一条路是安全解决方案，例如各种抗DDOS服务、流量清洗的服务、Wap等服务。

边缘计算

在这里我想强调的是边缘计算。大家都将CDN视为一个静态的东西，那么为什么不能将其作为一个通用的 关接口呢为CDN离用户最近并可实现很多功能，可以利用CDN开发很多智能解决方案，例如对多家客户的IP进行重合度分析；利用大数据技术结合自己的连接数、I/O等进行校验来实现自主学习的安全防护从而实现故障自主检测等。