背景技术
对等网络(P2P,Peer to Peer)流媒体的应用是在P2P文件交换的基础上发展起来的,P2P文件交换是用户从服务器将需要的文件(如视频流媒体)进行下载,当文件下载完成后,用户就可以使用该文件,如观看下载的视频流媒体。而P2P流媒体技术的应用,可以使用户在观看视频流媒体(可以不是一个完整的视频流媒体)的同时,与观看该视频流媒体的其它用户之间进行资源共享利用,该用户可以从这些观看该视频流媒体的其它用户中同时下载该视频资源,实现边下载边播放。因此,相对于P2P文件交换技术,其资源利用效率更高,下载速度更快,而且,P2P流媒体技术,并不需要将一个文件全部完整的下载完成后才能供用户使用,用户可以一边播放一边下载;进一步地,P2P流媒体文件在播放完后,并不保存在电脑硬盘上,可以很好地保护流媒体播放内容的版权。
P2P流媒体技术作为因特网(Internet)上一种高效的流媒体服务技术,被众多的大学、科研院所以及公司等机构等采用,基于P2P流媒体技术,这些大学、科研院所以及公司提出了多种P2P流媒体系统设计方案,例如,CoopNet、PROMISE、P2Cast等P2P流媒体系统设计方案。下面对目前提出的三种基于P2P的流媒体系统作简要介绍。
第一种基于P2P的流媒体技术的系统为纯P2P流媒体系统,在该系统中,没有专用服务器,任何一个节点均可提供流媒体文件及内容(流媒体对象),而流媒体文件的组织和查找可基于Pastry、Chord、CAN等传统P2P网络。其特点是,该系统的流媒体文件及内容源于不同的用户节点,不便于管理;而且,不同用户节点保存有不同的流媒体文件及内容,存在版权问题,因而不适合于用于商业模式。
第二种基于P2P的流媒体技术的系统为混合方式的P2P流媒体系统,在该系统中,设有专用的流媒体服务器提供流媒体文件及内容。因此,便于对流媒体文件及内容进行统一的管理,有利于版权保护,适用于商业模式。
第三种基于P2P的流媒体技术的系统为P2P流媒体组播系统,通过在P2P网络的对等节点上构建应用层组播树,用于传播实时流媒体内容。实际应用中,由于对等节点的性能、用户节点加入与退出的随机性以及流媒体服务质量(Qos,Quality of Service)要求等因素影响,P2P流媒体组播树的构建过程并不等同于一般的应用层组播。根据其服务模式及网络模型划分,目前的P2P流媒体组播系统模型又可以分为以下三类模型。
第一类模型:单多播树的视频流媒体网络模型,即单对多模式。适合实时的热点流媒体节目直播,是目前最为流行的技术方案,代表软件为ESM、ZigZag、DirectStream、P2Cast等。
第二类模型:多个多播树的视频流媒体网络模型。适合提供不同质量的视频流媒体节目,其视频流媒体对象可以从多个视频流媒体对象服务提供者获得,该模型稳定性高,实用性好,代表软件有PROMISE、CoopNet、GNUStream等。
第三类模型:基于网状结构的视频流媒体网络模型,是第一类模型和第二类模型的混合模型,通过缓存流媒体对象以服务其他节点,可以最大限度的利用网络节点的服务能力,进一步改进流媒体系统的稳定性和可用性,代表软件有DONet,PPLIVE等。
流媒体缓存技术的应用大大降低了流媒体服务器的负载,有效减少了Internet网络的数据传输量,因而,降低了用户可察觉的延迟、提高了可感知播放质量。实际应用中,通过提高流媒体缓存技术,可以进一步改进流媒体系统的稳定性和可用性,因此,下面对影响流媒体缓存效果的主要因素作简要介绍和分析。
(1)流媒体系统缓存空间。流媒体系统缓存空间对缓存效果有着直接的影响,当缓存空间有限时,所容纳的流媒体对象数就较少,需要进行更多的置换操作才能将需要的流媒体对象进行缓存,即需要不断将缓存的流媒体对象进行置换,以容纳新的流媒体对象,影响了缓存使用效率;当增大缓存空间时,所容纳的流媒体对象数也增多,可以在缓存中找到用户所请求流媒体对象的概率也随之增大,但同时,缓存空间的增大也会造成查找该流媒体对象缓存信息(如流媒体文件、内容、大小及其它记录信息)所需的时间增长,降低了系统的反应速度,同时增加了缓存设备硬件的投入,增加了成本。
(2)缓存存储策略。存储策略是指缓存信息在缓存中的存储组织方式,目前,通过对缓存流媒体对象全缓存策略的研究,发现流媒体对象的特性和用户节点的访问模式特点决定了将一个完整的流媒体对象缓存到一个缓存中的代价是相当大的,即使在集群缓存环境中,其缓存的代价也是居高不下。
因此,为了降低一个完整的流媒体对象缓存到一个缓存中的代价,现有技术中提出了部分缓存策略的概念,并得到普遍使用。部分缓存策略包括分段缓存策略和前缀缓存策略,在分段缓存策略中,将被请求的流媒体对象分成多个连续且互不重叠的部分,每个部分称为一个段。进行流媒体对象缓存时,以段为基本单位,每个段对应一个连续的帧序列,各段可以分别进行缓存和管理;在采用前缀缓存策略时,从流媒体对象的开头部分开始缓存。
基于分段缓存策略和前缀缓存策略结合起来的另一种存储策略是基于分段的前缀缓存策略。在该缓存策略中,将流媒体的每个缓存段进行前缀缓存,这样,段可以被独立进行前缀缓存,因而可以节省缓存服务器大量的磁盘空间,并可以将节省的磁盘空间有效地用于缓存大片段的受用户欢迎的流媒体部分。
(3)缓存放置和置换策略。缓存放置和置换策略所要考虑的内容如下:当系统中存在有多个缓存设备(节点)时,如何对这些缓存设备进行管理,所获得的流媒体对象放置在哪个缓存设备中;当有新的流媒体对象需要进行缓存但缓存设备又没有足够的可用空间时,如何选择缓存中需要删除的流媒体对象。
现有的缓存置换策略包括先进先出置换算法(FIFO,First IN First Out)、最近最少使用置换算法(LRU,Least Recently Used)、最近最不常用置换算法(LFU,Least frequently Used)、SIZE置换算法等,但这些缓存置换策略,都只考虑了时间局部性、流媒体对象大小等常规因素,实验表明,其缓存置换效果并不理想。
目前,对于网页(Web)的缓存置换策略算法,主要是基于键值比较或是基于预测的缓存置换算法。
1)基于键值比较的缓存置换算法
缓存置换算法的键值可以有多个,其中,其最重要的键值称为主键值,其余的键值称为从键值。其缓存置换思想是根据键值大小对缓存的流媒体对象被淘汰的次序进行排列,当主键值相等时,依次使用从键值。基于键值比较的缓存置换策略首先淘汰最小键值的缓存的流媒体对象,然后淘汰次小键值的缓存的流媒体对象,直到获取的缓存空间足够容纳新的流媒体对象为止。
基于键值比较的缓存置换算法遵循排序置换的原则,比较容易实现。
表1列出了目前已有的一些基于键值比较的Web缓存置换算法,并列出了它们使用的键值类型及键值个数。
表1基于键值比较的Web缓存置换算法键值
算法 |
主键 |
第二从键 |
第三从键 |
LRU |
最后访问时间 |
空 |
空 |
LRU-k |
第k次访问时间 |
空 |
空 |
LFU |
访问频率 |
空 |
空 |
LFU-aging |
访问频率 |
对象年龄 |
空 |
SIZE |
对象大小 |
最后访问时间 |
空 |
Log(size) |
Log(size) |
最后访问时间 |
空 |
HYPER-G |
访问频率 |
最后访问时间 |
对象大小 |
P/R |
最后访问时间 |
对象大小 |
空 |
LLF |
下载时间 |
空 |
空 |
HyBird |
函数值 |
空 |
空 |
GD-Size |
函数值 |
空 |
空 |
GDSF |
函数值 |
空 |
空 |
其中,
LRU算法,是最流行的缓存置换算法之一,它将最长时间没被访问过的缓存的流媒体对象淘汰,该算法基于刚被访问的流媒体对象很快将再次被访问,即基于时间局部性理论。
LRU-K算法,是改进的LRU算法,它淘汰距离倒数第K次被访问时间最远的流媒体对象。当K取1时,即为LRU算法。
LFU算法,该算法保存流行的流媒体对象,淘汰或置换访问次数最少的流媒体对象,也就是置换出最少使用的缓存的流媒体对象。但是该算法存在缓存污染(Cache Pollution)的问题:即当一个流行的流媒体对象变得不再流行时,但该流媒体对象仍将保留在缓存中很长一段时间,因而阻止了其它新的流行的流媒体对象来置换它。对于如何解决该算法的缓存污染,传统的LFU算法策略还没有提供任何解决的机制。
LFU-aging算法,是LFU算法置换策略的一个变种算法。它同时考虑了流媒体对象的访问频率和流媒体对象驻留在缓存中的年龄。通过考虑流媒体对象驻留在缓存中的年龄,解决了“缓存污染”问题,但另一方面,该算法没有考虑到缓存的流媒体对象大小。
SIZE算法,该算法策略淘汰缓存中最大的流媒体对象。通过置换出缓存中最大的流媒体对象,增加了小流媒体对象缓存的机会,因而提高了流媒体对象命中率,但影响了字节命中率。此外,该算法的另一个缺点是一些缓存的流媒体对象,几乎没有被访问或很少被访问,却占用系统的缓存空间,同时也具有“缓存污染”问题。
LRU-Threshold算法(表中未列出),和LRU算法基本一样,不同的是,它考虑了需要缓存的流媒体对象大小,即要求流媒体对象大小必须小于一个阀值才能被缓存。
Log(size)算法,该算法淘汰log(size)值最大的流媒体对象。如果流媒体对象具有相同的log(size)大小,将最近最少使用的流媒体对象进行置换。
LRU-MIN算法(表中未列出),该算法是对LRU算法的改进,首先定义一个流媒体对象大小S,并认为大于该流媒体对象大小S的流媒体对象不适合进行缓存。因此,当流媒体对象大于S,则置换出该流媒体对象;如果没有,则按照LRU算法置换出流媒体对象大小为S/2的流媒体对象,如果没有S/2大小的流媒体对象,则置换出流媒体对象大小为S/4的流媒体对象,直到缓存空间能够满足容纳新的流媒体对象。该算法考虑了流媒体对象的大小,但却没有考虑到流行度等因素。
Hyper-G算法,为LFU算法的另一种改进算法,与LFU算法不同的是,它还考虑了最后访问时间和缓存的流媒体对象大小。
Pitkow/Recher(P/R)算法,该算法淘汰最近最少使用的流媒体对象。如果所有的流媒体对象在同一天被访问,则置换缓存中最大的流媒体对象。
Lowest-Latency-First(LLF)算法,该算法的目标是使平均延迟最小化。通过记载每个缓存的流媒体对象的最近下载时间,根据记录的下载时间,置换或移去最早下载的流媒体对象。
Hybrid算法,该算法通过为每个流媒体对象定义一个函数,首先置换包含最小函数值的流媒体对象。
举例来说,对于一个位于服务器M的流媒体对象P,假设连接到服务器的时间为Cs;到服务器M的带宽为Bs;流媒体对象P在缓存中被访问的次数为Np,以及流媒体对象P的大小为Zp,则Hybrid算法为该流媒体对象定义的函数为:
((Cs+Wb/Bs)(Np)Wn)/Zp
其中,Wb、Wn均为常数。
GD_Size算法,该算法综合考虑了缓存的流媒体对象大小、获取该流媒体对象的网络开销因素以及用户节点访问的局部性特性,与单纯考虑用户节点访问局部性的算法比较,在性能上有很大的提高。
GDSF算法,该算法通过提供一个频率计数来对GD_Size算法进行进一步改进。其计算公式为:
K(d)=L+F(d)*C(d)/S(d)
其中,K(d)代表权值,L代表平滑参数。
F(d)为对象d的访问频率计数,如果流媒体对象d在缓存中命中,则F(d)=F(d)+1。
C(d)为将该流媒体对象放入到缓存中的代价,当C(d)=1时,GDSF取得最好的缓存命中率,即LFUDA算法。
S(d)为对象d的大小。
2)基于预测的Web缓存置换算法
实际应用中,通过统计分析发现,Web请求是具有一定的可预测性的,因此研究基于预测的Web缓存置换算法成为热点。该算法的原理是通过预测,将即将访问的流媒体对象保留在缓存中,而将未来不访问的流媒体对象或很长时间才会被访问的流媒体对象淘汰出缓存,从而提高缓存的命中率。如果该算法预测性相对准确,则可以大大提高被访问的流媒体对象的命中率,并有利于根据该算法进行相应的预测工作,以使系统达到更好的性能。但如果该算法预测准确率较低的话,则访问流媒体对象的命中率也随之降低。
常用的基于预测的Web缓存置换算法有以下几种:
基于马尔可夫模型的算法:该算法仅仅是基于时间的预测算法,因此预测的准确性不高。相关的文献研究表明,该算法预测的准确性为大约30%。
基于路径的预测模型:1996年,Kroeger和Long通过追踪文件打开事件来研究文件系统日志,其缓存命中率比LRU平均高15%。1998年,Schechter等通过路径文件,根据用户先前的请求序列来预测用户的下一请求,结果表明:在最好的情况下,其模型预测准确性为53%-76%;在最坏情况下,其预测准确性为40%-45%。
N-gram预测算法:它是一种基于路径的另一预测算法,由Su等学者在2000年提出,通过考虑历史访问记录中最长的匹配来预测用户的下m个请求。如果没有k长度的模式被匹配,则依次匹配k-1,k-2,......,1长度模式。当m=1时,该预测算法的预测准确性仅为14%。
从上述Web缓存置换算法可以看出:
(1)典型的Web对象大小通常只有几K至几十K字节大小,故Web缓存置换的基本单元一般为完整的对象;而流媒体对象通常比Web对象大得多,因此,如果以整个流媒体对象作为缓存置换的基本单元显然是不合适的,所以需要对Web的缓存置换算法加以改进,才能应用到流媒体。
(2)当前Internet上流媒体对象多为静态流媒体对象,通常都具有一次写多次读(WORM)的性质,当将静态流媒体对象放置在Internet上后,通常很少改变其WORM的性质。因此在流媒体网络缓存中,缓存的一致性并不是非常重要的问题,可以在一定程度上简化流媒体代理缓存系统的设计。
(3)在用户浏览模式上,通过研究发现,流媒体用户通常通过浏览流媒体的最初部分,再决定是否全部观看流媒体。因此在设计流媒体代理缓存系统时需要考虑到对用户浏览模式的适应,可能不需要将整个流媒体对象进行一次性的缓存。
由于上述特性的存在,使得流媒体缓存置换不能直接利用传统的Web缓存置换技术,而必须开发一种适用于流媒体的网络缓存置换技术。
目前,大多数研究都采取将流媒体对象进行分段缓存置换的方法,结合Web缓存置换算法研究成果,即针对流媒体对象特征改进现有的Web缓存置换算法,通过减少置换粒度来提高置换精度和缓存空间的利用效率。主要的流媒体缓存置换算法有如下几种:
HistLRUpick算法,是改进的LRU-k算法,应用于MiddleMan系统,该算法的优点是充分考虑了负载平衡因素和缓存置换功能。MiddleMan采用了集群体系结构,前端机负责定时根据节点机负载状况,如根据节点机在一段时间内转发的数据字节数、峰值连接数和带宽利用率确定负载状况。并选择其中一台节点机执行置换操作,通常选择的是最近一段时间内负载最轻的一台节点机作为置换操作的对象。被选中的节点机通过运行LRU-2、LRU-3和LRU-4算法来执行置换操作。
细粒度置换策略算法,应用于Mocha缓存系统中,采用了一种细粒度的置换策略,这种策略尤其适用于采用分层编码的流媒体格式数据。该策略分别计算每一层的流行度,流行度的计算既考虑用户对该层流媒体的兴趣,也考虑用户端到缓存代理端的网络带宽。通常,较低层的流媒体数据具有较高的流行度,而较高层的流媒体数据具有较低的流行度,相对来说,较高层的流媒体数据也较容易被置换出缓存区。这种置换策略与其它置换策略相比更精确高效,但是实现起来也更为复杂,执行策略算法需要的代价也较高。
基于缓存的资源算法(RBC,Resource Based Caching),该算法既考虑了缓存的流媒体对象大小,又考虑了传送该流媒体对象所需的磁盘输入输出(I/O,Input/Output)带宽。该算法试图有效地利用有限的系统资源,包括磁盘空间和磁盘带宽,并在磁盘空间和磁盘I/O带宽之间取得一个平衡:既要保持磁盘空间利用率和磁盘带宽利用率基本相同,又必须置换缓存中那些最远的未来才会使用的流媒体对象。
基于代价的缓存置换算法,该算法充分考虑了网络代价(缓存代理端到媒体服务器获取流媒体对象所需的网络资源)、启动延迟代价(从媒体服务器获得特定流媒体对象前缀所需的网络延迟时间)、媒体失真代价(淘汰该流媒体对象将造成的播放失真)等因素。在缓存空间紧张时,淘汰具有最低代价的缓存的流媒体对象。实际的测试也表明该算法比其他算法性能上有较大提高。
基于段的缓存置换算法,应用于基于段的流媒体缓存代理服务器,该算法为每个段计算一个缓存值,表示为这个段的引用频率和段距离流媒体对象头部的偏移长度的比值。该算法与基于段的缓存策略的设计意图非常吻合:流媒体初始段和流行度高的段具有较高的优先级。
由上述可以看出:
(1)传统的缓存置换算法以提高缓存命中率为性能优化指标,对于流媒体服务器,用户接收的媒体质量、用户的启动延迟以及多媒体数据对网络的消耗是流媒体服务器的主要指标,因此传统的缓存置换算法难以满足流媒体服务器的要求。
(2)目前的流媒体缓存置换算法,只是单独考虑影响缓存效果的某个因素,如流行度,传输代价,缓存增益等,而没有综合考虑这些因素来制定一个可行的缓存置换算法。
(3)目前,大多缓存置换算法对于流媒体的流行度的计算不是很全面,例如,有的单纯根据历史的点击次数进行计算,因此,假使在一段时间以后流媒体对象已经不流行了,但是由于其历史点击率很高,还将会在缓存中缓存较长时间才会被置换,甚至不会被置换,占用了系统的资源,造成系统资源利用率低。
(4)目前,大多的缓存置换算法针对的是传统的C/S结构的流媒体系统,还没有针对混合P2P流媒体系统的缓存置换算法。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明作进一步详细说明。
本发明实施例通过CDN Server接收客户端节点发送的包括客户端节点要求发送的流媒体对象的请求,获取所述客户端节点要求发送的流媒体对象,当CDN Server判断当前的缓存空间小于客户端节点要求发送的流媒体对象的大小时,触发缓存置换算法;根据缓存中流媒体对象长期流行度和近期流行度因素,计算流媒体对象流行度;并从缓存的列表记录中获取该流媒体对象的副本数量、大小及网络延迟,计算该流媒体对象置换因子,置换因子的大小对应流媒体对象应该被置换的优先级大小,置换缓存中应该被置换的优先级大的流媒体对象。
本发明实施例结合流媒体服务的特点和客户端节点的请求状态,最大程度上利用客户端节点的缓存,考虑负载均衡,提出的针对流媒体代理服务器端的缓存置换算法。缓存置换算法综合了流媒体服务质量的各个因素,如流行度、对象的网络延迟、对象的大小及其副本的数量,根据缓存利益/代价模型进行缓存置换。
为了实现上述目的,本发明实施例提出了一种实现流媒体缓存置换的系统。
图1为本发明实施例一种实现流媒体缓存置换的系统结构示意图。本实施例为基于CDN和P2P技术的混合流媒体系统,图中,客户端节点的大小表示其传输能力和带宽。参见图1,包括CDN服务器(CDN Server)和客户端节点,其中,
CDN Server,用于缓存流媒体对象以及对等节点(客户端节点)的目录信息,接收客户端节点发送的包括客户端节点要求发送的流媒体对象的请求,获取客户端节点要求发送的流媒体对象,确定已获取该流媒体对象并确定没有足够的剩余空间缓存该流媒体对象,触发缓存置换算法,根据缓存中流媒体对象长期流行度和近期流行度因素,计算流媒体对象流行度;并从缓存的列表记录中获取缓存的流媒体对象的副本数量、大小及网络延迟,计算流媒体对象置换因子,置换因子的大小对应流媒体对象应该被置换的优先级大小,用已获取的该流媒体对象置换应该被置换的优先级大的流媒体对象,向客户端节点发送请求的流媒体对象;
客户端节点,用于接收其它客户端节点发送的流媒体对象请求,如果缓存有该流媒体对象,为发送请求的客户端节点提供该流媒体对象;向CDNServer及其它客户端节点发送流媒体对象请求,接收CDN Server及其它客户端节点返回的流媒体对象。
客户端节点在上述过程中存在有三种状态:①请求流媒体对象传输状态;②流媒体对象服务状态,获得流媒体对象后,可以为其它节点提供服务;③空闲状态:当提供服务的任务完成后,进入空闲状态。
上述系统中的内容分发网络服务器还可以进一步用于设置成本函数算法,用于根据计算出的成本函数值大小决定应该被置换的流媒体对象。该算法根据请求的流媒体对象序列对应的状态序列计算成本函数,状态序列ψk(k=1,2,...,m)表示第k个流媒体对象请求到达后缓存中所存储的流媒体对象状态的集合,可以用ψ0表示缓存的最初状态,即没有缓存任何流媒体对象的状态。如果计算出的成本函数值越小,表明越应该置换出该成本函数对应的流媒体对象序列,并找出使成本函数值最小的状态序列,用已获取的流媒体对象置换缓存中成本函数值最小的状态序列。
图2a为本发明实施例一种实现流媒体缓存置换的设备结构示意图。参见图2a,该设备包含:接收单元、判断单元、流媒体对象流行度计算单元、流媒体对象置换因子计算单元、缓存单元及发送单元,其中,
接收单元,用于接收客户端节点发送的流媒体对象请求,并根据流媒体对象请求从因特网获取客户端节点要求发送的流媒体对象;
缓存单元,用于缓存流媒体对象及其信息,流媒体对象信息包括:资源索引号(HASH)、流媒体对象名称、发布者、流媒体对象在缓存中存放位置、流媒体对象的大小、所属节点集合(流媒体对象副本的数量)、累计访问的次数(LTimes)、直播的频道号(GUID)、开始时间、结束时间、流媒体对象长期流行度和近期流行度及流媒体对象的网络延迟等。
判断单元,用于判断客户端节点要求发送的流媒体对象的大小是否大于缓存单元剩余的缓存空间,并输出肯定或否定的判断结果;流媒体对象流行度计算单元,用于当判断单元的判断结果为是时根据设置的流行度计算公式从缓存单元读取已缓存的流媒体对象的长期流行度和近期流行度,得到已缓存的每一流媒体对象的流行度;
发送单元,用于当判断单元的判断结果为否时,将所述客户端节点要求发送的流媒体对象发送缓存单元;
流媒体对象置换因子计算单元,用于根据设置的置换因子计算公式,根据流媒体对象流行度计算单元得到的流媒体对象流行度,以及从缓存单元读取的流媒体对象信息,比如流媒体对象的大小、流媒体对象副本的数量、流媒体对象的网络延迟等,计算已缓存的流媒体对象置换因子,置换因子的大小对应已缓存的流媒体对象应该被置换的优先级大小,流媒体对象置换因子被发送至缓存单元,缓存单元将客户端节点要求发送的流媒体对象置换缓存单元中应该被置换的优先级大的流媒体对象。
缓存单元置换完成后,发送单元将客户端节点要求发送的流媒体对象发送至客户端节点。
在本发明的另一实施方式中,可以去掉流媒体对象流行度计算单元,由流媒体对象置换因子计算单元根据已缓存的流媒体对象的长期流行度和近期流行度获取已缓存的流媒体对象的流行度,然后根据已缓存的流媒体对象的网络延迟、副本数量、大小及流行度,计算已缓存的流媒体对象置换因子。
图2a中设备还可进一步包含:成本函数计算单元,用于设置成本函数计算公式,根据请求的流媒体对象序列对应的状态序列计算成本函数并找出使成本函数值最小的状态序列,将该状态序列发送至缓存单元,缓存单元用接收的流媒体对象置换缓存中的该状态序列。
图2b为本发明实施例一种实现流媒体缓存置换的系统结构示意图。参见图2b,该系统包括:内容分发网络服务器和客户端节点,其中,
内容分发网络服务器包括接收单元、判断单元、流媒体对象置换因子计算单元及缓存单元;
接收单元,用于接收客户端节点发送的流媒体对象请求,并根据所述流媒体对象请求从因特网获取客户端节点要求发送的流媒体对象;
缓存单元,用于缓存流媒体对象及其信息,所述流媒体对象信息包括网络延迟、副本数量、大小及流行度;
判断单元,用于判断客户端节点要求发送的流媒体对象的大小大于缓存单元剩余的缓存空间,并输出肯定或否定的判断结果;
流媒体对象置换因子计算单元,用于根据从缓存单元获取网络延迟、副本数量、大小及流行度,计算已缓存的流媒体对象置换因子,置换因子的大小对应已缓存的流媒体对象应该被置换的优先级大小;缓存单元将客户端节点要求发送的流媒体对象置换缓存单元中应该被置换的优先级大的流媒体对象。
实际应用中,内容分发网络服务器还可以包括流媒体对象流行度计算单元,用于当判断单元的判断结果为是时,根据已缓存的流媒体对象的长期流行度和近期流行度获取已缓存的流媒体对象的流行度。
较佳地,内容分发网络服务器还可以进一步包括发送单元,用于缓存单元置换完成后,将客户端节点要求发送的流媒体对象发送至客户端节点。
内容分发网络服务器还可以进一步包括成本函数算法单元,用于根据请求的流媒体对象序列对应的状态序列计算成本函数并找出使成本函数值最小的状态序列,用已获取的流媒体对象置换缓存中成本函数值最小的状态序列。
图3为本发明实施例CDN Server与请求客户端节点之间的行为关系流程示意图。本实施例中,混合P2P流媒体的CDN Server(CDN Server)通常部署在网络服务提供商(ISP,Internet Service Provider)网络的关键位置,用于进行代理缓存(Proxy Cache);请求客户端节点(Peer节点)为流媒体传输请求的发起者,硬件配置比较高(例如,内存大于256M,CPU频率大于1.8GHZ),有一定的缓存能力。参见图3,该流程包括:
步骤301,请求流媒体服务的客户端节点A向其它客户端节点以及CDNServer发起流媒体服务请求,请求流媒体对象X;
本步骤中,请求流媒体服务的客户端节点A向CDN Server及其它客户端节点发起流媒体服务请求,即请求下载被请求对象所缓存的自己需要的文件片段,也就是请求自己需要的流媒体对象,本所实施例中,假设客户端节点要求发送的流媒体对象记为流媒体对象X。
步骤302,CDN Server接收请求流媒体对象X的流媒体服务请求,记录流媒体对象X;
本步骤中,CDN Server接收到服务请求,记录流媒体对象X;其它客户端节点接收到服务请求,如果缓存有客户端节点A需要的流媒体对象X,将流媒体对象X传输至该客户端节点A,否则,该流媒体服务请求失败。
步骤303,CDN Server判断是否已缓存流媒体对象X;
CDN Server判断如果已缓存流媒体对象X,从缓存中读取流媒体对象X,向客户端节点A传输;如果CDN Server判断还没有缓存流媒体对象X,执行步骤304。
实际应用中,可以采用基于段的前缀缓存置换策略,即先将流媒体文件进行分段,然后对分出的流媒体数据段采用前缀缓存的策略进行缓存,本实施例中,流媒体文件的分发采用传统的P2P文件的分发方法(如:BitTorrent),即等长分发,将每个流媒体数据段作为单独的流媒体对象进行统计,不考虑整个流媒体文件的各个流媒体数据段之间的相关性。如果CDN Server采用直播方式,在CDN Server记录的流经ISP网内部的所有访问的流媒体对象记录格式如表2所示,包括资源索引号(HASH)、流媒体对象名称、发布者、流媒体对象在缓存中的存放位置、流媒体对象的大小、所属节点集合(流媒体对象副本的数量)及累计访问的次数(LTimes);如果CDN Server采用交互式点播方式,在CDN Server记录的流经ISP网内部的流媒体数据记录格式如表3所示,包括直播的频道号(GUID)、开始时间、结束时间、流媒体对象在缓存中的存放位置、流媒体对象的大小、所属节点集合(流媒体对象副本的数量)及累计访问的次数(LTimes)。
表2直播方式所有访问的流媒体对象的记录格式
资源索引号(HASH) |
流媒体对象名称 |
发布者 |
流媒体对象在缓存中的存放位置 |
流媒体对象的大小 |
所属节点集合(流媒体对象副本的数量) |
累计访问的次数(LTimes) |
表3交互式点播方式所有访问的流媒体对象的记录格式
直播的频道号(GUID) |
开始时间 |
结束时间 |
流媒体对象在缓存中的存放位置 |
流媒体对象的大小 |
所属节点集合(流媒体对象副本的数量) |
累计访问的次数(LTimes) |
同时在CDN Server记录已缓存的流媒体对象的信息,记录的格式如表4所示,包括资源索引号(HASH)/直播的频道号(GUID)、流媒体对象在缓存中的存放位置、流媒体对象的大小、所属节点集合(流媒体对象副本的数量)、缓存以后访问的次数(STimes)及从源服务器获取的平均延迟时间B(V)。
表4已经缓存的流媒体对象记录表格式
资源索引号(HASH)/直播的频道号(GUID) |
流媒体对象在缓存中的存放位置 |
流媒体对象的大小 |
所属节点集合(流媒体对象副本的数量) |
缓存以后访问的次数(STimes) |
从源服务器获取的平均延迟时间B(V) |
每个CDN Server统计本ISP网络内的客户端节点请求的流媒体对象资源的状况,用于缓存和缓存置换流媒体对象的依据。具体记录的参数如表5和表6所示,表中,V为某个流媒体对象,ψk-1为当前已缓存的流媒体对象集合。
表5统计的各个参数的标识符及其含义
符号 |
含义 |
Size(V) |
流媒体对象V的大小 |
CN(V) |
所属节点集合元素的个数(系统管理更新,获取)或流媒体对象V副本的数量 |
LTimes(V) |
流媒体对象V累计访问次数(从第一次访问以来),初值为0 |
STimes(V) |
流媒体对象V缓存以后被访问的次数,在每次置换算法执行后随着变化,记录自上次缓存操作执行后被访问的次数,初始值为LTimes(V) |
B(V) |
流媒体对象V的平均网络延迟 |
表6统计的全局区参数及其含义
Tl |
每次缓存置换操作发生的时刻,放在全局区保存 |
R(min(ψk-1)) |
当前缓存中最小的置换因子,上一次缓存置换操作保留,初值为0 |
步骤304,判断是否已获取流媒体对象X,如果没有,向Internet请求流媒体对象X,执行步骤305a;如果已获取流媒体对象X,执行步骤305b;
步骤305a,接收Internet返回的流媒体对象X,执行步骤305b;
步骤305b,判断CDN Server缓存空间是否有足够的剩余空间,如果CDNServer缓存空间已满,按照设定的缓存置换算法执行置换流程;如果CDNServer缓存空间未满,缓存流媒体对象X;
步骤306,CDN Server向客户端节点A传输流媒体对象X。
图4为本发明实施例设定缓存置换算法的流程示意图。参见图4,本实施例中,假定O是用户可访问的所有流媒体对象的集合,对于每一个流媒体对象g(v)∈O,设定该流媒体对象g(v)的大小为Size(g(v)),访问该g(v)的成本为Cost(g(v)),其流行性为P(g(v)),在本网络内副本的数量,即所属节点集合的数目为CN(g(v)),平均网络延迟为B(g(v))。假定每个CDN Server缓存的空间大小为S,该流程包括:
步骤401,CDN Server接收到客户端节点请求的流媒体对象Vk,判断是否触发缓存置换算法;
本步骤中,CDN Server接收到客户端节点请求的流媒体对象Vk,如果缓存有该请求的流媒体对象Vk,将该请求的流媒体对象Vk向客户端节点发送;如果没有,向因特网请求该流媒体对象Vk,接收因特网返回的流媒体对象,判断CDN Server缓存的所有流媒体对象以及接收的流媒体对象所占的空间总和是否大于或等于S,即接收的流媒体对象是否大于S剩余的缓存空间,如果不大于,将请求的流媒体对象Vk进行缓存;如果是,CDN Server触发缓存置换算法。
步骤402,计算流媒体对象流行度;
本步骤中,在计算流媒体对象流行度时,综合考虑流媒体对象长期流行度和近期流行度因素。定义流媒体对象长期流行度为:自流媒体对象被缓存以来,该流媒体对象被访问的频度;定义流媒体对象近期流行度为:该流媒体对象最近一段时间被访问的频度。
流媒体对象流行度P(g(v))的计算公式如下:
P(g(v))=Pl(g(v),n)*(1-α)+Ps(g(v),n,l)*α (1)
其中,pl(g(v),n)表示流媒体对象g(v)的长期流行度,参数n表示流媒体对象g(v)被点播的次数,即被累计访问的次数,其值为LTimes(g(v)),从CDN Server的统计表中获得;Tn-T0表示该流媒体对象自第一次访问以来的时间段,将LTimes(g(v))除以Tn-T0即得到pl(g(v),n)。
Ps(g(v),n,l)表示已缓存的流媒体对象g(v)的近期流行度,即自上一次置换操作执行以来该流媒体对象的访问频率;Tn-Tl表示该流媒体对象自上一次置换操作执行以来的时间段;STimes(g(v))表示自上次缓存置换操作执行以来该流媒体对象的访问次数。
本实施例通过综合考虑流媒体对象长期流行度和近期流行度因素来计算已缓存的流媒体对象的流行度,可真实反映已缓存的流媒体对象的此时的访问频率,防止流媒体对象流行度近期生较大变化时,导致曾被多次访问的流媒体对象,由于其较高的历史访问频度而占据缓存空间(即“缓存污染”),进而导致新的流媒体对象没有缓存空间。
α是平衡因子,其值小于1。通过调整α值,可以调整长期流行度和近期流行度之间的相对重要程度。
步骤403,根据已缓存的流媒体对象的流行度及已缓存的流媒体对象的其他信息,比如流媒体对象的大小、流媒体对象副本的数量、流媒体对象的网络延迟等,计算流媒体对象置换因子;
对于缓存置换因子R(g(v))的计算,即对当前缓存中的流媒体对象进行置换因子的计算,其计算公式为:
式(4)是基于利益/代价模型,即:
本步骤中,可以在每次启动算法时,对缓存中的所有流媒体对象进行计算,也可以根据实际情况对其进行调整,例如在一定时间段内考虑到置换因子变化不大,则可以设置一定时间间隔,在此时间间隔内,对上次启动计算后仍保留在缓存中的流媒体对象的置换因子不用重新计算。
实际应用中,考虑到置换因子计算公式中的流媒体对象流行度和流媒体对象的副本数量与流媒体对象在缓存中所存储的时间有直接关系,每次执行置换算法的时候,上次没有替换掉的流媒体对象的流行度和流媒体对象的副本数量随着时间会有所变动。为了更精确描述置换因子,本实施例中,在每次启动算法时,对缓存中的所有流媒体对象进行重新计算,
式(5)中,缓存利益代表缓存该流媒体对象的好处,缓存利益越大表示缓存该流媒体对象所获取的利益越大,即越应该缓存该流媒体对象;缓存代价表示为缓存该流媒体对象所付出的代价,缓存需要的代价越大,说明越不应该缓存该流媒体对象。
式(4)中,缓存利益综合考虑了流媒体对象流行度和预取流媒体对象的网络代价(流媒体对象的网络延迟)两个因素,流媒体对象流行度越高,说明缓存该流媒体对象就越能满足多用户端的需求,即缓存利益越大;预取流媒体对象的网络代价越高,说明如果置换了该流媒体对象,将来获取它需要付出较大的代价,反之,如果保留该流媒体对象,则实际减少了如果置换该流媒体对象后再次获取该流媒体对象需要的代价,也就是相当于产生了缓存利益。
式(4)中,缓存代价也综合考虑了缓存流媒体对象的大小(流媒体对象缓存需要占用的磁盘空间)和该流媒体对象在该CDN Server网络服务提供商(ISP,Internet Service Provider)内副本的数量两个因素。
实际应用中,对于CDN Server(缓存服务器),磁盘缓存空间和网络带宽资源是最宝贵的系统资源,网络带宽资源在缓存利益中已得到考虑,故缓存代价中主要考虑磁盘缓存空间资源。如果一个流媒体对象占用的磁盘缓存空间过大,其被置换出该缓存的概率也应该相应增加,这样可以有效避免缓存服务器宝贵的磁盘缓存资源被少数几个大空间的流媒体对象占用的不公平状况发生;流媒体对象副本的数量是指该流媒体对象在该CDN Server的网络内部拥有该流媒体对象的客户端节点的数量,也就是说,如果该流媒体对象越流行,其副本的数量也就越多,因此,对于流媒体对象副本数量较多的情况,可以利用客户端节点完成该流媒体对象的交换,也就是可以不需要CDN Server再进行该流媒体对象的缓存,从而节约CDN Server宝贵的缓存资源,提高缓存资源的利用率,即流媒体对象的副本数量越多,其置换因子的值越小,表示越需要置换出该流媒体对象。
式(4)中,参数B(g(v)),CN(g(v)),Size(g(v))可以从表5的记录中获取。
对于式(4),概括来说,所述置换因子的大小对应流媒体对象应该被置换的优先级大小,如果计算得到的缓存因子越大,说明越不应该置换该流媒体对象,反之则越应该置换该流媒体对象。
步骤404,计算状态序列成本函数极值,根据计算结果执行置换。
本步骤中,当计算出流媒体对象置换因子后,选择流媒体对象置换因子最小的N个流媒体对象(N的取值可由请求的流媒体对象决定,使请求的流媒体对象与缓存中除需要被置换的N个流媒体对象之外的流媒体对象所占的空间总和不大于S)。
式(4)中置换因子计算公式中分母所涉及的缓存代价因素是在现有的缓存置换策略基础上引入的,即基于利益/代价模型,如果缓存的代价越大,也就是流媒体对象的副本数越多和/或流媒体对象越大,表明缓存该流媒体对象需要花费的代价也越大,因此,说明越需要置换该流媒体对象,也就是说,式(4)考虑的缓存代价因素是比较一般化的、适用于普遍的网络环境。实际应用中,针对不同的网络环境和/或不同的流媒体服务,可能还会涉及到具体的网络环境以及流媒体服务本身所特有的一些需要考虑的因素,举例来说,一个网络内的热点流媒体对象在不同的时段可能会有比较大的不同等等。因此,在计算出各缓存流媒体对象的置换因子之后,可以根据其他所要考虑的代价因素,即在综合考虑多种因素的基础上,在有可能被置换的流媒体对象所构成的集合中选取一个代价最小的序列进行置换,进一步降低缓存置换带来的开销。
假定请求的流媒体对象序列为m=V1,V2,......,Vm,缓存中对应的状态序列为ψ0,ψ1,ψ2,……,ψm,其中,
状态序列ψk(k=1,2,...,m)表示第k个流媒体对象请求到达后缓存中所存储的流媒体对象状态的集合。ψ0表示缓存的最初状态,即没有缓存任何流媒体对象的状态。对于所有的ψk,k=1,2,......,m,有:
其中,Φk表示ψk-1缓存中需要被置换的流媒体对象的集合,在所有满足式(6)的ψk中,找出一个状态序列,使得成本函数:
的值最小。
其中,λk表示为: {ψk}表示状态序列。
如果某一状态序列的置换成本函数值最小,则表示根据该状态序列执行置换所引入的开销也最小,因而置换该状态序列。
上述步骤401~步骤404涉及的算法也可以使用下面的伪代码来实现。
Replacement_Algorithm
{
V:请求缓存的流媒体对象
根据式(4)计算缓存的流媒体对象置换因子,记为R(v)
If(R(v)<R(min(ψk-1)))
Break;/*计算的置换因子小于当前缓存中最小的置换因子,跳出置换算法*/
for(int i=0;i<已缓存的流媒体对象数;i++)
{
根据式(4)计算缓存的流媒体对象i的置换因子R(i);
}
根据置换因子的大小,对缓存的流媒体对象进行升序排列;
ReleaseBuf=0;/*回收空间计算变量*/
bool replaceFlag=false;
for(P=影片数据链表头;P!=NULL;P=P->next)
{
/*如果流媒体对象P正在被访问,不置换*/
If(流媒体对象P正在被访问)
Continue;
If(R(V)>p->置换因子)
ReleaseBuf+=p->缓存大小
else
if(ReleaseBuf>=sizeof(V))
{
replaceFlag=true;
break;
}
else
{
break;
}
}
If(replaceFlag)/*获得足够的缓存空间进行置换操作*/
{
进行置换操作;
记录最小的置换因子R(min(ψk));
}
}
由上述实施例可见,本发明实施例的一种实现流媒体缓存置换的方法、设备及系统,CDN Server通过接收客户端节点请求的流媒体对象,当判断CDN Server缓存的所有流媒体对象以及接收的流媒体对象所占的空间总和不大于S时,触发缓存置换算法;根据缓存中流媒体对象长期流行度和近期流行度因素,计算流媒体对象流行度;并从缓存的列表记录中获取该流媒体对象的副本数量、大小及网络延迟,计算该流媒体对象置换因子,置换流媒体对象置换因子最小的N个流媒体对象。综合考虑了优化性能指标如流媒体服务器,用户接收的媒体质量、用户的启动延迟以及多媒体数据对网络的消耗等性能指标,以及影响缓存效果的流行度,传输代价,缓存增益等因素,使计算出的缓存置换因子更具科学性。并在缓存置换算法中采用长期流行度和近期流行度相结合的方法,使获得的流行度更能反映某个流媒体片断的真实流行度;同时考虑本CDN Server的网络内的流媒体对象副本数量的多少,使流行度高同时副本数量较多的流媒体对象由ISP网络内的客户端节点进行交换完成,减少了CDN Server缓存的开销,提高了资源利用率。而且,还进一步根据具体的网络环境以及流媒体服务本身所特有的一些需要考虑的因素,综合考虑多种因素,构建基于状态序列的成本函数,状态序列包括被置换的流媒体对象所构成的集合,计算状态序列的成本函数值,从中选取一个代价最小的状态序列进行置换,进一步降低缓存置换带来的开销。
以上举较佳实施例,对本发明的目的、技术方案和优点进行了进一步详细说明,所应理解的是,以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。