缓存管理（精选12篇）
缓存管理 篇1
在互联网、云计算、大数据等高速发展的背景下,数据呈现爆炸式地增长。而其中增长最快并且最容易给信息基础架构带来挑战的就是数目庞大的小文件。由于在元数据管理、访问性能、存储效率等方面面临巨大的挑战性,因此海量小文件(Lots of Small Files,LOSF)问题[1]成为了工业界和学术界公认的难题。
HDFS分布式文件系统[2]是Apache Hadoop[3]项目开发的适合运行在通用硬件上的分布式文件系统,具有高可靠性、高容错性的特点,能提供高吞吐量的数据访问,适用于海量数据集的存储和分布式处理。然而HDFS文件系统并非是完美的,HDFS的设计建立在“一次写入、多次读取”任务的基础上,对HDFS来说,请求读取整个数据集要比读取一条记录更加高效。如果要处理一些用户要求时间比较短的低延迟应用请求和频繁读取大量小文件,则HDFS不适合。
目前有许多关于对HDFS读写性能优化的研究,文献[4]中提出了一种在HDFS的数据节点增加本地缓存的方法,该方法虽然缩短了数据读取的时间,但是每次读取数据时都必须访问缓存列表,同时每个数据节点都要维护一个缓存列表,缓存的数据块是分散的,可能会出现多个副本都缓存的情况,造成节点内存空间的浪费。文献[5]中通过增加新的本地缓存系统架构,使用合适的缓存算法来调整和管理数据在本地文件系统和分布式文件系统中的存储位置以及数据队列,该方法降低了对HDFS文件系统的频繁访问,在一定程度上减轻了主节点(Name Node)的负载。文献[6]针对小文件的读取问题提出了一个基于关系数据库的小文件合并策略,通过获取存储在数据库的元数据信息,直接以流式的方式读取小文件,并采取节点负载均衡策略,降低Name Node节点的内存消耗。
本文针对HDFS频繁访问海量小文件时效率低的问题,借鉴HDFS中的集中式缓存管理机制,提出了一种基于集中式管理的缓存优化方案。通过定义小文件,对缓存文件进行集中式管理;为保持缓存数据的一致性采用了一种新的一致性管理策略;并对其进行了缓存读取性能的测试,实验证明本文提出的方案很好地解决了HDFS频繁读取海量小文件的问题,提高了文件的读取效率。
1 总体架构
本文所提出的一种基于集中式管理的缓存优化方案遵循以下原则:保持原始框架;本文提出的优化方案是在已有的分布式文件系统的基础上,通过集中式的管理对小文件的读取进行优化,而不是提供一个新的hdfs框架,因此不需要对hdfs的存储框架和源码做任何的改动。
本文提出的一种基于集中式管理的缓存优化读取方案主要由3个部分组成,即客户端(Client)、主节点(Name Node)、数据节点(Data Node),如图1所示。其中Hadoop集群的组成部分:主节点和数据节点对该缓存优化方案中的客户端用户来说是透明的,它在该架构中是为客户端用户提供一系列相关的服务。客户端通过RPC协议[7]分别与Name Node和Data Node节点进行通信,完成对数据的读写操作。本文在集群客户端内设计并实现了缓存控制模块,其中缓存控制模块由缓存读取、缓存数据一致性控制部分组成。对Name Node和Data Node节点来说,因为客户端需要控制缓存文件和完成对缓存文件的各种相关操作,所以在提出的缓存优化读取方案是对客户端进行了扩展。
2 缓存优化方案的实现
2.1 缓存读取模块
如图2所示,本文通过设计一种基于集中式管理的缓存读取模块来处理频繁访问小文件的操作,当客户端Client向集群中的Name Node节点申请读取数据文件时,总体可以概括为以下4个步骤:
1)Client获得待读取的数据文件信息,判断该文件是否位于缓存中。
2)若该文件已缓存,那么直接与Data Node通信,读取数据文件。
3)若该文件不在缓存列表中,则判断是否可以缓存该文件,其中缓存的条件为小于1M的小文件;当满足缓存条件时,进行缓存操作,然后读取缓存数据文件,否则直接读取数据文件。
4)本文中使用的缓存替换算法为LRU[8](Least Recently Used)缓存替换算法。具体流程如图2所示。
已缓存的数据文件元信息通过集中式管理的方式存储到客户端用户的缓存模块中,即缓存列表中,以此实现对已缓存数据的集中式管理。通常认为大小在1 Mbyte以内的文件称为小文件,因此本文将缓存文件的阈值设置为1 Mbyte。
2.2 缓存替换与数据一致性模块
在hadoop的集中式缓存管理中,没有集成和使用任何的缓存替换算法,如果缓存空间已满或者删除缓存操作时,需要手动进行。
缓存读取缓存模块维护了一个缓存列表,其中缓存列表中缓存的是缓存数据文件在hdfs中的存储路径和Name Node中所对应的缓存管理(cachemanager)信息。缓存模块记录了所有被更改过的缓存项,这些缓存项按照LRU缓存替换算法进行排列,当客户端读取的数据文件被缓存时,缓存列表就被命中,每次对缓存列表中的缓存内容引用,缓存列表都会进行一次更新,即将引用的缓存项移至缓存列表的表头。当缓存空间已满时,采用LRU缓存替换算法进行缓存替换。
数据一致性[9]的实现,缓存中的数据可能会因为用户的操作而出现与低速实体数据不一致的情况,为了使缓存数据与低速实体数据保持一致性,一般情况下需要定期地将缓存中的数据与低速实体中的数据进行同步。在本文中,由于hadoop系统中的Data Node会向Name Node定期发送heartbeat RPC用于表明节点的状态,同时Data Node还会向Name Node定期发送block report和cache block用于同步block和cache的状态;因此hadoop系统本身具有数据一致性和数据持久化的特性,所以在本文所提出的方案中,数据一致性只需要考虑客户端用户维护的缓存列表与Name Node节点中的cachemanager的数据一致性即可。本文提出的策略是:
客户端定期获取cachemanager中的缓存项,与客户端维护的缓存列表进行比较,cachemanager与缓存列表中的缓存项不一致,大概可以分为以下两种情况:
1)缓存列表中存在,但是cachemanager中没有缓存该数据文件,那么删除缓存列表中的缓存项;
2)cachemanager中已缓存该数据项,但是缓存列表中没有该缓存项,那么移除cachemanager中的已缓存项。
3 实验与分析
本实验在操作系统为Centos6.6的64位华硕服务器下实现,硬件环境如下:CPU为2个6核Inter Xeon CPU E5-2620处理器,内存大小为64 Gbyte,通过虚拟化技术搭建hadoop集群,集群中设置1个Name Node节点和3个Data Node节点,网络环境为10.0.0.1网段的局域网,软件环境为hadoop-2.5.0。测试文件为小于1 Mbyte的小文件。
为了验证该缓存方案的高效性,测试在改进前后的hdfs框架下小文件的读取能力和响应时间,即Name Node响应数据块请求到客户端读取数据完毕的时间。其中比较结果如图3所示。
由图3可知,该缓存优化读取方案与原始的小文件读取响应时间相比,具有明显的优势,文件响应时间大大缩短。当读取的小文件被缓存命中时,客户端可以直接从数据节点内存中读取数据块,而且对于memory-locality的DFSClient,checksum检验其完整性已经完成,那么通过zero-copy直接读内存中的block。
从图4中可以得出,随着缓存数据文件的增大,文件读取响应时间也在增加;当缓存副本数由replication=1增加到replication=2时,读取响应时间大大缩短;且随着缓存数据文件的不断增大,文件读取响应时间同样发生变化,即replication=1和replication=2的文件读取响应时间的差值越来越大,replication=2到replication=3的文件读取响应时间差值变化不明显。
4 结论
本文针对HDFS频繁访问海量小文件的读取时延和频繁磁盘IO的操作问题提出了一种基于集中式管理的缓存读取优化方案,在集中式管理缓存的基础上,增加LRU缓存替换算法,通过定时刷新缓存管理列表达到保持数据一致性的目的。在缓存读取模块增加缓存预判条件,通过该方法可以避免大文件数据被缓存,不仅使该缓存方案更好地服务于海量小文件,还可以充分利用集中式缓存管理的特性。通过实验表明,该缓存优化方案可以减少小文件的访问时间,提高了海量小文件的读取效率。
本文的进一步的工作,集中式缓存管理目前还没有与YARN结构整合,下一步的研究工作希望可以解决集中式缓存与yarn的整合,减少对Name Node的频繁访问。
参考文献
[1]朱珠.基于Hadoop的海量数据处理模型研究和应用[D].北京:北京邮电大学,2008.
[2]SHVACHKO K,KUANG H,RADIA S,et al.The hadoop distributed file system[C]//Proc.IEEE 26th Symposium on Mass Storage Systems and Technologies(MSST).[S.l.]:IEEE,2010.
[3]陆嘉恒.Hadoop实战[M].北京:机械工业出版社,2011.
[4]赵婧,王洪波,程时端.HDFS数据节点本地缓存的设计与实现[EB/OL].[2015-07-05].http://www.paper.edu.cn/releasepaper/content/201112-98.
[5]YOON S D,JUNG I Y,KIM K H,et al.Improving HDFS performance using local caching system[C]//Proc.IEEE2013 Second International Conference on Future Generation Communication Technology(FGCT).[S.l.]:IEEE,2013:153-156.
[6]张海,马建红.基于HDFS的小文件存储与读取优化策略[J].计算机系统应用,2014,23(5):167-171.
[7]WANG B,CHEN L.Analysis and application of mechanism of Hadoop RPC communiucation[J].Journal of Xi'an university of posts&telecommunications,2012(6):80-83.
[8]周程.视频点播系统缓存算法研究[D].杭州:浙江大学,2011.
[9]陈莉君,康华.Liunx操作系统原理与应用[M].北京:清华大学出版社,2012.
缓存管理 篇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缓存了， 如下图所示：
无形故障——CPU缓存损坏 篇3
没办法，看来暂时没法安装系统了。该不会是什么病毒吧？进入安全模式，用杀毒软件检查，没有发现病毒。重新对硬盘进行分区、格式化均没有发现任何问题。这下麻烦了，用硬件替换法将内存、硬盘、显卡都换了个遍，仍然没有找到故障的原因。最后借来了同学的奔腾D 820换上，问题迎刃而解了。
万幸的是，我的奔腾D 915是三年质保的，离保修期截止还有几个月的时间。拿到维修站，经过维修人员的检查后发现是CPU的缓存出现了损坏，最终顺利地进入了保修处理流程。
tips
缓存管理 篇4
机会网络[1]的节点利用其移动性, 在没有完整链路的网络中使用“存储-携带-转发”的路由方式传递消息。现存的基本网络管理策略有[2,3]:DL (Drop Last Received) :丢弃最新接收的副本;DLR (Drop Least Recently Received) :丢弃在缓存中驻留最久的消息副本;DOA (Drop the Oldest) :丢弃已生存时间最长的消息。KRIFA等人[4]根据副本的历史信息估计其在网络中的副本数, 并推导出能满足最小延迟以及最大传输率所需的删除条件。文献[5]提出了一种基于节点集群的缓存统一维护管理策略, 利用P2P网络[6]的相关技术, 将相邻的节点构成一个簇, 并将能量较高且较稳定的一个节点作为簇头, 通过组网内实时在簇头节点上建立更新树并发送更新的消息。请求节点与簇头的路由距离比它到源节点的路由距离相对较短, 因此这样的策略使节点网络连接更可靠、响应延迟更短和能量消耗更小。叶晖等人[7]提出ON-CRP (Opportunistic Networking Cache Replacement Policy) 机会网络缓存替换策略, 利用消息副本与不同目的节点的相关度来执行缓存替换。由节点的社会属性可找出节点的行为模式, 然后以节点群组为目标进行消息递交, 但由于单一地依靠消息与节点的关联度进行替换判断, 可能会使消息在缓存中保存时间过长, 造成投递延迟增加。
本文综合消息的全局递交率, 根据人类移动模型[8]中表现出的节点移动规律, 考察网络中递交消息副本的路由记录与全局历史缓存信息, 利用消息参数反映的各中继节点和目的节点间的相对关系提出MIPM (Message Information for Priority Management) 缓存策略。根据参数进行缓消息存队列的管理, 由已传递消息的副本计算参数与路由向量记录判断消息送达的可能性, 从而充分利用节点有限缓存, 实现消息最大的成功投递率并降低投递延迟, 以提高网络整体性能。
1 基于消息参数的缓存管理
提出基于消息参数的缓存管理算法包括缓存管理替换与队列管理两个部分。其中替换策略的核心是通过估计副本缓存参数与缓存内消息进行比较替换, 各节点根据自身情况, 结合缓存中的消息参数进行取舍判定;队列管理采用路径向量匹配排队策略, 根据节点维护的状态信息结构进行缓存队列排序管理。
1.1 副本缓存参数
在机会网络中, 网络拥塞通常是由过多消息副本造成的。选取主要影响传输效率的两个参数, 消息副本数和传递深度进行缓存管理, 通过控制消息副本数或根据消息参数变化找到传输较优的平衡点。各参数定义如表1所示。
该策略在消息副本传播时以副本的相关状态参数作为其缓存参数的计算参数, 使单个节点对任一消息i计算的缓存参数更符合当前网络的传输优化条件。缓存策略不控制消息副本转发次数的条件下, 消息i产生后会被各节点在相遇时复制并转发。当每个节点收到新的消息时, 根据副本携带的各参数来估算此消息在整个网络中大致的副本数量nt (i) , 并依此计算出在缓存内分配的优先值Uj (i) , 进而在缓存溢出时根据Uj (i) 对相应的副本做出取舍判断。
消息i缓存参数的计算表达式:
其中Uj (i) 表示消息i到达节点j时的缓存参数, pj (i) 是节点j中消息副本i的效用值。由多副本传输机制, 在任一时刻t, 对于消息i可知其副本的消息剩余存活时间越小, 则消息i在网络中停留的时间越长, 被节点复制转发的副本越多, 进而增大其成功投递率。
由文献[9], [10]可知, 在大多数的移动模型中, 任意两节点的相遇时间t服从指数分布, 或在时间上表现出类似指数衰减的曲线, 如随机路点模型[11]、随机路线模型、随机方向模型、社区模型[12], 以及在现实生活中用移动设备采集的真实路径模型[13,14]等。
假设网络中共生成了Mt个互不相同的消息, 在任一时刻t下, 节点做出判断, 有可能会将生存时间为Tt (i) 的消息i丢弃, 对于任一消息i∈[1, Mt], Dt (i) 表示从消息产生至时刻t止, 缓存过消息i的节点总数 (源节点除外) , nt (i) 为在时刻t下携带有消息i副本的节点数, 则整个网络在t时刻对全部消息的平均全局递交概率Wt由下式表示:
其中:
Lt为t时刻时网络中的节点总数由以上定义描述可知, 有nt (i) ≤Dt (i) +1。由于两节点间的相遇时间服从参数为λ的指数分布[15], 则消息i的一个副本投递失败的概率等价于此节点在下次相遇时碰到目标节点的时间大于消息剩余存活时间, 即exp (-λRt (i) ) 。
效用值uj (i) 可看作是消息副本的临界效用, 是基于消息参数而得的某一副本相对当前节点内全部缓存副本的一个评估值, 在节点缓存溢出时的最佳缓存管理策略应是替换缓存内效用值最小的副本, 即有:
1.2 队列管理与替换算法
1.2.1 入栈管理
本文MIPM算法的入栈管理中, 设节点缓存内已有n个不同的消息副本i1~in, 节点考察参数Ht (1) ~Ht (n) , 并将其按大小排序组成队列。当节点j收到大小为Si0的消息i0时, 首先判断缓存容量, 若BSj≥Si0, 则可将i0直接放入缓存队列;若BSj<Si0, 说明缓存溢出, 则读取其Ht (0) 并与缓存中其他消息副本的Ht (i) 进行比较, 若Ht (0) <Ht (i) , 则节点丢弃i0;否则将Ht (i) 值最大的一个副本移除, 然后重复上述比较过程, 直到满足BSj>Si0, 即可将i0放入缓存。
从一个消息产生开始, 每个消息及其副本都带有唯一的路由表, 用以记录此副本在网络中经过的节点。消息的路由表用一个一维数组RV表示, 记作RV=[R1, R2, R3, ..., Rn]。其中Ri (i=1, 2, ..., m) 表示此副本经过的第i个中继节点的ID。随着消息副本在网络中的复制和传递, 每到一个中继节点, 该节点即读取此副本的目的节点ID和其路由数组RV, 并将其加入自身维护的区域路由列表中, 此表大小为n×m, 不同节点的路由记录来自缓存过的副本携带的路由表。
1.2.2 出栈管理
当网络中的节点移动时, 它们相遇后可进行通信。假设某节点J碰到网络中另一节点K时, 两节点在可进行消息交换的条件下, 先获取对方的ID, 分别记作NA和NB, 然后在各自的路由列表中查询此ID。若ID存在, 说明对方曾作为网络中某条链路Ri的中继节点Riy递交过消息, 它遇见Ri内上下节点Riy+1和Riy-1的概率较其他随机节点大。再读取对方Ri的全部中继节点ID, 到缓存中匹配各消息副本的目的节点Dx, 若存在, 说明此副本到达其目的节点的链路在网络中曾经存在。同时, 依照节点活动的社会规律性, 同一链路中的各结点再次相遇的概率大于其他节点。因此可判断对方结点是潜在的高效递交中继, 即可把相应的消息副本发送给对方。若匹配失败, 说明对方节点是在本节点历史链路中首次出现, 则按消息副本缓存参数Uj (i) 高低将缓存内消息副本排序后, 发送Uj (i) 最高的副本给对方节点。
各节点相互传递消息副本之后, 副本的Rv都会自动将接收方节点的ID记录到向量末尾并更新一次路由列表。
2 仿真验证与分析
2.1 仿真环境设置
使用the ONE (Opportunistic Network Environment) 平台[16]作为网络仿真工具。路由协议使用传染病路由算法[17] (Epidemic Immunity) , 仿真区域为4500m×3400m的城市道路网, 移动模型使用随机路点模型RWP (Random Way Point) , 仿真时间为43200秒。各个节点在本地对缓存内的消息按优先级排序, 通信方式为蓝牙传输, 通信范围10m, 信道传输速率256KBit/s, 初始化消息生存时间为18000s。默认节点缓存大小为20M, 消息大小为500-1000k Byte, 产生间隔为25-35s。
2.2 MIPM策略性能分析
本小节在不同的条件下对提出的缓存管理算法进行了仿真实验。对比本文的MIPM策略和具有代表性的RO (Remove the Oldest) 策略:丢弃在网络中最长驻留时间的消息。本节主要以消息投递率, 网络消耗量和传输延迟的性能指标对算法进行评估, 仿真以上管理策略并对它们的网络性能进行比较。
当节点缓存大小从20M增加至50M时, 对比两种策略的网络投递率。网络中节点数固定为210个。从图1中可看出, 随着节点缓存空间的增加, 两种策略的投递率均有上升, 而在缓存空间5M时MIPM策略的递交率比RO策略高约154.5%, 缓存到50M时同比高约31.9%, 且在缓存大小超过25M后MIPM算法的递交率上升变化趋缓, 稳定在90%左右。
在同样的仿真设置中, 考察各策略的网络开销。如图2所示, 当节点缓存仅有5M时, 两种策略所得网络开销较接近, 且缓存在增加的过程中, RO的网络消耗下降明显, MIPM在节点缓存大于10M后即无明显下降趋势, 在200附近上下波动, 是因为算法本身的限制使得节点在碰到合适的中继节点后继续发送消息;RO策略在有足够大的缓存时会减少节点的丢包次数, 单个节点携带消息的平均时间更长, 因此其网耗相对较小, 在缓存50M时的网耗仅为MIPM的39.1%。
同样的, 在图3中当节点数量恒定为210个时, 不同算法的网络递交延迟有较大差别。当缓存为5M时MIPM的延迟约为RO策略的48.8%, 随着缓存的增加, 其递交延迟也增加。到缓存增为50M时MIPM平均延迟为RO的46.2%, RO上升58.5%, MIPM上升50%, 但在这个方面MIPM有比较明显的优势, 能以更少的时间递交信息。
在缓存固定为20M而节点数增加的条件下, 两种策略表现出较平稳的网络递交率, 从图4看出, MIPM的递交率在80%上下波动, 而RO策略的递交率在50%附近, 有下降趋势。节点数量的增加对两种算法的网络递交率并无太大影响, MIPM因在队列管理中加入消息参数信息的判断因而能让节点更有目的地投递, 使网络有较高的递交率。
同样地, 图5显示在缓存不变而节点数从100个增加到400个时, 两种策略的网络消耗也随之增大。当节点较少时, MIPM的网耗略大于RO算法, 在节点为350以上时, MIPM表现出轻微优势, 比RO的网耗低约7.5%。从图中可看出MIPM算法的网络开销在节点数变化时其稳定性不如RO算法。节点数从100个变化到400个的过程中, MIPM增加了246.2%, RO增加了1100%。
当节点数从100变为400时, 在恒定缓存20M的条件下, 对比算法的网络递交平均延迟。从图6中可知在节点数进阶增加的条件下, 两种策略的平均延迟均呈类似下降趋势。在节点数增加300%的过程中, MIPM策略的延迟下降60%, RO策略延迟下降30.8%, 而横向比较中MIPM在节点数为100时延迟为RO的60.6%, 在节点数为400时为RO的33.3%。
通过仿真实验, 本文提出的MIPM机会网络缓存管理算法相比传统策略有较高的成功投递率和较少的网络消耗和网络延迟。从整体上评价算法对网络的改善效率, 在考虑消息参数与其效用值的基础上做出缓存替换决策能比传统缓存管理策略提高网络递交率约15%至40%, 同时能达到较低的网络递交延迟。结论证明本文提出的MIPM缓存管理算法在实验条件下能有较优的网络性能。
3 结论
电脑的缓存简介 篇5
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处理器。
幕后英雄 隐藏在硬件背后的缓存 篇6
我们都知道，缓存是用于平衡高速设备和低速设备之间速度差异的纽带，也是一种用于存储临时文件的交换区，其最大意义就是“尽可能”帮助低速设备不拖高速设备的后退。之所以是“尽可能”，是因为缓存的容量通常都很小，而且数据在缓存中的命中率也是有限的。但无论如何，缓存都是提高整体性能中不可或缺的关键一环。
以CPU内集成的L2、L3等小容量高速缓存为例（图1），它们就是CPU与内存之间的纽带。在数据交换的过程中，由于CPU的运算速率远超内存，因此CPU在更多的时间中都是在等待数据到来，或是把数据写入内存。而缓存会提前预读CPU即将访问的数据，当CPU需要读取数据时会绕过内存直接从缓存中调用，从而提高读取效率。
HDD的缓存情结
继CPU缓存之后，HDD机械硬盘的缓存也是声名在外。限于物理结构的制约，就速度一项HDD和内存相比简直堪比“垃圾”，如果没有缓存用于作为硬盘和内存之间数据交换的纽带简直就是“作死”，因此如今的HDD大都会配备64MB容量的缓存芯片（图2）。
受SSD固态硬盘的步步紧逼，机械硬盘领域还逐渐衍生出了新的品类：SSHD（混合硬盘）。与HDD相比，SSHD内除了传统的硬盘控制芯片和缓存芯片以外，还会额外加入NAND闪存芯片（多为8GB）和SSD主控芯片（图3～4）。其实，我们可以将新加入的两颗芯片理解为SSHD的特殊缓存模块，它们会将用户频繁使用的各种应用、数据预存到NAND中缓存，这个缓存具备学习和记忆功能，它预存的数据不会因为关机而消失，从而给用户带来PC越用越快的感觉。
SSD和缓存的暧昧关系
SSD固态硬盘的速度远远超过HDD，为何此类高速存储设备内也会内置缓存芯片呢？ 如果将这颗芯片取消会不会影响性能呢？这个问题的答案源于SSD所采用的主控芯片与存储介质。
简单来说，由于SSD的工作机制与HDD不同，其特有的FTL机制让操作系统只能对LBA（逻辑地址）进行操作而不能干涉到PBA（物理地址）的操作。因此，SSD需要一个可以动态转换LBA与PBA层的对应关系的FTL表。SSD容量越大，FTL表也就越大。而SSD内置的DRAM外部缓存芯片就可以用于保存FTL表，从而节省系统访问FTL表的时间提高读写效率。
另一方面，像三星840这类采用TLC闪存的SSD（图5），它所内置的高达512MB的DRAM外部缓存芯片并非提升系统性能，而是起到了延长TLC闪存耐久度的功效。此外，通过主控的特殊算法，还能将缓存用于4K小文件，从而明显提高4K性能。
问题来了，既然都说SSD离不开缓存，那为什么以东芝旗下Q系列SSD为代表的固态硬盘产品，会取消看似重要的缓存芯片呢（图6）？原来，这个秘密就源于东芝Q系列SSD所选用的主控芯片。
SSD主控可弥补缓存作用
东芝Q系列SSD所用的主控芯片是基于Marvell主控的二次开发，和Marvell最新的88NV11X0系列主控有着血缘关系。88NV11X0系列包括88NV1120和88NV1140两款，它们最大的特色就是不再需要DRAM外部缓存芯片。
88NV11X0系列主控芯片内置了两颗Cortex-R5 CPU核心，并通过嵌入式的SRAM硬件加速来优化IOPS随机性能。换句话说，88NV11X0主控可以通过更为复杂的固件算法来模拟DRAM外部缓存的功能，从而可以帮助SSD节省出一个缓存芯片的空间。要知道，88NV11X0主控的封装尺寸只有8×8mm2，最少仅需两颗芯片就可做成一个SSD。也许对2.5英寸标准尺寸SSD来说不算什么，但对M.2（NGFF）接口的迷你SSD来说就意义非凡了，使大容量2230（22mm宽，30mm长）规格的M.2成为了可能。
就性能而言，东芝Q系列SSD与同价位带缓存的SSD相比也是不遑多让（图7），失去了缓存芯片的帮忙并没有出现想象中的性能和寿命衰减。在M.2成为新一代主板和笔记本的标准接口后，不需要缓存的SSD主控将有更为广泛的发展前景，相同容量但尺寸更小的SSD可以帮助PC们进一步瘦身。
缓存成集显“激素”
笔记本用户肯定都发现了一个有趣的现象，CPU集成显卡在配备双内存时的性能更好，内存频率越高，集显性能也就越强。实际上，对CPU集显而言，系统会将一部分内存空间虚拟成集显的“缓存”（也可称为显存），缓存规格越高（如双内存时就是双通道），性能自然也就越强了。
而英特尔旗下的Iris/Iris Pro（锐炬）系列核芯显卡之所以可以获得媲美GT640M级别独立显卡的性能，答案就源于在CPU上加入了一颗128MB容量的eDRAM嵌入式缓存（图8），代号“Crystalwell”。我们可以将Crystalwell视为内存体系中的“四级缓存”，任何从三级缓存中被赶出来的数据都会到这里边来，其双向带宽可达50GB/s，从而彻底解决了集成显卡面临内存带宽不足的问题。
小 结
缓存管理 篇7
关键词：信息中心网络,管理,内置,缓存技术
近年来随着我国科学技术水平的不断提高,通信模式进一步完善,使信息中心网络覆盖率进一步提高。为保障信息中心网络运行通常,内置缓存技术的应用至关重要。ICN作为新型内置缓存系统,透明度高,有效优化信息中心网络缓存体系。ICN的可续应用能够有效提升信息传输效率,优化资源配置,最大限度促进内置缓存技术优势发挥,完善信息中心网络管理系统。下面本文将针对ICN技术进行详细分析,旨在通过本文理论论述促进内置缓存技术进一步发展。
1 ICN内置缓存技术
ICN作为新型的内置缓存技术,是传统技术的创新与发展,整合Web、CDN缓存技术,实现信息中心网络的优化传输与管理。ICN作为新的内置缓存技术具有自身不可比拟的优势,其透明度高,并具有细粒度化以及缓存泛在化的特征。ICN具有明显的自身特点,具体可从以下几点进行详细分析:
1)透明度高
ICN与传统缓存系统对比来看其独特优势在于其透明度高。传统缓存技术在对流量统计时以封闭系统形式运行,Web以及CDN等均属于这种缓存技术。Web缓存技术主要是应用在开放的HTTP协议中,缓存系统内容以域自主命名为主,面对同一对象无法实现有效的识别。就ICN缓存技术来看,则明显区别于传统技术,具有创新性,能够对传统缓存技术进行改进和升级,能够对同一种对象命名一致,并实现透明化。ICN缓存技术凭借凸出的技术特性,作为信息中心管理中通用性较强的基础服务。
2)缓存泛在化
传统缓存技术的应用要对缓存点详细位置十分明确,其缓存网络以树状为主要结构形态,规律性强,为构建缓存之间协同就要首先对流量需求进行把握,并构建在数学模型基础上。ICN缓存技术的另一个特征在于其缓存泛在化,对缓存点位置的确定较广泛,具有多元变化特征,其网络化程度高。同时,ICN缓存系统之间缓存关系不明确,以数学模型进行分析不能确定准确的协同关系。缓存泛在化对缓存内容上的要求要高于传统缓存内容要求,ICN缓存系统的可用性较高,能够实现对缓存时间与缓存结点的分析,以提升系统综合运行动态性,保证在网络内置缓存环境中有效提升缓存利用效率。
3)缓存细粒度化
就传统缓存技术来看主要是通过文件进行信息沟通与存储,而ICN缓存系统则是通过线速形式进行网络运行,其成本相对传统缓存系统来看较高,对线速执行要求更高。ICN缓存技术能够对缓存对象有效划分,并将数据块作为缓存单位,直接对缓存粒度有着影响。以粒度为文件的缓存模型,一般是独立参考的模型,在对缓存对象的流行度进行研究时发现,其流行度与请求序列关系不大,但是针对同一文件,由于Chunk间有着较大的关联性,所以,用户在对Chunk进行请求时,需要以线性顺序作为开头。将缓存系统中的大文件划分为小Chunk后,增加了获取网络节点的途径,而且有利于提升缓存的效率。所以文件的大小与缓存的效率有较大关系。
2 ICN缓存主要内容
通过对ICN缓存技术的系统分析可总结出,ICN缓存系统主要包括两个方面内容,其一是网络系统性能的优化,其二是缓存网络的简化。其主要内容的构成可通过下图1所示。
首先,村缓存系统性能优化方法来看。ICN缓存技术能够促进缓存效果进一步提高,提升客户服务只来给你,以合理方式和改进对策增强ICN透明度。针对ICN缓存系统运行要合理增加其网络内置设施。对缓存系统带来影响的因素较多,为有效提高缓存系统性能,实现优化改进,就要充分了解各因素并对其中关系确定,为找到最优优化方案提供依据。同时,专业技术人员在进行ICN缓存系统性能优化过程中,要从多角度进行分析和考虑,包括缓存节点的大小、资源共享形式等等,只有从全面角度出发才能实现对系统性能的有效优化。另外,缓存对象可用性分析与缓存对象关注度分析也十分必要,以进一步促进缓存资源利用率的提高,保障缓存系统运行完整性。
其次,对缓存系统建模与分析。缓存系统本身具有一定的复杂性,为全面分析缓存系统网络体系,要通过构建理论建模体系的形式进一步进行深入分析,对缓存网络行为的具体性及可用性进行分析。缓存系统建模,要充分考虑到以下几个方面,如缓存对象流行度、缓存网络拓扑模型、管理策略、系统稳态性等,通过多角度分析才能提高缓存系统建模完整性。另外由于缓存对象处于不同缓存结点位置时会有不同的缓存请求,这与上述分析也有着直接关系,只有对这些关系之间的关联性进一步分析和把握,才能构建有效的数学模型,对缓存系统建模中存在的问题进行分析,通过各缓存结点关系判断分析出其各种关系。
3 ICN内置缓存系统性能的优化
ICN作为提高内置缓存系统性能基础,为进一步改进与优化其缓存性能,就要作出透明度分析,并从其泛在化、细粒度等角度对缓存系统更好完善。下面本文从几个方面具体论述对ICN内置缓存系统性能优化方法:
1)缓存大小规划设计
内置缓存空间大小之直接影响着系统性能变化,若缓存空间较大则可进行大数据对象存储,提高缓存系统命中率。但与此同时若缓存空间过大其成本也越高,为既扩大缓存大小又合理控制成本,就要进行合理的规划与设计。
首先,对缓存空间大小设计同时要保障系统性能有所提升,ICN缓存在运行过程中要满足线速执行标准,直接给缓存大小造成限制性影响。ICN系统进行信息传输与流量承载过程中,要对接点缓存空间进行设计,注重差异性区别,保证缓存系统配置有效优化。另外,也要根据信息访问量进行ICN功能差别划分,对存储器材质以及配置合理优化。其次,要注重在不同结点进行不同资源配置,目的在于提升系统整体性能。对缓存系统规划过程中要充分对缓存资源配置问题进行考虑,以及结合网络流量需求等等。同时需要注意的是网络拓扑中心作为缓存系统优化的重要渠道,并且ICN节点不确定性,这就要求缓存空间的合理规划与分配,最大限度提升缓存网络性能。
缓存大小的规划设计中还可以通过非核心节点数量的增加,以有效扩大缓存大小,提升缓存性能。对网络拓扑结构的考虑过程中除了要对中心性指标分析外,专业技术人员还要对缓存节点与用户距离之间的大小进行充分考虑。
2)缓存空间共享优化
ICN内置缓存系统具有较高的透明度,使得不同流量以及不同应用类型要对有限的缓存资源进行竞争应用。不同的应用与类型之间存在明显的差异,缓存目标不同,为真正实现不同类型与应用之间进行有限缓存资源的共享,就要优化差异性服务,以解决ICN缓存系统中的重要问题。
首先,是固定划分的共享。固定划分主要是针对不同应用与类型的固定的缓存空间大小的划分,为不同应用与流量类型提供仅有的资源服务,如何进行合理比例的划分是固定划分的重要问题。根据理论经验总结可知,可构建动态反馈机制,以适应划分比例的调整,实现不同类别应用命中率与预期一致。通过下图2可对动态反馈机制进一步把握。
其次,是动态共享。缓存空间的动态共享则在一类应用不占用缓存资源时允许另一类应用占用,实现了缓存空间的统计复用。动态共享策略用于指定不同类型的应用共享缓存的方式,常用的两种策略包括基于优先级的共享策略。
4 结束语
综上所述,内置缓存技术的应用对改善内置缓存质量,提升信息传输效率有着重要作用。就目前我国网络发展形势来看我国已步入信息化网络时代,依托信息技术促进数据的沟通与交流,对大数据与高信息量进行缓解与梳理,对优化整体网络,提高网络内置缓存透明化都有着积极作用。在今后的信息中心管理中要进一步促进内置缓存技术的应用,促进ICN广泛推广,顺势新时期网络信息的高速发展,既保证信息传输安全稳定,同时也保障数据流量传输的透明可靠。ICN作为新的内置缓存系统,要在今后的应用中进一步完善和创新,以实现现代缓存技术水平进一步提高。
参考文献
[1]王永功,李振宇,武庆华,等.信息中心网络内缓存替换算法性能分析与优化[J].计算机研究与发展,2015(9):2046-2055.
[2]吴超,张尧学,周悦芝,等.信息中心网络发展研究综述[J].计算机学报,2015(3):455-471.
[3]曹健,王兴伟,张金宏,等.数据驱动的信息中心网络认知路由协议[J].计算机研究与发展,2015(4):798-805.
[4]冯宗明,李俊,吴海博,等.基于选择存储的CCN网络缓存发现方法[J].科研信息化技术与应用,2015(2):28-36.
[5]Zhang L,Estrin D,Burke J,et al.Named data network-ing(NDN)project.2010.http://www.named-data.net/techre-port/TR001ndn-proj.pdf
[6]李丹,陈贵海,任丰原,等.数据中心网络的研究进展与趋势[J].计算机学报,2014(2):259-274.
缓存管理 篇8
随着互联网资源和用户的快速增长,给现有的C/S模式带来了巨大的压力。面对大规模用户和大量多媒体数据传输时,服务器瓶颈问题限制了用户需求的发展。为此,研究人员提出了很多解决方案:IP组播在网络层解决一对多的通信问题,是节省网络带宽的有效方法,但由于网络层处理负荷增大,拥塞控制实现复杂等原因难以推广;服务器集群和CDN网络能保证服务质量,但服务器的购置和部署要付出高昂的成本,并且缺乏可扩展性。对等网络(P2P)把原来服务器的负荷向网络边缘转移,使单个能力有限而总数巨大的节点群体通过协作产生强大的聚合服务能力.达到资源的充分利用,从而解决了服务器瓶颈问题。
近年来.基于P2P的流媒体分发技术成为研究热点。国内外相继出现了各种类型的流媒体视频直播和点播系统。基于P2P流媒体的VoD技术与直播相比,能够发布更多数目的文件.可以为用户提供异步服务(VCR操作),因此引起了更广泛的关注。
有人提出了一种基于媒体文件分块的缓存机制,系统组织成树形拓扑结构对全局缓存信息进行控制。这种架构的缺点是需要较高的维护成本和可靠性较低。也有人提出了一种基于分段的缓存机制,增加了热门节目的播放质量,但是对较冷门的节目没有起到作用。有人提出了一种中心化的缓存管理机制,它的缺点是较低的可测量性。还有人提出了PROP的缓存管理机制,即基于树-网混合P2P结构的缓存管理机制。这种机制的提出主要是为了解决可测量性和可靠性的问题。在这种架构下,每个节点在获得一部分媒体分块时需要广播这部分分块的信息,节点丢弃数据分块时也需要向索引机节点发送删除消息。因此这种架构的缺点是增加了整个P2P网络的负荷。
为了合适的进行缓存内容的分配和提高特定媒体分块的搜索效率,在本文中提出了一种基于分布式缓存管理的P2P VoD系统架构(DCM P2P),这种架构的主要思想是:首先把整个媒体文件分成大小统一的媒体分块,当节点加入系统中时,根据加入系统的顺序每个节点固定缓存一定的媒体分块:缓存的媒体分块可以组成一个完整媒体文件的节点组成一个环。因此,在这个环内可以快速的找到这个媒体文件中某特定的媒体分块。
二、分布式缓存管理架构
整个系统架构由一个中心内容服务器(Server)和多个节点(Peer)组成。服务器用来进行版权保护和对播放质量进行控制.中心内容服务器中存储由内容提供商提供的完整的流媒体文件,当用户发出请求时为用户进行流媒体数据的传输。每个节点接收到媒体数据后进行播放并采用本文提出的算法把数据缓存于内存和磁盘中,用来为其他节点提供服务。在DCM P2P中,观看同一节目的多个节点组成不同的Chord环。下面主要介绍系统的架构和一些主要概念。
1. DCM P2P系统架构
DCM P2P的基础是节目组(即观看同一节目的所有节点)。DCM P2P的拓扑结构如图1所示。
整个覆盖网的拓扑结构有一系列环组成,每个环的大小等于媒体文件的数据分块的数目,例如一个媒体文件分成M个数据块,每个环则包括M的节点。每个节点根据其加入系统的时间存储相应的数据块(1～M).每个环中所有节点存储的数据块组合成一个完整的媒体文件。因此,在一个环中节点在进行VCR操作时可以很快的查找到它所需要的数据块。DCM P2P在每个存储有相同数据块的节点之间建立邻居关系,通过引入上、下邻居的概念每个节点可以找到过个存储了相同数据块的节点。
2. 命名机制
P={pi|1≤i≤k}来标识所有的节目名称。定义HASH功能H(pi)对pi到bi进行映射。
(1)节点标识符。如图2所示,节点n的标识符为Nodeld(n)=(bi,di,qi)。其中di标识n所在的环的级别。qi表示n所存储的媒体分块的编号。di和qi都可以叫做n的次标识符。
(2)资源标识符。如图3所示,Key=(bi,qi)定义为资源标识符。其中qi的含义同上,可以称为资源的次标识符。
3. 路由信息
因为DCM P2P和Chord的设计有所不同,所以它们每个节点的路由表Routing Table(RT)也不同。假设在DCM P2P中一个媒体文件分成M=2m个媒体分块,节点的数量为N.下面来描述一下路由表的一些相关概念。
(1)当前环的级别(Current-Ring-Level):节点N现在所在的环的级别。环的级别从底部开始向上增加.即最底部的环的级别为0。
(2)前向节点:在同一环中按逆时针方向旋转,节点N的下一个节点称为N的前向节点。
(3)后继节点:在同一环中按顺时针方向旋转,节点N的下一个节点称为N的后继节点。
(4)下层节点:如果N的RL≥1,则位于RL-1的环中与N存储有相同媒体块的节点称为N的下层节点。
(5)上层节点:位于RL+1的环中与N存储有相同媒体块的节点。
(6)邻居表(Neighbor Table):NT由节点N的前向节点、后继节点、下层节点和上层节点组成。
(7) RT(K).start:路由表中第k栏的第一个节点。假设节点的数量N=n×2m+p (0≤p≤M,n=0,1,2,L),可以得出:
(8)下一跳环间隔(Next hop Ring Interval):路由表中第k栏包含的环状间隔,即
以图1中的节点P1为例,P1所在的环RL=1,P1的前向节点为P4,后继节点为P5,下层节点为P2,上层节点为P3。
4. 节点加入和退出算法
节点M加入算法流程如下:
(1) M首先向服务器发出请求,请求加入某个节目组。服务器向节点发送一个包含下列信息的reply报文:M的编号、前向节点和下层节点。
(2) M接收到reply报文后建立自己的前向节点和下层节点。如果M的CRL为0,则M的下层节点是服务器。
(3)假设M的前向节点为P,下层节点为D。M向P和D发送请求加入系统报文,P和D接收到请求加入报文后分别更新自己的后继节点和上层节点.即P的后继节点和D的上层节点由M代替。
(4) M初始化它的路由表,P帮助M查找它的路由表信息。
(5) M从节点D获得它所需要存储的媒体分块。
(6)系统开始进行路由更新.更新每个节点的路由表(在下面将进行详细介绍)。
节点Q正常退出算法如下:
(1) Q向它的上层节点U发送“退出”消息,该消息包含Q的RT和NT。
(2) U在上层环中进行查找与Q存储有相同媒体分块的节点U',如果没有与Q存储内容相同的节点则把编号最大的节点选为U'。
(3) U'从U获得Q的RT和NT来代替Q。
(4) DCM P2P系统开始进行路由更新来更新每个节点的路由表。
如果一个节点是非正常离开的.它不会发送“退出”报文.只能通过其他节点来被动的发现它。因此我们要通过一定的容错机制来发现非正常退出系统的那个节点。因而,每个节点要周期性的向它的下层节点发送KeepAlive报文。若在T时间内(如10s)没有收到某个节点的回复信息,则认为该节点已经失效。相关节点在发现该节点失效后执行上面的步骤2,3和4。
5.资源搜索算法
资源请求的处理过程如下:
(1)当节点A请求一个媒体分块或接收到一个需要转发的请求报文时,首先A检查这一报文是否来自上层环。如果是.A把该报文转发给它的下层节点。如果不是,执行步骤2。
(2)节点接收到路由消息后检查其中包含的资源次标志符(既qi.所请求的媒体分块)。节点对key和它的NT中的节点次标识符进行对比,如果key∈NT,它向请求节点发送Response报文。如果keyNT,执行步骤3。
(3) A在RT中查找节点的次标识符中qi最接近key的节点B。A把报文转发给节点B。B重复A的过程.如果在当前环中查找失败,则在下层环中继续执行查找过程。
(4)如果最后请求报文被转发到了第0环,在此环中仍然没有找到包含key的节点,则服务器将为请求节点分发所请求的媒体分块。
6. 路由维护机制
由于视频点播系统中节点加入退出比较频繁.DCM P2P路由更新是基于事件的。即当节点加入、正常退出后通过KeepAlive报文发送节点失效后都会触发路由更新机制。
当一个新节点N加入系统时,N发现并更新它的RT中的所有相关节点。如果N'的下一跳节点为N,则N向N’发送通知报文,该报文包含N的所有信息。
当节点Q离开系统时,Q或Q的后继节点(当Q非正常退出时)初始化路由更新。当更新相应节点的路由表时,如果此节点A的下一跳节点B的标识符等于Q,则从A的RT中移除节点B。
三、性能仿真
在进行仿真分析之前,首先引入下面的几个参数:N为系统中节点的个数,M为一个媒体文件分成的媒体分块的数量,为消息在节点之间的平均往返时间,为DCM P2P系统中平均消息传送时延,为在Chord中平均消息传送时延。
因为本系统采用的资源搜索算法和Chord算法相似,所以在本文中我们主要对和进行对比。
1.理论分析
(1)时间消耗。在DCM P2P中提出多级环的目的是为了提高路由效率并降低时间消耗。在DCM P2P中只有部分节点参与路由选择,而Chord中所有的节点都参与其中。使用AMTD来代表在环中进行资源定位所用时间,则:
在实际环境中,路由效率由一些不确定因素决定,例如统一的请求分发。下面我们使用α来表示这些不确定因素。
在DCM P2P系统中,有N个节点,媒体文件被分成M个媒体分块。通过上面对DCM P2P的描述可以得出:
一般来说N>M,假设N=Mβ.通过上面两公式可以推导出下面的公式:
假设M=256.N=256×256,则β=2。通过上面的分析可以得出,DCM P2P系统中节点的个数N和节目热度(受欢迎程度)对数据分块的查找性能没有影响。M是决定AMTD的主要参数。系统中节点的个数越多,节目越热,采用DCM P2P越合适。
(2)维护成本。在DCM P2P中.路由更新在由M个节点组成的环中进行。Chord则是在N个节点组成的环中进行。则Chord进行路由信息维护的成本高于DCM P2P。但是DCM P2P需要维护上层和下层的邻居关系,要增加一定的维护成本.但是增加的维护成本因为较低可以忽略不计。
2.仿真分析
采用NS2网络仿真器对所设计的系统结构进行仿真分析。评估系统性能的指标主要包括启动延迟和平均消息传送时延(AMTD)。
仿真参数设置如下:节点和路由器之间的延迟是1～10ms,路由器之间的平均延迟是20ms。
当M为变量时,分析M对AMTD的影响。由表1可以看出AMTD由M决定,与系统的节点数目N无关。当M越小即数据分块越大时,系统的AMTD越小。
在VoD系统中,如果每个节点加入系统时开销比较低,则可以减小整个系统的负荷.同时提高用户的观看体验。DCM P2P中节点的加入算法和Chord相似,因此平均消息数量为O(log2N)。由表2可以看出DCM P2P减少了节点的启动延迟,但是没有增加系统的负荷。
四、结束语
针对P2P VoD系统中怎样有效的管理和使用用户的存储能力的问题,吸取Chord算法的优点提出了一种分布式缓存管理架构DCM P2P。DCM P2P通过把Chord中的包含所有节点的大环分成由一部分节点组成的多级环,提高了系统的性能。通过理论分析和仿真实验证明,这种分布式缓存管理架构提高了用户的观看质量并可以有效地支持VCR操作。
参考文献见www.dcw.org.cn
参考文献
基于缓存框架的Web缓存研究 篇9
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.
缓存管理 篇10
之后, 直写缓存的算法成为了解决容量问题的一个方法。用闪存卡存储热点数据并且所有设备共享存储也就成为了一种标准做法。我们称其为基于服务器的缓存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上的负荷将大大降低, 现有系统的使用寿命将得到大大延长, 并且数据中心可以用成本更低、容量更高的硬盘来进行配置。
清除iOS微信中的缓存文件 篇11
如果用户使用苹果设备，需要连接电脑后运行iTools，点击左侧列表中的苹果设备名称，在弹出的项目中选择“文件系统”这项。接着在中间的列表中选择“常用程序”，在展开的子项目中找到“微信”并展开。首先选择进入“Documents”文档目录，在右侧窗口里面可以看到很多缓存文件。通过鼠标选择这些缓存文件，点击工具栏中的“删除”按钮就可以进行清除操作。
除了软件自身产生的缓存信息以外，在聊天的过程中也会产生缓存信息，比如对讲产生的语音缓存、发送照片产生的图片缓存以及视频缓存等。接下来访问“Documents”文件夹中的“4771e841f1f2cc7de2cf477f61651d05”子目录，就可以看到这些聊天内容的缓存信息，通过“删除”按钮删除其中的缓存信息即可。
如果用户使用的是Android设备，那么可以直接使用文件管理器进入到手机的SD卡里面，再进入到微信应用所在的“Tencent”中的“MicroMsg”子文件夹，就可以看到一个字符串很长的文件夹。这其中就包括各种缓存文件的子目录，逐一进入这些目录下将其全部删除即可。
缓存模块设计浅谈 篇12
下面我们以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]王亚平.《数据库系统工程师教程》.清华大学出版社.