缓存系统范文（精选12篇）
缓存系统 第1篇
随着互联网业务的快速发展,网页访问流量的增长十分迅速,但用户访问Internet的数据中,有很大一部分是重复的,包括访问同样的页面、下载相同的软件或观看同一个流媒体影片。通过使用HTTP缓存技术[1],可以在缓存设备中缓存用户访问过的对象,这样对相同对象的访问就无需再占用服务器处理能力或者主干的出口带宽。
同时,由于互联互通带宽等因素的限制,用户进行网外页面浏览、在线视频、软件下载等HTTP访问时会导致时延较大、体验不高,通过部署缓存系统,使用户的请求可以由本地的Cache设备立即响应,因此可以极大的提高用户访问的响应速度,减少互联网时延对用户的影响。这样也就减少了不同运营商之间的网间结算费用,使其在宽带互联网市场的竞争中占得先机。
2 HTTP缓存系统基本原理特点
2.1 HTTP缓存系统及其发展
HTTP缓存系统的基本思想是将客户访问过的Web内容在Cache设备中存放一个副本,当该内容下次被访问时,不必连接到外部网站,而是由Cache设备中保留的副本提供[2]。Web内容可以缓存在客户端、代理服务器以及服务器端。缓存技术可以显著地提高WWW性能,它可以带来以下好处:
(1)减少网络流量,从而减轻网络拥塞;
(2)降低客户访问延迟,其主要原因有:缓存在代理服务器中的内容,客户可以直接从代理获取而不是从远程服务器获取,从而减小了传输延迟;没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取;
(3)由于客户的部分请求内容可以从代理处获取,从而减轻了远程服务器负载;
(4)如果由于远程服务器故障或网络故障造成远程服务器无法响应客户请求,客户可以从代理中获取缓存的内容副本,使得WWW服务的可用性得到了加强。
另一方面,HTTP缓存系统也可能会带来以下不足:
(1)客户获取的可能是过时的内容;
(2)如果发生缓存失效,客户的访问延迟由于额外的处理开销而增加。因此在设计Web缓存系统时,应力求做到Cache命中率最大化和失效代价最小化。
HTTP缓存早期产品的设计只是为了节省带宽,但对于减少延迟作用极小;它们简单地缓存Web对象并在特定时间端内将这些相同的对象传递给用户,如果源服务器的内容发生变化,缓存无法智能化地保持其变化。
为了消除这种延迟,HTTP缓存系统必须包含针对延迟的算法,以保持缓存内容的更新[3];对于Cache设备在将内容从其存储传递给用户时,需保障所传递的内容在有效期内是最新的。现在的HTTP缓存系统一般由负载均衡设备及缓存处理服务器组成,并通过一定的机制实时更新内容。负载均衡设备通过一定的策略将需要处理的Web访问需求均衡地分配到缓存处理服务器,缓存处理服务器主要负责保存某些特定的Web内容以提供给网内用户。
2.2 HTTP缓存系统的行业标准
HTTP缓存系统应符合以下标准:
(1)快捷性:缓存系统应该能够有效地降低客户的访问延迟。
(2)可扩展性:缓存系统应能够随着网络规模和密度的不断增长而很好地进行扩展。
(3)高效性:缓存系统应能保证命中率,节省广域网带宽越多越好。
(4)负载均衡:一个理想的缓存方案应能够将负载均匀地分发到整个缓存系统,以避免某一个缓存服务器成为瓶颈,而造成系统一部分甚至整个系统性能下降。
(5)稳定性:缓存系统采用的方案不应给网络带来不稳定;当整个缓存系统发生故障时,用户能切换至正常上网过程,以达到故障保护的目的。
2.3 HTTP缓存系统的部署方式
(1)分布式部署:分布式缓存技术和系统,即在不同的物理区域各部署一套缓存系统,各区域用户的访问都通过本地的缓存系统进行,并通过当地的互联网出口获取外网对象。在分布式缓存结构中,大多数的网络流量都发生在网络底层,有较短的传输时间、不容易产生网络拥塞,且可以更好地实现负载共享,容错性更好。然而,一个大规模的分布式缓存系统的配置可能会遇到的一个问题:管理困难、同一个内容的多个副本被保存在不同的缓存系统中,整个系统空间利用率不高。
(2)集中式部署:集中式缓存技术和系统,即将不同的物理区域用户的访问统一集中在整个网络系统的互联网总出口附近的一套缓存系统中进行。在集中式缓存结构中,大多数的网络流量都要走到总出口,因为请求次数多,缓存命中率更高,节省大量的广域网带宽,并提高缓存空间利用率。缺点是有相对较长的传输延时、容易产生网络拥塞,过多的请求数可能会成为瓶颈并带来较长的排队延迟、造成单个故障点、而且带宽要求高。
3运营商HTTP缓存系统部署探讨
3.1必要性及可行性分析
目前国内互联网服务市场的竞争已经进入了白热化阶段,面对市场竞争日渐激烈的现状,国内电信运营商都在加大宽带互联网的建设,挖掘企业潜在赢利的机会,来满足用户日益增长、丰富、多元化的需要;另一方面,由于互联互通等问题的影响,用户进行网外页面浏览、在线视频等Web访问时会导致时延较大、体验不高。为解决这一突出矛盾,运营商有必要通过HTTP缓存系统的部署,大大提升网内用户的使用感受,保持核心竞争力。
从当前情况来看,Web Cache技术可以提高用户Web访问的响应速度,减少互联网延时对用户的影响,减少对相同对象的访问所占用的主干出口带宽[4]。HTTP缓存技术业界发展已经成熟,其设备已经得到支持和接受。
3.2部署方式探讨
在运营商的网络中,HTTP缓存系统可采用集中式或分布式进行部署,部署拓扑如图1。
(1)在分布式部署中,对应于运营商网络,可在每个地市的城域网出口部署一套HTTP缓存系统,通过相应的路由策略配置把Web流量导向到HTTP缓存系统中。此方案优缺点如下:
方案优点:有较短的传输时间、不容易产生网络拥塞,流量压力分散到各个地市城域网,且可以更好地实现负载共享,容错性更好。
方案缺点:管理困难、同一个内容的多个副本被保存在不同的Cache中,整个系统Cache空间利用率不高;且设备数量和投资比较大。
(2)在集中式部署中,对应于运营商网络,可在省平面集中部署一套HTTP缓存系统,通过一定的引流策略将各地市需求的Web流量导向到集中的缓存系统进行处理。此方案优缺点如下:
方案优点:便于配置与管理、项目实施和统一监控;缓存命中率更高,节省大量的广域网带宽,并提高缓存空间利用率;需要设备数量与投资比分布式部署少。
方案缺点:有相对较长的传输延时、容易产生网络拥塞。
运营商可根据自身网络的实际情况,选择合适的部署方式,一般情况下,部署初期推荐采用集中式部署方案,有利于管理及维护,提高HTTP缓存系统的使用率;后期可根据需求容量等实际情况进行混合式部署(集中+分布),采用中心+地方两级部署架构,对业务需求大的地区采用分布式部署,中心地区的缓存系统供其余地区使用。
3.3业务流程及故障保护
缓存系统部署如图2。
两台缓存系统路由器/交换机作为整个组网的核心设备,可与IP城域网通过口字型或双上联进行组网。
缓存系统路由器/交换机与城域网核心路由器可建立ISIS邻居,收全网ISIS路由;与城域网RR路由器建立IBGP邻居,收城域网路由。
缓存系统路由器/交换机loopback地址打上MPLS标签通过bgp协议公告至全网。城域网通过RR及蜜罐设备等控制相关网段及业务,将需要缓存请求的流量下一跳直接指向缓存系统路由器/交换机设备loopback地址。流量经过缓存系统路由器/交换机设备上联端口进入时,通过匹配上联端口所做的PBR策略,将所有目标端口为80的HTTP流量下一跳直接指向与负载均衡器互联的端口,将请求流量导至负载均衡设备,负载均衡设备再通过相关算法,将请求分配至不同的缓存设备当中。
负载均衡器分别通过双上联旁挂在两台缓存系统路由器/交换机上,负载均衡设备通过负载均衡算法把HTTP流量导向到缓存系统服务器中。
HTTP请求流量通过缓存系统路由器/交换机的PBR策略路由分担至两台负载均衡设备,并且对PBR下一跳主备起备份的作用。两台负载均衡器通过心跳线保持会话同步,以保证HTTP请求为相同目的时,两台负载均衡器能将请求分配至同一台缓存服务器设备,提高缓存设备的命中率。
当HTTP访问请求到达缓存系统中:
(1)HTTP请求内容没有缓存:HTTP流量到达缓存系统中,当HTTP请求的内容在缓存系统中没有缓存,则缓存系统用本设备所分配的IP继续把HTTP请求发送到请求的服务器中,Internet源服务器把HTTP请求回复到缓存系统中,缓存系统把HTTP请求内容沿HTTP请求路径回复到用户端。回程流量不经过负载均衡设备直接从缓存系统路由器/交换机通过城域网核心返回城域网当中。
(2)HTTP请求内容有缓存:当HTTP流量到达缓存系统中,HTTP请求的内容已经存在缓存系统中,则缓存系统把缓存的内容回复给用户,沿HTTP请求路径回复给用户。回程流量不经过负载均衡设备直接从缓存系统路由器/交换机通过城域网核心返回城域网当中。
当部分缓存处理单元服务发生中断或响应时间较长时,负载均衡设备能自动将负载切换到其他工作正常、空闲处理能力较多的缓存处理单元上,保证业务的正常工作状态;当整个缓存系统发生故障时,用户能切换至正常上网过程,以达到故障保护的目的。
4结论
办公自动化系统中缓存技术的使用 第2篇
办公自动化系统中缓存技术的使用
作者：王姝
来源：《数字技术与应用》2012年第12期
摘要：由于办公自动化系统的应用人数较多，对数据的检索也比较频繁，因此，这就要求系统要有一个强大的缓存功能。ASP.NET 2.0新增以SqlCacheDependency类为核心的SQL数据缓存依赖功能。这项技术的使用可以保证数据的查询速度及数据查询的准确性。关键词：缓存技术办公自动化 ASP.NET 2.0
中图分类号：TP311 文献标识码：A 文章编号：1007-9416（2012）12-0064-011、ASP.NET 2.0缓存机制
办公自动化系统是由Web应用程序来实现的。整个系统中的数据全部存放在SQL数据库中，那么，当很多人在同时进行数据的查询时，要想提高数据查询的速度及准确性，就要改善Web应用程序的性能。可以为办公自动化系统增加缓存功能来实现。从数据库中进行数据的检索查询，是用户使用最多的操作，但是，Web应用程序的执行包括很多道程序，要先通过Web服务器，还要再通过数据库的服务器来执行，因此，其执行速度可想而知，成为了限制系统使用的一个瓶颈问题。这个问题在用户数量较多是，显得尤为严重与突出。
针对这个问题，可以转换一下思维方式。那就是将数据库中的数据先缓存于内存中，或者是相当于内存的其他存储器上，无论用户访问哪一个页面，都可以随心的访问数据库，这种提前将数据库的数据存于缓存中的办法，与用户在访问数据时将数据调入内存这种传统方式相比，很明显，前一种节省了更多用户的等待时间。这样就提高了系统数据有关功能的执行速度。
缓存系统 第3篇
【关键词】分布式 多级缓存技术 选课系统
【中图分类号】 G 【文献标识码】A
【文章编号】0450-9889（2014）02C-0183-03
一、高校选课系统现状分析
高校选课系统大部分都采用B/S三层结构，浏览器、Web应用服务器和数据库服务器，同时为了保证数据的一致性和完整性，数据库服务器一般只有一个，而应用服务器可以设置多个，逻辑结构描述如图1所示。当多个Web应用服务器在大量用户并发提出的请求时，因为操作数据库是串行执行，那么势必导致用户请求很久都得不到回应，延迟时间比较长，甚至出现浏览器页面超时等现象。
图1 高校教务系统的典型逻辑架构
针对选课系统现有的状况，必须进行相应的改进，以提高Web应用服务器的服务质量。缓存技术是其中比较热点的解决办法，它可以缓存数据库中的数据对象，也可以缓存中间处理对象和结果对象。搭建一个缓存服务器显然作用不大，在本文中将采用分布式缓存服务器集群的方式，也就是采用Web应用服务器分布式缓存技术，这样可以极大改善现有服务器所面临的高负载问题，提高Web应用服务器的吞吐量，降低响应时间，解决数据库的伸缩性等问题。
二、选课系统缓存对象分析与设计
在设置缓存之前，首先要弄清楚选课的整个流程，里面所涉及的对象，分析出其中的数据对象、过程对象和结果对象，之后考虑如何对这些对象进行缓存。
（一）选课系统流程分析。在学生进行抢选课的时候，首先进入课程页面找到自己喜欢的课程，如果该课程没有达到限定的选课人数，那么学生选择该课程成功，否则只能选择其他课程；然后当选择的课程通过后，便会进入该课程对应的教师页面，学生抢选自己喜欢的任课教师，如果该任课教师没有达到限定人数，那么该学生选教师成功，也就意味着该课程整体抢选成功，否则该学生只能再选择其他教师。在选课过程中或选课结束后，学生可以随时通过结果页面查看自己选课的总体情况，以便作出调整。通过以上分析，可以得到如图2选课系统流程图。
图2 选课子系统流程图
（二）缓存对象分析。经过分析，在高校选课系统中可以进行缓存的对象包括以下对象：课程信息对象，可以是数据对象，也可以是课程信息所形成的页面对象；课程人数限制信息，这个属于数据对象；课程已选人数信息，这个属于数据对象；教师信息对象，这个可以是数据对象，也可以是教师信息所形成的页面对象；教师人数限制信息，这个属于数据对象；教师已选人数信息，这个属于数据对象；选课结果信息，可以是数据对象，也可以是结果形成的页面对象。因此得出结论，这些信息都可以以数据对象的形式存储。
（三）缓存对象分类。选课系统可缓存的数据对象各有其特点，因此这些数据对象不能全部以统一的方式进行缓存，按照这些数据对象的特点，把这些数据对象分为参考数据对象、活动数据对象和资源数据对象。参考数据对象是指主要用于读取的数据对象，虽然这些数据对象很少有写入操作，却因为读取数据对象的用户数量较大，数据对象检索和列表也会产生巨大的数据对象条目。活动数据对象是指进行读取和写入的数据，这些数据对象是可以调整变化的，而且存在是短暂的。资源数据指的是同时进行读写的数据对象。
按照以上分析，选课系统中的参考数据对象包括课程数据对象、课程人数限制数据对象、教师数据对象和教师人数限制数据对象；活动数据对象包括选课结果数据对象、课程已选人数数据对象和教师已选人数数据对象。
（四）缓存逻辑模型设计。根据选课子系统可缓存对象的分析结果，分为三种不同的数据对象，那么在缓存这些数据对象的时候，需要在内存中建立对应独立的存储结构单元，称之为命名缓存。这些命名缓存之间完全互相隔离，互不干扰，当有多个应用程序共享同一个缓存集群时，可以为每个应用程序分别建立命名缓存。在同一个命名缓存中，对同类型的数据对象，但是内容不通的，需要对命名缓存进行分区，这样即可以解决数据冲突的问题，极大地提高检索效率。这样就得出一种新的缓存服务中数据对象新的逻辑模型，如图3所示。
图3 缓存逻辑模型设计
在本文的选课系统中，将参考数据对象类型命名为MyBasicData，并根据内容不同进行分区，分为课程数据对象分区、课程限制人数数据对象分区、教师数据对象分区和教师人数限制数据对象分区等；活动数据对象类型命名为MyActiveData，划分为选课结果数据对象分区、课程已选人数分区和教师已选人数分区等；资源数据对象类型命名为MySourceData。
三、构建基于JBoss Cache3.0分布式多级缓存
（一）分布式多级缓存逻辑架构设计。根据选课系统的特点，这些可被缓存对象基本上都是数据对象，因此可以在构建分布式缓存的时候，把缓存加到数据库服务器和Web应用服务器之间，用缓存服务器缓存数据库服务器中的数据对象，这样可以有效解决数据库服务器的伸缩性问题，极大缓解数据库服务器的压力。图4展示的便是构建的Web应用服务器分布式缓存架构，主要分为数据层、缓存层、应用服务层和用户层。
当用户访问应用服务内容的时候，Web应用服务器的应用程序查看数据对象是否可以在其对应的缓存服务器中获取，如果该数据对象在该缓存服务器中不存在，则查看分布式缓存其他结点缓存服务器中是否存在，直到找到所需的数据对象为止。如果整个分布式缓存中都不存在，便去操作数据库，获取到所需的数据对象，并尝试将该对象加载到分布式缓存中。
除建立服务器端缓存外，还需要建立应用服务层和本地缓存，以加快用户检索数据。同时保障应用服务层和本地缓存要与服务端对象具有一致性，对象从数据库服务器检索到分布式缓存，缓存再把对象存储到应用服务层和客户端，这样便形成了Web应用服务器分布式多级缓存。当用户发出请求时，服务首先查看本地缓存中是否存在相应对象，如果没有，则到服务端即缓存层查找，如果有则返回对象并同时更新应用服务层和客户端缓存。没有则到数据库查找到数据对象缓存到服务端并同时缓存到应用服务层和客户端。
图4 分布式缓存架构
（二）构建基于JBoss Cache3.0的Web应用服务器分布式多级缓存解决方案。JBoss Cache3.0是一个复制的事务处理缓存，它允缓存企业级应用数据来更好的改善应用服务器的性能。缓存服务器结点构成树形逻辑结构，节点间利用JGroup进行多播通信，节点间缓存数据将被自动复制，形成分布是缓存集群。因此利用JBoss Cache3.0在Web应用服务器和数据数据库之间建立分布式缓存，形成缓存层（如图5所示）以分解数据库服务器的压力是一个可行的解决方案。
图5 基于JBoss Cache3.0分布式缓存配置
1.替换策略设计。JBoss Cache3.0的缓存参数配置。配置是基于XML文档的，其中有两个关键参数是必须进行配置的。WakeUpIntervalSeconds参数定义替换线程多少时间运行一次，PolicyClass参数定义所采用哪种替换策略，如果不进行配置，将采用基于LRU算法的替换策略，也可以替换成其他替换策略。
命名缓存和缓存分区。在建立JBoss Cache3.0分布式缓存的时候，按照2节中的对象类型分析，需要命名多个不同的缓存和分区，分别缓存不同类型的数据，即命名MyBasicData用来存储参考数据，命名MyActiveData用来存储活动数据和命名MySourceData用来存储资源数据等。
2.构建分布式多级缓存。JBoss Cache3.0支持多级缓存，即支持服务层缓存和本地缓存。本地缓存不参与集群，并且也不与集群中其他缓存通信，通过串行化，用户在任意时间修改缓存模式。服务层缓存采用树形结构形成集群，集群节点之间利用JGroup建立可靠的组播通信，缓存更新采用同步或异步模式进行复制。在本案例中，建立一个名为TreeCache.xml的配置文件，在里面设置集群名称、设置缓存复制模式和JGroup通信配置等，然后部署到JBoss应用服务器中。
在基于JBoss Cache3.0分布式缓存中，缓存当用户发出请求时，服务首先查看本地和应用服务缓存中是否存在相应数据，如果没有，则到JBoss Cache3.0服务端即缓存层查找，如果有则返回数据并同时更新应用服务器和客户端缓存。没有则到数据库查找到数据缓存到JBoss Cache3.0服务端并同时更新应用服务器和客户端缓存。
在以上集成架构中，通过利用部署在中间层的JBoss Cache3.0，应用服务的可伸缩性、性能水平和可用性都得到了相当大的提高，更具体地说，提高了服务架构的可扩展性，实现了尽可能减少对数据库资源的争夺，注入更多的灵活性。可扩展性的架构可以根据不同服务节点的资源使用情况，进行动态调节用户到不同的服务节点，从而提高响应时间，降低了延迟。通过JBoss Cache3.0高可用性的集群，可以在某个节点发生故障的时候，降低数据损失。
四、分布式缓存技术在选课系统中的应用实践
广西农业职业技术学院选课系统应用服务器为JBossAS 5.0，在实际应用之前利用LoadRunner8.1针对建立JBoss Cache3.0分布式多级缓存前后进行压力测试。首先利用LoadRunner的VuGen分别录制在建立缓存之前与建立缓存之后两种环境下网上选课系统的脚本，然后利用Controller模拟50虚拟用户、100虚拟用户、150虚拟用户和200虚拟用户、250用户对该系统的访问，然后生成结果分析比较，发现配置缓存后，服务的吞吐量（如图6所示）和点击率（如图7所示）都得到很大提高。
图6 有无缓存吞吐量比较图
图7 有无缓存点击率比较图
通过验证之后，基于JBoss Cache3.0分布式缓存技术已经被用在广西农业职业技术学院选课系统中得到应用，有效解决了几千人同时并发访问Web应用服务器宕机的问题。
因此，在Web应用服务器中构建分布式多级缓存，当缓存层中缓存服务器数量足够多的情况下，可以大大提高Web应用服务器的服务质量。所以Web应用服务器分布式多级缓存是一个切实可行的提高Web应用服务器性能的解决方案。
综上所述，针对广泛应用的选课系统的所面临的高负载问题，为其建立Web应用服务器中构建分布式多级缓存，通过实际应用与模拟验证发现对Web应用服务器的性能有提高作用，为解决高校选课系统延迟大甚至宕机的问题提供了一种切实可行的办法。
【参考文献】
[1]王瑜，侯整风.缓存技术在在线考试系统中的应用[J]. 山东理工大学学报（自然科学版），2011 （5）
[2]王鑫.缓存技术在Web应用中的研究[J].潍坊学院学报，2011（4）
[3]刘妍，古志民.多重请求调度的分布式Web 缓存集群设计[J]. 装备指挥技术学院学报，2006（12）
[4]钟一青. 基于内容分发的cache集群系统[J].电脑与信息技术，2006（3）
[5]莫洪武.基于Velocity CTP3 分布式多级缓存的研究与应用[J].软件导刊.2010（10）
[6]韩英杰，石磊，基于最小延迟代价的Web 缓存替换算法研究[J]. 计算机工程与设计，2008（8）
【基金项目】2012年度广西高等学校立项科研项目（201204LX620）
【作者简介】莫洪武（1980- ），男，黑龙江拜泉人，广西农业职业技术学院讲师，研究领域：软件技术。
徐州广电云缓存系统建设 第4篇
目前, 徐州广电网络宽带用户发展稳中有升, 现有一条850M出口链路, 即将开通第二条200M出口链路, 出口链路峰值流量约1G。在上网高峰期, 出现网速慢、易掉线的问题。必须对网络上的流量进行一定程度的优化, 尤其是对P2P、HTTP在线视频流量进行优化。从而提高互联网应用的服务质量和用户满意度, 同时降低公司城域网外联出口的压力, 降低网络运营成本。
2缓存原理
互联网缓存技术属于被动缓存, 在内网用户发出请求连接后, 进行相应的资源下载缓存, 下载内容完全取决于内网用户的请求。具体工作流程如图1。
1.用户发起某热点网站的HTTP请求, 请求的目标URL为缓存系统缓存的特定网站资源, 请求被分光至监控子系统。
2.监控子系统解析用户的HTTP请求, 并查询缓存系统中是否有用户请求的资源。如果有, 监控子系统会向用户发出302重定向。
3.用户重新定向缓存子系统发起热点URL的HTTP请求。
4.如果该缓存服务器存储有用户请求的内容, 则由缓存系统直接向用户回复相关请求内容。
5.如果该缓存服务器没有保存用户请求内容, 则由用户直接向源网站请求内容。
6.源网站返回用户所请求的内容。
7.当下载内容到达热点阀值时, 缓存服务器会下载此热点文件到本地, 在有用户访问此资源时, 直接引导用户从缓存服务器下载资源。
缓存系统发展历程表如表1。
3建设方案概述
根据徐州分公司实际网络情况, 计划部署1台BWPPS设备, 监控850M出口链路和200M出口链路的上行流量, 引导用户连接到城域网内部署的BWPPC4000缓存服务器上;在城域网内部署缓存系统进行流量缓存, 为用户提供缓存应用服务。
1台BWPPS4000监控重定向服务器最大可以监控4Gbps双向流量, 本期部署设备能够满足未来3到5年的流量增长需求。部署如图2所示。
1.PPS模块 (重定向设备) :1台, 负责监控当前的出口链路与扩容后的链路流量分析和共享接入监控功能。
2.LBE (调度管理服务器) :1台, 负责各台PPC任务分配;负责调度内网用户之间数据交换。
3.PPC (缓存服务器) :2台, 负责缓存HTTP视频、迅雷、QVOD、BT, 迅雷等应用流量, 并向用户提供相应下载服务;这五种缓存协议采用协议混装方式安装在2台PPC服务器上。
4.PPM (管理服务器) :1台, 负责缓存系统的系统管理、设备容错、负载均衡等, 用于监控系统各设备及业务状态, 统计汇总系统数据。
4云管理平台
缓存系统的建设, 随着带宽需求的增加, 服务器也成倍增加。为实现服务器的计算和存储资源灵活调度, 则需引入云管理平台。
4.1云计算
云计算是一种基于网络的计算服务供给方式, 它以跨越异构、动态流转的资源池为基础提供给客户可自治的服务, 实现资源的按需分配、按量计费。云计算导致资源规模化、集中化, 促进IT产业的进一步分工, 让IT系统的建设和运维统一集中到云计算运营商处, 普通用户都更加关注于自己的业务, 从而提高了信息化建设的效率和弹性, 促进社会和国家生产生活的集约化水平。
4.2 HA集群设计
云计算平台将计算资源进行重新整合, 利用云平台自身的特点实现传统物理服务器上无法实现的高可靠性。
为了提升云业务系统的可靠性, 在云计算平台的计算资源池建设时, 可以将多个物理主机合并为一个具有共享资源池的集群。CVM HA功能会监控该集群下所有的主机和物理主机内运行的虚拟主机。当物理主机发生故障, 出现宕机时, HA功能组件会立即响应并在集群内另一台主机上重启该物理主机内运行的VM。当某一虚拟服务器发生故障时, HA功能也会自动的将该VM重新启动来恢复中断的业务。具体操作如图3所示。
在每台服务器节点上都运行了一个LRMd (Local Resource Manager daemon, 本地资源管理器守护进程) , 它是HA软件模块中直接操作所管理的各种资源的一个子模块, 负责对本地的资源进行状态检测, 并通过shell脚本调用方式实现对资源的各种操作。
当LRMd守护进程检测到本机的某台VM出现通信故障时, 首先将事件通知给DC, 由DC统一将该VM状态告知集群内所有的物理服务器节点, 并按照一定的策略算法, 为该故障的VM选择一个空闲的服务器节点, 在该节点上重启如图4所示。
HA技术有效的解决了目前其它高可用性解决方案面临的问题:
1.当物理服务器发生硬件故障时, 所有运行于该服务器的VM可以自动切换到其它的可用服务器上, 相对传统的双机容错为了提升云业务系统的可靠性, 在云计算平台的计算资源池建设时, 可以将多个物理主机合并为一个具有共享资源池的集群。CVM HA功能会监控该集群下所有的主机和物理主机内运行的虚拟主机。当物理主机发生故障, 出现宕机时, 方案, HA可以最大程度减少因硬件故障造成的服务器故障和服务中断时间。
2.不同于其它HA的双机热备方式, 所有参与HA的物理服务器都在运行生产系统, 充分利用现有硬件资源。同时, 对众多的操作系统和应用程序, 云管理平台提供统一的HA解决方案, 避免了针对不同操作系统或者应用, 采用不同的HA方案带来的额外开销和复杂性。
4.3云平台技术特点
1.自动侦测物理服务器和VM失效
云平台会自动的监测物理服务器和VM的运行状态, 如果发现服务器或VM出现故障, 会在其它的服务器上重新启动故障机上所有VM, 这个过程无需任何人为干预。
2.资源预留
云管理平台永远会保证资源池里有足够的资源提供给VM, 当物理服务器宕机后, 这部分资源可以保证VM能够顺利的重新启动。
3.VM自动重新启动
通过在其它的物理服务器上重新启动VM, HA可以保护任何应用程序不会因为硬件失效而中断服务。
5缓存系统部署效果
1.降低出口带宽压力
通过建设P2P流量缓存系统 (PPCache系统) , 可以有效地缓存HTTP/P2SP、P2P等应用流量, 实现变害为利, 减缓出口带宽扩容压力。通过PPCache系统部署, 在用户密集访问期间内, 根据部署协议模块和出口流量的情况, 能够向内网回吐流量超过300Mbps, 峰值命中率80%以上。
2.提高用户体验
建设P2P流量缓存系统 (PPCache系统) , 高效地缓存HTTP/P2SP、P2P等应用流量, 确保互联网用户下载体验得到明显改善。
3.减少用户投诉
P2P缓存系统在有效的降低出口带宽压力的同时, 节约出来的出口带宽, 有效保障宽带用户对其他网页、关键性应用的体验, 从而减少用户的投诉。
4.提升投资性价比
延缓链路扩容带来的硬件成本, 减少人工运维费用;节省网间结算费用, 节省的流量可以用于新增用户的接入。
5.互联网流量分析和共享接入监控
对互联网出口流量进行分析和统计, 并且能够对内网用户的共享接入行为进行分析和架空, 分析隐藏用户数量。
6系统指标
缓存流量统计表如表2。
系统部署一个月, 由表2可以看出HTTP应用, 命中率最高达到60%, P2P视频命中率最低, 达到28%, 随着存储内容的注入增加, 用户的数量和点击增长, 该指标将进一步提高。
如图5, 为缓存软件流量指标图, 红线部分为输出流量, 绿色部分为输入流量, 流量增益随着输入流量成正比变化, 即输入流量越大, 则带宽增益也越大。
注:命中率= (吐流量-回源带宽) /吐流量;放大比=回源带宽/吐流量
图6为宽带出口流控设备一周流量监控图, 左边六个尖峰为未开启缓存出口流量, 可以看出在晚间网络高峰期, 出现冒顶削峰现象, 伴随着是用户网速下降, 体验差。右数第一个尖峰为缓存开启, 即可看出流量明显下降, 没有出现冒顶现象。
7小结
缓存系统建设对于缓解出口带宽, 提高用户体验, 有着良好的效果。而对于部署在云平台上的缓存系统, 既可以实现缓存带来的带宽增益, 又可以有效利用各服务器的计算能力, 灵活调度存储资源, 防止宕机危害, 实现系统的高可用性。
摘要：本文通过徐州广电缓存系统建设, 介绍了互联网缓存原理、发展历程、建设方案、带宽增益指标等, 并详细介绍云平台管理实现方法, 指出第三代的云缓存系统才是今后的发展方向。
关键词：缓存,流量,带宽,出口,云计算
参考文献
[1]石琳, 曹亚强, 张国圆.徐州广电网络宽带优化方案[J].广播与电视技术, 2014 (3) .
缓存系统 第5篇
方法如下：
1、首先运行“CMD”，回车打开命提示符窗口;
无形故障——CPU缓存损坏 第6篇
没办法，看来暂时没法安装系统了。该不会是什么病毒吧？进入安全模式，用杀毒软件检查，没有发现病毒。重新对硬盘进行分区、格式化均没有发现任何问题。这下麻烦了，用硬件替换法将内存、硬盘、显卡都换了个遍，仍然没有找到故障的原因。最后借来了同学的奔腾D 820换上，问题迎刃而解了。
万幸的是，我的奔腾D 915是三年质保的，离保修期截止还有几个月的时间。拿到维修站，经过维修人员的检查后发现是CPU的缓存出现了损坏，最终顺利地进入了保修处理流程。
tips
VoD系统的数据缓存策略研究 第7篇
关键词：VoD,数据缓存,缓存替换
1 引言
视频点播(VoD-Video on Demand)系统是因特网的一项重要应用。随着链路带宽的不断增大与网络技术的发展,VoD技术已成为因特网最重要的多媒体应用之一。
由于视频VoD应用的数据传输存在着大码率、长时间传输的特点,对VoD服务器的带宽与响应延迟都有很高要求。为此,VoD 服务器广泛使用数据缓存技术:通过将部分磁盘数据缓存于内存等高速存储设备来降低对相对低速的磁盘的读取次数。使用数据缓存可以有效减少磁盘I/O操作次数,降低数据请求响应延迟,增大服务器并发处理能力。缓存算法通过设计良好的数据分块、预取、顺序预取、缓存替换等算法来提高对缓存内容的命中率。
缓存算法可以分为基于访问时间的策略、基于访问频率的策略、访问时间与频率兼顾策略、时间距离分布策略等类型。另有基于数据访问模式、基于VoD系统架构的策略等。
本文综述了缓存策略的组成与分类,列举各类缓存策略的典型算法,对各类策略的特点做出总结,并评价了各策略对VoD系统的适用性。
2 缓存策略的组成部分
缓存策略主要三方面:①缓存什么内容;②何时进行缓存;③当缓存空间已满时如何进行替换,即缓存替换算法。
本文2.1节对第一方面进行了描述;对于第二方面,大部分缓存算法使用预取策略来提前将部分磁盘数据放入缓存,以进一步减少磁盘I/O,加大缓存命中率。通过记录、分析以往的数据请求模式来预测将来可能被请求到的数据段,将访问可能性大的数据段放入缓存。第3节所述各策略从不同角度解决第三方面问题。
相比于其他应用,VoD视频点播存在很强的顺序数据访问模式:即在用户不进行VCR操作的情况下,对整个影片文件的各部分依次顺序访问,访问过的数据很少再次进行访问。此种数据访问模式是在设计VoD缓存算法时必须要考虑的。所以顺序预取方式适用于VoD系统。
2.1 缓存策略的数据块分割
网页等传统互联网应用由于文件较小,可以将每一文件作为一个缓存项进行整体缓存。而VoD影片文件的缓存与普通网页等文件有很大不同,由于影片文件过大,采用普通文件的缓存策略将一个影片文件进行整体缓存会很快消耗掉缓存空间,且难以得到较好的命中率。因此需将影片文件分割成块并分别缓存。
首部缓存和分块缓存策略普遍应用于VoD影片文件。首部缓存将影片文件开始的一部分放入缓存以减小点播用户的启动延迟,对于影片文件其他部分的访问需要直接读取磁盘。
分块缓存通过将影片文件切分成小块,以块为单位进行缓存操作。分块缓存分为定长分块与变长分块。定长分块将文件切分为大小相同的块,变长分块如文献[1],变长算法是基于影片文件越靠后的部分被访问的概率越低的推断,将文件按照首尾位置分块,各块大小按指数递增。
但以上定长与变长分块均忽略了两点:①影片文件会存在一些“热点片段”而这些热点片段并不均处于影片首部;②同一影片内“热点片段”的热度会随着时间不断改变,不同影片的热度也随时间不断变化。
单纯的将影片首部缓存或按指数增长方式将影片分块无法完全适应VoD系的需求。需设计良好的算法自适应影片热点的不同位置与变化。
3 缓存策略的分类
由于不同系统的数据访问模式不尽相同,同一种缓存策难以在各种数据访问模式下均取得满意性能,研究人员提出不同缓存策略以适应不同需求。缓存策略可分为以下几类:
基于访问时间:此类算法按各缓存项的被访问时间来组织缓存队列,决定替换对象。如LRU。
基于访问频率:此类算法用缓存项的被访问频率来组织缓存。如LFU、LRU-2、2Q、LIRS。
访问时间与频率兼顾:通过兼顾访问时间与频率,使得在数据访问模式变化时缓存策略仍有较好性能。如FBR、LRFU、ALRFU。多数此类算法具有一个可调或自适应参数,通过该参数的调节使缓存策略在基于访问时间与频率间取得一定平衡。
基于访问模式:某些应用有较明确的的数据访问特点,进而产生与其相适应的缓存策略。如专为VoD系统设计的A&L缓存策略,同时适应随机、顺序两种访问模式的SARC策略。
3.1 基于访问时间的缓存策略
LRU (Least Recently Used)是一种应用广泛的缓存算法。该算法维护一个缓存项队列,队列中的缓存项按每项的最后被访问时间排序。当缓存空间已满时,将处于队尾,即删除最后一次被访问时间距现在最久的项,将新的区段放入队列首部。LRU算法思路简单,易于实现,便于在其基础上进行各种改进,大量其他复杂缓存算法使用LRU作为基础。
但LRU算法仅维护了缓存块的访问时间信息,没有考虑被访问频率等因素,在某些访问模式下无法获得理想命中率。例如对于VoD系统,在没有VCR操作的情况下,数据被由前至后顺序访问,已访问过的数据不会被再次访问。所以LRU算法将最新被访问的数据最后被替换不适用于VoD系统。
3.2 基于访问频率的缓存策略
将被访问频率高的数据尽可能多地进行缓存是设计缓存策略的另一思路。此类策略有以下几种典型算法。
LFU (Least Frequently Used)按每个缓存块的被访问频率将缓存中的各块排序,当缓存空间已满时,替换掉缓存队列中访问频率最低的一项。与LRU的缺点类似,LFU仅维护各项的被访问频率信息,对于某缓存项,如果该项在过去有着极高的访问频率而最近访问频率较低,当缓存空间已满时该项很难被从缓存中替换出来,进而导致命中率下降。
LRU-2[2,3]算法记录下每个缓存页面最后两次被访问的时间。替换页面时替换掉倒数第二次访问时间距现在最久的一项。
在IRM (Independent Reference Model)访问模式下,LRU-2有着最好的预期命中率,由于LRU-2算法要维护一个优先级队列,所以该算法复杂度为logN(N为缓存队列中缓存项的数量)。
2Q [4](2 Queues)使用LRU队列替换了LRU-2中的优先级队列,将算法时间复杂度由logN降为常数,且维护缓存项的各信息所需空间比LRU-2小。
LIRS[5] (Low Inter-Reference Recency Set)维护一个变长的LRU队列,该队列的LRU端为最近至少被访问过2次的第Llirs项(Llirs为算法参数)。LIRS算法在IRM访问模式下可以获得很高的命中率,但对于SDD访问模式效率明显下降。
对于VoD系统,基于访问频率的策略可以捕捉到热点影片片段,使得对热点片段的大量请求免于进行缓慢的磁盘I/O。但影片热点会随时间不断变化,且此类策略无法利用VoD的顺序访问模式,所以纯粹以访问频率为度量来进行替换操作不适合VoD系统。
3.3 兼顾访问时间与频率
FBR[6] (Frequency Based Replacement)维护一个LRU队列,并将该队列分为New、Middle、Old三段。对队列中的每一缓存项均维护一个计数值。当缓存中的一项被命中时,被命中的缓存项被移至New段的MRU端,如果该项原本位于Old或Middle段,则其计数值加1,原位于New段则计数值不变。当进行替换操作时,删除Old段计数值最小的一项(LRU端)。
LRFU[7] (Least Recently Frequently Used)为每一个缓存项维护一个权值C(x),其初始值为0,C(x)按以下公式变化。
进行替换操作时,C(x)值最小的一项被删除。当时,LRFU算法行为类似于LFU;而当时,该算法行为逼近LRU算法。该算法通过选用合适的λ值来获得时间与频率因素的平衡。
LRFU虽然通过一个值来兼顾访问时间与频率因素,但由于值固定,当访问模式变化时,该算法无法做出相应的调整而造成性能下降。ALRFU[8] (Adaptive LRFU)在此方面对LRFU进行了改进。通过对数据访问模式的历史进行监控,ALRFU动态调整值来适应数据访问模式的改变,表现出比LRFU更好的适应性。
3.4 基于访问模式的缓存策略
文献[9]针对VoD系统的特点提出A&L算法。该算法通过记录每个缓存项的历史访问时间与访问数量来估计该项的未来被访问频率。以该频率值为度量,在进行缓存替换时替换掉该值最小的一项。由于该算法考虑了VoD系统的数据访问特点,所以广泛应用于VoD系统。
但A&L算法通过直接计算缓存区段生成以来的总的访问数量、频率来生成缓存权值,没有考虑VoD影片的访问热点会随时间不断变化。当某些缓存区段历史访问频率较高但最近访问频率下降时,仍保持较大权值,影响新的热点片段的缓存,无法适应影片热点的动态变化。
IBM提出的SARC[10]是针对于大型服务器的缓存算法,可在随机访问与顺序访问的数据访问模式下做出动态适应。SARC通过将随机访问与顺序访问分为两个队列分别管理来实现对两种不同访问模式的适应。并通过分析缓存大小-命中率的仿真试验数据曲线,得出对随机队列与顺序队列项分别进行替换的代价函数。当进行缓存替换时,通过两队列的代价函数来对代价小的队列进行替换。
4 总结与展望
本文所述各缓存策略在适用的数据访问模式、数据分块方式等方面各有侧重。LRU、LFU等通用算法应用广泛,SARC应用于大型服务器可适应不同数据访问模式。但对于VoD系统,上述通用算法无法完全满足VoD系统的具体要求。为VoD系统设计的A&L策略有较好性能,但其对历史访问与新近访问对未来访问趋势的影响未作区分,未能考虑到影片的动态变化。对于P2P VoD系统,缓存算法还需考虑节点对于数据的缓存能力。所以对于实际VoD系统,需根据系统特点,综合上述各策略设计满足系统动态性、异构性等特征的缓存策略。
参考文献
[1] K. Wu, P. S. Yu and J. L. Wolf. Segment-based Proxy Caching of Multimedia Streams, WWW’.2001,36-44
[2]E.J.O’Neil,P.E.O’Neil,and G.Weikum.The LRU-K page replacement algorithm for database disk buffering.ACM SIGMOD Conf,1993.297-306
[3]E.J.O’Neil,P.E.O’Neil,and G.Weikum,An optimalityproofofthe LRU-Kpage replacement algorithm,J.ACM,1999,46(1):92-112
[4]T.Johnson and D.Shasha.2Q:Alowoverhead high performance buffer management replacement algorithm.VLDB Conf,1994,297-306
[5]S Jiang,X Zhang.LIRS:an efficient lowinter-reference recency set replacement policy to improve buffer cache performance,Pro-ceedings of the2002ACM SIGMETRICS international conference on Measurement and modeling of computer systems,2002.
[6] JT Robinson, MV Devarakonda. Data cache management using frequency-based replacement.ACM SIGMETRICS Performance Evaluation Review, 1990.
[7] D Lee, J Choi, JH Kim, SH Noh, SL Min, Y Cho. LRFU: a spectrum of policies that subsumes the least recently used and least frequently used policies. IEEE Transactions on Computers, 2001.
[8] Nimrod Megiddo, Dharmendra S. Modha, Outperforming LRU with an Adaptive Replacement Cache Algorithm, Computer, 2004.
[9] S Chen, B Shen, S Wee, X Zhang, Adaptive and lazy segmentation based proxy caching for streaming media delivery, Proceedings of the 13th international workshop on Network, 2003.
数据库管理系统缓存替代算法研究 第8篇
数据库是指长期保存在计算机的存储设备上、并按照某种模型组织起来的、可以被各种用户或应用程序共享的数据集合。数据库管理系统是指提供各种数据管理服务的计算机软件系统。缓冲区被用作主存和外存之间数据交换的高速缓存区, 可以减少对外存的频繁访问, 从而提高系统的效率。因此, 选择一个科学、合理、高效的缓存替代算法是数据库管理系统提高性能的必然要求。
1 缓冲区的基本概念
1.1 缓存池
数据库缓存池是由一系列内存缓存 (也叫帧) 组成, 用来存储从磁盘读入内存的数据页 (也叫磁盘块) 。页是磁盘和主存交换数据的单位, 其大小通常为2K到8K。
1.2 缓冲管理器
在数据库管理系统结构中, 缓冲管理器是负责在必要时把页面从磁盘取到主存的软件层。它管理缓冲区内页申请和访问, 如果所需页不在缓冲池中, 则该页将被读入缓冲池。当然, 在请求页不再被使用时, 缓冲区管理器释放该页, 使得该页能够被再利用。对请求的页进行了修改, 缓冲管理器将保证这个修改能反映到相应的磁盘页上。
2 常用的缓存替代算法
缓存管理的核心任务是负责在必要时把页面从磁盘取到主存中的缓冲区, 如果主存中没有空闲的空间时, 必须替换掉主存中不需要的页面, 腾出空间归当前要运行的页面使用。用于页交换的算法很多, 包括比较经典的FIFO、CLOCK、LRU等, 都已经在数据库管理系统中起到了非常大的贡献作用, 但这些算法在软件产品中往往实现都比较复杂。
2.1 先进先出页面置换算法 (FIFO)
该算法总是淘汰最先进入内存的页面, 即选择在内存中驻留时间最久的页面予以淘汰。该算法实现简单, 只需把一个进程已调入内存的页面, 按先后次序链接成一个队列, 并设置一个指针, 称为替换指针, 它总是指向最早进入内存的页面。
2.2 最近最少使用策略 (LRU)
LRU算法 (1east recently used即最近最少使用的算法) 顾名思义就是:当需要淘汰某页面时, 选择当前一段时间内最久未使用过的页先淘汰, 即淘汰距当前最远的上次使用的页。由于LRU算法是一个栈算法, 所以可用近似栈的结构来管理缓冲中页面替代LRU算法。
2.3 时钟替换 (CLCOK算法)
该算法是LRU替换的变体, 它与LRU有相似的行为, 但相比较LRU来说开销较少。它使用current变量 (1~N) 以环形顺序选择替代页, N是缓冲帧的个数。帧以环形安排, 就像时钟的钟臂一样在表面移动。每一个帧有一个referenced位, 它在页的pincount变为0时开始启动。每个帧有一个访问标记 (refbit) , 每当调用缓存管理器的read Page () 方法访问某个缓存帧后, 该帧对应的访问标记 (refbit) 将设置为true。时钟指针每经过一个缓存帧, 检查该帧的访问标记 (refbit) , 若为true则该帧最近被访问过, 故不可选为替代帧;若refbit为false, 则要看pin Cnt (摁钉数) , 如果pin Cnt=0 (pin Cnt表示该页被几个进程使用) 则该帧就是要替代的牺牲品, 否则时钟指针走一步, 牺牲品的dirty (dirty用来表示该页面有没有被修改) 若为true, 则在覆盖之前先将该帧写回磁盘。
2.4 随机算法
随机算法是在可以被交换页组中, 随机选择一个页作为交换对象。
3 算法性能比较
3.1 性能分析项目
对一个缓存管理器来说, 能高效地提供页交换是其最重要的目的。而根据数据库管理系统不同的使用环境, 各种算法也将体现出不同的性能表现。所以对各种算法进行性能分析将是在工作中选择和使用合理算法必要前提。在这里, 使用了对各种算法在多种情况下对I/O操作次数进行分析。选择这种分析策略主要是考虑到操作次数从一个侧面反映了算法在时间与空间上的使用量。分析的参数主要有以下几个:
Page Num表示测试文件的页数;
Buf Num表示缓存管理器中帧个数;
Read Num表示系统测试时I (写) 的操作次数;
Write Num表示系统测试时O (读) 的操作次数。
3.2 实验图表 (见表1)
注: (1) FIFO算法 (2) LRU算法 (3) CLCOK算法 (4) 随机算法, 随机算法的Write Num值在不同情况下会有所不同
3.3 分析策略
在此将对R/W (读写的比率) 与W次数进行分析, 来判断各种算法在不同情况下的性能。因为缓存管理器的作用就是尽量减少对外存的读写, 所以在相同情况下, 当W次数相同时, R/W的比率越小, 缓存性能就越好。因为W操作是写信息, 数据库是用来保存信息的, W操作并不能体现缓存的性能。R操作反映的是数据库查询性能, 将直接关系到缓存性能, 所以应该尽量减少缓存的R操作, 以提高缓存性能。
3.4 分析图
4 结束语
从分析表和曲线图可以看出, 在W相同的情况下, LRU与CLOCK算法一直保持在各种算法R消耗较小的一边, 而FIFO和MRU则是高消耗的一边, 随机算法的消耗值则保持在中间。不过从曲线图的变化中, 可以发现随着文件的增大, 由于页的抖动问题, LRU与CLOCK算法的优势在缓慢的减小, 曲线变化率趋向与FIFO和MRU的变化速度。所以, 在数据库系统中, LRU和CLOCK算法将体现出较好的性能。
摘要：数据库管理系统的缓冲管理器常用的页面替代算法有FIFO、LRU、CLOCK算法和随机算法。对这几种替换算法的性能进行了分析, 最终结论认为, 在数据库管理系统中, LRU算法和CLOCK算法体现出较好的性能。
关键词：页面替代算法,数据库管理系统,LRU
参考文献
[1]D.Patel, Storage file mapping in databases, veritas sortware corpora-tion mountain view, CA9043April, 2003.
[2]Michael Stonebraker, the design of the postgres storage system, eecs department University of California Berkeley, CA94720.
基于APU的内存键值缓存系统 第9篇
伴随着Web2.0技术和互联网的快速发展,互联网服务系统正面临着来自海量数据的巨大压力。传统关系型数据库在数据吞吐和可扩展性方面远远不能满足需要,各种非关系型数据库凭借其简单的数据操作处理过程、水平可扩展性和高可用性,已代替关系型数据库广泛应用于互联网服务系统中。
键值数据库(key-value store)是以关联数组作为基础数据模型的非关系数据库,其中数组元素称为键值对象。键(key)用字符串表示,文件名、URL等均可以作为键;而值(value)可以是任何类型的无结构对象,如图片、文件等。键值数据库不提供类似SQL的查询语言,数据的获取和更新均通过简单的编程接口完成。由于使用简单的数据模型和操作接口,键值数据库的吞吐量很高。
内存键值缓存系统(In-memory Key-value Cache System)是运行在内存中的键值数据库,作为后端数据库的缓存系统而存在,通过保存最有可能被访问的键值对象来加速查询,广泛应用于Facebook、Twitter、Amazon等互联网应用系统中。目前已经用于实际系统的开源内存键值缓存系统有Redis[1]、Memcached[2]等,学术界在加速内存键值缓存系统方面的工作包括Mem C3[3]、MICA[4]、Mega KV[5]和Memcached GPU[6]等。
目前加速内存键值缓存系统的工作主要在多核CPU和GPU上开展[7]。图形处理单元GPU(Graphics Processing Unit)最初专为图形处理而设计,现在已大量用于通用计算领域。GPU是由大量计算能力较弱的算术逻辑单元组成的众核处理器,这些计算单元以单指令多数据(SIMD)的形式工作。GPU主要依靠大规模并行数据处理和极高的内存访问带宽来提高系统的计算能力,多数情况下作为CPU的协处理器,为CPU执行计算密集任务或访存密集任务。Mega-KV是利用GPU加速内存键值缓存系统的典型工作,其要点是将耗时最多的关键字索引操作交给GPU完成,是目前最快的内存键值缓存系统。
Mega-KV使用独立的GPU,即CPU和GPU使用不同的存储空间,相互之间通过PCI-e进行通信。为避免CPU和GPU之间的通信成为瓶颈,Mega-KV将检索关键字的哈希表保存在GPU的设备内存上,并将所有的索引操作(查询、插入、删除)交给GPU完成。据调研,目前互联网应用系统的访问以读请求为主[8](如Facebook的访问量中95%为读请求),我们通过实验发现Mega-KV处理少量写请求的效率很低,这是因为写请求的批量不够,GPU的计算资源未能充分利用。但如果将写请求交给CPU来做,又会造成CPU和GPU之间巨大的通信开销(哈希表需要在CPU和GPU之间同步)。也就是说,在CPU和GPU分离的结构中,CPU和GPU无法细粒度地分工合作,不能充分发挥出各自的优势。
目前AMD推出了集成GPU的新型处理Kaveri系列APU(Accelerated Processing Unit)。CPU和GPU被集成在同一块芯片中,共用一个系统内存,且CPU和GPU上运行的程序使用统一的地址空间,可用相同的地址指针访问同一个内存单元。由于CPU和GPU通过共享内存通信,避免了通过PCI-e的传输开销,CPU和GPU进行细粒度协作成为可能[9]。
本文首次在基于耦合CPU-GPU架构的新型处理器(具体来说,AMD Kaveri A10-7850K APU[10])上实现了一个内存键值缓存系统(称Harmony-KV),对CPU和GPU之间的细粒度协作进行了初步的探索,并针对CPU与GPU之间细粒度协作带来的共享数据访问提出了基于乐观并发控制的解决方案。在以读请求为主的多种工作负载下,我们比较了Harmony-KV和Mega-KV的性能。实验表明,在各种工作负载下,Harmony-KV的性能均优于Mega-KV,从而验证了Harmony-KV设计的有效性。
1 内存键值缓存系统简介
内存键值缓存系统由对象管理系统和索引数据结构组成。对象管理系统负责键值对象存储空间的申请/释放以及缓存替换策略的执行,索引数据结构根据关键字定位键值对象,通常采用哈希表或树结构。内存键值缓存系统对外提供三种数据操作接口:查询对象(GET)、插入对象(SET)和删除对象(DELETE)。吞吐量(单位时间处理的请求数)和响应延迟是两个主要的性能指标,其中响应延迟是指GET的处理延迟,因为GET是延迟敏感的操作,而SET和DELETE是非延迟敏感的。
图1是内存键值缓存系统处理数据请求的典型工作流程。当从服务器收到包含数据请求的包后,首先对包进行协议处理;然后解析出数据请求的类型,若是GET请求还需提取服务器的IP地址和端口号,以便向服务器返回查询结果;最后根据数据请求类型执行相应的操作。对于GET请求,查找索引数据结构获得键值对象的内存地址,从内存中获取键值对象,封装在数据包中发送给服务器。对于SET请求,首先由对象管理系统为键值对象分配缓存空间;若缓存空间不够,执行缓存替换策略释放所需空间,然后将键值对象插入对象管理系统,最后将关键字插入索引数据结构。对于DELETE请求,处理逻辑与GET类似,在从索引数据结构获得键值对象的内存地址后,首先将对应的索引项删除,最后从对象管理系统中删除键值对象。
我们将图1的数据请求处理流程从上到下划分为四个阶段:
接收和解析包:从网络接收包,解析出数据请求类型及相关参数。
对象管理系统操作:执行与对象管理系统有关的操作,包括分配和释放键值对象缓存空间。
索引操作:执行与索引数据结构有关的操作,包括关键字查询(Search)、插入(Insert)和删除(Delete)。
构造并发送包:仅GET请求涉及,从内存读取键值对象,封装到数据包中发送。
2 Mega-KV存在的问题
我们在Nvidia GTX 780 GPU上,利用95%GET、5%SET的工作负载,测量Mega-KV在索引数据结构上执行Search、Insert和Delete操作所花时间的比例。考虑到在大规模用户访问的情况下,内存键值缓存系统的存储空间通常会在短时间内耗尽,导致每个SET都会触发一个DELETE,因此实验假设系统存储空间已满,GPU每执行一次Insert都会伴随一次Delete,实验结果如图2所示。
图2的横轴表示GPU每批处理的Insert数量(对应的Search数量是Insert的19倍),纵轴是GPU执行I n s e r t及伴随的D e l e t e操作所消耗的时间与执行Search操作所消耗的时间之比。从测量结果可以看到,尽管Insert+Delete占总操作数的比例不到10%((5%+5%)/(5%+5%+95%)),但GPU执行这些操作的时间却占到总时间的38%~58%,可见GPU处理少量Insert和Delete操作的效率很低。
出现这种现象的原因在于GPU需要依靠大规模并行处理来提高性能,而SET和DELETE的数量太少,多数计算核处于闲置状态,且启动GPU运行(包括启动PCI-e数据传输、为GPU线程分配硬件资源等)会产生大量延迟,导致在处理Insert和Delete操作时GPU效率低下。
3 Harmony-KV的设计
本节介绍Harmony-KV利用A10-7850K APU实现CPU和GPU细粒度协作的设计要点。
3.1 任务分工
图1给出的四个阶段中,“接收和解析包”以及“构造并发送包”涉及网络I/O,而“对象管理系统操作”涉及内存分配和释放,这些都是GPU无法完成的,因此这三个阶段必须由CPU完成。索引操作包括Search、Insert和Delete三种,CPU和GPU都有能力执行,但根据上文的分析可知,在以读请求为主的工作负载下,GPU执行少量的Insert和Delete操作时十分低效。如果将这部分工作交给CPU处理,会有以下好处:1)CPU并不依靠批处理来提高效率,因此不需要积累工作负载,Insert和Delete可以随到随处理;2)如果Insert能够很快完成,一定程度上可以提高Search的命中率,缩短查询响应时间;3)CPU和GPU重叠执行Insert/Delete和Search,也可以减少总的索引操作时间。因此,Harmony-KV将Insert和Delete交给CPU处理,而仅将数量最大的Search交给GPU处理。
为此,我们以GPU为中心将数据请求处理流程划分为CPU预处理、GPU处理阶段和CPU后处理三个阶段。CPU预处理负责接收、解析包,一旦遇到SET和DELETE就直接进行处理,若遇到GET就为GPU积攒Search操作。GPU处理负责执行Search操作,将得到的键值对象地址传递给CPU后续处理。CPU后续处理根据地址从内存读取键值对象,将值封装到数据包中,发送给服务器。
因此,CPU预处理的输出(Search操作)成为GPU处理的输入,GPU处理的输出(键值对象地址)成为CPU后处理的输入,CPU预处理、GPU处理和CPU后处理形成一条三阶段的流水线。
3.2 GPU和GPU的通信
GPU是以批处理的方式工作的,为此CPU需将缓存的Search操作批量交给GPU,而GPU则将Search操作的结果批量交给CPU。由此可见,每一批查询请求都需要在CPU和GPU间进行两次数据交换。数据交换的最简单方式是内存拷贝,但内存拷贝产生的系统调用和用户/内核模式的切换会引入巨大的时间开销。Harmony-KV采用缓冲区交换的方式来避免内存拷贝,具体做法是Harmony-KV使用三个公共缓冲区,CPU预处理、GPU处理和CPU后续处理每次各使用一个缓冲区,在使用结束之后,由一个额外的CPU线程将它们使用的缓冲区沿着流水线的流动方向依次交换,在下一次执行开始之前,流水线各阶段均获得存储着其上一个阶段执行结果的缓冲区。例如,假设当前流水线三阶段(CPU预处理、GPU处理和CPU后续处理)分别使用着缓冲区b1、b2和b3,则在下一次流水线三阶段开始运行时,它们使用的缓冲区就变为了b3、b1和b2。
3.3 流水线调度
为限制GET请求的处理延迟,Harmony-KV采用固定周期的调度策略来调度流水线。系统设定一个调度周期,在每个调度周期开始时先交换流水线各阶段在上一个调度周期的执行结果,之后再启动各阶段的运行。流水线各阶段都需要在一个调度周期内将任务处理完成,因此,GET的响应延迟不会超过三个调度周期。
由于GPU的执行时间与批处理量相关,很难预测,故具体的调度周期通过实验得到,具体做法是:
若系统响应延迟的上限为UT,则每个阶段的处理时间就不应该超过1/3×UT,此时Harmony-KV就将调度周期值的初始值定为1/3×UT。在运行过程中,由一个额外的CPU线程负责统计流水线各阶段的执行时间,一旦任何一个阶段的处理时间超过1/3×U_T,这个CPU线程就减小调度周期的值,直到三个阶段的执行时间均小于调度周期为止。
3.4 任务映射
A10-7850K APU只有四个CPU核和一个GPU,为此,Harmony-KV使用Scheduler、Collector和Forwarder三个CPU线程,其中Scheduler负责缓冲区的交换和流水线的调度,并负责启动GPU运行;Collector和Forwarder分别执行CPU预处理和CPU后处理。每个线程绑定在一个CPU核上运行,操作系统进程使用余下的一个CPU核。GPU负责执行Search操作。
3.5 内存管理
对象管理系统负责内存管理和缓存替换。Harmony-KV使用slab内存分配器[11]进行内存管理,slab分配器按照slab类、slab和对象三个层次来组织和分配内存。为减小索引数据结构中需要存储的键值对象的地址长度,我们使用一个32位的正整数(称为location)来表示键值对象在slab分配器中的地址。location由slab类索引、slab索引和对象索引三部分组成。
Harmony-KV采用CLOCK算法[12]作为缓存替换策略。C L O C K算法是一种近似的L R U(L e a s t Recently Used)算法,其主要思想是使用一个bitmap表示key-value最近的访问状态,每个key-value都用一个比特位(bit)表示,值为1表示最近被访问过,值为0表示最近没被访问。在进行缓存替换时,从bitmap的遍历指针所指向的位置开始遍历,若遇到bit值为0的对象则回收此对象的存储空间,并将其从索引数据结构中删除。由于实现CLOCK算法时每个key-value只需引入额外的1bit空间,因此CLOCK算法所需的存储空间是十分小的。
3.6 索引数据结构
为保证高装载因子,Harmony-KV采用cuckoo哈希表[13]作为索引数据结构。Cuckoo哈希表通常使用两个哈希函数,故每个关键字(key)的有两个候选的哈希桶位置。在执行查找操作时,只需查找key候选的两个哈希桶;对于插入操作,首先计算key所有的候选哈希桶的索引下标,之后检查候选的哈希桶中是否有空闲的哈希表项,若有则将key写入此哈希表项,若没有则开始“cuckoo移动”,即:从key的候选哈希桶中任选一个哈希表项,用新的key替换此哈希表项原本保存的key,之后再将被替换的key重新插入到哈希表中,若在插入过程中哈希冲突一直发生,则重复插入N次(Harmony-KV中N值为5)之后直接从候选哈希桶中任选一个哈希表项插入。
在Harmony-KV中,哈希表被CPU和GPU共享,故哈希表的设计必须对CPU和GPU都是友好的。GPU适合处理规整的数据结构,而CPU偏好cache友好的数据结构。为此,哈希表实现为固定长度的数组而非链表,哈希表中并不直接存储变长的键值对象,而是取关键字的低32位作为关键字的标签(tag),并将4字节的标签和4字节的键值对象,location存放在一起。此外,每个哈希桶包含8个哈希表项,每个哈希桶的起始地址都为cache行对齐,因而对每个哈希桶的查找都能够在一个cache line中完成。此外,由于cuckoo哈希使用两个哈希函数,查找操作只需检查两个长度固定的哈希桶,故查找操作的时间复杂度为O(1),对于查询请求为主的内存键值缓存系统而言,此哈希表设计是十分高效的。
值得注意的是,由于哈希表中不存储完整的key,Forwarder从内存中读取键值对象后,还需对关键字进行检查。
3.7 哈希表并发访问控制
Collector和大量的GPU线程同时对哈希表进行写和读,会导致哈希表读写冲突和false miss。所谓false miss,是指在为解决哈希冲突进行cuckoo移动时,由于键值对象所在的哈希表项发生了改变而导致查找失败。
我们利用A10-7850K APU的内存操作宽度为8字节这样一个特性来解决哈希表读写冲突的问题。由于Harmony-KV的哈希表存储的是8字节的(tag,location),刚好是A10-7850K APU的内存操作宽度,因而以哈希表项为单位的读、写不需加锁,这自然解决了读写冲突的问题。
我们采用乐观并发控制的方法解决false miss问题。具体做法是:Harmony-KV使用一个字节数组作为标识数组(flag array),每个哈希桶都使用一个数组项作为其标识(flag)。若Insert操作在cuckoo移动过程中修改了某个哈希表项存储的内容,则将此哈希表项所属哈希桶的flag值加1;对于Search操作,在查找每个哈希桶之前先记录其flag值,若对所有候选哈希桶的查找均失败,则检查它们的flag值是否改变,对于flag值改变的哈希桶需要重新进行一次查找,若此时查找仍失败,则Search操作失败。
4 实验
4.1 实验环境
Harmony-K V运行于一台P C机上,使用一片AMD A10-7850K APU,包含四个3.7GHz的CPU核以及一个包含512个1.7GHz计算单元的GPU。系统内存使用16GB 1333MHz的DDR3,最大内存带宽为12.8GB/s。操作系统是64位的Ubuntu15.04,内核版本为3.19.0-15。两个客户端运行于一台16核服务器上,分别向Harmony-KV发送请求和接收响应。两台机器通过Intel 82599ES双端口10Gb网卡相连。Harmony-KV和客户端均使用Linux内核提供的原始套接字(Raw Socket)和UDP协议进行网络传输。服务器发送查询请求时,使用Multiget技术[8]将尽可能多的GET请求放入同一个包中。
由于很难找到与A10-7850K APU计算能力相当的独立GPU,我们将Mega-KV运行于A10-7850K A P U上,并且忽略其P C I e数据传输的开销。Harmony-KV和Mega-KV的哈希表大小均设为1GB,系统延迟设为1000微秒。实验通过对比在少量写请求的工作负载下Harmony-KV与Mega-KV的吞吐量,来验证Harmony-KV设计的有效性,吞吐量用Mops(million operations per second)衡量。
客户端使用YCSB[14]生成关键字满足均匀分布(Uniform)和偏态分布(Skewed)的工作负载,其中偏态分布为skewness参数值为0.99的Zipfian分布。实验使用以下4种不同key/value大小的数据集,依次按a、b、c、d命名:8bytes/8bytes、16bytes/64bytes、32bytes/512bytes和64bytes/1024bytes。工作负载中GET请求为95%,SET请求为5%。
实验使用了全部2×4=8种组合的工作负载。为叙述方便,用数据集名字+GET占比+关键字分布规律来为工作负载命名,如a95U表示使用数据集a、GET占比为95%、关键字符合Uniform分布(U)的工作负载。
5.2 系统吞吐量
图3是在8种工作负载下,Harmony-KV和Mega-KV的吞吐量,括号中的数字为Harmony-KV相比于Mega-KV的吞吐量提升倍数。在全部8种工作负载下,Harmony-KV的吞吐量均高于Mega-KV,提高倍数为1.07~2.26。这是因为将数量很少的Insert操作交给了CPU后,GPU可以专注处理大批量的Search操作,GPU的计算资源得到了充分利用。
当工作负载为a95S时,Harmony-KV的吞吐量以及吞吐量的增长倍数都是最高的。当工作负载为d95S时,Harmony-KV的吞吐量和吞吐量的增长倍数最小。这是因为随着key/value的增大,Mega-KV和Harmony-KV的访存需求激增,此时访存带宽成为两个系统的瓶颈口,而这个瓶颈口无法通过在C P U和G P U间细粒度的任务划分解决,因此Harmony-KV与Mega-KV相比系统吞吐量几乎相等。
结束语
针对基于独立G P U的内存键值缓存系统Mega-KV存在计算资源利用不充分的问题,本文提出利用耦合CPU-GPU架构的处理器中CPU和GPU之间的细粒度协作来解决该问题,并在这种架构的AMD Kaveri系列APU上实现了一个内存键值缓存系统Harmony-KV,在以读请求为主的工作负载下,Harmony-KV的性能均比已有系统更优,从而验证了Harmony-KV设计的有效性。
缓存系统 第10篇
无线网络定位是一个重要课题[1,2,3],同时具有广阔的应用前景。比如需要知道突发事件所在的位置, 室内人员活动分布, 战场上敌方军车的运动情况, 天然气管道泄漏地点等。定位信息除了用来报告事件地点之外, 实时监测目标的行动路线, 预测目标的前进轨迹等应用也是很有价值的。
无线网络定位系统主要指的是无线传感器网络和其它类似传感器网络的系统。在这类系统中, 位置已知并且固定的节点称作beacon节点, 位置未知, 需要测定的节点称作mote节点。无线网络的定位系统的底层网络往往由这两类节点构成。目前常见的无线定位系统有基于射频识别技术的人员区域定位系统[5,6]; 基于Cricket的精确测距的精确坐标定位系统[7]; 和基于无线传感器网络的节点定位系统[2]等。虽然这些系统在功能上有互补性, 但是由于这些系统的硬件平台和通信协议方面存在很大差别, 导致开发过程的代码缺乏一致性, 很难相互共享, 造成集成开发上的效率很低, 也带来维护上的困难。
本文的主要工作是针对上述困难, 研究基于无线网络定位系统而开发的服务器端程序中普遍使用的数据缓存模块的封装。封装的目的是开发出一套统一化的缓存模块,以便针对多种无线网络定位系统的硬件平台可以重复利用。封装工作紧紧抓住各种无线网络定位系统的共性, 对其进行抽象化, 借助设计模式以及编程语言的泛型等高级特性, 对该模块进行定制和封装。
这些系统定位原理以及定位算法迥异, 但是这类系统底层网络的特性是一致的, 均是由beacon和mote构成, 这是本文工作可以展开的必要条件, 因为上层服务器端的数据结构与底层网络的构成密切相关。 还需强调, 从总体架构上, 这些定位系统也具有相似性, 从数据传输的层面分为底层网络、基站、服务器和数据应用。上位机端的服务器是整个系统的核心部分, 它负责将从基站接收的数据进行解析, 临时数据的缓存, 数据处理以及提供数据查询接口。根据功能的不同将服务器的程序模块化为四个部分, 对临时数据的缓存是由数据缓存模块负责。在实际开发过程中, 不同系统的数据缓存模块的数据结构以及存储算法并不相同, 但实际上, 由于这类系统的潜在的相似性, 使得对该类系统的数据缓存模块进行统一化处理, 结构和接口的封装是可以进行的(其实对于其它几个模块的封装和接口规范化的工作都是可以进行的)。这就是本文的主要内容所在。
1数据缓存模块的数据结构
1.1存储单元
前面提到, 无线网络定位系统的底层网络特性和类似, 是由固定的坐标已知的beacon节点以及可移动的坐标未知的mote节点构成。一般来说, 要对mote进行定位, 需要获得的数据与mote和beacon都有关系, 比如某一个beacon接收到某一个mote的RSSI[2]值, 抑或某一个mote接收到某一个beacon的距离值(通过TDOA技术[8])等等, 所以, (moteID, beaconID, value)这样的数据称作一个数据单元, 它描述了某一个时刻特定beacon对特定mote的信息的获取。
因此, 在一般情况下, 缓存模块设定的存储单元与beacon、mote以及两者之间关联的量有关。beacon或者mote可以通过ID进行标识, 关联的量在不同的系统中是不同的。
1.2二维表结构
上一节对存储单元做了介绍,可以看到,字典查找思想可以借鉴。比如以beacon或者mote的ID为键值,进行索引。其中一个思想是建立一个二维表的数据结构(如图1所示)。
第一维是按照mote作为键值, 第二维设计成线性表, 这样的方式进行存储。之所以用mote的ID作为键值, 是因为mote是被定位目标, mote之间是独立关系, 针对每一个mote的数据应该独立存储。第二维的数据是具有时序性的, 不同beacon的数据掺杂在一起, 故要对特定beacon的数据查找需要遍历整个表。而表的平均长度取决于mote的发包频率以及beacon的个数。
1.3三维表结构
三维表的数据结构较为复杂, 但是对系统数据的表述更加合理。将mote和beacon的ID分别作为一级和二级键值进行索引, 内部存储特定beacon和mote之间的数据。
回顾图1,三维表的数据结构的扩展就是将该图中的链表进行了细分, 每一个维度的数据结构是需要针对具体情况而设计,才能使得性能最佳。比如对于Cricket系统,二级表可以设计成链表, 因为TDOA技术要求beacon的个数不能太多,否则会导致延迟很大,一般来说,beacon的个数不会超过10个, 所以Cricket系统的二级表的查询次数很少, 一般不会超过10次, 这样就获得了链表的优势, 节省资源。而在WSN系统中, beacon的个数较多, 同时beacon的ID值不太大(一般不会超过65536), 而且每一个beacon的信息都需要获取的情况下, 数组的形式就更加合理。通过数组下标来索引某一个beacon的ID, 这样查询的时间复杂度是O(1), 非常之快。
图2展示了在Cricket系统中的数据缓存模块的UML示意图。图中的listener对应为mote。这个程序图展示了如何具体实现这样的三维表。同时注意到二级表BeaconList是继承自一个双端队列CricketDeque以及一个泛型的优先级队列PriorityList<T>, 这说明两点, 一是存储最终数据用的是一个双端队列, 二是用了一个泛型的优先级队列, 表明数据结构不需要关心到底最终存储的数据具体是什么类型, 都可以接纳。在这个实现中, 已经能够部分体现出一个封装性的思想了。泛型的应用使得代码的重用性大大增强, 是用来进行模块化封装的一个强有力的工具。
2数据缓存模块的封装
通过上一节的介绍看出, 数据缓存模块的数据结构较复杂, 对其进行标准化制定和封装, 难度颇大。下面先介绍实时系统, 泛型, 散列表三个概念, 解决方案即从这三个概念入手。
(1) 实时系统[9]
时间是实时系统中的一个最重要的因素。实时系统具有以下特点:系统必须在指定时间内处理相关事件,进程/线程并发执行,以及需要对系统的性能进行优化。
本文所述的这些系统都属于实时系统, 因此可以引入活动类的概念。活动类的实例化, 即活动对象能够执行它自己的控制线程, 因此,可以不需对其发送消息, 就可以开始执行相应的动作。也就是说,因为活动对象自己存有一个控制线程,它的执行可以是独立的,不需外界的触发。数据缓存模块需要独立的获取数据,独立的进行数据处理等并发工作,所以,需要将数据缓存模块设计成一个活动类的活动对象。
(2) 泛型
泛型是高级程序设计语言的一种特性[10]。泛型允许程序员在程序中编写代码时定义一些可变部份, 这些可变部份只需在使用前必须做出指明。通过泛型类可以创建独立于类型的类, 泛型方法是独立于类型的方法。接口, 结构等也可以使用泛型的方式创建。泛型非常有利于代码的重用。很多高级语言都支持泛型, 比如C++, Java, C#等。
结合我们的需求,不难看出,对于结构复杂的数据缓存模块进行封装, 泛型必不可少。不同系统所需处理以及对外提供的数据类型都是不同的, 通过使用泛型, 我们可以定义一种通用的缓存结构, 以及通用的通信标准, 当具体应用在某一个系统上时, 只需对相应的泛化部分进行指明。
(3) 散列表
缓存模块的封装,也需要用到散列表的技术。三维表每一维都有一个键值, 在插入数据或者查询数据时, 需要通过键值索引到它对应的子集合的数据中去。对于key-value对的情形, 散列表性能非常突出。散列表的数据结构可以自行设计,关键是设计好的散列函数。一个好的散列函数的要求是, 让每个关键字都等可能的散列到所有槽位的任何一个中去, 并与其它关键字已被散列到哪一个槽位无关。同时我们需要的散列表是泛型结构。可以直接使用一些编程语言提供的散列表的类库。在C#的Dictionary<TKey,TValue>的泛型散列类库,可以直接使用;也可以仿照它实现自己的泛型, 散列表。
回顾上一节不同系统的缓存模块的不同的实现,可以看到, 要进行统一化的封装, 先要将有差异的地方进行统一, 同时保证统一化的性能仍然良好。针对这类系统数据存储单元的特性, 将缓存模块设计成一个活动对象, 具有独立的线程来执行任务;它的数据结构设计成三维表, 前两维分别有mote的ID和beacon的ID来索引, 并统一定制为散列表。第三维设计成泛型的双端队列, 这是因为数据的采集具有时序性, 我们需要对这些数据的先后顺序进行区分, 此外过早的数据可以进行剔除, 双端队列的优良的两头的插入删除性能可以最佳地满足这一需求。
图3描述了这一实现的UML结构。
实际中,第一维的MoteList的键是mote的Id, 值是BeaconList;第二维BeaconList的键是beacon的Id, 值是DataList, DataList的成员是DoubleQueue<T>, DoubleQueue<T>继承自通用双端队列deque<T>(这个泛型类在C#语言中需要自行实现)。这就是它们之间的基本关系。这是一个标准数据结构, 同时具有一般性和重用性。当新的系统需要一个特点的缓存容器时, 只需对其中的泛化部分进行指定即可。
3性能分析
首先分析图1和图2两种数据结构的算法复杂度。
对于图1所示的二维表结构, 第一维的链表是以mote(在Cricket系统中即为listener)的Id作为键值的, 每一个mote下面延伸出第二维subList, 存储接收到它的数据的beacon的信息。subList中的数据是按照接收的时间序列来存储的, 所以如果要查找某一个时间段上某一个mote以及beacon的数据, 需要对subList进行遍历, 这个复杂度是O(n), n是subList的期望长度, 显然这个期望长度正比于beacon的个数以及发包节点的发射频率。对于数据处理模块而言, 当它要对某一个mote的数据进行处理时, 从缓存模块得到的数据就是该mote所对应的subList, 事实上数据处理模块需要对这个subList进行一次重组, 以使数据按照beacon归类, 这带来了一个额外的时间开销, 并且增加了数据处理模块的工作量, 复杂度是O(n)。当然, 数据的插入复杂度式O(1), 首先根据数据中的mote的Id, 以O(1)的时间找到对应的键值, 找到所属的subList, 然后把数据插入尾部。
图2所示的三维表结构, 第一维是ListenerList, 通过listener的Id对这个表进行索引, 时间复杂度是O(1), 它有一个成员叫做BeaconList, 这表明对一个listener相关数据进行维护, 它包含一个BeaconList, 存储着收到该listener数据的所有beacon的对应信息; BeaconList也可以设计成一个hash map, 但是实际应用当中, 有的系统的beacon的数目是固定的, 并且很有限, 例如RFID系统中的beacon数目是5～7个, Cricket系统中的beacon数目是4～8个, 所以BeaconList设计成了一个优先级队列, 这样虽然要查找某一个beacon, 对该表的遍历的时间开销并不大, 可以看作是介于O(1)和O(n)之间, 更重要的是, 内存开销被最大限度地节省了, 如果是hash map, 那么要开辟一个足够大的hash pool, 以保证随机的查找的期望复杂度能接近O(1)。具有优先级的意图是出于对三角定位算法的支持。在所有的beacon中, 某些坐标下的beacon对某一个listener的定位精度会比其它的高, 此外beacon自身的精度值也略有差异, 这些情况反映在优先级别中。
再对封装后的数据结构的性能做一个简单分析。首先考虑数据插入的时间复杂度, 假设要插入的数据是(moteId, beaconed, value), 那么只需调用(伪代码示例):
MoteList[moteId].BeaconList[beaconed].Add(value)
即可, 因为散列表的平均查找复杂度是O(1), 再加上双端队列的插入的时间复杂度是O(1), 所以一个插入指令的操作时间复杂度是O(1)。
数据的删除也是类似的。通过mote和beacon的Id快速索引到对应的双端队列中, 再加上删除是从两端删除, 双端队列对于该操作的时间复杂度是O(1), 所以删除指令的时间复杂度是O(1)。
当然, 散列表对于内存资源的占用较大, 为了获得查找的快速, 需要一个数目很大的槽位, 所以散列表的内存占用较大。
通过比较可以看出, 封装后的缓存模块的时间性能非常良好, 当然损失了一些功能, 比如不再支持优先级, 这个事情被移到了数据处理模块中去, 因为优先级的定义在不同的系统是大不相同的。
标准化并不是完美的, 回顾第一节介绍的Cricket系统的缓存数据结构, 它的第一维是散列表, 第二维却是一个优先级队列。在beacon个数有限并且固定的情况中, 第二维结构使用了链表, 可以大大减少内存使用, 而且性能几乎相同。但是为了做一个标准化的工作, 让整个缓存模块的数据结构能够具有普适性, 散列表和泛型的结合是一个很好的办法。
4结语
数据缓存模块的集成与封装是基于这些系统开发而进一步进行的拓展研究。这几类数据采集系统从整体架构上, 以及程序的任务模块管理上, 具有显著的共性。将共性部分抽象, 分离出来, 制定成通用库、模板抑或通用功能模块, 从而实现代码重用是本文工作的目的。总体而言, 缓存模块乃至其它模块的封装, 可节省今后类似系统开发成本, 加快开发进度, 降低维护难度, 提高系统运行的稳定性。
当然, 目前的封装工作虽显成效, 但是经历的历练尚不够多, 为能使其运行更加健壮, 首先需要对该项工作进行精细的推敲; 二是放眼于更广泛的数据采集系统; 甚至更具一般性的无线网络, 抽象出更具一般性的系统模型和架构, 使得今后研究开发工作的触角可以延伸到更远的领域。
摘要：无线网络系统的总体结构分为底层网络、基站、上位机端的服务器以及数据应用。底层无线网络对数据进行采集;基站汇集底层网络的数据并发往上位机端;上位机端的服务器对数据进行接收、缓存以及处理。数据缓存是服务器端的重要任务,在实际开发中,是由数据缓存模块来负责。从介绍数据缓存模块的程序架构入手,对该模块的架构进行封装,使其达到可重用性,通用性等目的,为今后这类系统的开发提供便利。
关键词：无线网络,数据缓存模块,系统架构,封装
参考文献
[1]Ian F Akyildis,Tommaso Melodia,Kaushik R Chowdhury.A survey onwireless multimedia sensor networks[J].Computer Networks,2007,51(4).
[2]孙利民,李建中,等.无线传感器网络[M].北京:清华大学出版社,2005.
[3]任丰原,黄海宁,林闯.无线传感器网络[J].Journal of Software,2003,14(7).
[4]Garg V,Bansal N K.Smart occupancy sensors to reduce energy con-sumption[J].Energy and Buildings,2000,32(1):81-87.
[5]Zhen Z N,Jia Q S,Song C.An indoor localization algorithm for lightingcontrol using RFID[C]//IEEE Energy 2030,Atlanta,Georgia,USA,2008.
[6]Ni L M,Liu Y,Lau Y C.Landmarc:Indoor location sensing using activeRFID[J].Wireless Networks,2004,10:701-710.
[7]Priyantha N B.The Cricket indoor location system[C]//Computer Sci-ence and Engineering at the MIT,2005.
[8]Thomas N J,Cruickshank D G M,Laurenson D I.Performance of aTDOA-AOA hybrid mobile location system[C]//International Confer-ence on 3G Mobile Communication Technologies,2001,34:57-66.
[9]Jasonc T Roff.UML基础教程[M].北京:清华大学出版社,2003.
幕后英雄 隐藏在硬件背后的缓存 第11篇
我们都知道，缓存是用于平衡高速设备和低速设备之间速度差异的纽带，也是一种用于存储临时文件的交换区，其最大意义就是“尽可能”帮助低速设备不拖高速设备的后退。之所以是“尽可能”，是因为缓存的容量通常都很小，而且数据在缓存中的命中率也是有限的。但无论如何，缓存都是提高整体性能中不可或缺的关键一环。
以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，从而彻底解决了集成显卡面临内存带宽不足的问题。
小 结
缓存系统 第12篇
关键词：存储区域网,光纤通道,文件系统,缓存,超元数据
引言
随着Internet技术的迅猛发展,网络上的数据信息已经呈爆炸式增长,网络服务器需要存储的信息和数据也越来越多,对服务器存储容量要求不断提高,导致简单的内部存储从容量上已经无法满足这一境况,用户对于数据传输可靠性或数据传输速率等方面的要求也越来越高。因此,服务器存储“外部化”已经成为必选的策略。为服务器提供专用的外部存储环境,充分利用最新的存储硬件技术和网络技术,才能够最终满足对大容量数据快速可靠的存储、精确高效的访问和安全稳定的备份等需求。
1 网络存储技术的发展
1.1 直连式附加存储(Direct Attached Storage,DAS)
在存储功能“外部化”的发展历程中最先被设计出的存储体系架构被称为DAS[1,2,3,4],在现在的部分网络环境中仍然被使用。其特点是磁盘阵列(Redundant Array of Independent Disk,RAID)等存储设备通过总线技术直接连接到计算机的系统总线上,而计算机既作为应用服务器,同时作为存储服务器,响应客户机的访问请求后,访问直连的存储设备并返回数据给客户[5]。这是一种以服务器为中心的存储体系结构,在更高要求的场合存在较多问题:存储设备只存在于单一的服务器,不同服务器的存储设备不能共享,利用率不高;不同服务器的存储设备不能相互备份,安全性不高;当存储设备越来越多后,需要在更长距离和服务器连接,此技术上的连线距离有限,增加存储设备等变更操作困难;各个NAS设备之间的数据信息不容易聚合,而且NAS的集中式结构容易产生单点故障失效问题等[6]。为了部分解决问题,出现了将数据从通用的应用服务器中分离出来,建立专门的存储子系统服务器的技术,跨越了机内存储。
这种技术通过专用电缆将服务器总线和存储设备连接,并通过小型计算机系统接口(Small Computer System Interface,SCSI)协议和指令来存取数据。但本质上这种方案和DAS还是统一形式,具有DAS的各种缺点。
1.2 网络附加存储(Network Attached Storage,NAS)
为了解决DAS的各种问题,逐渐发展出了NAS网络附加存储技术。它通过网络文件系统(Network File System,NFS)和公用网络文件系统(Common Internet File System,CIFS)等标准化的协议提供文件级的数据访问。
在NAS网络中,计算机系统是通过文件重定向器从一个NAS中得到的数据。当一个用户/应用试图通过网络访问NAS中的数据时,重定向器把对本地文件系统的本地路径重定向到使用TCP协议的网络操作系统而连接到某个远程服务器,服务器上运行的软件提供支持多个客户访问的文件系统。
1.3 区域存储网络(Storage Area Network,SAN)
SAN是通过专用高速网将一个或多个网络存储设备和服务器连接起来的专用存储系统。如图1。SAN在最基本的层次上定义为互连存储设备和服务器的专用光纤通道网络,它在这些设备之间提供端到端的通讯,并允许多台服务器独立的访问同一存储设备。与局域网(Local Area Network,LAN)非常类似,SAN提高了计算机存储资源的可扩展性和可靠性,使实施的成本更低,管理更轻松。
SAN网络根据具体实现的协议不同被划分为IP SAN和FC SAN两种。其中IP SAN是伴随着i SCSI协议的出现而逐步投入实际应用之中,它使用IP协议族,运行于高速以太网。而FC SAN相对目前应用更为广泛,使用光纤通道(Fiber Channel,FC)协议族,运行于专门的光纤通道网络之上。
2 文件系统
文件系统是对文件存储器空间进行组织分配,负责文件存储并对存入的文件进行保护和检索的系统[7][8]。文件系统中的数据一般包括两部分:文件数据和元数据。其中,文件数据包括目录数据和实际数据;而元数据是用来组织和管理文件数据的数据。
随着信息化时代的快速发展,各领域的数据信息量也迅速膨胀扩大。一般采用文件系统对海量的数据进行管理和存储。由于这些存储的数据需要随时查阅或实时更新,因此要求文件系统中的数据能够方便快速地被访问。现有技术中,在对文件系统的数据进行访问时,通常是通过磁头寻道硬磁盘的方法来确定待访问的数据,即根据文件系统中各个磁盘之间的逻辑对应关系,查找到需要访问的数据。现有技术数据访问方法中,定位待访问数据都需要通过磁头寻道硬磁盘来访问待访问数据,这种方法由于受到磁盘机械结构的限制,导致了文件系统的响应时间增长,降低了服务质量。
为了便于理解下面列举一个访问文件系统中数据的例子。例如文件系统中共有20个存储块,依次编号为0、1、2、3……19;如果此时需要访问文件系统中的某一数据,服务器首先找到的是第0号存储块,第0号存储块各级访问请求中携带的信息(可以理解为线索信息),索引找到第3号存储块,在找到第3号存储块后,第3号存储块根据线索信息索引到第1号存储块,在找到第1号存储块后,第1号存储块根据线索信息索引找到第9号存储块,进而从第9号存储块中定位所要访问的待访问数据。可见,访问文件系统中的数据首先都需要经过数个或数十个不同磁盘间相互查找的过程定位待访问数据,进而对待访问数据进行访问。
3 本方案详细阐述
3.1 本方案所要解决的问题
由于硬磁盘的机械结构限制,磁头寻道时间大约要10毫秒,一个硬磁盘对随机请求的响应率仅仅为每秒100个请求。即使是网络存储使用磁盘阵列的前提下,把请求分配到各个磁盘上,也很难突破每秒1 000个。
目前的缓存技术主要就是针对访问过的数据进行高速的缓存,如果数据一段时间内没有被访问就被替换出缓存。这种类型缓存的问题主要有两个:
(1)当大量访问文件数据以后(比如拷贝巨大文件),以前缓存的目录和文件系统的数据由于一段时间没有使用就被替换出去,当访问其他目录的时候会出现一段时间非常缓慢的现象。这降低了服务器的服务质量。
(2)访问没有访问过的目录或者文件花费的时间相对较长。
本方案提出了基于超元数据缓存的高速数据访问,以使得应用服务器在访问文件系统中的数据,尤其是访问目录数据和元数据时,能够快速响应应用服务器的数据访问请求,提升服务质量。
3.2 本方案实现的具体实施例
本方案通过在存储网络中增加独立的缓存系统,来加速文件系统的访问速度。本方案中的缓存系统就是图2中的超元数据缓存模块。存储系统是磁盘系统。服务器对存储的访问分为3类:超元数据块的读;超元数据块的写;数据块的读写。
(1)元数据缓存模块首先会从存储系统中把所有的超元数据读取出来,并且缓存。这个过程后面叫超元数据块载入过程。
(2)超元数据缓存模块收到服务器的文件数据块请求。这个过程叫数据块请求过程。
(3)超元数据缓存模块把请求直接转发给存储系统。这个过程叫数据块请求处理过程。
(4)超元数据缓存模块收到服务器的元数据读请求,直接把缓存的数据提交给服务器。这个过程叫超元数据块读请求处理过程。
(5)超元数据缓存模块收到服务器的元数据写请求,直接修改缓存中的数据。这个过程叫超元数据块写请求处理过程。
(6)然后把修改的缓存数据同步到存储系统。
(7)检查修改的超元数据缓存,如果有新的超元数据块需要载入或者删除,则载入或删除新的超元数据块。(在添加或删除目录和文件的时候可能会出现)。
3.3 本方案实施实例的数据访问方法
代理服务器预先获取存储服务器的文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存。本实施实例的数据访问方法包括:接收应用服务器发起的数据访问请求和超元数据更新操作请求。
为了为应用服务器提供其想要查找的数据,首先需要接收应用服务器发起的数据访问请求,判断数据访问请求是否为超元数据访问请求,具体可以判断数据访问请求中索引信息指示的数据是否为目录数据和元数据中的至少一个,如果“是”,对超元数据进行读取或更新操作;如果“否”,将数据访问请求发送至存储服务器的文件系统。
在判断出数据访问请求的数据是超元数据的情况下,直接在预先保存的超元数据中找到索引信息指示的数据即可,进而根据数据访问请求中的要求对索引信息指示的数据进行相应的读取或更新操作。
应用服务器的数据访问请求为超元数据访问请求时,可以直接在预先保存的超元数据中查找,将索引信息指示的数据发送给应用服务器。
应用服务器可以对超元数据进行更新操作,更新操作包括数据增加、修改和删除操作,针对不同的数据访问请求,处理方法也不同,因此需要在确定数据访问请求中索引信息指示的数据为超元数据的情况下,按照是否将原来不是超元数据的数据增加为超元数据的条件,进一步确定数据访问请求为超元数据增加请求还是超元数据修改、删除或读取请求。
增加超元数据,从文件系统中获取超元数据中不存在的数据,并加入到超元数据中。
修改超元数据,可能是将一些原来不是超元数据的数据更新为超元数据,也可能是将原来是超元数据的数据更新为文件数据,而这些数据往往以存储块的形式存在的,因此,预先保存的超元数据可能就会从文件系统中载入新的超元数据块,或删除原有的超元数据块。
上述方法不需要通过磁头寻道硬盘的方法来访问超元数据,而是直接对缓存的超元数据进行读取或更新操作,能够快速响应应用服务器的超元数据访问请求,并能够将数据访问请求对代理服务器中存储的超元数据进行的操作同步到文件系统。该方法整体提升了存储服务器的服务质量。
3.4 本方案实施实例的数据访问装置
本方案给出了2种数据访问装置:
数据访问装置1能够对应依次执行上述方案实施例中的步骤。缓存器预先获取存储服务器的文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存。访问接收模块用于接收应用服务器发起的数据访问请求,并将数据访问请求发送给第一判断模块。第一判断模块用于接收访问请求,可以是判断数据访问请求中索引信息指示的数据是否为目录数据和元数据中的至少一个。
请求转发模块用于在第一判断模块的判断结构为“否”的情形下,将数据访问请求发送至存储服务器的文件系统;超元数据模块用于在第一判断模块的判断结果为“是”的情况下,对超元数据进行读取或更新操作。超元数据操作模块结构包括数据获取模块获取数据访问请求中索引信息指示的数据;数据发送模块用于将索引信息指示的数据发送给应用服务器,如图3。
数据访问装置2缓存器是预先获取存储服务器的文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存。访问接受模块用于接收应用服务器发起的数据访问请求,并将数据访问请求发送给请求判断模块。请求判断模块用于接收访问请求,判断数据访问请求是否为超元数据访问请求。
请求转发模块用于在请求判断模块的判断结构为“否”的情形下,将数据访问请求发送至存储服务器的文件系统;超元数据模块用于在请求判断模块的判断结构为“是”的情况下,对超元数据进行的操作。超元数据操作模块结构包括第二判断模块,判断数据访问请求中索引信息指示的数据中是否包括超元数据中不存在的数据;第一处理模块用于在第二判断模块的判断结果为“是”时,从文件系统中获取超元数据中不存在的数据,并加入超元数据;第二处理模块用于在第二判断模块的判断结果为“否”时,从数据访问请求修改或删除索引信息指示的数据,如图4。
本方案中数据访问装置可以是代理服务器。代理服务器能够预先获取文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存。之后,代理服务器接收应用服务器发起的数据访问请求,判断数据访问请求中索引信息指示的数据是否为目录数据和元数据,如果是,对超元数据进行读取或更新操作;如果否,将数据访问请求发送至文件系统。代理服务器不需要通过磁头寻道硬磁盘的方法来访问超元数据,而是直接对缓存的超元数据进行访问,能够快速的响应应用服务器的数据访问请求,提升了存储服务器的服务质量。
3.5 本方案实施的数据访问系统
本方案实施的数据访问系统1包括存储器和存储器进行通信的处理器,存储器中存储处理器可执行的程序代码,程序代码包括:
(1)用于获取文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存;
(2)用于接收应用服务器发起的数据访问请求;
(3)用于判断数据访问请求是否为超元数据访问请求;
(4)用于在(3)的判断结构为“是”的情况下,对超元数据进行读取或更新操作;
(5)用于在(3)的判断结构为“否”的情况下,将数据访问请求发送至存储服务器的文件系统。
存储器中存储处理器用于获取上述程序代码,并执行。
数据访问系统1能够通过处理器执行存储器中的操作指令,完成预先获取文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存;在接收到的应用服务器发起的数据访问请求中索引信息指示的数据为目录数据和/或元数据时,从预先保存的超元数据中确定索引信息指示的数据;在索引信息指示的数据不是超元数据时,将数据访问请求发送至文件系统等操作。
本方案实施的数据访问系统2包括应用服务器、代理服务器和存储服务器。存储服务器拥有存储文件系统,应用服务器用于向代理服务器发起数据访问请求。代理服务器用于预先获取存储服务器的文件系统中所有的目录数据和元数据,并将目录数据和元数据作为超元数据保存;接收应用服务器发起的数据访问请求,当数据访问请求为超元数据访问请求时,对超元数据进行读取或更新操作;当数据访问请求为非超元数据访问请求时,将数据访问请求发送至存储服务器的文件系统。
该数据访问系统中代理服务器不需要通过磁头寻道硬磁盘的方法来访问超元数据,而是直接对缓存的超元数据进行读取或更新操作,能够快速的响应应用服务器的超元数据访问请求,并能够针对超元数据访问请求的类型不同进行不同的操作,整体提升了存储服务器的服务质量。
4 本方案实验和数据
4.1 实验环境介绍
本实验的网络环境如图5,网络中有5个设备,两台服务器,一台FC交换机,一台磁盘阵列以及cache设备。实验过程中cache设备并不是始终接入网络的。我们通过对比网络中是否接入cache设备的目录访问效率来观察cache设备的作用。
两台服务器配置intel i7处理器,2G内存,并在服务器上运行ubuntu 14.04。然后我们在服务器上创建实验所需要的目录环境。首先,创建目录test_dir,并在该目录下创建1000个子目录,然后在各个子目录下面继续创建100个子目录,并在这些子目录中的最后一个子目录存放一个目标文件target。创建过程由下面脚本实现:
4.2 简单查找实验和数据
首先,网络中并不接入cache设备,登陆服务器,接着进入test_dir目录,最后运行timefind–name target命令并记录运行时间。
然后,网络中接入cache设备,重复执行timefind–name target命令并记录运行时间,单位为秒。多次实验得到图6数据:
图6中纵轴表示时间,单位是秒,横轴表示不同次查找。从图6中可以看到接入cache以后,服务器查找文件的性能有少量的提升。在不接入cache的情况下,服务器多次查找同一个文件所花费的时间也是会下降的,这是因为服务器会使用内存来做缓存,从而减少磁盘的访问。
4.3 复杂查找实验和数据
4.2节中的实验服务器只进行文件查找操作,并没有任何的文件读写操作,现实情况并不存在这样简单的场景。所以本节我们构造复杂的实验环境,首先我们在服务器后台运行dd if=/dev/zero of=var/test bs=8k count=100000命令,其次运行进入test_dir目录,运行timefind–name target命令。最后对比cache服务器是否接入网络的数据。多次实验得到图7数据:
图7纵轴表示时间,单位是秒,横轴表示不同查找的编号。从图7中可以看出当服务器进行大量文件访问的时候,同时进行文件查找的效率是很低的,并且查找时间不稳定,极大影响了用户的体验。其原因是文件访问时服务器把大量的内存用于缓存文件的内容,此时进行目录查找则需要多次的访问磁盘,导致查找性能急速下滑。而接入cache设备以后,服务器在大量访问文件的时候,同时查找的性能保持不受到任何的影响。
5 结语
本方案不需要通过磁头寻道硬盘的方法来访问超元数据,而是直接对缓存的超元数据进行读取或更新操作,能够快速响应应用服务器的超元数据访问请求,并能够将数据访问请求对代理服务器中存储的超元数据进行的操作同步到文件系统。该方法整体提升了存储服务器的服务质量。提高服务器文件系统加速,尤其是访问目录的时候,缩短服务器集群主备切换时间。
参考文献
[1] Gibson G A,Meter R V.Network-attached storage arch itecture[J].Communication of the ACM,2000,43(11):11-17
[2] Phillips B.Have storage area networks come of age[J].Computer,1998,31(7):10-12
[3] Katz R H.Network-attached storage systems[C]//Proceedings of the Conference on Scalable High Performance Computing.Williamsburg,VA,USA,1992:68-75
[4]赵跃龙等.一种智能网络磁盘(IND)存储系统结构[J].计算机学,2008,5:859
[5]谢胜彬等.DAS、NAS与SAN的研究与应用[J].计算机与现代2003,7:8
[6] Yokota H.Autonomous disks for advanced database applications[C]//Proceedings of the 1999 International Symposium on Database Applications in Non-Traditional Environments(DATE'99).Kyoto,Japan,1999:435-442
[7] Ghemawat S,Gobioff H,Leung S.The Google file system[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles.New York,USA,2003:29-43
