专利名称：用于网络加速以及对高速缓存文件系统进行高效索引编制的系统及方法
技术领域：
本申请总体上涉及数据存储及检索，并且更具体而言，涉及用于网络加速以及对高速缓存文件系统进行高效索引编制的系统及方法。
背景技术：
虽然低成本膝上型计算机可能很快改进发展中世界的计算机接入，但它们的广泛部署将增加对本地联网基础设施的需求。在本地高速缓存静态Web内容可以减轻一些此类需求，但是该途径在其有效性上受限，特别是在较小环境中尤为如此。对于扩充Web高速缓存的一个选择是使用广域网(WAN)加速器，即，使用定制协议对在其间传递的冗余流量进行压缩的设备。这些设备独立于应用，并且可以改进由使用慢速网络链路的客户端所见的延迟以及有效带宽。在第一世界环境中，这些设备通常用于对经由低速WAN链路连接的中央办公室与分支办公室之间的通信进行加速。WAN加速器被部署在边缘路由器附近，并且通过透明地截取和修改到具有其他 WAN加速器的目的地的流量来进行工作。到不具有WAN加速器的目的地的流量穿过未经修改的设备，从而保持透明性。对于所截取的流量，加速器通常将数据流分成更小的块 (chunk)，在每个加速器处存储这些块，并继而利用对所高速缓存的块的引用来替换该数据的未来实例。通过传递对块的引用而非完全数据，加速器对数据流进行压缩。对于扩充网络高速缓存的另一选择是改进高速缓存存储引擎。大型企业和ISP尤其从网络高速缓存中获益，因为它们可以将其成本及管理分摊在较大的用户群体上。高速缓存存储系统设计已通过该此类用户成形，从而导致偏爱第一世界使用场景的设计决策。 然而，由于盘大小已经比RAM大小更快地增长，因此当今购买百万兆字节(terabyte)的盘比购买能够为如此之多的存储编制索引的机器便宜得多，因为大多数低端服务器具有较低的存储器限制。该盘/RAM关联使得现有高速缓存存储系统对于其中非常期望具有附接至廉价低功率机器的百万兆字节的廉价存储(能够以低于100美元/TB购得)的发展中世界使用成问题。然而，如果为百万兆字节的存储编制索引需要IOGB的RAM (对于当前的代理高速缓存是典型的)，则这些部署将需要服务器级机器，以及它们的关联成本和基础设施。更糟的是，该存储器专用于由单一服务所使用，从而使得统一的多用途服务器难以部署。该情况尤其令人遗憾，因为在发展中地区中的带宽往往在相对货币和绝对货币上都比在美国和欧洲更为昂贵。
发明内容
在此所描述的说明性实施方式的系统和方法解决了现有WAN加速器和网络高速缓存系统所出现的问题。举例而言，在一个实施方式中，提供一种用于对数据网络上的数据检索进行加速的方法。该方法包括由第一代理设备接收对从最终用户设备向源数据设备发送的数据的请求。第一代理设备建立与第二代理设备的连接。第二代理设备与源数据设备进行通信。第一代理设备向第二代理设备传输针对数据的请求。第二代理设备向源数据设备转发请求，并且从源数据设备接收数据。第一代理设备接收与由第二代理设备从所接收数据中生成的多个数据块对应的多个块名称。第一代理设备使用多个块名称来确定本地数据存储单元是否包含多个数据块中的一个或多个。响应于对本地数据存储单元不包含与多个块名称关联的多个数据块中的一个或多个的确定，第一代理设备确定用于对关联于多个块名称的多个数据块进行检索的优化检索调度。例如，在一些实施方式中，第一代理设备可以确定哪个本地对等设备来请求与多个块名称关联的非本地存储的数据块。此外，在一些实施方式中，如果整体性能增加，则第一代理设备可以在广域网上检索本地存储的数据块， 而不是从局域网对等设备或者从本地数据存储对本地存储的数据块进行本地检索。第一代理设备在检索关联于多个块名称的多个数据块之后将数据提供给最终用户设备。在另一实施方式中，提供一种用于存储及检索数据的方法。该方法包括布置辅助存储设备以包括连续区块(block)的表以及文件系统。文件系统可以是具有分层目录的日志文件系统或常规文件系统中的一个。该方法对关联于对所请求文件的数据请求的标识符 (例如，关联于web对象的URL)进行哈希，以生成标识表内位置的哈希值。该方法读取表内的位置以确定在该位置处是否存在文件。如果在该位置处存在文件，则该方法使用关联于现有文件的元数据来将现有文件的标识符与关联于数据请求的标识符进行比较，以确定其是否为文件命中。如果其为文件命中，则该方法确定该文件是否包括存储在文件系统上的附加数据。如果存在附加数据的话，该方法从文件系统检索附加数据，并将所请求文件返回给请求设备。在又一实施方式中，一种用于存储及检索数据的方法包括布置辅助存储设备以包括具有多组连续区块的表以及文件系统。该方法对关联于对所请求文件的数据请求的标识符进行哈希，以生成标识表内的集合的哈希值，并且确定该集合内的区块是否包含关联于数据请求的标识符的匹配标识符。响应于对区块包含关联于数据请求的标识符的匹配标识符的确定，该方法从该集合内的该区块检索所请求文件。如果存在与未在该块中存储的所请求文件相关联的附加数据，则该方法从文件系统检索附加数据。所请求文件被返回给请求设备。在又一实施方式中，一种用于存储及检索数据的方法包括布置辅助存储设备以包括具有多个连续区块集合的表以及文件系统。该方法还在主存储器中布置具有该多个连续区块集合的对应表。该方法对关联于对所请求文件的数据请求的标识符进行哈希，以生成标识表内的集合的哈希值。该方法确定主存储器中对应表中的集合内的块是否包含关联于数据请求的标识符的匹配标识符。响应于对主存储器中对应表中的集合包含匹配标识符的确定，该方法从辅助存储设备上的集合内的对应块检索所请求文件。此外，如果存在附加数据的话，则该方法从文件系统检索附加数据，并将所请求文件返回给请求设备。此外，在另一实施方式中，一种用于存储及检索数据的方法包括布置辅助存储设备以包括循环日志文件系统，并且在主存储器中布置具有多个连续区块集合的表。该方法对关联于对所请求文件的数据请求的标识符进行哈希以生成标识表内的集合的哈希值，并且确定主存储器中表的集合中的块是否包含关联于数据请求的标识符的匹配标识符。响应于主存储器中表的集合中的块包含关联于数据请求的标识符的匹配标识符，该方法标识存储于循环日志文件系统中的所请求文件的位置。该方法从辅助存储设备内的循环日志文件系统的该位置检索所请求文件，并将所请求文件返回给请求数据的设备。此外，所公开的实施方式包括执行一个或多个上述方法的装置和计算机程序产品。参考以下的附图及详细描述，说明性实施方式的其他目的、特征和优点将变得清楚。
图1图示了可在其中实现说明性实施方式的网络环境；
图2是图示了根据说明性实施方式的、在图1中所描绘的系统之间的通信交换的序列
图3是图示了根据说明性实施方式的系统架构的示意图； 图4图示了根据说明性实施方式的多分辨率组块(MRC)方案； 图5图示了根据说明性实施方式的对若干个组块方案进行比较的表； 图6图示了根据说明性实施方式的用于智能减载的算法； 图7是图示了根据说明性实施方式的图6中的智能减载的示意图； 图8图示了使用根据说明性实施方式的多分辨率组块方案的潜在带宽节省； 图9图示了使用根据说明性实施方式的多分辨率组块方案的盘操作成本； 图10图示了使用根据说明性实施方式的多分辨率组块方案的存储器占用比较； 图11图示了根据说明性实施方式的、对于64KB区块的多分辨率组块计算开销； 图12是图示了根据说明性实施方式的用于对来自对象高速缓存的数据进行存储及检索的过程的流程图13是图示了根据说明性实施方式的图12的过程的示意图； 图14是图示了根据说明性实施方式用于对来自对象高速缓存的数据进行存储及检索的另一过程的流程图15是图示了根据说明性实施方式的图14的过程的示意图； 图16是图示了根据说明性实施方式的用于对来自对象高速缓存的数据进行存储及检索的又一过程的流程图17是图示了根据说明性实施方式的图12的过程的示意图； 图18是图示了根据说明性实施方式的用于对来自对象高速缓存的数据进行存储及检索的又一过程的流程图19是图示了根据说明性实施方式的图12的过程的示意图； 图20是对根据说明性实施方式的用于对来自对象高速缓存的数据进行存储及检索的上述过程进行比较的表；
图21是描绘根据说明性实施方式的用于对来自对象高速缓存的数据进行存储及检索的上述过程的吞吐量含义的表；以及
图22是描绘根据说明性实施方式的用于对来自对象高速缓存的数据进行存储及检索
10的上述过程的资源使用的图表。
具体实施例方式在对若干个说明性实施方式的以下详细描述中，对附图做出了参考，这些附图形成详细描述的一部分，并且在附图中通过示例说明的方式示出了可在其中实践本发明的特定优选实施方式。以充足的细节描述了这些实施方式以使本领域技术人员能够对本发明进行实践，并且应当理解，可以利用其他实施方式而不脱离本发明的精神或范围。为了避免对于使本领域技术人员能够实践在此所描述的实施方式而言不必要的细节，描述可以省略本领域技术人员已知的某些信息。因此，不应在限制意义上采用以下详细描述，并且说明性实施方式的范围仅由所附权利要求书限定。参考图1，其呈现了可在其中实现所公开的实施方式的说明性网络环境100。网络环境100包括局域网(LAN)llO、广域网(WAN)120以及因特网130a和因特网130b。局域网 110向诸如个人计算机、膝上型计算机和PDA设备之类的客户端设备102提供数据连接性。 如在此所引用，Waprox是一种也提供WAN加速的代理设备。如本文中所使用的代理设备指代充当内容请求设备(例如，客户端设备102)与内容提供设备(例如，web服务器)之间的中介的、至少具有处理器、存储器和数据存储组件(可以在外部)的物理计算机。代理设备可以包括专用硬件或者一个或多个执行软件的处理器和/或二者的组合，用于提供诸如但不限于安全、管理控制和/或高速缓存服务之类的特征。根据公开的实施方式，局域网110包括用于对一个或多个客户端设备102的数据检索进行加速的一个或多个Waprox 104。在一个实施方式中，局域网110是网状网络环境，其使Waprox 104能够彼此直接进行通信以便交换数据。然而，局域网110可以实现为星型拓扑或者使节点能够以各种方式彼此进行通信的任何其他拓扑。除了局域网110内的 Waprox 104以外，在局域网110与广域网120之间的边缘路由器附近部署了 Waprox 106。 Waprox 106充当局域网110中的Waprox 104与广域网120中的Waprox 108之间的网关 Waprox0 Waprox 108部署在广域网120与因特网130a和130b之间的边缘路由器附近，并且为充当Waprox 106的因特网网关/Waprox。如本文所使用，对“Waprox” 的引用指代 Waprox 104、Waprox 106 和 Waprox 108 的全部或者其中的任何一个。例如，围绕四个目标设计Waprox- (1)使压缩最大化、(2)使盘寻找最小化、(3)使存储器压力最小化，以及(4)对本地资源加以利用。术语“本地资源” 和“本地对等设备”可以包括物理上紧邻的机器，这些物理上紧邻的机器在技术上可以在其他网络上，这利用起来没有广域网120昂贵。Waprox被配置为压缩Waprox对之间的冗余流量，该Waprox对中的一个在客户端附近，被称为R-Waprox，一个更靠近内容，被称为S-Waprox。例如，可以压缩Waprox 108(充当 S-Waprox)与 Waprox 106 (充当 R-Waprox)之间的或者 Waprox 106 (充当 S-Waprox)与 Waprox 104 (充当R-Waprox)之间的冗余流量。对于发展中地区，S-Waprox很可能被置于带宽不如客户端设备102附近的带宽昂贵的地方。在其中Waprox使用主要是Web相关的一个实施方式中，Waprox对TCP流而不是IP 分组进行操作，因为对TCP流进行缓冲可以产生用于内容指印的更大区域。内容指印(CF) 通过提供用于仅基于其内容而将数据流分为较小片或块的独立于位置并且独立于历史的技术来形成WAN加速的基础。在优选实施方式中，Waprox利用Rabin技术来在字节流的滑动窗口(例如，48字节)上生成整数值或者指印。当指印匹配于指定的全局常数时，该区域构成块边界。平均块大小可以利用参数η来控制，该参数限定了有多少K的低阶(low-order) 比特用于确定块边界。在平均情况下，期望的块大小为2~n字节。为了防止块过大或过小， 可以指定最小块大小和最大块大小。由于Rabin指印技术通过内容而不是偏移来确定块边界，因此数据流中局域化的改变仅影响此改变附近的块。一旦已经对流进行了组块，Waprox 可以对块进行高速缓存，并将对先前高速缓存的块的引用/块标识符(诸如SHA-I哈希)传递给本地Waprox而不论该引用/块标识符的来源如何。作为结果，Waprox可以在流内、跨流并且甚至跨文件和协议进行压缩。如果本地Waprox具有所高速缓存的块，则数据被重新组装并传递到客户端设备102。任何未被高速缓存的块可以从远程Waprox (例如，Waprox 108)或者其他的近旁/本地对等设备(例如，Waprox 104)获取。尽管在上文中将Rabin指印技术描述为优选的指印技术，但Waprox可以利用包括但不限于Manber锚索技术的其他内容指印技术来确定块边界。图2图示了在内容请求设备210、R-Waprox 220、S-Waprox 230以及内容提供设备240之间的数据传输的示例。内容请求设备210可以是Waprox 104和/或客户端设备 102。R-Waprox 220 和 S-Waprox 230 分别为网关 Waprox，诸如 Waprox 106 和 Waprox 108。 Waprox使用Waprox之间的三种通信信道控制信道、数据信道和监视信道。控制信道用于连接管理和块名称交换。例如，在一个实施方式中，当内容请求设备210发起TCP连接用于在广域网120上向内容提供设备240发起数据请求202时，该连接被R-Waprox 220透明地截取。在其他实施方式中，内容请求设备210可被配置为明确地向R-Waprox 220发送诸如但不限于所有HTTP请求之类的流量。在某些实施方式中，R-Waprox 220可以经由被配置为自动向R-Waprox 220发送某些流量的路由器接收数据请求202。在一个实施方式中， R-waprow 220不截取不可高速缓存的协议(例如，SSH、HTTPS)。R-Waprox 220选择在网络拓扑上更为靠近内容提供设备240的S-Waprox 230，并向其发送具有内容提供设备MO的 IP和端口号的打开连接消息204。利用该信息，S-Waprox 230打开TCP连接并且向内容提供设备240发送数据请求206，并且内容请求设备210与内容提供设备240之间的逻辑端对端用户连接被建立起来。当内容提供设备240向S-Waprox 230发回数据208时，S-Waprox 230从数据 208生成块名称并在块名称消息212中将该块名称发送给R-Waprox 220。如在图3中将进一步描述的那样，Waprox利用使多个块大小能够共存于系统之中的新颖的多分辨率组块技术。块名称消息212包含序列号，使得R-Waprox 220可以以正确顺序重建原始内容。 在R-Waprox 220重建块数据214并将其传递给内容请求设备210之后，R-Waprox 220向 S-Waprox 230发送块确认(ACK)消息216。S-Waprox 230继而可以安全地从其存储器中丢弃所传递的块，并且继续对更多块名称进行发送。当内容请求设备210或者内容提供设备240关闭连接时，对应的Waprox向其他网关发送关闭连接消息226，并且一旦所有数据均已传递，网关与客户端之间的连接便被关闭。然而，控制信道仍然保持连接。所有的控制消息携带它们的逻辑端对端流标识符，因此可以针对许多同时的数据流对一个控制信道进行复用。为了效率，控制消息可以相互搭载 (piggyback)ο
数据信道用于请求和传递未高速缓存的块，因此其无状态并且实现为简单请求-回复协议。例如，在R-Waprox 220处高速缓存未中的情况下，数据信道使用块请求消息218和块响应消息222来传递实际块内容。在一些实施方式中，S-Waprox 230可以如将要进一步描述的那样发送用于查询给定块是否被R-Waprox 220高速缓存的块窥视消息 (未示出)，以便提供智能减载。最后，监视信道用于使用简单的心跳协议来检查对等端的存活性和负载水平。 Waprox通过在监视信道上交换心跳2 来监视其对等端的状态。心跳响应230携带对等端的盘和网络I/O的负载水平，使得可以在对等设备之间平衡请求负载。图3是图示了根据说明性实施方式的Waprox 300的系统架构的示意图。Waprox 300包括处理器310、用于使得Waprox 300能够在网络环境100上发送及接收数据的网络接口 320、存储器330 (在此亦称为主存储器)、用于执行如上所述的Rabin指印技术的内容指印引擎340、以及诸如硬盘之类的数据存储系统350 (在此亦称为辅助存储)。处理器310 可以是能够执行存储器330中所存储指令334的任何类型的微处理器和/或专用电路。块数据370由于成本和容量而存储在数据存储系统350上。例如，Waprox 300的数据存储系统350通常是百万兆字节的或者更大。在一些实施方式中，除了块数据370以外，数据存储系统350还可以存储块元数据索引360，该块元数据索引360包含描述块数据 370中所存储块的数据。例如，块元数据索引360可以包括头部信息、属性以及链接关系。 尽管图3图示了整体驻留在数据存储系统350上的块元数据索引360，但是在一些实施方式中，块元数据索引360可以部分地或者整体地驻留在存储器330中。在一些实施方式中，块元数据的高速缓存索引332被部分地或者完全地保存在存储器中以避免盘访问。然而，在一些实施方式中，存储器330可以完全没有高速缓存索引332。存储器330还可以充当用于块数据的高速缓存以减少针对常用内容的盘访问。Waprox的性能主要由三个因素所确定——(1)压缩率、(2)盘性能以及(3)存储器压力。压缩率指代原始数据的经物理传输数据(块引用)的分数，并且反映了由接收器侧高速缓存而产生的网络带宽节省。盘性能确定经高速缓存的块访问时间(寻找时间)，而存储器压力影响块索引和存储器中高速缓存管理的效率。这三个因素影响总延迟，该总延迟是用以重建及传递原始数据的时间。为了实现高效带宽，Waprox减少了总延迟而同时实现高压缩、低盘寻找和低存储器压力。块大小直接影响所有三个上述因素，并且因此也影响到有效带宽。如果改变是细粒度的，诸如段落中词语被改变，则小的块大小可以导致更好的压缩。仅修改包含该词语的块，并且段落的其余部分可以被压缩。然而，对于相同的存储大小，更小的块产生更多的块总量，从而增加元数据索引大小，并且增加存储器压力和盘寻找。大的块产生较少的块总量，从而由于每次读取可以提供更多的数据而降低存储器压力并且提供更好的盘使用。然而，大的块可能错过细粒度的改变，从而导致较低的压缩。在使用内容指印的系统中没有明确的标准块大小——例如，2KB、8KB和16KB块大小已由其他WAN加速器所使用。公开的Waprox通过使用在下文中称为多分辨率组块(MRC)的技术来允许多个块大小在系统中共存来组合大的块和小的块二者的优势。Waprox使用MRC来实现(1)高压缩率、(2)低盘寻找以及(3)低存储器压力。当内容重叠高时，Waprox可以使用较大块来减少盘寻找和存储器压力。然而，当较大块错过压缩时机时，Waprox使用较小块大小来实现较高的压缩。相反，现有WAN加速器通常使用固定块大小，我们将其称作单分辨率组块或者SRC。生成多个块大小需要仔细处理，这不仅是为了效率，而且也是为了确保块边界对齐。如图4 (a)中所示，用以生成块的朴素(naive)方法可能产生未对齐的块边界。在此， 伴随多个大小而多次运行指印算法。然而，由于不同的边界检测机制、块大小限制或者其他问题，较大块的边界不与较小块的边界对齐。作为结果，当获取块以重建数据时，块的某些区域重叠，而某些块仅部分地重叠，从而在必须获取部分命中的块以满足较小的未中范围时导致被浪费的带宽。Waprox通过执行单趟指印步骤来解决上述问题，其中所有的最小边界均被检测， 并且继而通过对相同边界检测约束的不同数量的比特进行匹配而生成较大块。该过程产生图4(b)中所示的MRC树，其中最大块为根，并且所有的更小块与一些它们的叶块共享边界。 使用一个指印趟来执行该过程不仅产生更干净的块对齐，而且需要较少的CPU。通过MRC过程生成的所有块均被存储到数据存储系统350，即使较小的块包含与它们的父亲相同的数据。在这一决策背后的基本原理基于对盘空间是便宜的观察。此外， 使所有块完全独立简化了元数据索引编制过程，因此，降低了系统中的存储器压力并且最小化了盘寻找。例如，当从数据存储系统350读取块内容时，MRC需要仅一个索引条目访问以及仅一个盘寻找。两个其他选择将是从较小块重建大的块，我们称其为小MRC (MRC-Small)；以及将较小块作为偏移存储到根块中，我们称其为大MRC (MRC-Large)0虽然小MRC和大MRC 二者均可通过仅保存唯一性数据而减少盘空间消耗，但它们受害于较多的盘寻找和较高的存储器压力。为了重建较大块，小MRC需要获取共享内容的所有较小块，这可能显著增加盘访问。在该过程中访问了针对每个小的块的元数据，从而与伴随仅一个块条目的标准MRC相比增加了存储器压力。大MRC避免了多次盘寻找，但却使块索引管理变得复杂。当块被从盘收回(evict)或者被覆写时，所有的从属块必须也被无效。这需要每个元数据条目增长以包括所有的子块名称，或者需要所有的子块元数据条目包含到它们的父亲的反向指针。MRC 通过使所有块彼此独立而避免了这些问题。该选择以更多的盘空间消耗为代价而大大简化了设计。例如，假设IMbps的WAN连接，Waprox可以在单个ITB盘上存储一个月量以上的块数据。图5总结了不同方案的权衡。当R-Waprox 220从S-Waprox 230接收MRC树(仅块名称)时，其建立候选者列表以确定哪些块可在数据存储系统250中本地获取、可在本地对等设备(例如，Waprox 104)处获取以及可从S-Waprox 230获取。为了得到该信息，其从根开始，针对每个块的状态对其本地高速缓存和本地对等设备进行查询。在一个实施方式中，R-Waprox 220使用存储器中高速缓存索引332来处理该查询，因此，不需要额外的盘访问。如果块被命中，则R-Waprox 220停止对该块的任何孩子的查询。对于未中，R-Waprox 220找到仅包含未中的子树的根， 并从S-Waprox 230获取未中的块。在对内容进行重建之后，R-Waprox 220将MRC中每个未高速缓存的块存储到数据存储系统350以供未来引用。此外，S-Waprox 230利用新颖的块名称提示优化技术来预测R-Waprox 220处的命中与未中以便对MRC树进行修剪，因为如果在树的高层级处存在高速缓存命中或者当子树是所有未中高速缓存时，发送完全的MRC树将浪费带宽。一次发送树的一个层级避免了浪费带宽，但却因大量的往返而增加了传输延迟。作为替代，S-Waprox 230包含提示表，该提示表包含连同时间戳的最近所见块名称。在发送MRC树之前，S-Waprox 230针对该提示表对所有的块名称进行检查。对于提示表中的任何命中，S-Waprox 230避免发送该块之下的子树。如果其为未中或者块名称提示不新鲜(stale)，则S-Waprox 230确定未中的最大子树并且发送针对该整个子树的一个块内容，因此，消除了 MRC树的任何低效交换，并且进一步增加了有效压缩率。S-Waprox 230使用时间戳来使旧提示条目无效。然而，还可以使用其他机制来使旧提示条目无效，诸如Waprox之间的无效消息，或者其他形式的高速缓存同步。Waprox合并了对等互传机制(peering mechanism)以使用更廉价/更快速的本地连接性与近旁的对等端(例如，Waprox 104)共享诸如盘、存储器和CPU之类的资源。其允许Waprox在对等端中分发块获取负载以及利用多个块高速缓存进行并行存储，从而改进性能。相比之下，现有WAN加速器仅支持点对点通信。为了减少源自请求对等端的可伸缩性问题，Waprox使用被称为最高随机权重 (HRff)的一致性哈希的变体。无论节点扰动(churn)如何，HRW确定性地选择针对块的负责对等端。HRW以更多的CPU周期为代价消耗小的存储器。然而，可以使用其他形式，包括其他的一致性哈希方法、基于目录的方案或者基于查询的方法。在接收来自S-Waprox 230的块名称消息后，R-Waprox 220向其负责对等端 Waprox发送块请求消息。该消息包括未中的块名称以及未中块的名称所源于的S-Waprox 230的地址。如果对等端Waprox具有该块，则其利用块响应消息将所请求的块内容发回给 R-Waprox 220。如果没有，则对等端代理可以从S-Waprox 230获取未中的块，将其传递到 R-Waprox 220，并且本地保存该块以供未来请求。在一些实施方式中，如果对等端不在相同 LAN中并且可能招致单独的带宽成本，则对未中块的获取后退到R-Waprox 220而不是对等设备。在完成数据重建之后，R-Waprox 220通过在数据信道中发送块安置消息儿将任何未高速缓存的块分发到其对应的对等端。虽然块高速缓存命中由于它们降低带宽消耗而是期望的，但是过多的盘访问可能由于增加整体延迟而使有效带宽降级。如果盘性能低下，则该问题加剧。因而，R-Waprox 220利用图6中所描绘的智能减载(ILS)方案，该ILS方案利用MRC树的结构并且对块获取进行动态调度，以在给定资源预算的情况下使有效带宽最大化。如果对更多盘请求进行排队将增加整体延迟，则智能减载(ILS)方案机会性地使用网络带宽来代替那样做。例如，通过针对较大块使用盘并且在网络上获取较小块，R-Waprox 220可在没有盘过载的情况下维持高有效带宽。参考图6，智能减载(ILS)过程600取R-Waprox 220的链路带宽(BW)和往返时间 (RTT)作为输入602。每个对等端Waprox使用监视信道来以未决盘请求(Qi)604和将从网络接收的未决字节(Bi)606的数量的形式发送包含其网络及盘负载状态的心跳。在一个实施方式中，为简单起见，R-Waprox 220假设每个块的盘读取延迟(S)608或者寻找时间对于所有的对等端都是统一的。在接收来自S-Waprox 230的块名称后，R-Waprox 220在步骤610中运行HRW算法以将块名称(C)划分到负责对等端中。一些块名称被指派给R-Waprox 220本身。继而在步骤612中，R-Waprox 220通过并行地向对应对等端发送块窥视消息来检查块是否为高速缓存命中。基于查找结果，R-Waprox 220在步骤614中生成候选者列表。注意，可以按照
15来自于S-Waprox 230的名称提示来保存该查找和候选者列表生成过程(图6中第2行和第 3行)，R-Waprox 220将其用于在不进行实际查找的情况下确定结果。ILS过程600中的下一步骤是在步骤616中估计针对网络及盘队列的获取延迟。从候选者列表中，ILS过程600 知道哪个块需要在网络上获取(网络队列，N)以及哪个块需要从本地盘或对等端获取(盘队列，Di)。基于该信息，ILS过程600估计针对每个块源的延迟。在步骤618中，对于每个盘队列，所估计的盘延迟将是每个块的盘延迟(S)乘以高速缓存命中的数量。在步骤620中， 对于每个网络队列，所估计的盘延迟将是一个RTT加上高速缓存未中块的总大小除以BW。 如果在网络或盘队列中存在未决块，则相应地调整每个延迟。在一个实施方式中，ILS过程 600假设R-Waprox 220与对等端之间的延迟小。ILS过程600中的最终步骤是在步骤622 中对期望的队列延迟进行平衡，但是是以带宽敏感的方式这样做。ILS过程600决定是否应当将一些高速缓存命中从盘队列中移动到网络队列——因为从每个源获取块可以并行地完成，总延迟将是它们之中的最大延迟。如果预期网络将引起最高延迟，则ILS过程600在步骤6 停止，因为不可能进行进一步有成效的调度。当盘延迟占主导时，ILS过程600可以通过从网络获取一些块而使其减少。ILS过程600选择最小的块，因为其减少了一个盘寻找延迟而增加了最小网络延迟。如图7中所示，ILS过程600对所估计的延迟进行更新，并且重复该过程直到延迟得到均衡。在完成ILS过程600之后，R-Waprox 220将块请求消息分发到对应的对等端。为了避免可能的队头(HOL)阻塞，R-Waprox 220以请求在候选者列表中出现的顺序来发送请求。注意，ILS过程600适用于MRC和SRC 二者。然而，通过能够将最小块从盘队列移动到网络队列(如图7中所示)，MRC可以比SRC更加减少盘延迟，这导致更小的总延迟。因而，ILS过程600在与MRC相结合时提供更好的总盘性能及压缩，以及有效带宽中的大幅增加。例如，图8分别图示了使用与SRC相比的MRC技术，在两种类型的工作量动态生成的Web内容以及冗余大文件上的理想带宽节省和实际带宽节省。该结果由实现所有上述 Waprox设计的仿真器所生成。对于动态生成的Web内容(图8a)，仿真器选择多个热门新闻站点。仿真器每5分钟获取首页并且测量获取之间的冗余。为了模拟冗余的大文件(图 8b)，仿真器一次一个地下载两个不同版本的Lunix内核源tar文件2. 6.沈.4和2. 6. 26. 5， 并且还收集分组级踪迹。每个tar文件的大小大约为276MB，并且两个文件有94%的冗余。如所期望的那样，理想带宽节省随着块大小减小而增加。然而，由于块索引编制元数据传输开销，在256字节块大小的情况下，利用SRC的实际节省的峰值在新闻站点上具有 58%的带宽节省，并且在Linux内核上具有拟％的带宽节省。带宽节省随着块大小的进一步减小而下降，并且当块大小为32字节时，实际节省在新闻站点上仅为25%并且在Linux内核上仅为36%。在另一方面，无论最小块大小如何，MRC方法均接近理想节省。对于32字节的最小块，其在两个工作量上都实现了接近于最大的节省——在新闻网站上约为66%并且在 Linux内核上约为92%。这是因为MRC在任何可能的时候都使用较大的块并且块名称提示显著减少了元数据传输开销。当将最佳压缩率进行比较时，MRC的有效带宽在Linux内核上高于SRC的有效带宽125%，而其在新闻站点上显示出24%的改进。如果我们着眼于图9中所示的、针对每个配置的盘I/O的输了，MRC的减少的每块索引编制开销变得更加清楚。SRC的盘获取成本随着块大小减小而大幅增加，从而使得小块的使用对于SRC几乎不可能。甚至在小块大小时，MRC也需要少得多的盘操作。当叶节点块大小为32字节时，SRC在新闻站点上执行8. 5倍那么多的盘操作(图9a中所示)，而在 Linux内核上更多至22. 7倍(图9b)。存储器压力直接限制WAN加速器可以以高速服务的高速缓存的量以及其所需的用于该存储的存储器量。图IOa和图IOb将利用不同组块方法的存储器占用进行了比较。 仿真器对仿真期间所使用的块索引条目的数量进行计数，并且计算实际的存储器占用。每个条表示存储器占用(MB)。每个条顶部之上的数字以千为单位显示出所使用的高速缓存条目的数量。由于空间约束，仿真器仅示出了具有程度2的MRC树，但是其他结果遵循相同的趋势。MRC招致比SRC所招致的少得多的存储器压力，因为MRC针对任意大的块而需要一个高速缓存条目，而SRC针对相同内容则需要若干个块条目，因此。然而，小MRC甚至需要比SRC所需要的更多的高速缓存条目，因为重建较大块需要对其所有的子条目进行访问。 在32字节块大小的情况下，小MRC针对Linux内核消耗几乎300MB，而MRC仅需要大约10 MB用于高速缓存条目。大MRC显示出与MRC类似的高速缓存条目数量。然而，因为每个子块具有到其父亲的反向指针，所以大MRC的实际存储器消耗比MRC差得多。大MRC在新闻工作量上消耗几乎为MRC两倍那么多的存储器。虽然MRC在不牺牲盘性能的情况下保持高带宽节省，但是其由于增加的块数量而在指印及哈希计算中消耗更多的CPU周期。图11示出了用于在来自IOMB文件的一个平均大小为64KB的块上运行Rabin指印算法和SHA-I的平均时间。Rabin指印被证明仍然是相当昂贵的，花费比SHA-I多三倍的时间。然而，总计SHA-I成本随着MRC的叶块大小的减小而增加。如果朴素地实现，则具有高度η的MRC树的总CPU成本将是每级的η X Rabin指印时间+SHA-I计算的总和。在一些实施方式中，可以对S-Waprox 230和R_Waprox220 二者应用两个一般优化。第一，Waprox可以仅对内容运行一次Rabin指印，检测最小块边界，并且从它们中导出较大的块边界。第二，Waprox仅在必要时使用块名称提示来计算SHA-I哈希。例如，如果 S-Waprox 230知道该块在先前已被发送到R-Waprox 220，则S-Waprox 230假设其所有孩子已经在R-Waprox 220中并且仅发送父亲的名称。同样地，如果R-Waprox 220知道块先前已被存储于盘上，则其不重新存储该块的孩子。此外，R-Waprox 220可以利用特定优化来实现。例如在一个实施方式中，当顶级块对于R-Waprox 220未中但是在MRC树中的较低级中存在一些块命中时，R-Waprox 220 仅需要对高速缓存未中的候选者列表块运行指印。为了对此作出支持，R-Waprox 220现在连同每个块名称提示一起存储Rabin指印值(8字节)。如果候选者列表中的块是高速缓存命中，则R-Waprox 220可以检索针对该块的指印值。如果块是高速缓存未中，则R-Waprox 220运行指印功能以找到和存储任何更小的块。R-Waprox 220现已知道针对候选者列表中所有块的Rabin指印值，因此R-Waprox 220还可以重建任何父亲而无需对高速缓存命中块运行指印。现在参考图12和图13，呈现了流程图和示意图，该流程图和示意示了根据说明性实施方式的、用于对来自高速缓存的数据进行存储及检索的、在此称为HashCache的过程1200。HashCache是设计用于在负担不起存储器的情况下(比如在发展中国家中)满
17足对高速缓存存储的需求的可配置高速缓存存储引擎。HashCache提供了与网络高速缓存设计中传统看法的彻底脱离，并且使用比当前技术少6倍到20倍的存储器而仍然提供可媲美的或者更佳的性能。如将要进一步描述的那样，HashCache的一些实施方式，例如 HashCache-Basic (图12和图13中所示)和HashCache-Set (图13和图14中所示)，不使用主存储器来进行索引编制并且获得可与诸如Squid Web代理高速缓存之类的传统软件解决方案相比的性能。最高性能策略，HashCache-Log (图18和图19中所示)，与商用高速缓存设备等同地执行，而使用仅为它们大小的十分之一的主存储器索引。在这些策略之间的是不同策略的范围，例如，HashCache-ktMem (图16和图17中所示)，其以存储器消耗来交换适合于发展中地区中的工作量范围的性能。除了具有低资源消耗的良好性能以外，HashCache提供适合于发展中世界使用的多个附加的益处(a)许多HashCache可以被定制以与系统活动而不是高速缓存大小成比例地使用主存储器；(b)不同于商用高速缓存设备，HashCache不需要是在机器上运行的单独应用；(c)通过简单地选择适当的索引编制方案，相同的高速缓存软件可被配置成适于小教室的低资源最终用户高速缓存，以及用于更高级别网络的高性能骨干高速缓存；(d) 在其最低存储器配置中，HashCache可以在(例如，经由USB)附接至外部多倍百万兆字节存储的膝上级硬件上运行，对于现有设计甚至不可能的场景；以及(e) HashCache提供灵活的高速缓存层，从而允许其不仅用于Web代理，而且还用于其他面向高速缓存的存储系统。例如，具有1百万兆字节(TB)大小的HashCache的web代理可以提供允许对范围宽泛的流量进行高速缓存的大HTTP存储。此外，web代理可以在非高峰时段中推测性地预加载内容。 另外，这类系统可以从仅拥有256MB的总RAM的低级膝上型计算机进行驱动。在部署中，一个这样的膝上型计算机可以针对其余的膝上型计算机充当高速缓存服务器，因此消除了对单独的服务器级硬件的需求。与其他Web高速缓存相比，利用单个ITB驱动器，如在Squid 的情况中，单独的存储器中索引就将超过10GB。因此，HashCache可以部署在对于当前方法而言不可达到的配置中，诸如具有附接至低功率机器的多倍百万兆字节的外部存储高速缓存。参考图12，过程1200实现了 HashCache-Basic，HashCache族中最简单的设计选项，这完全移除了存储器中索引。过程1200可以由用于维护对象高速缓存的上文所公开的通用WAN加速器、web代理和/或Waprox设备来实现。此外，过程1200可由其他应用/设备利用，以对任何类型的数据进行高速缓存。过程1200在其中辅助存储被布置以包括连续区块的表1302 (即，其中在每个二进制目标文件(bin)中存储的具有一个对象的固定大小的非链式哈希表)以及常规文件系统或日志结构的文件系统1303 (如在图13中所描绘的实施方式中所示)的环境中执行。日志结构文件系统将其存储当作循环日志，并且按顺序向日志的头部进行写入。这通过避免昂贵的盘寻找而使磁介质上的写入吞吐量最大化。过程1200通过接收关联于标识符(例如，网站的URL 1304)的数据请求而在步骤 1202处开始。在步骤1204中，该过程对标识符进行哈希以生成哈希值1306。所有或一部分生成的哈希值1306标识连续区块的表1302中的区块位置1308。在步骤1206中，该过程读取存储在连续区块的表1302中的区块位置1308中的数据(如果有的话)。在步骤1208中， 该过程确定在区块位置1308内是否存在文件。在本文及图中所使用的术语“文件”指代完整文件、部分文件、对象、URL或者高速缓存的实体。如果文件作为块位置1308存在(例如，文件1310)，则该过程在步骤1210中对存储在所存储文件的头部中的标识符(例如，URLJi 象名称或者其一部分)进行比较，以在步骤1212中确定其是否与关联于数据请求的标识符相匹配(即，文件命中)。如果其为文件命中，则在步骤1214中，该过程在步骤1214中确定该文件是否包含未存储在连续区块的表1302中的确定区块位置中的附加数据(例如，1312)。 任何附加部分的位置可以由存储在表中确定区块位置中的文件/对象的元数据来标识。如果对象的元数据指示出存在任何附加部分，则该过程在步骤1216中从辅助存储中的常规文件系统或日志文件系统1303检索该附加部分/数据。在步骤1218中，该过程返回检索到的文件/对象。然而，如果该过程在步骤1208中确定文件不存在于区块位置1308内，或者在步骤 1212中确定所请求数据的标识符与区块位置1308处存储的标识符不匹配，则该过程在步骤1220中从远程源(例如，内容提供设备M0)请求所请求的数据/对象。在步骤1222中， 该过程在表1302中的区块位置1308中存储或覆写检索到的数据。如果在步骤12M中该过程确定检索到的数据大于区块位置1308的块/ 二进制目标文件大小，则该过程在步骤 1226中将附加数据存储在常规文件系统中或者将附加数据写入到日志文件系统1303的开始处。在步骤12 中，该过程将存储在常规文件系统或日志文件系统中的附加部分的位置信息添加到存储在区块位置1308处的对象的元数据/头部。该过程在步骤1218中返回检索到的文件/对象。HashCache-Basic与高性能高速缓存相比的性能影响在于，HashCache-Basic将在哈希冲突中有所增加(降低了高速缓存命中率)并且将在每次请求时，甚至在高速缓存未中时需盘访问。此外，存储对象将需要每个对象一次寻找(由于哈希使位置随机化)并且可能需要到循环日志的附加写入。HashCacheIet是HashCache族的另一实施方式，其通过扩展盘表以成为N路集合关联性哈希表而减少哈希冲突，其中每个二进制目标文件可以储存N个元素(如图15中所示，盘表1502)。在HashCache-Set中，映射到集合上的对象/URL可被置于该集合中的任何位置。因为位置在盘上是连续的，并且因为短读取具有比寻找低得多的延迟，所以读取集合的所有成员仅花费比只读取一个元素略多的时间。每个元素仍然包含具有对象的任何其余部分的完全对象名称、大小以及在循环日志1503和/或常规文件系统中的位置。参考图14，过程1400图示了 HashCache-Set的实现。过程1400通过接收关联于标识符/对象名称(例如，网站的URL 1504)的数据请求而在步骤1402处开始。在步骤1404 中，该过程对标识符进行哈希以生成哈希值1506。所有或一部分生成的哈希值1506标识盘表1502中的集合1508。在步骤1406中，该过程对集合1508内的每个元素/区块的元数据进行读取，直到该过程在步骤1408确定匹配的标识符。如果该过程在集合的区块内找到匹配，则该过程在步骤1410中从所标识的区块检索文件1510。在步骤1412中，该过程从文件 1510的头部或元数据确定文件1510是否包含未在盘表1502的集合1508内的确定区块位置中存储的附加数据(例如，1512)。如果文件的元数据指示存在未以集合1508存储的附加部分，则该过程在步骤1414中从辅助存储的常规文件系统或日志文件系统1503检索附加部分/数据。在步骤1416中，该过程对文件的最近最少使用(LRU)的数据进行更新。LRU 数据被用于确定当没有空区块可用于集合内的新条目时将集合内的哪个文件/区块覆写。 尽管上述过程替换了最近最少使用(LRU)，但其他高速缓存替换策略(诸如但不限于最不常用(LFU))可以被实现于本文所描述的任何HashCache实现中。该过程在步骤1418中返回检索到的文件/对象。如果该过程在步骤1408中未在集合内的任何区块内找到匹配的标识符，则该过程在步骤1420中从远程源请求所请求的数据/对象。在步骤1422中，该过程确定在盘表 1502的集合1508内是否存在空区块用于存储检索到的数据。如果集合具有空区块，则该过程在步骤14M中将检索到的数据存储在集合1508内的空区块位置(例如，区块1516)中。 如果该过程确定集合1508不包含任何空区块，则该过程在步骤1似6中利用新检索到的数据来覆写与集合内的其他区块相比具有最近最少使用(LRU)数据的区块的数据。如果该过程在步骤14 中确定检索到的数据大于集合内的区块的区块大小，则该过程在步骤1430 中将附加数据存储在常规文件系统(未示出)中或者将附加数据写入到日志文件系统1503 的开始。在步骤1432中，该过程将存储在常规文件系统或日志文件系统1503中的附加部分的位置信息添加到存储于集合内的区块位置处的对象的元数据/头部。如果该过程尚未这样做，则在步骤1416中，该过程对存储在集合1508的区块中的文件/对象的最近最少使用(LRU)数据进行更新。该过程在步骤1418中返回检索到的文件/对象。在不使用存储器中索引的情况下，上述过程1400 (HashCache-kt)减少了映射到相同哈希二进制目标文件的热门对象的影响，而仅略微增加了用以访问对象的时间。虽然 HashCache-Set消除了起源于哈希二进制目标文件中冲突的问题，但其仍然具有若干个问题。第一，HashCacheIet需要针对高速缓存未中的盘访问。第二，HashCache-Set缺乏用于在集合内进行高速缓存替换的高效机制。使用盘上机制来实现集合内的LRU之类的事情将需要关于每个高速缓存命中的潜在盘写入，因此降低了性能。需要盘寻找来确定高速缓存未中对于具有低高速缓存命中率的工作量而言是一个主要问题，因为无索引高速缓存将花费大多数其盘时间来确认高速缓存未中。该行为将对最终用户增添额外的延迟，并且不提供益处。为了解决需要寻找高速缓存未的问题，图16和图17呈现了公开的HashCache族的另一实施方式dashCache-ktMem，其实现存储器中索引，但是采用若干种优化来保持该索引比传统方法小得多。例如，HashCache-ktMem所采用的一种优化技术是在主存储器中存储针对每个被高速缓存的对象的H比特哈希值(例如。每个对象8个最高有效哈希比特)。 这些哈希值可以存储在二维矩阵1702中，该二维矩阵1702对应于盘表1704，其中一行针对每个二进制目标文件，并且N个列对应于N路关联性。LRU高速缓存替换策略将需要每个对象的前向指针和反向指针来维持LRU列表，从而在假设32比特指针的情况下带来(H+64) 比特的每对象存储器成本。然而，HashCache-ktMem如下减少了该存储。第一，我们注意到N条目集合中的所有条目共享相同的模数哈希值(％S)，其中S是盘表1704中集合的数量。HashCache-ktMem无损地从每个哈希值中丢弃最低的Iog^比特，从而将哈希存储减少到每对象仅H - Iog(S)比特。第二，HashCacheIetMem通过从0到N-1对条目进行简单地排列来实现LRU，因为高速缓存替换策略仅需要在N条目集合内实现，从而，每个条目仅使用Iog(N)比特。第三，在一些实施方式中，HashCache-ktMem可以仅针对一些集合而非所有集合保留存储器中索引，因此基于请求率而非高速缓存大小来约束存储器中条目的数量。该方法在下文中称为HashCache-ktMemLRU，其以LRU方式保留集合并且按需从盘获取针对集合的存储器中索引。通过仅保留部分集合，HashCache-ktMemLRU需要对保留对每个集合的二进制目标文件号、每集合的LRU指针以及哈希表，以在存储器中找到给定集合。决定何时使用HashCacheIetMem对HashCache-SetMemLRU取决于哈希值的大小以及集合关联性。例如，假设8路关联性以及每对象8个最高有效哈希比特，平衡点(break-even point)为大约50%——一旦将在存储器中存储半数以上的集合，则移除LRU指针和二进制目标文件号而仅保留所有集合(S卩，使用HashCache-ktMem代替 HashCache-SetMemLRU)更加廉价。利用低哈希冲突率，HashCache-SetMem可以在不访问盘的情况下确定更多的高速缓存未中，而HashCache-ktMemLRU具有其可调存储器消耗，将需要针对未中的一些部分进行盘访问。然而，一旦集合处于存储器中，执行集合内高速缓存替换决策就无需针对策略维护进行盘访问。向盘写入对象仍将需要盘访问。现在参考图16和图17，过程1600说明了 HashCacheIetMem的实现。过程1600 通过接收关联于标识符/对象(例如，网站的URL 1706)的数据请求而在步骤1602处开始。 在步骤1604中，该过程对标识符进行哈希以生成哈希值1708。所有或一部分生成的哈希值 1708标识存储在存储器中的二维矩阵1702中的集合1710，该二维矩阵1702对应于存储在辅助存储中的盘表1704。在步骤1606中，该过程对二维矩阵1702的集合1710内的每个元素的元数据进行读取，直到该过程在步骤1608中找到匹配的标识符或者直到集合1710内的所有元素均已被检查。如果该过程在集合1710的区块内找到匹配，则该过程在步骤1610 中从辅助存储中的盘表1704的对应集合1714检索文件1712。在步骤1612中，该过程从文件1712的头部或元数据确定文件是否包含未在盘表1704中存储的附加数据1716。如果文件的元数据指示存在未利用盘表1704存储的附加部分，则该过程在步骤1614中从辅助存储中的常规文件系统或日志文件系统1718检索附加部分/数据。在步骤1616中，该过程对文件/集合的最近最少使用(LRU)数据进行更新。该过程在步骤1618中返回检索到的文件/对象，并且过程1600在此后终止。如果该过程在步骤1608中未在集合内的任何区块内找到匹配的标识符，则该过程在步骤1620中从远程源请求所请求的数据/对象。在步骤1622中，该过程确定在盘表 1704的集合1714内是否存在空区块用于存储检索到的数据。如果集合具有空区块，则该过程在步骤16M中将检索到的数据存储在集合1714内的空区块位置(例如，区块1720)中。 如果该过程确定集合1714不包含任何空区块，则该过程在步骤16 中利用新检索到的数据来覆写与集合1714内的其他区块相比具有最近最少使用(LUR)数据的区块的数据。如果该过程在步骤16 中确定检索到的数据大于集合1714内区块的区块大小，则该过程在步骤1630中将附加数据存储在常规文件系统(未示出)中或者将附加数据写入到日志文件系统1718的开始。在步骤1632中，该过程将文件的位置信息和其他标识信息添加到在主存储器中的集合1710内存储的元数据。如果该过程尚未这样做，则在步骤1616中，该过程对存储于集合1714的区块中的文件/对象的最近最少使用(LRU)数据进行更新。该过程在步骤1618中返回检索到的文件/对象。使用HashCache-ktMem，高速缓存命中针对小文件需要一个寻找，并且如果关联集合的元数据在存储器中，则高速缓存未中无需寻找(排除来自哈希冲突的假阳性)。因为对象位置由它们的哈希值规定，因此高速缓存写入仍然需要寻找，从而将性能劣势的 HashCache-ktMem留给了可将所有内容写入循环日志的高性能高速缓存。该性能问题对于具有低请求率的高速缓存不是问题，但是对于更高请求率工作量将成为问题。
21
为了解决该问题，我们引入图18和图19中所示的新的策略HashCache-Log，其消除了盘表(例如，盘表1704)并且与高性能高速缓存类似地将盘当作日志1902。对于一些或者所有对象，HashCache-Log对指定盘上位置的附加偏移(32比特或64比特)进行存储。 HashCache-Log保留具有N路集合关联性和每集合LRU替换的存储器中索引1904，因为它们以紧凑的实现消除了针对高速缓存未中的盘寻找。虽然该方法显著增加了存储器消耗， 但其也可以产生大的性能优势，因此该权衡在许多情况下是有用的。然而，甚至在添加日志位置时，存储器中索引1904仍然比传统高速缓存小得多。例如，对于8路集合关联性，每集合LRU需要每条目3个比特，并且每条目8个比特可以最小化集合内的哈希冲突。添加32 比特日志位置将每条目大小从11比特增加到43比特，但是事实上消除了写入流量的影响， 这是因为现在所有的写入都可以被累积并且在一个盘寻找中被写入。此外，HashCache-Log 需要几个比特(假设为4个)来记录日志生成号，从而将总数推向47比特。甚至是每条目 47比特，HashCache-Log仍然使用是当前的高性能代理的6_12分之一那么小的索引。如果HashCache-Log利用在其中一半的对象极少被再次引用(如果有的话)的Web 对象热门程度，则HashCache-Log甚至可以进一步减少该开销。在该情况下，HashCache-Log 可以从存储器中索引丢弃一半的日志位置，并且只将它们存储在盘上，从而以性能中很小的损失将平均条目大小减少到仅31比特，在下文中称之为HashCache-LogLRU。HashCache-LogLRU允许对每集合日志位置条目的数量进行配置，通常每N对象集合使用N/2个日志位置。集合中的其余日志偏移作为小的连续文件存储在盘上。将该文件与存储器中索引1904保持同步需要几个写入，这少量降低了性能。在该情况下，存储器中索引大小1904比传统高性能系统小9-20倍。图18和图19图示并示意性地描绘了实现HashCache-Log的过程1800。过程1800 通过接收关联于标识符/对象名称(例如，网站的URL 1906)的数据请求而在步骤1802处开始。在步骤1804中，该过程对标识符进行哈希以生成哈希值1908。所有或者一部分生成的哈希值1908标识存储器中索引1904中的集合1910。在步骤1806中，该过程对存储器中索引1904的集合1910内每个元素的元数据进行读取，直到该过程在步骤1808中找到匹配的标识符或者直到集合1910内的所有元素均已被检查。如果该过程在集合1910的区块内找到匹配，则该过程在步骤1810中确定所请求数据的位置(即，标识用于从辅助存储中的日志1902检索数据的偏移)。在步骤1812中，该过程从日志1902上的经确定位置检索所请求的数据(例如，数据1912)。在步骤1814中，该过程对存储器中索引1904中的文件/ 集合1910的最近最少使用(LRU)数据进行更新。该过程在步骤1816中返回检索到的文件 /对象。如果该过程在步骤1808中未在存储器中索引1904中的集合1910内的任何区块内找到匹配的标识符，则该过程在步骤1820中从远程源请求所请求的数据/对象。在步骤 1822中，该过程将检索到的数据写入到连续区块中日志1902的头部。该过程将文件的位置信息和其他标识信息添加到存储于存储器中索引1904的集合1910内的元数据。如果该过程尚未这样做，则在步骤1814中，该过程对存储器中索引1904中文件/集合1910的最近最少使用(LRU)数据进行更新。该过程在步骤1816中返回检索到的文件/对象。使用以上所述的HashCache优化，高速缓存存储可以针对小对象需要低至每对象 1个寻找，而没有高速缓存未中的代价，并且事实上没有分批在一起并写入到循环日志末端的高速缓存写入的成本。然而，通过注意到每读取预获取多个对象可以平摊每对象的读取成本，甚至可以进一步改进该性能。例如，相关访问可能出现在像Web页面之类的情况中， 其中在页面的HTML中可以嵌入多个小对象，从而导致许多对象在一小段时间中被一起访问。将这些对象在盘上分组在一起将减少用于读取及写入的盘寻找。这些页面的其余区块可以在日志中全都被合并在一起并且被一起写入，使得对它们进行读取可以更快，理想的是利用一个寻找。为了支持该策略所需的仅有改变是(在区块中)保存同时写入的所有相关内容的内容长度，使得可以在一个寻找中对其一起读取。当多个相关对象被一起读取时，系统将平均以每个读取一个以下的寻找来执行读取。该方法可以应用于许多先前描述的 Hash-Cache策略，并且仅需要使用HashCache的应用提供对象关于其相关的一些信息。假设不多于256个区块的预获取长度，该策略仅需要每个正被读取的索引条目8个比特。在 HashCache-LogLRU的情况中，仅具有存储器中日志位置信息的条目需要附加的长度信息。 否则，该长度也可以存储在盘上。作为结果，假设每个集合的一半的条目包含日子位置和预获取长度，向HashCache-LogLRU添加该预获取仅将存储器中索引大小增加到每对象35比特。图20图示了对以上所公开的各种版本的HashCache进行比较的表。如在图20中可见，许多HashCache策略使用可以使用256MB或者更少来高速缓存TB大小的盘。甚至是更多存储器消耗的HashCache策略也针对TB大小的盘使用小于IGB的存储器，同时提供与任何当前商用产品相同或者比其更好的性能。相比之下，商用产品针对TB盘高速缓存需要从4GB到13GB不等的存储器。因此，HashCache可以部署在对于当前方法而言不可达的配置中，诸如通常在第三世界国家中找到的低功率机器上。图21是描绘不同的HashCache策略与商用web代理高速缓存产品相比的吞吐量含义。最大请求率(rr)是盘寻找率、命中率、未中率以及写入率的函数。需要写入率是因为并非所有由于高速缓存未中而被获取的对象都是可高速缓存的。图21呈现了作为这些参数的函数的每个系统的吞吐量。高速缓存命中率(chr)简单地为介于0与1之间的数字，可高速缓存率(cbr)也是如此。由于未中率为(1 - chr)，因此写入率可以表示为(1 -chr) -Cbr0峰值盘寻找率(t)是硬件依赖的测量量，并且相关对象的平均数量(rel)总是正数。这些吞吐量是保守估计，其不考虑存储器中的热对象高速缓存，其中主存储器中的一些部分被用作针对频繁使用对象的高速缓存，这可以进一步改进吞吐量。使用所描绘的吞吐量估计，HashCache-LogLRU和HashCache-Log (二者都具有读取预获取)提供不亚于最佳商用产品的相同吞吐量。例如，利用SATA型7200 RPM硬盘驱动器，HashCache-LogLRU、 HashCache-Log以及商用产品具有沈4 (请求/秒)的估计吞吐量。吞吐量对于所有三者而言增加是相同的，对于以10，000RPM旋转的SCSI型驱动器增加到340 (请求/秒)，并且对于以15，000RPM旋转的SCSI型驱动器增加到560 (请求/秒)。因此，HashCache可以提供可与任何当前设计相比的吞吐量而使用显著较少的存储器。现在参考图22，其呈现了图示各种HashCache策略与Squid (—种开源web代理高速缓存产品)和Tiger (—种商用web代理高速缓存产品)相比的针对单盘实验的资源使用的图表。在所有情况中，盘均为最终的性能瓶颈，其具有接近100%的利用。用户及系统 CPU保持相对低，其中较高系统CPU水平关联于具有较高请求率的配置。然而，最令人惊讶
23的度量是Squid的高存储器使用率。即便其存储大小仅为HashCache所使用的存储大小的三分之一，其仍然超过HashCache的最高性能配置中HashCache的存储器使用。相比之下， 最低性能HashCache配置具有可与Squid相比的性能，而在存储器使用方面则几乎不值一提。从前文中应当明白，已提供了具有显著优势的发明。以上公开内容描述了要求保护的发明的某些实施方式，并且并不旨在对要求保护的发明的范围进行限制。此外，所公开的实施方式在上文中是参考流程图示、序列图和/或框图进行描述的。流程图示和/或框图的每个框，以及流程图示和/或框图中框的组合可以通过计算机程序指令、硬件组件和/ 或其任何组合来实现。此外，图中的流程图和框示了根据所要求保护的发明的各种实施方式的系统、方法和计算机程序产品的可能实现的架构、功能性和操作。就此而言，流程图或框图中的每个框可以表示代码的模块、片段或者部分，其可以包括用于实现(一个或多个)特定逻辑功能的一个或多个可执行指令。在一些替代实现中，框中所指出的功能可以不按图中所指出的顺序发生，和/或被省略。此外，根据所涉及的功能性，被连续示出的两个框实际上可以基本上同时地被执行，或者框有时可以以反向顺序执行。此外，用于执行所公开的实施方式的计算机程序指令还可以被存储在计算机可读介质中，该计算机可读介质可以引导计算机或者其他可编程数据处理装置以特定方式工作，使得该计算机可读介质中所存储的指令产生包含实现流程图和/或框图的一个或多个框中所指定功能/行动的指令装置的制品。计算机程序指令还可以被加载到数据处理装置上以使得一系列操作步骤在数据处理系统上执行从而产生计算机实现的过程，使得在数据处理系统上执行的指令提供用于实现流程图和/或框图的一个或多个框中所指令功能/行动的过程。本文中所使用的术语仅用于描述特定实施方式，而并不旨在对本发明进行限制。 如本文中所使用，单数形式“一个”、“一种”以及“那个”旨在也包括复数形式，除非上下文另有清楚指明。此外，如在本文中所引用的，模块可以被限定为用于执行特定功能的硬件、 软件和/或其组合。软件被限定为计算机可执行指令，包括但不限于对象代码、汇编代码以及机器代码。硬件可以包括但不限于一个或多个处理器/微处理器、电子电路以及其他物理组件。应当进一步理解，当术语“包括”和/或“包含”等在本说明书和/或权利要求书中使用时，指定所阐述特征、完整物、步骤、操作、元素和/或组件等的存在，但并不排除一个或多个其他特征、完整物、步骤、操作、元素、组件和/或其组的存在。本发明的描述是为了说明及描述的目的而呈现的，而非旨在成为穷举性的或者将本发明限制于公开的形式。在不脱离本发明的范围和精神的情况下，许多修改和变型对于本领域技术人员将明显的。所公开的实施方式被选取用于解释本发明的原理和实际应用， 并且用于使其他本领域技术人员能够针对适合于所设想的特定用途的具有各种修改的各种实施方式而理解本发明。
权利要求
1.一种用于使用第一代理设备的处理器和本地数据存储单元对数据网络上的数据检索进行加速的方法，所述方法包括由所述第一代理设备接收对于从最终用户设备向源数据设备发送的数据的请求；由所述第一代理设备建立与第二代理设备的连接，所述第二代理设备与所述源数据设备进行通信；由所述第一代理设备将对于所述数据的所述请求传输到所述第二代理设备，所述第二代理设备将所述请求转发到所述源数据设备并且从所述源数据设备接收所述数据；由所述第一代理设备接收与由所述第二代理设备从所接收的数据生成的多个数据块对应的多个块名称；使用所述第一代理设备的处理器来确定所述本地数据存储单元是否包含使用所述多个块名称的所述多个数据块中的一个或多个；响应于对所述本地数据存储单元不包含与所述多个块名称关联的所述多个数据块中的一个或多个的确定，确定用于对关联于所述多个块名称的所述多个数据块进行检索的优化检索调度；以及响应于基于所述优化检索调度对关联于所述多个块名称的所述多个数据块进行检索， 将所述数据提供给所述最终用户设备。
2.根据权利要求1所述的方法，还包括响应于对所述本地数据存储单元不包含与所述多个块名称关联的所有所述多个数据块的确定，从所述第二代理设备请求与所述多个数据块关联的非本地存储的数据块中的至少一个；以及响应于接收来自所述第二代理设备的所述非本地存储的数据块中的至少一个，将所述非本地存储的数据块中的至少一个存储在所述本地数据存储单元中。
3.根据权利要求1所述的方法，还包括响应于对所述本地数据存储单元不包含与所述多个块名称关联的所有所述多个数据块的确定，从本地对等设备请求与所述多个数据块关联的非本地存储的数据块中的至少一个；以及响应于从所述本地对等设备接收所述非本地存储的数据块中的至少一个，将所述非本地存储的数据块中的至少一个存储在所述本地数据存储单元中。
4.根据权利要求1所述的方法，还包括响应于对所述本地数据存储单元不包含与所述多个块名称关联的所有所述多个数据块的确定，向所述第二代理设备传输对于与所述多个数据块关联的非本地存储的数据块中的至少一个的第一请求，以及向本地对等设备传输对于与所述多个数据块关联的所述非本地存储的数据块中的至少另一个的第二请求，其中所述第一请求和所述第二请求并行执行。
5.根据权利要求1所述的方法，还包括由所述第一代理设备向所述第二代理设备传输块确认消息以指示所述数据到所述最终用户设备的成功传输。
6.根据权利要求1所述的方法，还包括响应于关闭所述最终用户设备与所述第一代理设备之间的连接，由所述第一代理设备向所述第二代理设备传输关闭连接消息以通知所述第二代理设备关闭其与所述源数据设备的连接。
7.根据权利要求1所述的方法，其中所述最终用户设备与所述第一代理设备之间的第一连接是低带宽连接，并且所述第二代理设备与所述源数据设备之间的第二连接与所述低带宽连接相比为高带宽连接。
8.根据权利要求1所述的方法，其中所述本地数据存储单元包括多个数据存储单元。
9.根据权利要求1所述的方法，其中所述第二代理设备生成所述多个数据块，以产生共存的不同大小的数据块的层级。
10.根据权利要求9所述的方法，其中生成共存的不同大小的数据块的所述层级包括 通过使用全局常数^来确定对齐的边界的初始集合用于针对所有块大小的边界检测； 改变用于每个级别的比特的数量&使得使用最低(n + m)个比特的较高级别具有作为使用η个比特的较低级别的子集的边界；以及通过使用最小块大小执行内容指印来确定较高级别边界；以及响应于对所述较高级别边界的确定，合并比最小大小小的块。
11.根据权利要求1所述的方法，其中由所述第一代理设备接收的所述多个块名称对应于由所述第二代理设备生成的所述多个数据块的部分列表。
12.根据权利要求11所述的方法，还包括所述第二代理设备通过从所述多个数据块的所述部分列表移除所述第二代理设备先前已遇到的数据块的名称来生成所述多个数据块的所述部分列表。
13.根据权利要求12所述的方法，还包括所述第二代理设备通过在所述多个数据块的所述部分列表上保留所述第二代理设备先前尚未遇到的数据块的名称来生成所述多个数据块的所述部分列表。
14.根据权利要求1所述的方法，还包括响应于对所述本地数据存储单元不包含与所述多个块名称关联的所有所述多个数据块的确定，由所述第一代理设备向多个本地对等设备分发对于与所述多个数据块关联的非本地存储的数据块中的至少一个的请求；以及响应于从所述多个本地对等设备接收所述非本地存储的数据块中的至少一个，将所述非本地存储的数据块中的至少一个存储在所述本地数据存储单元中。
15.根据权利要求1所述的方法，其中确定用于对所述多个数据块进行检索的所述优化检索调度还包括将从所述第二代理设备请求本地存储的数据块的网络获取延迟与从所述本地数据存储单元和本地对等设备中的至少一个检索所述本地存储的数据块的盘获取延迟进行比较；响应于所述网络获取延迟小于所述盘获取延迟，从所述第二代理设备请求最小的本地存储的数据块；以及对所述网络获取延迟和所述盘获取延迟进行更新；以及重复比较、请求和更新步骤，直到所述网路获取延迟与所述盘获取延迟均衡。
16.根据权利要求1所述的方法，其中所述第一代理设备根据权利要求20所述的方法来组织所述本地数据存储单元。
17.根据权利要求1所述的方法，其中所述第一代理设备根据权利要求22所述的方法来组织所述本地数据存储单元。
18.根据权利要求1所述的方法，其中所述第一代理设备根据权利要求25所述的方法来组织所述本地数据存储单元。
19.根据权利要求1所述的方法，其中所述第一代理设备根据权利要求四所述的方法来组织所述本地数据存储单元。
20.一种用于存储及检索数据的方法，所述方法包括 布置辅助存储设备以包括连续区块的表和文件系统；对与对于所请求文件的数据请求关联的标识符进行哈希以生成标识所述表内的位置的哈希值；读取所述表内的所述位置以确定现有文件是否位于所述位置处； 响应于对现有文件位于所述位置处的确定，确定所述现有文件是否包含与所述数据请求关联的所述标识符的匹配标识符；响应于对所述现有文件包含与所述数据请求关联的所述标识符的匹配标识符的确定， 确定所述现有文件是否包括存储在所述文件系统上的附加数据；响应于对所述现有文件包括存储在所述文件系统上的附加数据的确定，从所述文件系统检索所述附加数据；以及将所述所请求文件返回给请求所述数据的设备。
21.根据权利要求20所述的方法，还包括响应于对现有文件不位于所述表内的所述位置处或者所述表内的所述位置处的所述现有文件不包含与所述数据请求关联的所述标识符的所述匹配标识符的确定，从远程设备请求所述所请求文件；响应于从所述远程设备接收所述所请求文件，将所述所请求文件写入由所述哈希值标识的所述表内的所述位置；将大于所述表内的所述位置的附加数据写入到所述文件系统；对所述所请求文件的元数据进行更新以指示所述所请求文件的所述附加数据的位置；以及将所述所请求文件返回给请求所述数据的所述设备。
22.一种用于存储及检索数据的方法，所述方法包括布置辅助存储设备以包括具有连续区块的多个集合的表和文件系统； 对与对于所请求文件的数据请求关联的标识符进行哈希以生成标识所述表内的集合的哈希值；确定所述集合内的区块是否包含与所述数据请求关联的所述标识符的匹配标识符； 响应于对所述区块包含与所述数据请求关联的所述标识符的匹配标识符的确定，从所述集合内的所述区块检索所述所请求文件；确定所述所请求文件是否包括存储在所述文件系统上的附加数据； 响应于对所述所请求文件包括存储在所述文件系统上的附加数据的确定，从所述文件系统检索所述附加数据；以及将所述所请求文件返回给请求所述数据的设备。
23.根据权利要求22所述的方法，还包括对使用统计进行更新以指示所述集合内存储的文件何时被最后检索。
24.根据权利要求23所述的方法，还包括响应于对所述集合不包含与所述数据请求关联的所述标识符的匹配标识符的确定，从远程设备请求所述所请求文件；响应于从所述远程设备接收所述所请求文件，确定由所述哈希值标识的所述集合是否具有空区块；响应于所述集合具有所述空区块，将所述所请求文件写入到所述空区块； 响应于所述集合不具有所述空区块，利用所述所请求文件覆写所述集合内选择的区块，基于所述集合的所述连续区块中的所述使用统计来选择所述选择的区块；响应于所述所请求文件大于所述集合内的区块大小，将大于所述区块的附加数据写入到所述文件系统；对元数据进行更新以指示所述所请求文件在所述集合内的存在；以及将所述所请求文件返回给请求所述数据的所述设备。
25.一种用于存储及检索数据的方法，所述方法包括布置辅助存储设备以包括具有连续区块的多个集合的表和文件系统； 在主存储器中布置具有连续区块的所述多个集合的对应表；对与对于所请求文件的数据请求关联的标识符进行哈希以生成标识所述表内的集合的哈希值；确定主存储器中的所述对应表中的所述集合内的区块是否包含与所述数据请求关联的所述标识符的匹配标识符；响应于对主存储器中的所述对应表中的所述集合包含匹配标识符的确定，从所述辅助存储设备上的所述集合内的对应区块检索所述所请求文件；确定所述所请求文件是否包括存储在所述文件系统上的附加数据； 响应于对所述所请求文件包括存储在所述文件系统上的附加数据的确定，从所述文件系统检索所述附加数据；以及将所述所请求文件返回给请求所述数据的设备。
26.根据权利要求25所述的方法，还包括对使用统计进行更新以指示所述集合内存储的文件何时被最后检索。
27.根据权利要求沈所述的方法，还包括响应于对主存储器中的所述对应表中的所述集合不包含匹配标识符的确定，从远程设备请求所述所请求文件；响应于从所述远程设备接收所述所请求文件，确定由所述哈希值标识的所述集合是否具有空区块；响应于所述集合具有所述空区块，将所述所请求文件写入所述空区块； 响应于所述集合不具有所述空区块，利用所述所请求文件覆写所述集合内选择的区块，基于所述集合的所述连续区块中的所述使用统计来选择所述选择的区块； 将大于所述区块大小的附加数据写入所述文件系统；对与主存储器中的所述对应表中的所述集合中的对应区块关联的元数据进行更新，以指示所述所请求文件在所述集合内的位置；以及将所述所请求文件返回给请求所述数据的所述设备。
28.根据权利要求20、21、22以及所述的方法，其中所述文件系统是循环日志文件系统和常规文件系统中的一个。
29.一种用于存储及检索数据的方法，所述方法包括 布置辅助存储设备以包括循环日志文件系统； 在主存储器中布置具有连续区块的多个集合的表；对与对于所请求文件的数据请求关联的标识符进行哈希以生成标识所述表内的集合的哈希值；确定主存储器中的所述表的所述集合中的区块是否包含与所述数据请求关联的所述标识符的匹配标识符；响应于对主存储器中的所述表的所述集合中的所述区块包含与所述数据请求关联的所述标识符的匹配标识符的确定，确定对存储在所述循环日志文件系统上的所述所请求文件的位置进行标识的偏移；从所述辅助存储设备内的所述循环日志文件系统的位置检索所述所请求文件；以及将所述所请求文件返回给请求所述数据的设备。
30.根据权利要求四所述的方法，还包括对使用统计进行更新以指示所述集合内存储的文件何时被最后检索。
31.根据权利要求30所述的方法，还包括响应于对所述集合不包含与所述数据请求关联的所述标识符的匹配标识符的确定，从远程设备请求所述所请求文件；响应于从所述远程设备接收所述所请求文件，将连续区块中的所述所请求文件写入辅助存储中的所述循环日志文件系统的开始处；对与主存储器中的所述集合关联的元数据进行更新以指示所述所请求文件在所述循环日志文件系统上的位置；以及将所述所请求文件返回给请求所述数据的所述设备。
32.根据权利要求20、21、22、24、25、27、四和31所述的方法，其中所述标识符是关联于所述数据请求的统一资源定位符(URL)。
33.根据权利要求20、22、25和四所述的方法，其中从所述文件系统检索数据还包括每次读取预获取多个对象。
34.一种关于提供数据检索的装置，所述装置包括 处理器；数据存储单元；以及存储器，用于存储包括可执行指令的数据，所述可执行指令在由所述处理器执行时执行权利要求1-33所述的方法。
35.根据权利要求34所述的装置，其中所述数据存储单元使用少于256MB的存储器对至少百万兆字节的数据进行高速缓存。
36.根据权利要求34所述的装置，其中所述数据存储单元高速缓存是外部硬盘驱动ο
37. 一种计算机程序产品，其包括计算机可读存储介质，所述计算机可读存储介质具有存储于其上的计算机可读程序，其中当所述计算机可读程序在计算机上执行时，使得所述计算机执行权利要求1-33所述的方法。
全文摘要
本发明所公开的说明性实施方式涉及用于网络加速以及对高速缓存文件系统进行高效索引编制的系统、方法以及计算机程序产品。例如，所公开的实施方式通过引入诸如但不限于多分辨率组块和智能减载之类的新颖特征而实现(1)高压缩率、(2)低磁盘寻找、以及(3)低存储器压力使用。此外，所公开的实施方式引入了支持利用很少的主存储器或者不使用主存储器而允许大尺寸web高速缓存的哈希高速缓存策略族。
文档编号G06F15/16GK102439580SQ201080021877
公开日2012年5月2日 申请日期2010年3月20日 优先权日2009年3月20日
发明者巴达姆 A., 朴 K., L. 彼得森 L., S. 佩 V., 任成桓 申请人:普林斯顿大学托管委员会