基于指数分段的流媒体代理混合缓存算法

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

基于指数分段的流媒体代理混合缓存算法

陈铁群,陈浩

湖南大学计算机与通信学院,湖南长沙(410082)

E-mail:ironox@

摘要:本文提出了基于指数分段的流媒体代理缓存算法。该算法在现有指数分段的基础上,考虑到不同媒体对象的流行度和相同对象的不同段落存在不同的流行度,结合高效的LRV 算法,使得代理缓存能尽量缓存热点段落,而不是象指数分段算法那样严格按照段落的先后顺序来管理缓存。对于前缀段落,综合考虑其带宽,延迟和访问次数,以减少启动延时。事件驱动实验表明,该缓存算法在缓存命中率,启动延时率等方面有所提高,缓存的整体性能得到增强。

关键词: 指数分段;流媒体;代理缓存;启动延时

中图法分类号:TP393

1.引言

Internet的迅速发展使得信息通信发生了革命性的变化,人们已经不满足于简单的文字和图片信息,流媒体已经成为Internet上信息传播的主要方式。流媒体与传统静态媒体相比有三个显著的特点:1.流媒体内容数据量较大;2.延时敏感度高;3.交互性很强,这就使现有网络面临巨大的考验。

目前处理该问题的常见方法就是部署边缘代理服务器,通过代理服务器处理本地客户的请求,缓存并转发来自源服务器的数据。虽然代理服务器在处理静态的基于文本的媒体内容方面取得了成功,但是在应对流媒体内容的时候却往往碰到困难。因为传输流媒体数据需要占用较多的网络带宽资源,而且持续时间较长,从而导致源服务器及网络只能支持数量有限的并发流,所以仅仅是部署边缘代理服务器还远远不能支持网络中流媒体内容的平滑传输。目前的一个主要解决方案就是求之于大规模的内容分发网络(CDN),CDN凭借其高带宽网络和大容量的存储能力可以平滑传输流媒体内容,但是CDN成本过高。目前的研究主要集中于改善代理服务器的缓存算法来保证流媒体服务的质量,因此缓存管理算法和策略成为流媒体传输领域的热点。

本文提出的基于指数分段的混合缓存算法考虑到媒体对象的流行性差异,尽力缓存流行的媒体对象的热点段落。本算法旨在通过细化缓存调度对象粒度,以达到较高的缓存命中率,降低启动延时,减少抖动。

2.相关工作

目前提高代理服务器缓存性能主要分两个方向。一个方向是对流媒体对象进行不同的划分和调度,以探索提高代理服务器缓存效率。通常是通过在代理服务器中缓存流媒体对象的前缀部分来减少客户感知的启动延时。在传输前缀部分的同时,代理服务器从源服务器获取该对象的后续部分。因此前缀的大小是关系到系统整体性能的关键参数。另一个方向则聚焦于流媒体本身的量度,如分层缓存(Layered Media Caching)[1]、多版本缓存(Multiple Version Caching)[2]等。

将整个流媒体缓存在代理服务器中,这对于代理缓存来说,缓存整个流媒体内容所需的磁盘空间和网络开销必然是巨大的。于是S Sen等[3]提出了前缀缓存算法,该算法在代理服务器上缓存流媒体对象的前面的数个片段(称作前缀),当客户端请求该对象时,代理服务器

立即向客户传送该对象前缀部分,存储长度为{d max -s,0}的前缀部分(其中s 为客户端的播放延时,d max 为服务器端的最大延时),以此来减少客户端的延迟。虽然前缀缓存能有效降低延迟,但是它不能根据媒体流行度变化动态调整。

对于媒体对象的分段策略,Wu K 等提出了指数分段缓存[4],指数分段缓存。一个媒体文件O 被分成多个大小相等的块B(block),块B 是用来进行传送的最小单元。越靠近前面,段落所包含的块就越少。段落0含有块0,段落l 含有块l ,段落2含有块2和3…段落i 包含的块的个数是()121i i −≥。

如果在缓存中缓存每个媒体对象之前缀,虽然可以减少启动延时,但是对于访问次数极少的对象仍旧在缓存中保存其前缀,很明显会降低其命中率。对于前缀,我们提出了一个效能公式,综合考虑延迟,热度和带宽的因素,优先缓存访问频率较高,延迟较大,带宽较匮乏的媒体前缀部分。

3. 基于指数分段的混合缓存算法

对于缓存算法分段策略,我们则采用指数分段的策略。指数分段一大优点就是可以快速释放缓存空间,特别是在将段落编号较大的段落替换出缓存时,一次操作最高可能一次释放掉一个对象大小的一半。 对于段,则分成两类,分别采用不同的缓存效能公式。

3.1 缓存管理策略

我们把设每个媒体对象分为两部分,称之为前缀段和后缀段。如同[1]一样,我们为每个对象固定的保留P init 个段做为前缀段,系统总是优先缓存前缀段。最小分块大小为B ,对于每个流媒体对象的某个分段i ,为其维护以下数据结构:

ref N :该段落被访问的次数;f T : 首次访问该段落的时间;r T : 上次访问该段的时间;c B : 该段已经缓存的块数;sum L :该段总的访问长度。

为了减少启动延时,我们认为有必要为系统中的每个流媒体对象保留一小段前缀。首先,用户首次访问该对象的时候,系统能够立即为其服务;再者,如果不优先保存前缀,对象可能会完全被替换出缓存,而当用户新的请求到达时就会造成启动延时。如同[1]一样,我们为每个对象固定的保留一些分块P init 做为前缀,系统总是优先缓存这些分块。.对于P init 段的管理策略,我们考虑两个方面:

1. 对于延迟较大的媒体对象,很明显要优先缓存其前缀才能保证收看质量。同样的,

如果从源服务器获取某个段的带宽资源匮乏(我们可以使用PCAP 库这样的工具进

行周期性的测量带宽),也应该优先缓存。

2. 段落被访问的次数,段落的访问频率越高就应该优先被缓存。

系统为P init 段落维护一个LRV 栈,每个段有一个相对值(relative value )

,很明显其相对值跟获取改段落的延迟和访问次数成反比,跟带宽成正比。因此我们可以将其定义为:

BW

(())a ref L N β+ (1)

其中a L 为该段落的启动延时,BW 为其带宽限制(媒体对象的每一个段落共享该值),ref N 为该段落被访问的次数,β为系统可调参数,可以用来调整代理服务器的性能侧重方向。 β

相关文档
最新文档