火龙果大型WEB网站架构深入分析缓存.docx
- 文档编号:25773692
- 上传时间:2023-06-13
- 格式:DOCX
- 页数:23
- 大小:173.50KB
火龙果大型WEB网站架构深入分析缓存.docx
《火龙果大型WEB网站架构深入分析缓存.docx》由会员分享,可在线阅读,更多相关《火龙果大型WEB网站架构深入分析缓存.docx(23页珍藏版)》请在冰豆网上搜索。
火龙果大型WEB网站架构深入分析缓存
缓存
1介绍
缓存就是利用本地参考原则:
当CPU要读取一个数据时,首先从缓存中查找,找到就立即读取并送给CPU处理;没有找到,就用相对慢的速率从内存中读取并送给CPU处理,同时把这个数据所在的数据块调入缓存中,可以使得以后对整块数据的读取都从缓存中进行,不必再调用内存。
它们几乎被用在每一个计算层上:
硬件、操作系统、Web浏览器、Web应用程序等。
一个缓存就相当于是一个临时内存:
它有一个有限的空间量,但访问它比访问原始数据速度要快。
缓存也可以存在于各个层的架构中,但经常在离前端最近的那个层上发现,在那里可以快速实现并返回数据,无需占用下游层数据。
那么如何利用缓存使数据访问更快呢?
在这种情况下,有许多地方可以插入缓存。
一种是在请求层节点上插入缓存,如图1所示。
图1在请求层节点插入缓存
在请求层节点上放置一个缓存,即可响应本地的存储数据。
当对服务器发送一个请求时,如果本地存在所请求数据,那么该节点即会快速返回本地缓存数据。
如果本地不存在,那么请求节点将会查询磁盘上的数据。
请求层节点缓存即可以存在于内存中(这个非常快速)也可以位于该节点的本地磁盘上(比访问网络存储要快)。
图2多个缓存
当扩展到许多节点的时候,会发生什么呢?
如图2所示,如果请求层被扩展为多个节点,它仍然有可能访问每个节点所在的主机缓存。
然而,如果你的负载均衡器随机分布节点之间的请求,那么请求将会访问各个不同的节点,因此缓存遗漏将会增加。
这里有两种方法可以克服这个问题:
全局缓存和分布式缓存。
1.1全局缓存
顾名思义,全局缓存是指所有节点都使用同一个缓存空间。
这包含添加一台服务器或某种类型的文件存储,所有请求层节点访问该存储要比原始存储快。
每个请求节点会以同种方式查询缓存,这种缓存方案可能有点复杂,随着客户机和请求数量的增加,单个缓存(Cache)很容易溢出,但在某些结构中却是非常有效的(特别是那些特定的硬件,专门用来提升全局缓存速度,或者是需要被缓存的特定数据集)。
在图3中描述了全局缓存常见的两种方式。
当一个Cache响应在高速缓存中没有发现时,Cache自己会从底层存储中检索缺少的那块数据。
如图4所示,请求节点去检索那些在高速缓存中没有发现的数据。
图3负责检索数据的全局缓存
图4全局缓存里负责检索的请求节点
大多使用全局缓存的应用程序都倾向于使用第一种类型,利用Cache本身来驱逐和获取数据以防止来自客户端的同一个数据区发出大量的请求。
然而,在某些情况下,使用第二种实现反而更有意义。
例如,如果该缓存用于存储大量的文件,低缓存的命中率会导致高速缓冲区不堪重负和缓存遗漏。
1.2分布式缓存
分布式缓存即缓存在分布式系统各节点内存中的缓存数据。
如图5所示,每个节点都有自己的缓存数据,所以如果冰箱扮演着缓存杂货店的角色,那么分布式缓存就是把食物放置在不同的地方——冰箱、橱柜和饭盒——当索取的时候,方便拿哪个就拿哪个,而无需特地往商店跑一趟。
通常情况下,会使用一致性哈希函数对缓存进行划分,例如,一个请求节点正在寻找一个特定块的数据,在分布式缓存中,它很快就会知道去哪里找,并确保这些数据是可用的。
这种情况下,每个节点都会有一小块缓存,然后在向另一个节点发送数据请求。
因此分布式缓存的优点之一就是只需向请求池添加节点即可增加缓存空间,减少对数据库的访问负载量。
当然,分布式缓存也存在缺点,例如单点实效,当该节点出现故障或宕机,那么该节点保存的数据就会丢失。
图5分布式缓存
分布式缓存的突出优点是提高运行速度(前提当然是正确实现)。
选择不同的方法也会有不一样的效果,如果方法正确,即使请求数很多,也不会对速度有所影响。
然而,缓存的维护需要额外的存储空间,这些通常需要购买存储器实现,但价格都很昂贵。
其中一个非常流行的开源缓存产品:
Memcached(即可以在本地缓存上工作也可以在分布式缓存上工作);然而,这里还有许多其他选项(包括许多语言——或者是框架——特定选项)。
Memcached用于许多大型Web站点,其非常强大。
Memcached基于一个存储键/值对的hashmap,优化数据存储和实现快速搜索(O
(1))。
Facebook采用不同类型的缓存技术来提升他们的网站性能(参考“Facebookcachingandperformance”)。
在语言层面上使用$GLOBALS和APC(在PHP里提供函数调用),这有助于使中间函数调用更快(大多数语言都使用这些类型库来提升网站页面性能)。
Facebook使用全局缓存并且通过多台服务器对缓存进行分布(参考“ScalingmemcachedatFacebook”),这就允许他们通过配置用户文件数据来获得更好的性能和吞吐量,并且还可以有一个中心位置更新数据(这是非常重要的,当运行成千上万台服务器时,缓存实效和一致性维护都是非常大的挑战)。
2Web缓存技术概述
WWW是互联网上最受欢迎的应用之一,其快速增长导致网络拥塞和服务器超载,缓存技术被认为是减轻服务器负载、降低网络拥塞,减少客户访问延迟的有效途径之一。
其基本思想是利用客户访问的时间局部性(TemporalLocality)原理,将客户访问过的内容在Cache中存放一个副本,当该内容下次被访问时,不必连接到驻留网站,而是由Cache中保留的副本提供。
Web内容可以缓存在客户端、代理服务器以及服务器端。
研究表明,缓存技术可以显著地提高WWW性能[,它可以带来以下好处:
(1)减少网络流量,从而减轻网络拥塞;
(2)降低客户访问延迟,其主要原因有:
①缓存在代理服务器中的内容,客户可以直接从代理获取而不是从远程服务器获取,从而减小了传输延迟;
②没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取;
(3)由于客户的部分请求内容可以从代理处获取,从而减轻了远程服务器负载;
(4)如果由于远程服务器故障或网络故障造成远程服务器无法响应客户请求,客户可以从代理中获取缓存的内容副本,使得WWW服务的鲁棒性(Robustness)得到了加强。
Web缓存系统也会带来以下问题:
(1)客户通过代理获取的可能是过时的内容;
(2)如果发生缓存失效,客户的访问延迟由于额外的代理处理开销而增加。
因此在设计Web缓存系统时,应力求做到Cache命中率最大化和失效代价最小化;
(3)代理可能成为瓶颈。
因此应为一个代理设定一个服务客户数量上限及一个服务效率下限,使得一个代理系统的效率至少同客户直接和远程服务器相连的效率一样。
2.1Web缓存系统的理想特性
一个理想的Web缓存系统应具有以下特性:
(1)快捷性:
缓存系统应该能够有效地降低客户的访问延迟;
(2)鲁棒性:
鲁棒性意味着可用性,客户希望Web服务随时可用;
(3)透明性:
缓存系统对客户应是透明的,客户得到的结果仅仅是快速的响应和良好的可用性;
(4)可扩展性:
Web缓存系统应能够随着网络规模和密度的不断增长而很好地进行扩展;
(5)高效性:
Web缓存系统给网络带来的开销越小越好;
(6)适应性:
缓存系统能够适应客户请求和网络环境的动态变化,这涉及到缓存管理、缓存路由、代理配置等,对于获得理想的缓存性能至关重要;
(7)稳定性:
Web缓存系统采用的方案不应给网络带来不稳定;
(8)负载均衡:
一个理想的缓存方案应能够将负载均匀地分发到整个网络,以避免某一个代理或服务器成为瓶颈或Hotspot点,而造成系统一部分甚至整个系统性能下降;
(9)异构处理能力:
随着网络规模和覆盖域的不断增大,网络将跨越一系列不同的硬件和软件体系结构。
Web缓存系统应能够适应不同的网络体系结构;
(10)简单性:
简单的方案容易实现且易被普遍接受,一个理想的Web缓存方案配置起来应简单易行。
围绕上述特性,一个Web缓存系统必须解决好以下问题:
(1)缓存体系结构:
缓存代理在网络中如何组织和配置;
(2)代理合作:
代理间如何合作,相互合作的代理可以提高命中率而改善缓存系统的性能;
(3)缓存路由:
当一处缓存代理失效时,如何将请求向其它缓存代理转发;
(4)缓存替换算法:
当缓存空间不够时,缓存内容如何替换;
(5)缓存一致性:
即缓存内容的时效性问题,如何防止缓存的内容过时;
(6)内容预取:
代理如何决定从服务器或其它代理处进行内容预取以减少客户的访问延迟;
(7)负载平衡:
如何解决网络中的“Hotspot”现象;
(8)缓存内容:
什么样的内容可以被缓存。
在设计Web缓存系统时,必须涉及上述问题。
2.2Web缓存方案概述
2.2.1Web缓存体系结构
一个Web缓存系统的性能取决于其客户群的大小,客户群越大,缓存的内容被再次请求的可能性就越高。
相互合作的Cache组可能会提高命中率而提高缓存系统的性能,因此缓存系统的体系结构应确保代理间能够有效地进行合作。
典型的缓存体系结构有以下几种:
层次式、分布式和混合式。
图1Web缓存系统体系结构图
2.2.2层次式缓存体系结构
在层次式缓存体系结构中,Cache在网络呈多级配置,如图1(a)所示。
为简单起见,假定有四级:
底层Cache、局域层Cache、区域层Cache、广域层Cache。
底层是客户/浏览器Cache,当客户端Cache不能满足客户的请求时,该请求被转发到局域层Cache,如果仍然得不到满足,则该请求被转发到区域层Cache直至广域层Cache。
如果该请求在各级Cache中都得不到满足,则请求最终被转发到服务器。
然后服务器对该请求的响应自顶向下地发送给客户,在沿途的每一个中间层Cache中留下一个副本。
请求相同内容的其它请求则自下而上地进行转发,直到在某一级Cache中得到满足。
层次式缓存体系结构带宽效率高,点击率较高的Web内容可以快速高效地分布到网络中。
但该体系结构也存在一些不足:
(1)建立层次式缓存体系结构,缓存服务器必须配置在网络中关键的访问点上,缓存服务器间需相互合作;
(2)每一级Cache都会带来额外的延迟;
(3)高层Cache可能会成为瓶颈并带来较长的排队延迟;
(4)同一个内容的多个副本被保存在不同的Cache中,整个系统Cache空间利用率不高。
2.2.3分布式缓存体系结构
针对层次式缓存结构的上述缺陷,一些研究者提出了分布式缓存体系结构,在这种结构中,只有低层Cache,如图1(b)所示。
文献中的分布式Web缓存结构中,没有超出局域层的中间Cache层,Cache之间相互协作以处理失效。
为了确定将客户请求转发给哪一个局域层Cache来获取失效的内容,每一个局域层Cache保留一份其它局域层Cache中缓存内容的目录信息,以便发生失效时将客户请求准确地转发到相应的局域层Cache。
缓存阵列路由协议CARP(CacheArrayRoutingprotocol)是一种分布式缓存方案,它将URL空间分割成不同的部分,将每一部分指定给一组松散耦合的Cache组,每个Cache只能缓存具有指定给它的URL的Web内容,从而可以根据客户请求内容的URL来确定将请求转发给哪一个Cache。
在分布式缓存结构中,大多数的网络流量都发生在网络底层,不容易产生网络拥塞,Cache空间利用率高,且可以更好地实现负载共享,容错性更好。
然而,一个大规模的分布式缓存系统的配置可能会遇到几个问题:
连接次数较多、带宽要求高、管理困难。
2.2.4混合式缓存体系结构
混合式体系结构如图1(c)所示,同级Cache采用分布式缓存结构,相互合作。
Harvest集团设计的互联网缓存协议ICP(theInternetCacheProtocol)支持从RTT最小的父Cache或邻居Cache中获取相应的内容。
2.2.5缓存体系结构的优化
研究表明层次式缓存体系结构和分布式缓存结构相比,层次式缓存体系结构具有较短的连接时间,因此将较小的文档缓存在中间层Cache中可以减少访问延迟;分布缓存结构具有较短的传输时间和较高的带宽利用率。
理想的方案就是将二者结合起来,充分发挥各自的长处,同时减少连接时间和传输时间。
2.2.6缓存路由
出于对Web缓存系统扩展性的考虑,大多数缓存系统将大量的Cache分散在互联网上,这样带来的最大问题是如何快速地定位缓存有所需内容的Cache,这就是缓存路由问题。
该问题有点类似于网络路由,但却不能用同样的方式解决。
传统的网络路由可依地址聚类(层次式的地址表示使得地址聚类成为可能)而进行,但是在WWW中,具有相同URL前缀或服务器地址前缀的文档未必发送给相同的客户,难以对路由地址进行聚类,这样缓存路由表将大得难以管理。
此外,缓存内容不断更新,过时的缓存路由信息将导致缓存失效。
为降低Cache失效的代价,理想的缓存路由算法应该将客户的请求路由到下一个代理,该代理具有较高的命中可能性且位于或接近于客户到服务器的网络路径上。
当客户的请求被转发到指定的Cache时,如果该Cache缓存有请求的内容,则将其发送给客户,否则通过IP组播将请求转发给同组的其它Cache,由缓存有相应内容的Cache对客户的请求进行响应,如果所有Cache中都没有缓存请求的内容,则该请求被转发到源服务器。
Harvest缓存系统将Cache组织成层次式结构并使用Cache解析协议ICP(InternetCacheProtocol),当发生Cache失效时,低层Cache在将客户请求转发到上一层Cache前,首先查询兄弟节点Cache是否缓存有相应的内容,以避免顶层Cache超载。
自适应Web缓存系统为每一个服务器建立Cache树,树中的Cache被组织成相互重叠的多点传送组,一个请求通过这些传送组来获取相应的缓存内容。
该方法对每一个服务器构造不同的Cache树,因此没有根结点的超载问题,自配置性和鲁棒性都比较好。
但是对点击率较低的内容请求可能会经过较多的Cache,产生较大的Cache通信开销,作者建议通过限制请求经过的Cache数来解决该问题。
2.2.7哈希函数法
Cache阵列路由协议CARP使用一个基于阵列成员列表和URL的哈希函数来确定一个Web对象确切的缓存地址或一个Web对象应缓存在什么地方。
在SummaryCache中,每个代理保存一个同组中其它代理所缓存内容的URL摘要信息,该代理在转发客户请求时检查这些摘要信息以确定将请求转发给哪一个代理。
为减小开销,这些摘要信息定期进行更新。
试验表明该系统可以显著地减少Cache间的信息数量、带宽消耗以及协议带来的CPU开销,而保持和ICP几乎一样的缓存命中率
2.2.8Cache替换算法
Cache替换算法是影响代理缓存系统性能的一个重要因素,一个好的Cache替换算法可以产生较高的命中率。
目前已经提出的算法可以划分为以下三类:
(1)传统替换算法及其直接演化,其代表算法有:
1LRU(LeastRecentlyUsed)算法:
将最近最少使用的内容替换出Cache;
②LFU(LeaseFrequentlyUsed)算法:
将访问次数最少的内容替换出Cache;
③Pitkow/Recker提出了一种替换算法:
如果Cache中所有内容都是同一天被缓存的,则将最大的文档替换出Cache,否则按LRU算法进行替换。
(2)基于缓存内容关键特征的替换算法,其代表算法有:
1Size替换算法:
将最大的内容替换出Cache;
②LRU—MIN替换算法:
该算法力图使被替换的文档个数最少。
设待缓存文档的大小为S,对Cache中缓存的大小至少是S的文档,根据LRU算法进行替换;如果没有大小至少为S的对象,则从大小至少为S/2的文档中按照LRU算法进行替换;
③LRU—Threshold替换算法:
和LRU算法一致,只是大小超过一定阈值的文档不能被缓存;④LowestLacencyFirst替换算法:
将访问延迟最小的文档替换出Cache。
(3)基于代价的替换算法,该类算法使用一个代价函数对Cache中的对象进行评估,最后根据代价值的大小决定替换对象。
其代表算法有:
1Hybrid算法:
算法对Cache中的每一个对象赋予一个效用函数,将效用最小的对象替换出Cache;
②LowestRelativeValue算法:
将效用值最低的对象替换出Cache;
③LeastNormalizedCostReplacement(LCNR)算法:
该算法使用一个关于文档访问频次、传输时间和大小的推理函数来确定替换文档;
④Bolot等人提出了一种基于文档传输时间代价、大小、和上次访问时间的权重推理函数来确定文档替换;
⑤Size—AdjustLRU(SLRU)算法:
对缓存的对象按代价与大小的比率进行排序,并选取比率最小的对象进行替换。
总之,为了使Cache命中率最大化,围绕Cache替换算法已经开展了大量的工作,但是替换算法的性能很大程度上取决于WWW访问的特性,还没有哪一种替换算法能够对所有Web访问模式都优于其它算法。
2.2.9缓存一致性
Web缓存系统可以减小访问延迟,但带来了一个副作用:
缓存的副本提供给客户的可能是过时的内容,因此必须有一套缓存一致性机制来确保缓存的内容能够及时进行更新及有效性确认,以便为客户提供最新的内容。
目前主要有两种缓存一致性类型:
强缓存一致性和弱缓存一致性。
2.2.10强缓存一致性
(1)客户端确认:
对于每一次访问,代理都认为缓存的内容已经过时并随请求发送一个“IF—Modified—Since—date”报头到服务器。
如果在指定的时间后该内容发生了变化,则服务器将更新后的内容发送给代理并最终发送给客户;如果请求内容未修改,则发回“304”响应,表示文档未修改,缓存内容继续有效。
(2)服务器确认:
当服务器检测到一个内容发生变化时,服务器向所有最近请求过该内容并有可能缓存该内容的客户发送作废信息。
该方法要求服务器必须保存一个访问该内容的客户链表以便发送作废信息,当客户数量很大时,该方法将变得不适用,同时,该链表本身也可能过时,造成服务器向许多已经不再缓存该内容的客户发送作废信息。
弱缓存一致性
(1)自适应TTL(TimeToLive)机制:
通过观察一个文档的生存期来调整其生存时间,从而解决缓存一致性问题。
如果一个文档在一个相当长的时间内都未修改过,它往往不会再发生变化。
这样,一个文档的生存期属性被赋予一个该文档目前“年龄”(等于目前时间减去上一次修改的时间)的百分比。
自适应TTL法可以将一个文档过时的可能性控制在<5%的范围内。
大多数的代理服务器都使用该机制,但是这种基于文档生存期的缓存一致性机制并不能确保缓存内容的有效性。
(2)捎带作废机制
Krishnamurthy等人提出使用捎带作废机制来提高缓存一致性的效率。
他们提出了三种机制:
①捎带确认PCV(PiggybackCacheValidation)机制:
利用代理发送给服务器的请求来提高缓存一致性。
例如,当一个代理向服务器发出请求时,它捎带一系列缓存的但可能过时的来自该服务器的内容进行有效性确认;
②捎带作废PSI(PiggybackServiceInvalidation)机制:
其基本思想是当服务器对代理进行响应时,把一系列上次代理访问后变化的内容告诉代理服务器并由代理将这些内容作废,从而延长其它缓存内容在Cache中的缓存时间;
③PSI和PCV混合机制:
该机制根据代理上次请求作废的时间距当前时间间隔的大小来确定采用何种机制,以实现最佳的总体性能。
如果这个时间间隔较小,则使用PSI机制,否则使用PCV机制来对缓存内容进行确认。
其基本原理是时间间隔越小,与PSI一起发送的作废数量就小,但随着时间的增长,发送作废的开销将大于请求确认的开销。
2.2.11内容预取
Web缓存技术可以提高Web性能,但研究表明,不管采用何种缓存方案,最大缓存命中率通常不大于40~50%。
为进一步提高缓存命中率,引入了预取技术。
预取技术本质上是一种主动缓存技术,其基本思想是在处理客户的当前请求时,利用客户访问内容或模式的先验知识,对客户接下来的请求内容进行预测,并利用客户请求的间隙将预测内容缓存在Cache中,从而更好地隐藏延迟,提高服务质量。
早期研究集中在浏览器/客户与Web服务器之间进行内容预取,当代理被引入后,人们的研究兴趣转到了代理与服务器之间的预取技术研究。
研究表明预取技术可以有效地降低客户访问延迟,但预取技术仍饱受争议,原因有二:
(1)内容预取是一种实时性要求较高的任务,它主要利用客户请求的间隔进行,而这个间隔一般情况下小于一分钟[23],如果在这段时间内不能完成预取任务,预取将变得毫无意义。
因此对预取算法的效率有较高的要求。
(2)内容预取是通过加重服务器负载及增加网络流量为代价来降低客户端响应时间的,因此对预取的准确度有较高的要求。
同时,一个预取模型在确定预取文档的数量时,必须考虑客户的访问特性、服务器负载及网络流量状况,如果抛开这些因素来进行预取可能会造成事与愿违的效果。
总之,一个良好的预取模型,效率、准确度要高,付出代价小。
围绕预取的高效性和准确性还需做进一步的研究。
2.2.12负载平衡
当众多客户同时从一台服务器获取数据或服务时就会发生HotSpot现象,导致服务器性能下降甚至失效。
目前处理该问题的方法大多数是使用某些复制策略将被请求的内容分贮在互联网上,从而将负载分散到多个服务器(代理)上,避免单个服务器成为为瓶颈。
2.2.13缓存内容
一个代理可能发挥多种作用,除进行数据缓存外还可以进行连接缓存和计算缓存。
连接缓存指在客户与代理、代理与服务器间使用持久连接,来减少建立TCP连接开销及服务器发送时的慢起动开销,从而减小客户访问延迟时间。
计算缓存可以看作是Web服务器可以将它们的部分服务迁移到代理,以减轻服务器瓶颈,其应用之一就是动态数据缓存,通过代理来缓存动态数据并将一部分计算迁移到代理,由代理来产生和维护缓存的动态数据,从而提高客户获取动态数据的性能。
3JAVA缓存技术
3.1Hibernate的缓存机制介绍
缓存是介于应用程序和物理数据源之间,其作用是为了降低应用程序对物理数据源访问的频次,从而提高了应用的运行性能。
缓存内的数据是对物理数据源中的数据的复制,应用程序在运行时从缓存读写数据,在特定的时刻或事件会同步缓存和物理数据源的数据。
缓存的介质一般是内存,所以读写速度很快。
但如果缓存中存放的数据量非常大时,也会用硬盘作为缓存介质。
缓存的实现不仅仅要考虑存储的介质,还要考虑到管理缓存的并发访问和缓存数据的生命周期。
Hibernate的缓存包括Session的缓存和SessionFactory的缓存,其中SessionFactory的缓存又可以分为两类:
内置缓存和外置缓存。
Session的缓存是内置的,不能被卸载,也被称为Hibernate的第一级缓存。
SessionFactory的内置缓存和Session的缓存在实现方式上比较相似,前者是SessionFactory对象的一些集合属性包含的数据,后者是指Session的一些集合属性包含的数据。
SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句,映射元数据是映射文件中数据的拷贝,而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来,SessionFactory的内置缓存是只读的,应用程序不能修改缓存中的映射元数据和预定义SQL语句,因此SessionFactory不需要进行内置缓存与映射文件的同步。
SessionFactory的外置缓存是一个可配置的插件。
在默认情况下,SessionFactory不会启用这个插件。
外置缓存的数据是数据库数据的拷贝,外置缓存的介质可以是内存或者硬盘。
SessionFactory
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 火龙果 大型 WEB 网站 架构 深入 分析 缓存