媒体缓存（精选9篇）
媒体缓存 篇1
摘要：随着Internet技术的发展和普遍应用, 流媒体技术在Internet上得到了广泛的应用。对流媒体对象的访问, 需要高且稳定的传送速率, 网络带宽消耗大且持续时间长, 容易给其他类型文件的访问带来影响, 若用户过多, 还会使初始流媒体服务器过载。代理缓存技术可帮助解决上述问题。文中介绍了流媒体代理缓存的特点, 流媒体代理缓存的算法, 流媒体代理缓存的评价指标和影响流媒体代理缓存效果的因素。
关键词：流媒体,代理缓存
0 引言
二十一世纪己经进入了数字化的信息时代, 随着Internet技术的发展和普遍应用, 网络电视、远程教育、视频会议、宽带电视广播、移动和无线多媒体服务蓬勃发展起来, 视频、声音、图像、动画等多媒体信息已成为人们生活的一部分;流媒体的需要速度正以指数级增长着, 它的实时性、高速性、宽带性使Internet的网络设施常常不能满足流媒体的需求;网络资源和流媒体的广泛应用之间的矛盾日益广, 节约网络资源保证流媒体应用成为挑战性的研究课题, 流媒体代理缓存技术是解决这一课题的重要技术。
当用户访问某流媒体对象时, 所访问内容可以缓存在子网的代理服务器中, 子网中的其他用户所发出的对相同内容的请求就可以直接由代理服务器进行响应, 这样可以大幅度减少Internet信息传输量和带宽占用, 提高流媒体应用启动响应速度, 降低初始流媒体服务器的负载, 也可为用户节约大量网络使用费用。代理缓存技术现已广泛用于对HTML网页和图像文件等传统Web对象的服务中, 并收到了相当好的效果。
1 流媒体代理缓存的特点
流媒体代理缓存的逻辑结构如图1所示。相对于现在已广泛使用的用于传统Web对象的代理缓存, 流媒体代理缓存有如下特点。
(1) 流媒体对象的文件大小通常比传统的Web对象文件要大几个数量级。一般的web文件以kB为单位, 而流媒体文件的大小多以MB为单位, 包含一部完整电影的流媒体文件往往要超过100MB, 因此, 当容量有限时, 缓存只能存储少量完整的流媒体文件。
(2) 当前Internet上流媒体对象多为静态流媒体对象, 通常都具有一次写多次读 (WORM) 的性质, 当它放置在Internet上后, 通常很少进行改变。因此在流媒体网络缓存中, 缓存的一致性并不是非常重要的问题。这在一定程度上简化了流媒体代理缓存的设计。
(3) 在用户浏览模式上, 通过研究发现, 流媒体用户通常只浏览其最初部分以决定是否全部观看。因此在设计流媒体代理缓存系统时, 必须考虑到对该情况的适应, 而不需要不加区分地总是将整个流媒体文件一次性缓存。
由于这些特性的存在, 使得不能直接照搬传统的Web缓存技术, 而必须开发一种适用于流媒体的网络缓存技术。
2 代理缓存算法
2.1 选择缓存算法
在用户接入带宽资源有限的情况下, 保证正常的媒体播放速率成为媒体缓存算法的主要设计目标。有一类缓存算法, 根据带宽情况对影响媒体播放的关键数据或者内容进行有选择地缓存, 把这类缓存算法称为选择缓存算法 (Selective Caching) 。
Miao Zhourong等人以保证正常媒体播放为前提, 在考虑磁盘容量的约束条件下, 提出了两种媒体数据帧选取缓存算法 (Frames-elected Caching) , 分别针对骨干链路有无QoS保证时的情形。当骨干链路有QoS保证时, 帧选取的原则是使用骨干链路的带宽需求和客户端播放缓存需求最小;当骨干链路无QoS保证时, 帧选取的原则是使得代理缓存可以为客户端播放缓存提供尽可能多的帧, 以提高网络拥塞时媒体播放的鲁棒性。
同样以降低骨干链路带宽需求为目标, 提出不以媒体数据帧为缓存对象, 而以部分超速率数据为对象的速率分段缓存算法 (Rate-Staffed Caching) 。该算法针对VBR流式传输, 对高于指定数据传输阀值的媒体数据部分进行缓存。类比于时域上的前缀缓存, 速率分段缓存算法也存在如何选取截断速率的问题。研究表明, 在磁盘容量和网络带宽两个约束下, 确定优化的速率是一个背包问题。
2.2 基于间隔的缓存算法
用户请求具有高度时域邻近性 (Temporal locality) 的情况下, 对同一媒体对象的两个连续播放请求的间隔内容做缓存, 可以显著降低服务器的吞吐量。该类缓存算法称为基于间隔的缓存 (Interval leaching) , 最初的思想由Dan提出。当存在对媒体对象相同部分的两个连续请求时, 则连续请求的间隔部分将随着播放过程被缓存。该算法目前已经有多种衍生版本。最具代表性的是Tewari提出的基于资源的缓存 (Resource haled caching, RBC) 算法。RBC算法以每个媒体对象对缓存空间和传输带宽的需求为约束条件, 提出了一种启发式的算法选择媒体对象的缓存粒度进行选择。其粒度可以是一个滑动间隔、一系列邻近间隔的组合, 甚至是完整的媒体对象。
2.3 基于分段的缓存
基于间隔的缓存算法, 其有效性依赖于用户请求在时域上的有效性。当到来请求的时间间隔较长时, 其性能有可能退化到全对象缓存。为此, 研究人员开始考虑选取部分的媒体关键内容进行缓存, 例如由Sen等提出的前缀缓存 (Prefix Caching) , 是将媒体内容分成前缀 (Prefix) 和后缀 (Suffix) 两个片段部分, 并且优先缓存前缀。前缀缓存可以有效地降低用户播放媒体对象时的启动时延, 是目前应用较为广泛的流媒体缓存技术。其不足之处在于媒体前缀部分的长度不容易确定。在有限的网络资源的约束下, 为达到指定的启动时延的前缀缓存, 其部署是一个部分背包问题 (Fractional Knapsack) 。
更为普遍的方式是将媒体内容分为多个片段。即基于分段的缓存 (Segment based Caching, 以下简称分段缓存) 。分段缓存将媒体内容沿着播放时间分成多个片段 (Segment) , 并将片段作为存储和置换的基本单元。分段策略是分段缓存的主要研究热点, 依据它可以将分段缓存算法分成等长划分和变长划分两类。变长划分算法的代表是Wu K, Yu P等人, 提出的片段长度以指数增长的缓存算法策略, 这类策略设基本的存储单位为块 (block) , 则第i个片段由第2i-1, 2i-1+1, …, 2i-1块构成, 片段长度为2i-1个块。由于可以通过一次性丢弃较大的后续片段, 来适应缓存流行度的变化, 该算法可以取得比普通的前缀缓存更低的平均启动时延和更高的字节命中率。在等长划分算法中。片段长度的选择是关键, 基于媒体的受访特性确定等分片段的长度, 可以获得比指数分段缓存或者前缀缓存更低的网络带宽占用阁。分段缓存算法可以提供较为精细的缓存粒度, 带来更多的灵活性, 成为目前主流的代理服务器缓存算法之一。
2.4 结合编码转换的缓存算法
随着网络使用的普遍化, 用户接人网络呈现出多样化的发展趋势, 用户的终端环境、接人带宽以及允许获得的服务质量各不相同, 因此请求的视频质量也可能各不相同。为了适应接人网络带宽的不同需求。需要根据用户的请求和带宽状况, 动态地改变缓存内容质量和传输速率。结合编码转换技术, 其缓存算法可以利用向不同用户提供不同版本的媒体内容来满足不同用户的需求。有两种简单方案: (1) 缓存媒体的完整版本 (Full Version Only, FVO) , 每次根据用户请求由代理服务器进行编码转换。这种方式对代理服务器的CPU资源提出了很高的要求, 无法很好地为不同的网络用户服务。 (2) 仅缓存经过编码转换后的流媒体 (Transcoded Version Only, TVO) , 编码撰换预先由媒体服务器完成。这样的存储方式难以满足所有用户对流媒体质量的不同要求, 而且会对网络带宽带来较大压力。
为了解决这两种方案之间的矛盾, Xue yan Tang等人提出了一种自适应的缓存方式。该算法根据代理服务器CPU资源和网络带宽资源的状况, 动态地决定是缓存原始版本还是缓存编码转换后的版本。这种方法的缺点在于可能会对同一个视频对象缓存多个版本, 对缓存空间提出了较高的要求。
Masahiro等人则建议只为每个媒体对象缓存所得到的最高质量的版本, 但是代理服务器可以灵活地采用最大申请 (根据网络带宽) , 平均申请 (根据一段时间内用户申请质量的最大值与网络带宽比较, 取较小值) 和等同申请 (按照用户请求的质量申请) 三种不同的策略向媒体服务器请求所需内容, 这种算法在缓存空间受限的情况下对缓存效率改善明显。但是, 由于代理缓存可向服务器中申请不同质量的流媒体版本, 媒体服务器仍然为此承担编码的负载。
为了降低媒体服务器的编码负担, Bo Shen等人提出了一种可编码转换的缓存系统。采用降低比特速率 (bit-rate reduction) 和降低空间分辨率 (spatial resolution reduction) 两种编码转换技术在网络边缘完成质量自适应。根据缓存版本数量和缓存命中后的行为, 提出TEC-11, TEC-12和TEC-2三种缓存策略。TEC-11和TEC-12都只会对同一个缓存对象存储一个版本。不同的是TEC-11总是缓存最高质量的, TEC-12总是缓存最低质量的, 而TEC-2则会为同一个缓存对象存储多个版本。
随着编码理论和信号处理技术的发展, 部分编码转换技术几乎可以达到实时的效果, 大大增加了此类技术的实用性。
3 流媒体代理缓存性能评价指标
3.1 命中率HR (Hit Rate)
用户通过代理访问流媒体服务器时, 代理服务器通过查找自己的缓存或直接访问流媒体服务器来提供用户所需要的资源。如果代理服务器在自己的缓存中找到用户所要访问的资源, 则称之为一次命中;反之, 如果代理服务器通过直接访问流媒体服务器来提供所要访问的资源, 则称之为一次缺失。
undefined
命中率是评价代理缓存系统性能最主要的指标。代理缓存系统的命中率高, 说明直接从代理缓存空间获得资源响应的成功率高, 从而降低响应延迟。
3.2 访问延迟
访问延迟是指从用户发出一个请求开始, 到用户接收到该请求的响应为止所经历的时间。代理缓存系统的目标之一是降低访问延迟。因此可用访问延迟这个性能指标对代理缓存系统进行评价。代理服务器可能从自身的缓存空间获得资源作为响应, 也可能将请求转发到服务器以获得响应。因此, 访问延迟应该考虑缓存命中和缓存未命中的情况。需要注意的是, 从发出请求到获得响应的整个过程中都涉及到Internet的网络传输, 对访问延迟的计算, 通常都要考虑网络的传输模型。
3.3 空间利用率
空间利用率是评价代理缓存空间的利用情况的指标。代理缓存系统的存储空间虽然是在辅助存储器上 (如磁盘缓存) , 但同样也有成本的问题。传统的Web代理缓存通过对象命中率和字节命中率来考虑代理缓存的空间利用率, 而流媒体是部分缓存的, 因此在缓存空间内尽可能大地缓存“热门”节目, 将会大大提高缓存命中率, 减少客户启动延迟和对流媒体服务器的访问, 从而提高代理缓存的利用率。
4 影响流媒体代理缓存效果的因素
使用流媒体代理缓存主要是为了降低流媒体服务器负载, 减少Internet网络数据传输量, 降低用户可察觉延迟、提高可感知播放质量, 为此可以对影响流媒体代理缓存效果的因素进行下列分析。
(1) 缓存空间。
缓存空间对缓存效果有着影响, 当缓存空间有限时, 所容纳对象数少, 会带来更多的置换操作, 影响了缓存使用效率;当缓存空间增大时, 可以在缓存中找到用户所请求内容的概率也随之增大, 但同时也会造成缓存信息查找时间的增长和缓存设备硬件投入的增加。
(2) 存储策略。
存储策略指所缓存内容在缓存中的存储组织方式。通过对缓存流媒体对象全缓存策略的研究, 发现将一个完整的流媒体文件放到一个缓存中代价是相当大的, 即使在集群缓存环境中也同样如此, 流媒体文件的大体积特性和用户对其访问模式特点决定了这种情况的形成。为此, 包括分段缓存和前缀缓存在内的部分缓存概念被提出, 并得到普遍使用。在分段缓存策略中, 将被请求的流媒体对象分成连续且互不重叠的多个部分, 每个部分称为一个段。进行缓存时, 以段为基本单位, 每个段对应一个连续的帧序列, 各段可以分别进行缓存和管理。在采用前缀缓存策略时, 由流媒体对象的最初部分开始进行缓存。当前使用最多的是基于分段的前缀缓存策略, 这是将分段缓存和前缀缓存结合起来的一种存储策略。在该策略中, 将流媒体为每个缓存段进行前缀缓存。这样, 段能被独立缓存, 磁盘空间也因而能更有效地用于缓存大片段的受欢迎部分。
(3) 缓存放置和置换策略。
当有多个代理缓存设备时, 怎样对这些缓存进行管理, 所获得的对象要防止在哪个缓存中;当有新的对象要缓存又没有足够可用空间时, 要如何选择要删除对象, 这些是缓存放置和置换策略所要考虑的内容。已有缓存置换策略如FIFO, LRU, LFU, SIZE等都只考虑了时间局部性, 文件大小这些常规因素, 而未充分利用考虑平均服务响应时间, 远程网络通信量减少率等衡量流媒体代理缓存效果的指标, 实验表明其效果并不理想。适用于流媒体的缓存放置和置换策略必须综合考虑各远程链路可用带宽, 数据传输可靠性和数据丢失率, 到流媒体服务器的距离, 流媒体文件的编码方式等影响流媒体缓存系统性能和回放质量的因素。
5 流媒体代理级缓存设计要求
流媒体不同于一般的媒体数据, 其特点使现有的Web代理缓存技术不能满足要求, 流媒体代理缓存必须在原有的缓存技术基础上进行改进, 使之能够适合大体积对象流式传输的要求。
对于代理外部来说, 流媒体代理缓存技术要实现以下目标:
(1) 减少对主干带宽的消耗, 减轻流媒体服务器的负载。利用本地缓存存储一部分媒体数据, 减少从服务器请求的数据量。使用合理的传输方法, 减少到服务器的直接连接数, 从而达到节约主干带宽, 减轻服务器负载目的。
(2) 提高对用户请求的响应速度, 降低客户端启动延迟。采用适当的缓存算法和缓存管理方法, 提高用户访问的命中率, 提高本地缓存的响应速度, 可以快速响应用户的请求。
(3) 提高访问的透明性。对于客户来说, 设置本地代理以后, 对所有可得资源的访问就像直接在访问原始服务器, 客户感觉不到代理的存在。
对于代理内部来说, 流媒体代理缓存技术要实现以下目标:
(1) 提高代理缓存的空间利用率。分析客户的行为, 确定媒体的“热门”程度, 以期尽可能大地缓存最热门的媒体节目, 减少对“冷门”媒体节目的缓存, 及时清理“死亡”的媒体节目。
(2) 协调代理之间的负载。如果相互靠近的网络中有一台以上代理服务器, 则各代理之间应该根据负载的不同进行协调, 及时把多余的客户分流到空闲的代理上去。
(3) 代理之间的内容共享。这可以在一定程度上缓解网络紧张, 减轻服务器的负载。
(4) 代理服务具有一定的健壮性。
6 结束语
将经常被访问的流媒体的部分或者全部缓存在代理上, 使后来的访问用户的访问请求能从本地得到响应, 缩短了响应时间和用户可察觉延迟时间, 减少了远程服务器负载和网络通信量, 节省了带宽资源和系统处理资源, 对于我国目前的网络环境来说, 流媒体代理缓存技术缓解网络拥塞状况。
随着无线网络的不断发展, 针对无线信道传输可靠性差, 误码率高, 用户移动等特点, 建立有效的缓存策略, 使得部署在传统Internet与无线网络边缘的代理服务器为无线用户提供高效的流媒体服务, 是需要研究的一个问题。
现有的缓存策略的研究都是将Web对象与流媒体对象分开考虑, 这与大多数实际情况不符, 如何建立高效的混合缓存策略也是需要研究的问题。
参考文献
[1]Miao Zhourong, Ortega A.Scalable proxy caching of video under stor-age constraints[J].IEEEJSAC, 2002, 20 (7) :1315-1327.
[2]Chen S, Shen B, Wee S, et al.Adaptive and lazy segmentation basedproxy caching for streaming media delivery[C]//Proc.NOSS-DAC’03, 2003.
[3]Chen Songqing, Shen Bo, Wee Susie, et al.Investigating PerformanceInsights of Segments-based Proxy Caching of Streaming Media Strategies[C]//Proceedings of SPIE/ACM International Conference on Multime-dia Computing and Networking (MMCN’04) , 2004.
[4]Radulovic I, Frossard P Verscheure O.Adaptive Video Streaming in LossyNetworks:versions or layers?[C]//Proceeding of IEEEICME, 2004.
[5]Shen Bo, Lee Sung-Ju, Bssu S.Caching Strategies in Transcoding-En-abled Proxy Systems for Streaming Media Distribution Networkes, IEEETrans On Multimedia, 2004, 6 (2) .
[6]Sen S, Rexford J Towsley D.Proxy prefix caching for multimedia stre-ams[C]//Proc.IEEE INFOCOM’99, 1999.
[7]Dan A, Sitaram D.A generalized interval caching policy for mixed in-teractive and long video workloads[C]//Proc.IS&T/SPIE Conf on Mul-timedia Computing and Networking (MMCN’96) , 1996.
[8]Zhang Z-L, Wang Y, Du DHC, et al.Video staging:A proxy-server-based approach to end-to-end video delivery over wide-area networks[J].IEEE Trans Networking, 2000, 8:429-442.
[9]余江, 刘威, CHOU Chun-Tung.流媒体代理缓存技术研究[J].计算机科学, 2006 (33) .
媒体缓存 篇2
那么遇到类似问题，我们最好清除DNS缓存。
具体步骤：
通过“开始->运行->输入CMD”进入命令行模式。 (注意是命令行模式哦）
第二步：在命令行模式中我们可以看到在ipconfig /?中有一个名为/flushdns的参数，这个就是清除DNS缓存信息的命令。 第三步：执行ipconfig /flushdns命令，当出现“successfully flushed the dns resolver cache”的提示时就说明当前计算机的缓存信息已经被成功清除，
第四步：接下来我们再访问域名时，就会到DNS服务器上获取最新解析地址，再也不会出现因为以前的缓存造成解析错误故障了。
当然对于win7电脑，可能会不太一样，（也可以使用windows+R键，也可以呼出下面的对话框）
1、我们点击左下角的开始，并输入cmd
2、输入cmd后就会弹出如下对话框，
3、这时候我们输入清空DNS缓存命令的：ipconfig/flushdns，我们输入完了命令之后，按下电脑键盘上的回车键（Enter）即可开始清空DNS缓存了， 如下图所示：
流媒体代理服务器缓存技术研究 篇3
1 前言
相对于传统的web对象 (如HTML页面和静态图像) , 流媒体对象所具有的数据量大和对带宽需求高等特性需要对现有的代理缓存策略进行充分的拓展。为了缩短客户端的启动延时, 一个有效的方法就是在靠近客户端的代理服务器上缓存被频繁访问的数据。这种方法缩短了传输的距离, 提高了对象的可用性并降低了丢包率。
流媒体代理服务器缓存是一种内容复制技术, 利用缓存的流媒体内容服务访问的用户, 代理服务器位于骨干网和企业网之间, 能够通过转发操作向局域网内的用户提供互联网的访问服务。同时, 面对庞大的互联网单个代理服务器的缓存效果比较有限, 可以考虑多个代理服务器协同工作的流媒体缓存形式。
流媒体代理服务器的功能如下:
管理部件:负责与用户、服务器进行协议交互;在响应访问的过程中决定是否缓存内容或者能否利用缓存内容直接服务用户访问;
存储部件:包括缓存空间和保存内容、缓存替换、缓存查询等空间管理操作。具体涉及缓存空间的组织方式、缓存内容的选取过程、释放内容的选择、释放动作的执行等内容;
发送部件:负责完成实时数据的接收和发送工作。并需要根据传输情况将转发的数据包再进行重组或转发。
2 缓存算法分析
2.1 滑动区间缓存
这类算法缓存了一个媒体对象的滑动区间, 并使用它对流媒体进行连续的访问。典型算法包括:Interval Caching、Resource-based Caching。
间隔缓存算法 (Interval Caching) :如图1所示, 对于相同对象的两个连续请求, 第一个请求从服务器获取对象并缓存在代理当中, 第二个请求可以从缓存当中获取数据并随后释放。如果两个请求到达的时间间隔很短, 那么只有很小的一部分媒体对象数据需要被缓存, 并且第二个请求完全可以从代理获取完整的服务。如果在一个很短的期间内对于一个对象有很多的请求, 那么这些相邻的缓存间隔可以被组织起来, 直到最后一个请求得到满足之后再释放被缓存的部分。
基于资源的缓存 (Resource based caching, RBC) 算法:将Interval Caching部署于代理服务器的磁盘中。由于磁盘的容量比内存大得多, 为改变间隔缓存的存储粒度提供了足够空间。RBC算法以每个媒体对象对缓存空间和传输带宽的需求为约束条件, 提出了一种启发式的算法对媒体对象的缓存粒度进行选择。依靠对象的特征和可用的资源, 被选择出来的粒度可以是一个滑动间隔, 一系列邻近间隔的组合, 或者是完整的媒体对象。
基于间隔的缓存适用于用户请求具有高度的时域邻近性 (Temporal locality) 的情况, 此时间隔缓存可以显著的降低网络带宽消耗的峰值和连续请求的启动时延。然而, 当用户请求的分布在时域上稀疏时, 该算法的有效性就会随着到来请求间隔的增长而降低。
2.2 前缀缓存算法 (Prefix Caching)
前缀缓存在代理服务器上缓存流媒体对象的起始部分, 叫做前缀。由于前缀部分可以直接从代理服务器获取从而有效降低了客户端的启动延时。在提供前缀服务的同时代理服务器从原始 (内容) 服务器上获取其余的后续部分 (叫做后缀) 并转发给客户端, 进而节省了部分骨干网带宽并保证了播放的连续性。对于前缀缓存策略, 前缀部分的大小和分段方法是决定系统性能的重要因素。前缀缓存在运行期间的缓存状态如图2所示。
前缀缓存算法是目前应用最为广泛的流媒体缓存技术。其不足之处在于媒体前缀部分的长度不容易确定, S.Jin等人的研究[5]表明, 在有限的网络资源的约束下, 为达到指定的启动时延的前缀缓存的部署是一个部分背包问题 (Fractional Knapsack) , 需要贪婪式的优化算法来解决。
2.3分段缓存算法 (Exponential Segment Caching)
分段缓存推广了前缀缓存方法, 将媒体对象分割成一系列的段落, 并根据它们各自的效能来决定是否缓存。不同的分段缓存算法具有不同的分段方法和效能计算方法。将媒体对象按照统一的大小进行分割, 一个媒体对象分割不同尺寸的段落, 长度根据与媒体头部的距离按照指数方式增长, 段i的大小为2i-1, 包含2i-1, 2i-1+1, …, 2i-1帧 (如图3) 。采用指数划分的分段策略可以通过丢弃大的后续片段快速获得足够的磁盘空间, 达到适应用户请求变化的目的。媒体片段的利用代价定义为片段被访问的次数除以其距离媒体起始片段的距离, 因此具有更高访问频率的初始片段将优先被缓存。
分段缓存的一个显著特征是它支持VCR类的操作, 如随即访问、前跳和后跳。当客户请求对象时, 代理首先分发热点部分来提供对于流的纵览, 客户可以决定是播放整个流还是快速跳到由热点引入的一些特殊部分。此外, 快速的前跳和后跳操作, 只有相应的热点被传送和显示, 而其他部分被掠过。同样, 服务器的负载和骨干网都会因此大幅降低, 而客户不会错失媒体对象的任何重要段落。
2.4 速率分裂缓存算法 (Rate-Staged Caching)
上述缓存算法是按照时间轴来分割媒体对象, 而速率分裂缓存则按照速率轴来分割对象。速率较高的部分被缓存在代理上, 速率较低的部分仍然保留在原始服务器 (如图4) 。速率分割缓存方法非常适用于VBR流, 因为只有较低的接近于恒速的部分通过骨干网络被传送。在代理服务器缓存高速率的部分能够明显降低速率的变化并提高骨干网络带宽的利用率。速率分割缓存当中一个值得探讨的问题是如何选取切断速率和高速率部分的大小。实验证明利用一个相当小的缓存空间就能够明显降低带宽。
3
算法性能比较 (见表1)
4针对不同类型用户的缓存算法
以上算法均为同构网络环境下的代理缓存算法, 但由于接入网络和设备配置的不同, 用户往往对同一流媒体对象在速率或编码格式等方面有不同的要求。为了适应这些非同类的客户, 最直接的方法就是对不同速率或格式生成多个副本, 每个针对一类用户, 但这种方法对服务器的存储要求极高。另一种方法是进行代码转换, 将流媒体转换成更低速率或不同格式, 但这需要大量的计算开销, 使代理服务器不能支持太多的用户。更有效的方法是使用分层编码和传输, 客户可以获取部分层次, 重构出与其能力相匹配的流媒体。
分层缓存将原始媒体对象压缩成几个层, 最重要的层叫做基础层, 包含了表现对象最重要特征的数据, 附加层也做增强层, 包含的数据可以用来逐渐提高质量。客户可以根据它的能力预定累积层的一个子集来重建流 (如图5) 。对于分层缓存, 假定被缓存的部分是半静止的, 而完整的层被缓存。为了最大化整体收益, 采用基于随机背包模型分析的有效的启发式算法来确定缓存的内容。对于动态环境下的分层流, 采用基于分段的缓存替代和预取方案, 来获取缓存空间和可用带宽的有效利用。主要的目标是要处理个体客户的拥塞问题。代理将跟踪每个对象的每一层为基础的流行性。当被缓存的层的质量低于可以向客户端传送的最高质量时, 代理使用一个滑动窗口向服务器申请缺失的段落。缓存替换时, 一个牺牲的层依照流行度来确定, 缓存的段落被从尾部开始释放直到获得了足够的空间。
5 展望
代理缓存可以有效降低流媒体分发时的用户体验时延和骨干链路带宽需求。本文主要针对同构网络用户, 对现有的各种流媒体代理缓存策略进行了分类比较。
流媒体代理缓存技术除了自身仍然面临着众多的选择和折衷, 在其他很多方向上还有很多问题有待解决。
现有的缓存策略的研究都是将Web对象与流媒体对象分开考虑, 这与大多数实际情况不符, 如何建立高效的混合缓存策略是目前需要研究的问题。
合作式缓存作为提高缓存系统扩展性的一个方案得到了广泛关注, 设计一个流媒体对象在合作式缓存系统中进行高效分布和缓存的方案, 对提高流媒体缓存技术的扩展性具有重要意义。
参考文献
[1]向广利, 朱平.代理缓存技术在流媒体中的应用.湖北教育学院学报.2005 (5) 26-29
[2]张祥德, 刘兵, 高飞等.流媒体技术研究.计算机应用研究.2003, No.3:82-84.
[3]王国英.Rough集理论与知识获取.西安:西安交通大学出版社.2001:167-203.
[4]周永来.流媒体技术及其在网络广播中的应用:[硕士学位论文].天津:天津大学, 2004.
[5]S.Jin, A.Bestavros, A.Iyenger.Accelerating InternetStreaming Media Delivery Using Network-awarePartial Caching.in:Proceedings of IEEE InternationalConference on Distributed Computing Systems.Vi-enna, Austria.2002.New York, NY, USA:IEEE, 2002.p153-160
[6].罗万明, 林闯, 阎保平.TCP/工P拥塞控制研究.计算机学报.2001 (24一1) .1一1S
电脑的缓存简介 篇4
L1 Cache(一级缓存)是CPU第一层高速缓存，分为数据缓存和指令缓存。内置的L1高速缓存的容量和结构对CPU的性能影响较大，不过高速缓冲存储器均由静态RAM组成，结构较复杂，在CPU管芯面积不能太大的情况下，L1级高速缓存的容量不可能做得太大。一般服务器CPU的L1缓存的容量通常在32256KB。
L2 Cache(二级缓存)是CPU的第二层高速缓存，分内部和外部两种芯片。内部的芯片二级缓存运行速度与主频相同，而外部的二级缓存则只有主频的一半。L2高速缓存容量也会影响CPU的性能，原则是越大越好，现在家庭用CPU容量最大的是512KB，而服务器和工作站上用CPU的L2高速缓存更高达256-1MB，有的高达2MB或者3MB，
L3 Cache(三级缓存)，分为两种，早期的是外置，现在的都是内置的。而它的实际作用即是，L3缓存的应用可以进一步降低内存延迟，同时提升大数据量计算时处理器的性能。降低内存延迟和提升大数据量计算能力对游戏都很有帮助。而在服务器领域增加L3缓存在性能方面仍然有显著的提升。比方具有较大L3缓存的配置利用物理内存会更有效，故它比较慢的磁盘I/O子系统可以处理更多的数据请求。具有较大L3缓存的处理器提供更有效的文件系统缓存行为及较短消息和处理器队列长度。
其实最早的L3缓存被应用在AMD发布的K6-III处理器上，当时的L3缓存受限于制造工艺，并没有被集成进芯片内部，而是集成在主板上。在只能够和系统总线频率同步的L3缓存同主内存其实差不了多少。后来使用L3缓存的是英特尔为服务器市场所推出的Itanium处理器。接着就是P4EE和至强MP。Intel还打算推出一款9MBL3缓存的Itanium2处理器，和以后24MBL3缓存的双核心Itanium2处理器。
媒体缓存 篇5
互联网的流媒体技术已经发展的相当完善,但是3G移动流媒体技术还存在很多问题,把互联网流媒体技术完美的整合到3G网络是移动流媒体快速发展的一个有效途径,并且现在已经取得了一些进展。文献[1]提出边缘流媒体服务器集群(CESS)设计,同时提出MCLBS缓存替换算法来使CESS能够达到自适应的负载均衡,提高了缓存命中率。文献[2]提出采用中心缓存代理和用户边界缓存代理的两级代理设计,缩短了数据传输时延。但是目前的研究对减小移动核心网络负担的考虑较少。
移动网络一般都采用蜂窝结构,每个无线终端首先利用无线信道与无线蜂窝的中心基站通信,然后通过基站连接到Internet上的服务资源,当前认为较好的方法是在基站内通过设置代理服务器来提高整个系统的性能,但是每个代理服务器只负责一个蜂窝内的用户,缓存的分片利用率太低,代理的计算、网络资源等都没有得到充分利用。因此,文中引入P2P资源共享思想,并通过有效的缓存置换算法,提高每个代理服务器的利用率,减小网络延迟,从而提高移动流媒体业务的服务质量。
1 基于P2P的3G流媒体代理结构PSPA
由于移动用户获取流媒体服务主要通过访问Internet中的多媒体资源,这需要在无线网络和Internet的交界边缘上建立有效的传输机制和服务,同时流媒体在传输过程中会大量占用移动核心网的网络资源,因此文中提出了适用于3G网络的P2P流媒体代理结构(P2P-based 3G streaming proxy architecture,PSPA)如图1所示,结合第3部分给出的缓存共享模型SCOP,能够有效降低流媒体对核心网资源的占用,提高流媒体服务质量。从整体上PSPA采用两层代理结构,中心缓存代理(central cache proxy,CCP)为一层代理,位于Internet的边缘,距离移动核心网较近,提供缓冲代理服务,加快用户访问流媒体资源,通过Gi接口与GGSN通信。一层代理有两个主要功能:一是提供流媒体缓存代理,减小由于Internet网络拥塞造成的网络延迟,减小流媒体服务器的负载,使其同时为互联网提供服务影响。二是流媒体调度,主要进行P2P分片信息的定位和维护。客户边界缓存代理(client edge cache proxy,CECP)为二层代理,架专线连接到覆盖若干个无线蜂窝区域代理服务器的路由器上,然后通过lups接口链接到SGSN。每个CECP可以根据数据流量的大小选择覆盖一个或多个无线蜂窝区域,达到最大的覆盖范围和最小的数据延迟。对于3G流媒体业务流量很大的区域,可以考虑每个无线蜂窝区域的中心基站都设置一个客户边界缓存代理,以保证流媒体的服务质量。距离较近的几个客户边界缓存代理通过内部高速网连接在一起,方便流媒体分片的共享。
基于P2P的3G流媒体代理结构PSPA的优点:1)使用中心缓存代理规避了Internet网络造成的网络延迟;2)通过CECP的缓存代理,减少对二层流媒体代理的访问,降低流媒体对无线核心网的网络资源占用;3)由于大多数节点位于无线蜂窝的中心基站,通过内部高速网共享节目分片,基本无需通过核心网,避免了流媒体业务对核心网承载的其他业务的冲击;4)中心代理的设置使流媒体服务器在为移动网络提供服务的同时,不影响其在互联网的服务;5)实施成本低,具有较强的可行性。
2 PSPA的缓存置换策略SCOP及工作流程
缓存技术是控制网络延迟、抖动最常用的方法。互联网中P2P文件共享模式研究较多,已经取得丰硕的成果,例如以Napster[3]为典型代表的集中目录式;以Gnutella[4]为代表的纯P2P模式和以KaZaa[5]为代表的混合模式,这些都已经在互联网中得到了很好的应用。但是移动网络不同于Internet网络,移动核心网的复杂程度较低,负载能力也远不如Internet网络,因此不能照搬Internet网络上的P2P模型。
文中结合3G流媒体代理结构PSPA,借鉴互联网P2P文件共享模型,建立了一种适合PSPA网络的流媒体P2P策略(Shared cache of PSPA,SCOP),如图2所示。PSPA结构中的客户边界代理将作为P2P模型中的普通节点,相邻的几个普通节点组成一个簇,同一个簇中的节点通过高速网连接到一起,各个簇通过移动核心网与中心缓存代理CCP通信。本文中把中心缓存代理称为中心节点。由于每个簇中的节点不多,因此簇中采用纯P2P模型,采用泛洪算法共享分片,而中心节点可以看作是各个簇的超级节点。互联网中的流媒体服务器作为根节点,只提供分片下载。
当移动流媒体客户请求CECP节点提供分片时,CECP将依次查询以下位置是否存在分片:1)结点本地缓存;2)通过泛洪算法查询本簇内其他节点缓存;3)利用中心节点记录的分片信息查询其他簇节点缓存;4)中心节点缓存;如果以上都不命中,则访问流媒体服务器获取需要的数据。
3 缓存置换算法
因为用户的点播规律满足Zipf分布规律[6],如果能把点播率较高的影片分片尽量多的存放在客户边界代理和中心代理,将很大程度上提高流媒体分片的共享速度,这需要高效的缓存置换算法。PSPA总体上是两级代理结构,两级代理缓存将采用不同的置换算法。中心代理缓存采用LRU缓存置换算法,客户边界缓存代理采用基于媒体数量的置换算法,本文重点分析客户边界缓存的置换,并对基于媒体数量的置换算法进行了优化。
基于媒体数量的置换算法的原理是:把一个媒体文件划分成若干长度相同的分片,随着系统的运行,分片在各节点的数量将发生变化,最理想状态下,客户完整观看一部影片无须从根节点获取任何分片,而只从其他节点获取即可,并且从其他节点获取分片远比从根节点获取分片占用的网络资源少,同时网络延迟也小的多。这就意味着如果分片副本数量越少,影片的数量就越多,分片置换的时候首先把副本数量多的置换[7]。
结合本文的缓存模型,对该算法进行了优化。在中心节点中以簇为单位保存各个分片在簇中的副本数量λi,当某节点下载分片i时,λi增加,同时中心节点更新分片信息,当节点分片需要置换时,则置换λ最大的分片,对应的λ减小并更新分片信息,当两个分片的λ相同时,按照先进先出原则置换。
4 仿真实验
本文对访问不同缓存所使用的时间、PSPA系统总缓存空间与影片库总空间不同比值情况下的缓存命中率以及中心节点带宽开销进行了测试,测试环境由9个节点和一个服务器构成,其中一个为中心节点,其他节点设置为两个簇。考虑到实际网络中节点的差异,各节点采用不同配置,所有数据为多次测试数据的平均值,测试结果如图3-图5所示。表1为各符号的含义。
由图示数据可以看出,在簇内和簇间,由于高速网的存在,访问的数据不太大时,Tnc和Tmc相差不大,能够提供流媒体分片的快速共享。对中心节点访问,当数据小于30KB时,处理时间Tcc在400μm以内,而直接通过流媒体服务器提供数据,处理时间一般远大于Tnc、Tmc、Tcc,说明PSPA系统能够有效提高流媒体的播放质量。同时,PSPA系统对带宽的占用也比较小,实验数据显示在系统的启动的初期,由于分片较少,对带宽的占用还较多,但随着系统中分片的增加,系统对带宽的占用成下降趋势,最终趋于平稳。当出现集中点播时,PSPA系统对带宽占用基本不变,相对应的C/S模式带宽占用则出现很大波动。
5 结论
本文提出了一种新的3G流媒体缓存代理PSPA设计,并在其基础上提出了基于P2P的缓存置换策略。通过仿真实验可以看出,PSPA与SCOP的结合可以有效减小数据传输的延迟,优化代理的储存空间,使代理负载均衡,降低了对网络带宽特别是对移动核心网带宽的占用。但是实验也反映出了一些问题,将在后续进一步研究:当两个簇距离较远时,数据访问时间将会延长;当点播冷门节目时,延迟较大,并且缓存命中率降低;中心缓存代理负担相对较重等。
摘要：3G时代已经到来,伴随着3G的快速发展,移动流媒体服务的需求迅速增长。由于移动网络带宽远达不到互联网的带宽,流媒体业务的增长将增加网络延迟,影响流媒体的观看质量,因此提出了一种新的基于P2P的3G流媒体缓存代理结构PSPA,配合PSPA设计了代理缓存置换策略SCOP,该设计能有效降低对移动核心网带宽的占用。最后,仿真实验和实验结果分析表明,PSPA体系与代理缓存置换策略SCOP的结合,能有效提高移动流媒体的服务质量,对3G流媒体的应用具有一定的参考价值。
关键词：移动流媒体,P2P,缓存置换,缓存代理
参考文献
[1]Chai Yunpeng,Gu Lei,Li Sanli.Cluster-Based Edge Streaming Server with Adaptive Load Balance in Mobile Grid[J].JOURNAL OF COMPUTER RESEARCH AND DEVELOPMENT,2007,44(12):2136-2146.
[2]YANG Bo,LIAO Jianxin,LV Xinrong,et al.Design and Implementation of Streaming Media Cache System in3G Network[J].COMPUTER ENGINEERING,2007,33(13):213-215.
[3]Napster[EB/OL].http://www.napster.com/.
[4]Gnutella[EB/OL].http://gnutella.wego.com/.
[5]kazaa[EB/OL].www.kazaa.com.
[6]Cai Qingsong,Li Zimu,Hu Jianping.Study on characterizing streaming media and user access to media on the internet[J].Journal of Bei-jing University of Aeronautics and Astronautics,2005,31(1):25-30.
媒体缓存 篇6
(一) 系统结构
系统结构的整体设计结合因特网的结构特点, 原始流媒体服务器与分布在各自治系统内的代理通过骨干网互连组成流媒体CDN, 各因特网自治系统内的代理与客户机组成与其他自治系统相互独立的P2P流媒体网络如图1所示。
(二) 传输策略设计
在整个系统的传输策略中, 必须把各节点同服务器组成一棵多播树, 基于层次簇的概念提出了一种自适应分布式多播树构建协议NICE, 如图2所示, 这棵多播树必须遵循以下几条原则:
1. 在任意一层中, 其成员节点只能属于一个簇;
2. 如果节点a属于层的一个簇, 则它必然是层中一个簇的簇头;
3. 层中如果没有成员节点i, i也不可能出现在层中 (j>i) ;
4. 每个簇的大小都在k到3k之间, k是系统常量, 簇头为处于簇几何中心的节点;
5. 这颗多播树最多只能有层且最高层只有一个成员节点。
根据NICE协议, 我设计的流媒体系统模型中, 当用户节点a向系统发出请求时, 它根据网络速度和其IP地址被索引服务器划入一个域, 在这个域中, 节点相互之间都建立了连接, 节点a点播影片时, 首先在域中进行搜索, 如果其他节点有他所需要的数据, 就直接从域中节点下载数据。如果域中没有需要的数据, 节点a就向服务器发出查询命令, 服务器就向节点a返回拥有数据片断的节点地址, 然后节点a就与这些节点建立连接以下载数据。如果用户节点退出下载, 首先它向索引服务器发出信息, 则索引服务器就把它从所属的域中删除。
(三) 节点的管理
1. 新节点的加入
当新节点加入的时候, 系统必须把它映射到L0层的一个簇中, 图3中展示了一个加入过程:
假设A12要加入多播组, 它首先联系服务器提出加入请求, 服务器返回给它层级结构最高层即L2层的主机节点地址, 待加入的节点随即连接最高层L2层的节点C0, C0通知A12在次高层L1层中以它为领袖节点的簇中其他节点B0、B1、B2的地址, A12联系这些节点, 在这些节点中寻找和它相距最近的一个, 在本文的讨论中, 这种距离的远近是用节点主机之间的端到端延迟来表征的, 然后位于L1层的这个节点又将它自己所在L0层簇的所有节点地址通知A12, 这个过程使得A12能在L0层找到其应该位于的簇, 并掌握该簇其他节点的地址。
一个典型的加入过程需要的请求-应答消息O (k1ogN) 对, 由于反复为一个新节点寻找最“好”的簇使其加入, 相应需要很多查询和应答工作, 因此, 就造成加入过程的延迟可能相对较长, 一个可能的改进方案是使待加入节点暂时找到一个父节点来接受数据内容, 这样就能够使用户的等待时间大大缩短。
2. 节点的离开和故障的恢复
当一个节点离开多播组的时候, 它会发送Remove消息给它所在的所有簇, 这称为节点的正常离开。节点正常离开后, 其所在最高层的相应簇删除这个节点, 由于这个节点是其下层所有相应簇的领袖节点, 故这些下层簇的领袖节点需要重新选择。
但有的情况下, 比如网络连接突然断开, 节点主机崩溃, 此时非正常离开的节点不能够及时通知所有簇内的其他节点, 则其他节点根据节点心跳信息去检测节点的离开, 如果若干个时间间隔没有收到一个节点的软状态信息, 则认为此节点已经脱离该簇。
当一个簇的领袖节点离开的时候, 那就必须在簇内重新选择一个领袖节点, 其方法如下:每个节点根据现有信息重新计算以选择领袖节点, 由于各节点状态信息存载不一致的可能性, 因此若选择的领袖节点不唯一, 则需通过交换心跳信息来使其唯一化。
IP网络的路由遵从最长路由匹配的原则, 所以, 根据客户机的IP地址可以比较一台机器分别与另外两台机器间距离的远近 (跳数) , 基于这一考虑, 下面给出一种新的替换节点的查找策略。
(1) 正在接受流媒体服务的客户机每隔一定时间 (比如一分钟) 就从代理服务器下载一次能够提供本机正在播放的流媒体服务的客户机列表;
当正在为本机提供服务的客户机不能及时提供服务时:
(2) 按与本机IP地址最大匹配的原则从列表中选择替换者并通知代理服务器原服务提供者失效;
(3) 验证新替代者的可用性, 若不可用重复 (2) , 若可用则请求所需流媒体内容。
这一过程所造成的流媒体内容的间断或抖动可适当增加播放缓存屏蔽掉, 一旦本机与新的服务提供者取得联系, 便以最快速度下载流媒体内容, 直到播放缓存中的流媒体内容恢复到正常水平。
(四) 代理服务器的缓存及替换策略
本文提出的基于P2P混合流媒体代理缓存系统中, 代理服务器在系统中扮演着两个角色, 一是做系统的代理服务器;另一个作用是P2P索引服务器, 向各用户节点发出控制流, 协调并控制节点的数据流。
通过大量的调查研究发现, 对于节目数目确定的流媒体系统中, 用户对节目点播服从Zipf分布, 一般情况下, 有90%的用户集中点播10%的节目。对于冷门节目, 同时点播的用户少, 不能体现P2P技术的优势;但对于热门节目, 同时有大量的用户点播, P2P技术优势逐渐体现, 随着用户数的增加, 这种优势更加明显。因此, 对于节目的冷热程度, 代理服务器应采用不同的缓存替换策略。
冷门节目:对于冷门节目, 本文提出用户直接从代理服务器上点播的方式, 此时代理服务器的缓存是系统中唯一的缓存, 根据代理服务器的性能可以采用前缀缓存、分段缓存、及批处理缓存以及补丁缓存等CDN技术常用的缓存技术和替换策略。
热门节目:对于热门节目, 本文提出一种基于节点的缓存及替换策略, 以下是缓存和替换过程:
1. 首先, 代理服务器对热门的节目进行整体缓存;
2. 当第一个节点加入时, 节点用户从代理服务器上边下载边观看边缓存并在P2P索引服务器中注册其缓存内容;
3. 第二个节点加入时, P2P索引服务器查找缓存有该内容的在线客户机节点目录, 选择第一个节点为请求者提供服务, 同时缓存内容并注册其缓存内容;
4. 当有大量节点加入时, 新加入节点从最近的空闲节点处下载观看, 并且缓存媒体内容并注册其缓存内容;
5. 代理服务器根据客户机节点注册目录, 判断, 如果流媒体所有片断都分布在不同的各节点中 (假设一部片长为120min, 大小为300M的影片, 可以1min为一片段, 共分成120个片断, 如果不同的节点中分别有这120个片段中的一个片段或多个片段的缓存时) , 这时, 代理服务器中可以释放此流媒体文件的缓存空间;
6. 如果从客户机节点目录判断, 有影片某一片断在任何节点都没有缓存时, 此时代理服务器从源服务器中快速下载此片断并缓存, 以补充节点中没有缓存的片断, 以供各节点使用。
(五) 户节点的缓存及替换算法
客户机在下载播放一个流媒体文件时可根据自身状况决定是否对此文件进行保存, 并供其他客户下载播放。能缓存流媒体文件并充当其他客户机的服务器的客户机必须本身有足够的资源, 包括可用的磁盘空间、输出带宽、磁盘的I/O带宽, 以及CPU的处理能力等, 除了能保证客户机自身对这些资源的消耗外, 还有足够的空闲资源能为一个或一个以上的其他用户提供服务。
客户机在播放一个新的流媒体文件时同时缓存该文件, 以往客户机的缓存空间一般不大, 一次只能缓存一个流媒体文件, 所以以往的算法是客户机每下载播放一个新文件时都要清空自己的缓存空间并缓存新下载的文件, 但是考虑到目前客户机性能的提高, 尤其是内存容量的增加, 目前客户机同时缓存多个流媒体文件已不是问题。同时, 如果客户机要下载的文件流行度高, 其系统中已有足够多的其他客户机已缓存了该文件, 本机就没有必要再对其缓存了, 基于以上考虑, 我对此问题进行了深入研究, 提出了一种替换算法。
下面是该算法的详细描述, 其中M表示要被下载的文件, 客户端流媒体文件缓存算法:
1. 首先客户机根据P2P索引服务器客户端缓存目录, 如果客户端传输的流媒体文件所有片断都已经分布在不同的节点中, 则不需要缓存M, 否则执行2;
2. 判断客户端有没有足够的缓存空间, 如果有, 则缓存M, 并在P2P索引服务器中注册, 否则, 执行3;
3. 若客户端没有足够缓存空间, 则删除满足“流媒体文件所有片断都已经分布在不同的节点中”的流媒体文件, 并注销所删除文件在缓存代理服务器上所做的注册信息, 再缓存M, 并在P2P索引服务器中注册, 否则, 执行4;
4. 若没有满足“流媒体文件所有片断都已经分布在不同的节点中”的流媒体文件, 则删除节点中被最多节点使用的文件, 注销所删除文件在P2P索引服务器上的注册信息, 并通知代理服务器, 缓存删除的流媒体文件中没有在其他节点中缓存的块, 再缓存M, 并在P2P索引服务器中注册, 结束。
算法的设计目标是使流媒体文件在客户节点中有足够的缓存, 又使每个客户节点缓存的流媒体文件数量最少, 从而最大可能地提高客户节点的效率, 且减少客户节点直接从代理服务器下载文件的数量, 进一步提高系统容量。
(六) 小结
在基于P2P的混合结构中, 充分利用P2P技术和CDN技术的优势, 对流行程度不同的节目采用不同的方式进行处理, 挖掘了流媒体服务器、流媒体代理服务器和客户节点的有效资源。充分利用了客户节点的资源, 提高客户节点的效率, 从而大大提高了代理服务器的容量, 减少了代理服务器的数量, 节省了建设成本, 同时也提高了客户的命中率, 减少了用户延迟和提高了空间利用率。通过这种混合结构, 大大提高了流媒体服务的质量。
参考文献
[1]易光华, 傅光轩.基于对等网络的VOD模型研究[J].网络安全技术与应.2005 (2) :26-28.
[2]方炜, 吴明晖, 应晶, 张引.基于P2P的流媒体应用及其关键算法研究[J].计算机应用与软件, 2005, 22 (5) :35-38.
基于缓存框架的Web缓存研究 篇7
1 缓存框架OSCache研究
OSCache由Open Symphony设计,它是一种开创性的JSP定制标记应用,提供了在现有JSP页面之内实现快速内存缓冲的功能。OSCache也是一个被广泛采用的高性能的JZEE缓存框架,它能应用于任何Java应用程序的缓存解决方案。
OSCache是Open Symphony组织提供的一个J2EE架构中Web应用层的缓存技术实现组件,它能缓存任何Java对象,拥有全面的API,可以永久缓存,支持集群,缓存过期控制等等。
1.1 缓存标签实现部分页面缓存
OSCache提供一系列的JSP标签库,实现主要缓存功能,这些标签是:cache、usecached、flush等等。
1)cache标签
这是OSCache标签库中最重要的一个标签,使用格式如下:
some JSP content//需要缓存的内容
包括在标签之间的内容将被缓存处理。页面第一次加载的时候,标签中的内容被处理并被缓存起来,页面被再次访问的时候,缓存机制首先会检查这部分内容是否失效。如果缓存内容已经失效,这时缓存内容将被重新处理并且返回处理过后的信息;如果缓存内容没有失效,那么返回给用户的将是缓存中的信息。
2)usecached标签
这个标签是cache标签的一个嵌套标签,主要用在程序控制中通知父标签是否使用以前的缓存内容,如:
<%try{%>
some JSP content//需要缓存的内容
<%}
catch(Exception){%}
<%}%>
上述代码在系统容错性方面提供了很好的容错方案。当程序捕获到异常时,通过Catch分支中usecached标签的use属性执行操作。当use属性值为true时,读取缓存内容。若此时系统发生错误,用户看到的不再是单调乏味的报错页面而是储存在缓存中的内容。
3)flush标签
该标签的作用体现在允许操作者在任意运行期间自主手动刷新缓存内容。格式如下:
上述代码表示刷新session范围内键值为my Example的缓存内容。
1.2 Cache Filter实现整个页面缓存
在OScache组件中提供了一个cache Filter用于实现页面级缓存,开发者只需配置Web.xml便可实现该功能。Cache Filter用于对Web应用中的某些动态页面进行缓存,尤其是那些需要生成PDF格式的页面以及包括大量图片文件的页面。Cache Filter的运用不仅缩短了服务器响应时间,减小了数据库服务器的压力,而且显著提高了Web服务器的性能。
1.3 Java API for OSCache缓存管理
在实际应用中除了JSP标签库,还可以使用OSCache提供的Java API。其中有一个重要的Java类———General Cache Administrator,用它来建立、刷新和管理缓存。
2 Hibernate数据缓存
在操作数据库的时候,通常使用SQL语句添加、删除、更改、查询数据,ORM(object Relational Mapping,对象关系映射)通过使用描述对象和数据库之间的映射,将Java程序中的对象自动持久化到关系数据库中。Hibernate正是一个ORM的实现,它使得与关系数据库打交道变得十分轻松,就像操作普通Java对象一样,同时不必考虑如何把它们从数据库表中取出或放回到数据库表中。Hibernate模型结构如图1所示。
2.1 Hibernate一级缓存和二级缓存
Hibernate提供两级缓存,一级缓存是Session级别的缓存,属于事务范围的缓存。这一级缓存由Hibernate管理,一般情况下无需进行干预;二级缓存是Session Factory级别的缓存,属于进程范围或群集范围的缓存。这一级别的缓存可以进行配置和更改,并且可以动态加载和卸载。Hibernate还为查询结果提供了一个查询缓存,它依赖于第二级缓存。Hibernate的二级缓存由从属于Session Factory的所有session实例共享,Hibernate二级缓存的工作过程如下:
l)查询的时候,形成一条SQL语句“select*from table_name where…(查询条件)”查询数据库,一次性获得所有的数据对象。
2)把获得的所有数据对象根据ID(对象在业务表中的唯一标识)放入二级缓存中。
3)当Hibernate根据ID访问数据对象的时候,首先从Session一级缓存中查找,并按从一级缓存,到二级缓存,再到数据库的顺序查找,直到找到查询结果,并把结果按照ID放入缓存。
4)删除、更新、增加数据的时候同时更新缓存。
显然,对数据库中所有的数据都实施缓存是最简单的方法。但是,如果没有对当前数据的使用情况进行考察就全部缓存起来,内存会迅速被几乎不可能再重用的数据充斥,系统的性能会急剧下降。因此,只有当数据满足一定的缓存条件时,才可以将其纳入缓存管理。
2.2 Hibernate二级缓存的实现
Hibernate为众多的第三方缓存组件提供接入接口,如JCS,Ehcache,OSCache,Swarm Cache,JBoss Cache等。Hibernate对缓存进行了良好封装,透明化的缓存机制使得在上层结构的实现中无需面对繁琐的缓存维护细节。目前Hibernate支持的缓存机制通过下面的Java类来实现net.sf.Ehcache.hibernate.Provider,net.sf.hibernate.cache.OSCache Provider,net.sf.hibernate.cache.Swarm Cache Provider,net.hibernate.cache.Tree Cache Provider。
3 Web应用缓存方案的提出
企业级的Web应用除了实现核心业务外,还包括必不可少的查询模块。针对查询模块出现的问题,结合上述缓存技术提出一个解决方案。
3.1 查询模块
查询模块,通常是一个用户接口。通过该接口,用户可以查看存储在数据库中的各种信息。一般来说,使用查询模块的员工分为两类:一类人员是使用该系统的一线操作员,另一类人员是通过该模块查看并掌握业务总体情况的领导。
对于一线操作人员来说,查看的数据量相对较少。因为他们只需关心自己最近一小段时间内处理那部分数据,特别是每一条记录的详细明细。这类人员对这些记录的关心程度与时间先后顺序密不可分,越是新近的操作记录他们查看的频率越是高。并且这些记录都保持稳定,生成后不再被更改。因此,对数据库的查询结果进行缓存是一个良好的系统提速方案,可以显著提高系统的响应速度。
一线操作员的查询流程归纳为以下几个步骤:
1)用户选择或者输入查询条件,提交查询请求。此时系统形成完整的SQL语句提交给数据库,例如:“select*from table_name where condition”。
2)系统根据形成的SQL语句从数据库中读取所有符合查询条件的实体列表,显示在前台页面。
3)用户查看实体列表,找到真正关心的某一条数据,查看详情。此时传递该条记录的ID号,形成新的SQL语句:“select*from table_name where id=***”。
4)数据库服务器进行再次查询同时返回该条记录详细信息。
从上述流程了解到,对数据库的实体查询操作并不涉及实体的更新。一旦信息被返回,用户不会关注查询过后数据库中的数据是否发生改变,而且用户更加关注最新的一条或几条记录。因此,对数据库的查询结果进行缓存是一个良好的系统提速方案。具体思想为,将查询出来的所有记录进行分页显示,并将第一页里的每条记录信息由动态页面转化为静态页面缓存起来。提供一个专门的Java类,负责将动态页面按规定的模式解析成为静态页面,并将每条记录的明细页面保存为“***.html”的形式,其中***为该条记录的ID号码。一线操作员使用查询模块的缓存方案流程如图2所示。
使用查询模块的另一类用户是领导。他们通过查询模块了解一段时间内发生业务的总体情况,其时间间隔较长,查询数据量较庞大。对于这样的查询,查询响应的速度显得尤其重要。无论是访问数据库还是将查询结果显示到前台都会耗费过多的系统资源,必须实现分页功能缓解系统压力。将查询出来的数据一并放入缓存,只有当用户需要查看具体某页的时候才显示该页的查询结果。这样做可以避免重新获取和释放对象,不必每次都从数据库中获取数据。
此时需要这样一种机制,不仅能够在内存中保存对象同时也提供保持内存中对象更新的功能,即对象缓存。Hibernate通过对不同数据库的统一接口设计,实现透明化通用分页实现机制。以下是实现分页功能的关键函数:
Criteria.set First Result(int x)//从第x条记录开始获取
Criteria.set Fetch Size(int y)//获取记录大小
更重要的是缓存框架作为第三方插件可以方便的引入到Hibernate中,因此对于查询模块的缓存设计提出Hibernate整合缓存框架的方案。领导使用查询模块的缓存方案如图3所示。
3.2 缓存框架的选择
在选择缓存框架之前,首先列出选择缓存框架需要达到的目标:
1)在Web应用中能够快速访问数据。
2)提供可配置的缓存管理,以便通过描述方式而不是编码方式修改参数。
3)发挥多个缓存框架的优势,提供符合具体项目需求的缓存框架结构。
4)最流行的Java开源缓存框架是OSCache和Ehcache。对于运用JSP开发表示层的Web应用来说,OSCache是一个易于操作并能快速提高性能的页面级缓存,但是对于Hibernate来说OSCache并不是最好的选择。而Ehcache本身出自于Hibernate,能够更好的支持Hibernate。因此,采用Ehcache作为Hibernate的二级缓存实现。
从整个系统的角度来说,具体缓存方案为:利用Ehcache作为Hibernate的二级缓存,实现查询结果的对象缓存,同时利用0SCache实现对JSP页面的缓存。
上述缓存方案应用于湖北省水路交通规费征稽网络系统,实现从略。
4 结束语
改文重点阐述了缓存框架OSCache的缓存组件与Hibernate的数据缓存管理。Hibernate不仅能够提供强大的、高性能的数据查询功能,而且还拥有良好的缓存管理机制。本文提出将第三方组件OSCache、Ehcache和Hibernate整合在一起的Web缓存方案,实现了页面缓存和查询结果的对象缓存,很大程度地改善了系统的性能。
参考文献
[1]赵玉伟.WWW中缓存机制的应用研究[D].武汉:武汉理工大学,2006.
[2]Duane Wessels.Web Caching[M].United States of America:O'Reilly&Associates Inc,2001:1-6.
[3]阎洁.Web应用若干关键技术的研究[D].武汉:武汉理工大学,2008:33-46
[4]opensymphony.What is OSCache[EB/OL].http://www.opensymphony.com/oscache/wiki/what%20is%20OSCache.html,2005.
[5]opensymphony.Tag Reference of OSCache[EB/OL].http://www.opensymphony.com/oscache/wiki/JSP%20Tags.html,2005.
[6]Object Renational Mapping-Persistence and Caching for Java[EB/OL].http://cayene.apache.org,2007.
[7]夏昕,曹晓钢,唐勇.深入浅出Hibernate[M].北京:电子工业出版社,2005.300-301.
媒体缓存 篇8
之后, 直写缓存的算法成为了解决容量问题的一个方法。用闪存卡存储热点数据并且所有设备共享存储也就成为了一种标准做法。我们称其为基于服务器的缓存1.0版本。虽然这个方法在一台物理服务器中行之有效, 但是当虚拟工作负载迁移到另一台物理服务器, 那么这个工作负载就不能载使用原来服务器的缓存, 而且热点数据必须重新创建, 热点数据在第二台物理机器的缓存被创建之前将会有一段时间性能下降。这种现象需要管理员介入, 实现服务器集群负载平衡。1.0版缓存的另一个难题是需要支持集群应用。最后, 管理员需要更改配置和脚本, 以确保多个物理服务器上的数据不被意外损坏。
QLogic的Fabric Cache解决了这些问题, 并创建基于服务器的高速缓存2.0。二十多年以来QLogic一直致力于fabric层面的革新解决方案, 因此QLogic从新型的主机总线适配器 (HBA) 着手来解决缓存1.0的问题, 则显得顺理成章。Fabric Cache™QLE10000缓存SAN适配器可以作为PCIe卡的闪存连接到光纤通道 (FC) HBA。读和直写式缓存算法完全交由HBA上的系统级芯片 (SOC) 进行管理。SOC负责在本地闪存卡或架构内任何其他Fabric Cache卡上为读操作寻找给定的数据块。这就是基于服务器的高速缓存2.0。因为FC架构具有带宽优势, 而SOC具有智能, 存储区域网络 (SAN) 中的读取操作仅在当数据块不在任何所连接闪存内存上的时候才发生。这解决了物理机之间移动的虚拟化工作负载问题, 因为无论虚拟机迁移至何处, 工作负载都可以访问到原来的缓存。
Fabric Cache QLE10000解决方案使用两个PCIe插槽。第一个插槽可以容纳包括SOC在内的适配器, 并且第一个插槽通过带状电缆和第二个PCIe板相连, 实现像PCIe接口那样的功能, 并提供200GB或400GB企业级的单个单元 (SLC) 闪存内存。第二个插槽为闪存板提供电源。SLC的使用让系统运行速度更快, 并最大程度的利用闪存单元。由于闪存是集群内所有服务器的共享资源, 对于所有Fabric Cache适配器而言, 闪存的总容量就显得非常充足且可扩展。且无需修改SAN或任何其他交换设备或电缆设施。在一个四核的SOC上, 该适配器可提供一个8Gbps的双端FC连接和一个缓存引擎。
QLogic标准的管理工具提供一个直观的图形用户界面或者是命令行界面实现控制参数。高级用户和OEM厂商可以通过开放的应用程序编程接口 (API) 来访问系统, 并使用特定的功能。不久将有可用于VMware、HyperV、Xen和其他管理工具的插件。有一点不会改变的是, Fabric Cache使用标准的QLogic适配器驱动堆栈。该堆栈支持众多操作系统, 包括Windows Server和Linux。
如果采用服务器端缓存1.0配置, 则需要购买和安装一个PCIe闪存卡和一个完全独立的高速缓存软件系统, 该系统除了HBA驱动之外, 还需要专用的驱动程序。Fabric Cache可针对HBA卡、闪存和缓存在单个SKU下进行定制。
QLogic使用TPC-E测量了FabricCache的性能。硬件配置使用的是32GB DDR内存和24核的Dell PowerEdge720服务器, 操作系统是Windows Server 2008。SAN环境是使用HP EVA6300, 配置有7个100GB的LUN和24个10K RPM硬盘驱动器。另外, HBA使用具有400GB闪存容量的Fabric Cache QLE10542。第一组测试中使用的一台服务器运行250个用户。在没有缓存的情况下, 系统性能为每秒74交易事务处理量 (TPS) 。随着缓存启用后, 系统性能提升7倍, 达到544TPS。
第二组测试使用四台服务器, 负载250个用户工作量。在没有缓存的情况下, 系统表现为87 TPS。随着缓存启用后, 系统性能上升至1, 925 TPS, 增长达22倍。第三组测试评估共享缓存环境下的性能, 使用两台服务器, 负载250个用户的工作量, 并且配置了一个本地缓存和SAN (可以跨服务器共享) 。相比本地缓存544TPS的性能, SAN缓存只稍微慢一些, 表现为500TPS, 最大约8%的差异。在这两种情况下, 本地或SAN缓存命中的延时都是小于1ms。这表现还不错, 尤其是你要知道这个SAN高速缓存中还包括架构延迟和PCIe延迟。这表明, 该架构具有足够的带宽用于物理服务器之间的共享SAN缓存。
大多数数据中心都部署了大量管理SAN的脚本。基于服务器的高速缓存1.0意味着需要修改许多有关数据位置和负载均衡的脚本。QLogic的Fabric Cache在添加到主机的过程中无需额外的软件, 因此对现有的配置管理来说是完全透明的。这意味着, 可以在不中断现有运营的情况下, 大大提升工作负载的运行速度。只要将HBA卡安装到集群中, 然后启动缓存即可。SAN上的负荷将大大降低, 现有系统的使用寿命将得到大大延长, 并且数据中心可以用成本更低、容量更高的硬盘来进行配置。
缓存模块设计浅谈 篇9
下面我们以Map接口为例来说明设计下文件存取模块使用各种实现类时, 总是要生成数据结构的具体实现, 因为系统不知道集合中如何存放对象。但在访问实际集合时, 用使用接口的方法, 这样就可以在需要时将数据结构从数组集合变成散列表的集合然后由于集合类仍然实现相同的集合接口, 不需要改变他的代码。
用何种方式存放对象呢?这是缓存最为重要的一步, 在Java 2中有很多的数据结构接口, 接口和集合类的选择是缓存非常重要的。
Map接口用于保持关键字 (Key) 和数值 (Value) 的集合, 集合中的每个项目加入时都提供数值和关键字
Map接口有三个实现集合类;Hash Map、Weak Hash Map、和Tree Map类。Hash Map是基于Hash表的映射;Weak Hash Map是基于弱引用Hash表的映射;Tree Hash是基于平衡树的映射。
Hashtable继承自Dictionary类, 而Hash Map是Java1.2引进的Map interface的一个实现Hash Map允许将null作为一个entry的key或者value, 而Hashtable不允许还有就是, Hash Map把Hashtable的contains方法去掉了, 改成containsvalue和contains Key。因为contains方法容易让人引起误解。最大的不同是, Hashtable的方法是Synchronize的, 而Hash Map不是, 在多个线程访问Hashtable时, 不需要自己为它的方法实现同步, 而Hash Map就必须为之提供外同步。Hashtable和Hash Map采用的hash/rehash算法都大概一样, 所以性能不会有很大的差异。
Hash Map可谓JDK的一大实用工具, 把各个Object映射起来, 实现了“键--值”对应的快速存取。但实际里面做了些什么呢?
在这之前, 先介绍一下负载因子和容量的属性。大家都知道其实一个Hash Map的实际容量就因子*容量, 其默认值是16×0.75=12;这个很重要, 对效率很一定影响!当存入Hash Map的对象超过这个容量时, Hash Map就会重新构造存取表。两个关键的方法, put和get:
先有这样一个概念, Hash Map是声明了Map, Cloneable, Serializable接口, 和继承了Abstract Map类, 里面的Iterator其实主要都是其内部类Hash Iterator和其他几个iterator类实现, 当然还有一个很重要的继承了Map.Entry的Entry内部类, 它包含了hash, value, key和next这四个属性, 很重要。
这个就是判断键值是否为空, 并不很深奥, 其实如果为空, 它会返回一个static Object作为键值, 这就是为什么Hash Map允许空键值的原因。
我们把关键的方法拿出来分析:
因为hash的算法有可能令不同的键值有相同的hash码并有相同的table索引, 如:key=“33”和key=Object g的hash都是-8901334, 那它经过indexfor之后的索引一定都为i, 这样在new的时候这个Entry的next就会指向这个原本的table[i], 再有下一个也如此, 形成一个链表, 和put的循环对定e.next获得旧的值。到这里, Hash Map的结构, 大家也十分明白了吧?
所谓的重构也不万能的, 就是建一个两倍大的table, 然后再一个个indexfor进去, 如果你能让你的Hash Map不需要重构那么多次, 效率会大大提高!
参考文献
[1]飞思科技产品研发中心.《Java2应用开发指南》.电子工业出版社.
[2]王亚平.《数据库系统工程师教程》.清华大学出版社.