CN113949897B - 一种mp4视频流媒体点播的分片缓存加速方法 - Google Patents

Abstract

本发明涉及一种MP4视频流媒体点播的分片缓存加速方法，创建加速节点集群，该集群包括负载均衡层、业务代理层和CACHE层，负载均衡层对来自终端的视频请求按照一定的负载均衡策略进行分配；业务代理层按照视频内容请求为用户提供视频服务；利用业务代理层对视频内容请求进行一致性哈希，CACHE层将不同的缓存请求内容打散到不同节点服务器的CACHE服务上面；CACHE服务下载视频源。本方案利用分片技术，将大的视频文件拆分成大小相等的文件分片，然后将拆分后的文件分片随机均匀地分散存储到CDN加速节点集群中的各缓存服务器的不同磁盘中去，从而大大提升了缓存空间的利用率，进一步改善了视频播放的体验。

Description

一种MP4视频流媒体点播的分片缓存加速方法

技术领域

本发明涉及视频处理技术领域，尤其涉及一种MP4视频流媒体点播的分片缓存加速方法。

背景技术

随着互联网技术的蓬勃发展，视频作为网络应用中的流量大户占据着互联网流量的半壁江山。人们对视频的清晰度、流畅度的体验要求越来越高。720p、1080p的视频变成了普遍的入门级的需求，2k、4K，甚至8K的视频也逐渐走入我们的视野。

在视频编码层面，提升视频编码压缩率作为其中一个重要的方法。随着视频编解码技术的发展，H.264、H2.65、AV1等等这些新的视频编码标准的出现，视频的压缩率不断提高，但是单单通过应用新的编码标准来降低码率，远远跟不上高清晰、高帧率、低延时的需求，视频码率越来越大，而人们对流畅度、播放延时的要求确越来越高，秒开、0卡顿，成为视频服务提供商的技术平台的优化目标和考核标准。

在互联网上，利用CDN技术是提升视频播放体验的一种最直接最有效的最佳优化实践，通过CDN的就近路由，缓存优化等加速手段，可以大幅降低视频播放卡顿的问题，极大改善用户的播放体验。但是视频码流越来越大导致视频文件越来越大，视频应用越来越普及带来越来越大的并发量，也给CDN技术平台带来越来越大的挑战。针对这种大并发大流量的视频的应用场景，如何进行优化，提升CDN技术平台的服务能力，改善用户体验也是长期摆在CDN技术服务提供商面前的一个问题。

在CDN技术上，如何提升视频内容在CDN加速节点中的缓存效率，是非常重要的一环。利用有限的缓存空间、有限的设备和磁盘空间最大程度上提升缓存的效率是CDN技术不断优化的目标之一。

在CDN加速节点集群中，如果没有做针对性的优化，往往会因为不同服务器缓存不同的视频内容，在某些视频热度突然变高的情况下，很容易引起单机、单硬盘负载超过瓶颈，导致视频播放卡顿的问题。

一般的做法，是采用热点统计加预测方法，将认为热度比较高的视频复制到集群内多台服务器上面来分散热点，从而来缓解单机单硬盘瓶颈的发生概率。但是如何预测一个内容的热度还是比较困难的，一般是采用事后对点播的数据进行统计汇总计算得出每个视频内容的热度值，然后再产生复制指令进行内容的复制的方法。但是因为互联网本身具有传播速度非常快的特性，有时候一个本来大家认为并非热点的视频会突然因为某个事件变成“网红“内容，不可避免地导致突发性单机单硬盘产生瓶颈。另外，根据热门度，到底应该复制几份到集群中的其他服务器上面比较合理，如何根据热度的变化再动态地变更视频内容的复制的“份数”都是需要解决的问题。最后，因为内容的复制，必然引起缓存空间的利用率下降，导致更多相对冷门的视频被挤出缓存引起这些视频访问的非命中带来的体验的下降也是需要解决的问题。

发明内容

本发明的目的在于提供一种MP4视频流媒体点播的分片缓存加速方法，以解决上述背景技术中遇到的问题。

为实现上述目的，本发明的技术方案如下：

一种MP4视频流媒体点播的分片缓存加速方法，包括以下步骤：

第一步：创建加速节点集群，该集群包括负载均衡层、业务代理层和CACHE层，其中业务代理层内部至少设有一个代理服务，CACHE层内部至少设有一个CACHE服务；

第二步：负载均衡层对来自终端的视频请求按照一定的负载均衡策略进行分配；

第三步：业务代理层按照视频内容请求为用户提供视频服务；

第四步：利用业务代理层对视频内容请求进行一致性哈希，CACHE层将不同的缓存请求内容打散到不同节点服务器的CACHE服务上面；

第五步：CACHE服务将视频的内容请求作用于视频源，下载视频内容。

上述方案中，业务代理层发送过来的内容的分片请求，如果请求的内容在缓存中不能命中，则会自动回源到源站进行分片内容的获取，否则由本身的磁盘缓存直接为业务代理层提供服务。

上述方案中，CACHE层通过CACHE服务基于一致性哈希算法将缓存请求内容打散分配到不同的磁盘进行存储，结合代理服务到CACHE服务的一致性哈希，通过将内容分片进行两层的一致性哈希，消除集群内“热点”设备引起的性能瓶颈

与现有技术相比，本发明的有益效果是：本方案是一种利用分片技术，将大的视频文件拆分成大小相等的文件分片，然后将拆分后的文件分片随机均匀地分散存储到CDN加速节点集群中的各缓存服务器的不同磁盘中去。

而采用视频分片技术，可以较好地解决以上几个问题。对于一个大型的视频文件，譬如一个100M的文件，拆分成1M一个文件块，然后将文件分片通过哈希的方法打散后均匀分布到不同的服务器和一台服务器的不同的磁盘中去。这样子，即使部分视频内容在某个时候突然成为“热点“，也不太可能导致单机或者单硬盘产生热点，而引起负载不均，使单机或者单硬盘产生瓶颈；其次，因为单机单磁盘不再会因为“热点”视频的出现导致瓶颈，从而不再需要把热点视频复制多份到集群中的其他服务器或者服务器中的其他硬盘上，从而大大提升了缓存空间的利用率，有限的空间内可以存储更多的视频内容，能够一定程度上提升缓存的命中率，从而能够进一步改善了视频播放的体验。

附图说明

参照附图来说明本发明的公开内容。应当了解，附图仅仅用于说明目的，而并非意在对本发明的保护范围构成限制。在附图中，相同的附图标记用于指代相同的部件。其中：

图1为本发明整体工作原理示意图；

图2为本发明中节点服务器的磁盘配置图；

图3为本发明中MP4视频文件格式示意图；

图4为本发明中CACHE服务的分片访问示意图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，现在结合附图对本发明作进一步详细的说明。这些附图均为简化的示意图，仅以示意方式说明本发明的基本结构，因此其仅显示本发明有关的构成。

根据本发明的技术方案，在不变更本发明实质精神下，本领域的一般技术人员可以提出可相互替换的多种结构方式以及实现方式。因此，以下具体实施方式以及附图仅是对本发明的技术方案的示例性说明，而不应当视为本发明的全部或者视为对本发明技术方案的限定或限制。

下面结合附图和实施例对本发明的技术方案做进一步的详细说明。

实施例1，如图1所示，一种MP4视频流媒体点播的分片缓存加速方法，以包含2台节点服务器的CDN加速节点集群为例，包括以下步骤：

第一步：创建加速节点集群，该集群包括负载均衡层、业务代理层和CACHE层，其中业务代理层内部至少设有一个代理服务，CACHE层内部至少设有一个CACHE服务。首先，从逻辑角度上(即图中的水平方向上)来看，整个集群分为三层，即“负载均衡层”、“业务代理层”和“CACHE层”

第二步：负载均衡层对来自终端的视频请求按照一定的负载均衡策略进行分配，使集群能够高性能高可靠地持续提供服务。

第三步：业务代理层按照视频内容请求为用户提供视频服务。其中“业务代理层”为用户提供视频服务，从用户的角度来看，按照在线视频播放的需求规范来支持用户对视频的播放请求，包括处理请求的接收、防盗链、鉴权、下载限速等业务逻辑，以及处理视频特有的快进快退的拖拽和处理“CACHE层”负载均衡逻辑等等。

第四步：利用业务代理层对视频内容请求分片，并通过进行一致性哈希发送到CACHE层的不同节点上，CACHE层将不同的缓存请求内容打散到不同节点服务器的CACHE服务上面。其中“CACHE层”不直接面向用户提供服务，它隐藏在“业务代理层”后面，利用“业务代理层”对内容进行一致性哈希，将不同的内容打散到不同节点服务器的“CACHE服务”上面，来为“业务代理层”提供一个可平行扩展的大的缓冲池；同时，对于“业务代理层”发送过来的内容的分片请求，如果请求的内容在缓存中不能命中，则会自动回源到源站进行分片内容的获取，否则由本身的磁盘缓存直接为“业务代理层”提供服务。

第五步：CACHE服务将视频的内容请求作用于视频源，下载视频内容，并对视频源进行分片缓冲加速，改善视频播放的体验。

另外，从物理角度上(即图中的垂直方向上)来看，每台服务器本身又是一个完整的个体，同时包含了“业务代理层”和“CACHE层”的功能。这样子，能够充分利用“业务代理层”主要是进行网络I/O消耗，而“CACHE层”主要是磁盘I/O的消耗的特性，将两个服务整合在一台硬件服务器上来，能够充分利用单机服务器的CPU/内存/网络IO/磁盘IO的资源，提升设备的利用率，一定程度降低设备的总体成本。

如图2所示，在“CACHE层”，通过“CACHE服务”，基于一致性哈希算法将内容打散分配到不同的磁盘进行存储，结合前面“代理服务”到“CACHE服务”的一致性哈希，通过将内容分片进行两层的一致性哈希，消除集群内“热点”设备引起的性能瓶颈。

本发明对内容将大文件切成小片，利用双层一致性哈希的技术，第一层通过“代理服务”对分片内容的一致性哈希，选择集群中不同的“CACHE服务”，从而避免单机成为“热点”；第二层再通过“CACHE服务”对分片内容的一致性哈希，选择单机中不同的“裸盘“，从而避免单块磁盘成为“热点”。利用双层哈希技术，能够将分片内容均匀地分散到不同服务器的不同磁盘中，大大降低“热点”的发生，提升整体的运行效率。

实施例2，基于实施例1，下面对MP4视频的格式做简单介绍，然后以MP4视频为例，对基于http的流媒体播放请求的处理过程进行说明。

MP4视频格式是MPEG-4的标准，对应的标准为ISO/IEC 14496-12，即信息技术视听对象编码的第12部分：ISO基本媒体文件格式(Information technology Coding ofaudio-visualobjects Part 12:ISO base media file format)。

MP4的基本格式如图3所示。整个MP4文件本身是作为一个视频容器，文件中的所有数据都被装入到各种box中，同时有些box还可以包含其他子box，这种box称为containerbox。

一个MP4文件在头部有且只有一个“ftyp”类型的box，作为MP4格式的标志并包含关于文件的一些信息；之后会有且只有一个“moov”类型的box(Movie Box)，它是一种containerbox，子box包含了媒体的metadata信息，metadata中包含了重要的音视频帧的索引；MP4文件的音视频媒体数据包含在“mdat”类型的box(Midia Data Box)中，该类型的box也是container box，可以有多个，也可以没有(当媒体数据全部引用其他文件时)。

为了提升流媒体播放的性能，在生成MP4的时候，需要将moov放在mdat的前面，这样能够直接从MP4文件的头部开始分析，快速定位音视频帧的位置，而不需要先读取文件头部的信息，然后根据mdat box的大小，计算出moov的偏移量，然后再跳到文件尾部去分析，这样子在一定程度上能够降低处理的难度，同时提升服务的响应性能。

在进行MP4流媒体播放请求的时候，终端可以指定从视频的任意一个时间点开始播放，所以需要CDN服务器能够对MP4文件进行解析，通过分析封装在moov box中的metadata中的音视频帧的索引，从而定位到用户要求播放的时间点所对应的mdat中的音视频帧的起始文件偏移量；另外，由于终端要求的不是完整的视频内容，需要对MP4文件的moov box进行重新封装，然后跳过不需要的mdat中的音视频帧，将需要的音视频帧重新封装到新的mdat box中，然后将内容下发给终端。

为了定位某一个帧对应的mdat所在的位置，moov box中有一个stbl containerbox,其中包含的stts(time to sample box)、stsz(sample size box)、stsc(sample tochunkbox)、stss(sync sample box)、ctts(composition time to sample box)、stco(chunk offsetbox)等几个子box来根据播放起始时间来进行mdat中的音视频帧的偏移量的定位。

因为“负载均衡层”不是本发明的重点，以下假设请求已经到达“业务代理层”，同时假设MP4文件的moov box已经被前置到ftyp box之后，mdat box前面。基于缓存分片技术的MP4的流媒体处理过程分为两部分，第一部分从“业务代理层”的“代理服务”的角度进行描述，第二部分从“CACHE层”的“CACHE服务”的角度进行描述。

下面是“代理服务”的处理流程：

步骤1.1：终端发起对视频内容的请求，如：地址为：http://example.com/a.mp4，并通过http的querystring部分指定从第n秒开始播放。

步骤1.2：“代理服务”经过应有的鉴权认证后，按照初始配置的分片大小slicesize，向“CACHE层”发起第一个分片的请求，由于ftype box本身很小，只有24个字节，所以基于上面的假设，第一个分片一定是存放了mp4的moov头。

向“CACHE层”发起的请求，严格地控制在一个分片内，譬如，如果设置slice size为1048576(即1M),那么可以向“cache服务”请求如图4中CACHE的分片访问中A、B、C、D四种内类的非跨分片的请求，而不能发出如E、F这种跨分片的请求。

在向“CACHE服务”发请求的时候，在HTTP HEADER中添加Range头，把当前请求的分片的文件偏移位置通过标准的HTTP Range请求传递给“CACHE”服务。

步骤1.3：“代理服务”获取到MP4文件的首个分片后，对HTTP Range请求得到的响应头中的Content-Range进行分析，得到MP4文件完整文件的大小。然后，对MP4的头进行扫描分析，检查moov box是否在ftyp后面，如果不是，则由moov后置的这种情况的处理逻辑来处理。为了让说明更简单清晰，这里省略moov box在文件尾的情况的处理。

步骤1.4：检查moov box是否已经下载完整，如果因为moov box超过了slicesize,那么循环生成对“CACHE服务”的分片请求并保存到“代理服务”的内存缓存中，直至moov box下载完整。

步骤1.5：moov box下载完整后，对moov box进行分析，利用moov中的stlb box所包含的各个子box，对视频播放起始位置进行定位：用stts box查找用户的播放起始时间对应的音视频帧的sample,并通过stss box找到与起播时间最近的视频关键帧的位置，只有从关键帧开始发送数据才能保证终端起播的时候不花屏，最后通过stsz box中记录的每个sample的长度计算出最终要发送给终端的mdat中的音视频帧对应的文件偏移量。

步骤1.6：在缓存中生成新的MP4的ftyp和moov box，在生成moov box的过程中，因为跳过了部分音视频帧，需要对其中的stbl中的各个子box进行裁剪，同时对部分涉及到包含了绝对偏移量的子box，如stco或者co64进行偏移量的调整。

步骤1.7：将生成的MP4 ftyp和moov box发送给终端。

步骤1.8：在缓存中生成新的MP4的mdat box，并根据步骤1.6中得到的起始播放的音视频帧的物理文件的偏移量，向“CACHE服务”请求视频起始帧的所在的slice。

在缓存中生成新的MP4的mdat box时，因为通过步骤1.5的计算，已经提前知道裁剪后的mdat box的大小，所以可以预先写入mdat box头的大小字段，而不需要后续再取变更。

步骤1.9：“代理服务”一边从“CACHE服务”获取数据，一边向终端发送数据。

步骤1.10：“代理服务”在一个分片处理完毕后，根据步骤1.3得到的MP4完整文件的大小，进行循环，向“CACHE服务”获取新的分片，并发送给终端，直至所有mdat的音视频数据发送完毕。

下面再对moov后置于mdat之后的情况的处理进行简要说明：

在以上步骤1.3中，通过检查MP4文件头，发现ftyp后面跟的是mdat，那么需要根据mdat本身box的大小，得到后续moov box在完整MP4文件中的偏移量。然后“代理服务”根据得到的偏移量，向“CACHE服务”发起获取moov box的slice分片的请求，并最终获取到完整的moov box。并执行步骤1.5中的moov box的分析过程，进行视频播放起始位置的定位，生成新的MP4 ftyp，和moov box，发送给终端。最后重新定位到mdat box中的偏移位置，进行音视频帧数据的发送，直至发送到mdat的尾部。

下面是“CACHE服务”的处理流程：

步骤2.1：“CACHE服务”接收到分片请求后，首先需要检查请求是否跨分片，如果跨分片，则直接拒绝服务，返回错误信息并结束。如果没有跨分片，则将当前的请求URL以及按照slice size对齐的分片起始和结束位置组合成key，检查其缓存中是否有当前请求块的内容。

如：请求的Range是100-2000，那么进行slice size对齐后的起始结束位置是0-1048575，和url进行如下组合：“url|slice_start|slice_end”，计算得到缓存的key，按照本例得到的缓存key为:“http://example.com/a.mp4|0|1048575”。

“CACHE服务”不支持跨片请求是因为“CACHE服务”本身是严格按照slice size对齐的分片为单位进行存储的，因为跨分片的逻辑由“业务代理层”来解决比“CACHE层”解决来说相对更方便。同时“CACHE服务”又支持非跨片的slice size非对齐的请求，这样子避免了“业务代理服务”必须要按分片对齐进行请求所带来无效数据的传输引起的浪费，从一定程度上能够提升系统的性能。

步骤2.2：如果本地缓存中找到对应分片的内容，则从缓存中获取该内容，并跳转到请求的起始字节偏移位置，对应的字节开始向“代理服务”发送视频分片内容，直到所要求的所有字节发送完毕，整个过程处理完毕。

步骤2.3：如果本地缓存中没有找到对应分片的内容，则“CACHE服务”向源站发起类似于“代理服务”向“CACHE服务”发起的获取分片的请求，只是“CACHE服务”向源站发起的请求是严格按照slice size对齐的，除非请求的是视频文件的最后一个分片。

步骤2.4：“CACHE服务”获取到源站发送过来的分片内容，“CACHE服务”首先将内容用以上步骤2.1计算出来的缓存key,以URL和本机部署的磁盘列表进行一致性哈希计算，选中其中一个磁盘后，将内容以缓存key作为存储路径，存储到对应的磁盘中。其次，分片内容在落盘的同时，向“代理服务”发送所需的分片中的数据。

在本步骤中，采用“一致性哈希”对分片内容打散后存储到本机不同的磁盘中，有利于在本机部署的硬盘有变动的时候，避免之前缓存的内容大量miss。

本发明是一种利用分片技术，将大视频文件拆分成大小相等(除了最后一个)的文件块，然后将拆分后的文件块随机均匀地分散存储到CDN加速节点集群中的不同缓存服务器的不同磁盘中去。本发明具备以下优点：

1、能够充分利用集群中各节点服务器和各硬盘的硬件资源，充分利用各硬件的I/O吞吐能力和磁盘空间，大大降低“热点”节点服务器和“热点”磁盘的发生概率，使集群在资源条件下不变的情况下，最大程度上发挥整体的并发服务能力。

2、其中大文件切片打散缓存存储的特性，避免了需要开发复杂的热点预测算法，避免了复杂的预测算法效果难以评估的问题，降低了系统的开发和部署的难度。

3、由于大文件切片存储回源请求的特性，可以在终端请求的时候，按需从源服务器分片获取，而不需要一次性获取一个庞大的完整文件，小的分片一旦获取成功，就能够立即进行缓存，相当于使下载缓存过程具备断点续传的能力，能够很大程度上避免因为大的视频文件在从源站下载过程中出现的下载中断引起的缓存不成功的问题，从而大幅度提升了缓存的效率和可靠性。

4、由于分片切片缓存存储的特性，也避免了“CACHE服务”需要进行连续大文件存储的需求，从而可以在缓存层面专注于进行中小文件的性能优化，便于整体性能的提升。

本发明是主要应用于CDN视频加速技术平台，通过对大视频文件内容进行物理分片，将分片后的内容分块进行哈希，均匀存储到不同的缓存单元(集群中的不同服务器的不同硬盘)中，在对终端提供服务的时候又重新组装保证逻辑上仍然是完整的视频文件，从而来解决传统的视频缓存技术方法所面临的单节点或单磁盘“热点”问题，“热点”内容预测难度大的问题，以及缓存空间利用率不高的问题。

虽然本发明着眼于MP4视频，但是利用其基本设计原理，经过协议格式的适配，同样可以应用于其他基于HTTP协议的视频格式(譬如FLV等)的流媒体视频在线点播CDN缓存加速服务，也可以应用于基于非HTTP协议的流媒体播放协议(譬如RTSP等)的流媒体视频在线点播的CDN缓存加速服务。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是，以上所述仅为本发明的具体实施方式，并不用于限定本发明保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应含在本发明的保护范围之内。

Claims (5)

1.一种MP4视频流媒体点播的分片缓存加速方法，其特征在于，包括以下步骤：

第一步：创建加速节点集群，该集群包括负载均衡层、业务代理层和CACHE层，其中业务代理层内部至少设有一个代理服务，CACHE层内部至少设有一个CACHE服务；

第二步：负载均衡层对来自终端的视频请求按照负载均衡策略进行分配；

第三步：业务代理层按照视频内容请求为用户提供视频服务；

其中，业务代理层中“代理服务”的处理方法包括如下步骤：

步骤1.1：终端发起对视频内容的请求；

步骤1.2：“代理服务”经过应有的鉴权认证后，按照初始配置的分片大小slice size，向“CACHE层”发起第一个分片的请求；

步骤1.3：“代理服务”获取到MP4文件的首个分片后，对HTTP Range请求得到的响应头中的Content-Range进行分析，得到MP4文件完整文件的大小；然后对MP4的头进行扫描分析，检查判断moov box是否在ftyp后面，如果不是，则将moov后置；

步骤1.4：检查moov box是否已经下载完整，如果因为moov box超过了slice size,那么循环生成对“CACHE服务”的分片请求并保存到“代理服务”的内存缓存中，直至moov box下载完整；

步骤1.5：对moov box进行分析，利用moov中的stlb box所包含的各个子box，对视频播放起始位置进行定位；

步骤1.6：在缓存中生成新的MP4的ftyp和moov box；

步骤1.7：将生成的MP4 ftyp和moov box发送给终端；

步骤1.8：在缓存中生成新的MP4的mdat box，并根据步骤1.6中得到的起始播放的音视频帧的物理文件的偏移量，向“CACHE服务”请求视频起始帧的所在的slice；

步骤1.9：“代理服务”一边从“CACHE服务”获取数据，一边向终端发送数据；

步骤1.10：“代理服务”在一个分片处理完毕后，根据步骤1.3得到的MP4完整文件的大小，进行循环，向“CACHE服务”获取新的分片，并发送给终端，直至所有mdat的音视频数据发送完毕；

第四步：利用业务代理层对视频内容请求分片，并通过进行一致性哈希发动到CACHE层的不同节点上，CACHE层将不同的缓存请求内容打散到不同节点服务器的CACHE服务上面；

其中，CACHE层中“CACHE服务”的处理方法包括如下步骤：

步骤2.1：“CACHE服务”接收到分片请求后，首先需要检查请求是否跨分片，如果跨分片，则直接拒绝服务，返回错误信息并结束；如果没有跨分片，则将当前的请求URL以及按照slice size对齐的分片起始和结束位置组合成key，检查其缓存中是否有当前请求块的内容；

步骤2.2：如果本地缓存中找到对应分片的内容，则从缓存中获取该内容，并跳转到请求的起始字节偏移位置对应的字节开始向“代理服务”发送视频分片内容，直到所要求的所有字节发送完毕，整个过程处理完毕；

步骤2.3：如果本地缓存中没有找到对应分片的内容，则“CACHE服务”向源站发起类似于“代理服务”向“CACHE服务”发起的获取分片的请求；

步骤2.4：“CACHE服务”获取到源站发送过来的分片内容，“CACHE服务”首先将内容用以上步骤2.1计算出来的缓存key,以URL和本机部署的磁盘列表进行一致性哈希计算，选中其中一个磁盘后，将内容以缓存key作为存储路径，存储到对应的磁盘中；其次，分片内容在落盘的同时，向“代理服务”发送所需的分片中的数据；

第五步：CACHE服务将视频的内容请求作用于视频源，下载视频内容。

2.根据权利要求1所述的一种MP4视频流媒体点播的分片缓存加速方法，其特征在于：在第四步中，业务代理层发送过来的内容的分片请求，如果请求的内容在缓存中不能命中，则会自动回源到源站进行分片内容的获取，否则由本身的磁盘缓存直接为业务代理层提供服务。

3.根据权利要求1所述的一种MP4视频流媒体点播的分片缓存加速方法，其特征在于：在第四步中，CACHE层通过CACHE服务基于一致性哈希算法将缓存请求内容打散分配到不同的磁盘进行存储，结合代理服务到CACHE服务的一致性哈希，通过将内容分片进行两层的一致性哈希，消除集群内“热点”设备引起的性能瓶颈。

4.根据权利要求1所述的一种MP4视频流媒体点播的分片缓存加速方法，其特征在于：在步骤1.2中，向“CACHE层”发起的请求，严格地控制在一个分片内。

5.根据权利要求1所述的一种MP4视频流媒体点播的分片缓存加速方法，其特征在于：在步骤1.5中，对视频播放起始位置进行定位时，用stts box查找用户的播放起始时间对应的音视频帧的sample,并通过stss box找到与起播时间最近的视频关键帧的位置，最后通过stsz box中的每个sample的长度计算最终要发送给终端的mdat中的音视频帧对应的文件偏移量。