CN103038742B - 用于在分布式存储系统内动态复制数据的方法和系统 - Google Patents

Abstract

在分布式存储系统的第一存储子系统处的服务器计算机从客户端接收对对象的第一客户端请求。如果该对象不存在于第一存储子系统中，则服务器计算机将分布式存储系统的第二存储子系统识别为具有所请求的对象的复制品，所请求的对象包括内容和元数据。服务器计算机将对所请求的对象的对象复制请求提交给第二存储子系统，并且从第二存储子系统独立接收所请求的对象的内容和元数据。服务器计算机使用所接收的元数据和内容在第一存储子系统处生成该对象的新的复制品，并且将该对象的新的复制品的元数据返回给客户端。

Description

用于在分布式存储系统内动态复制数据的方法和系统

技术领域

所公开的实施例总体上涉及数据库复制，以及更具体地涉及在分布式存储系统的两个存储子系统之间动态复制数据。

背景技术

对于弱易变数据，在数据的一个实例（或复制品）处的改变或变化必须最终复制到数据库的所有其他实例，但是没有更新必须发生的严格时间限制。这对于不常改变的某些数据来说是适当模型，尤其当在世界各地分布的位置处存在数据库的许多实例时。

在全球范围对大量数据的复制可能是既缓慢又低效的。尤其，长途网络路径具有有限带宽。总的来说，对大片数据的单个改变需要通过网络的有限带宽传输该大片数据。此外，相同大片数据被传输给数据库实例中的每一个，其使带宽使用乘以数据库实例的数量。

另外，网络路径和数据中心有时会失败或变得不可用达一定时间段（用于升级的意外中断以及计划中断两者等）。一般，复制系统不会适度处理这样的中断，通常需要人工干预。当复制基于静态网络拓扑结构，并且某些链路变得不可用或更有限时，基于原始静态网络的复制策略可能是低效或无效的。

根据定义，存储在分布式存储系统内的数据不是在单个位置处，而是跨地理区域乃至全球分布。因此，挑战是，设计在较大分布式存储系统内的优化实时数据复制方案，使得该方案不仅消耗尽可能少的资源，而且改进分布式存储系统所提供的服务。

发明内容

所公开的实施例解决了与跨分布广泛的分布式系统将分布式数据库的数据复制成多个复制品相关联的上面缺陷和其他问题。在所公开的实施例的部分中，对各片数据的改变被跟踪作为改变量（delta），并且改变量被传输给数据库的其他实例，而不是传输该片数据本身。在一些实施例中，读取数据包括读取基础值和任何随后的改变量两者，因此，读取数据的客户端看见更新的值，即使改变量尚未被并入基础数据值。在一些实施例中，数据到其他实例的分发利用网络数据结构来减少跨网络中的长途链路传输的数据量。例如，需要从洛杉矶传输到巴黎和法兰克福两者的数据可以被传输到巴黎，随后从巴黎传输到法兰克福。

依据一些实施例，用于在分布式存储系统内复制对象的计算机实现的方法在一个或多个服务器计算机处实现，所述一个或多个服务器计算机每一个具有一个或多个处理器和存储器。存储器存储用于在每一个服务器计算机上的一个或多个处理器执行的一个或多个程序，该每一个服务器计算机与包括多个存储子系统的分布式存储系统相关联。

在第一存储子系统处的服务器计算机从客户端接收对对象的第一客户端请求。如果该对象不存在于第一存储子系统中，则服务器计算机将第二存储子系统识别为具有所请求的对象的复制品，所请求的对象包括内容和元数据。服务器计算机将对所请求的对象的对象复制请求提交给第二存储子系统，并且从第二存储子系统独立接收所请求的对象的内容和元数据。服务器计算机使用所接收的元数据和内容在第一存储子系统处生成该对象的新的复制品，并且将该对象的新的复制品的元数据返回给客户端。

在一些实施例中，当接收到第一客户端请求时，服务器计算机从第一客户端请求提取所请求的对象的对象ID、使用该对象ID来查询第一存储子系统的元数据表、并且根据查询结果确定该对象是否存在于第一存储子系统中。

在一些实施例中，服务器计算机通过将对所请求的对象的查询发送给第三存储子系统来识别第二存储子系统，并且从第三存储子系统接收响应。第三存储子系统包括存储在多个存储子系统处的对象的元数据。来自第三存储子系统的响应将第二存储子系统识别为源并且将第一存储子系统内的块存储识别为目的地。

在一些实施例中，服务器计算机通过将元数据复制请求提交给第二存储子系统的元数据管理组件来将对所请求的对象的对象复制请求提交给第二存储子系统。元数据复制请求包括所请求的对象的标识符。当从第二存储子系统的元数据管理组件接收了所请求的对象的元数据时，服务器计算机使用所请求的对象的区段表来识别对象内容在第二存储子系统处的位置，并且将内容复制请求提交给第二存储子系统的内容管理组件，内容复制请求包括所请求的对象的所识别的内容位置。在一些实施例中，给予该内容复制请求比不是由实时客户端请求触发的其他内容复制请求更高的优先级。

在一些实施例中，当接收到所请求的对象的元数据时，服务器计算机在第一存储子系统的元数据表中为该对象生成元数据条目，并且将所接收的元数据插入元数据表的新近生成的元数据条目。对于新近生成的元数据条目，服务器计算机将在新近生成的元数据条目中的对象状态属性设置为“正上载（uploading）”，并且将新近生成的元数据条目返回给发出请求的客户端。

在一些实施例中，服务器计算机从客户端接收对访问对象的客户端指定的部分的第二客户端请求。对于从第二存储系统接收的对象的每一个块，如果该块与对象的客户端指定的部分重叠，则服务器将该块返回给发出请求的客户端。另外，服务器计算机将该块的复制品存储在第一存储子系统内，并且对第一存储子系统中的元数据条目进行更新以反映该块在第一存储子系统内的存在。

在一些实施例中，服务器计算机通过为每一个所接收的块生成元数据更新，来对第一存储子系统中的元数据条目进行更新，元数据更新包括该块在第一存储子系统内的位置信息，并且使用该块的位置信息来对元数据条目的区段表进行更新。如果对象的多个块位于第一存储子系统的一个块存储内，则服务器计算机将元数据条目的对象状态属性更新为“已终态化（finalized）”，以及如果对象的多个块位于第一存储子系统的多个块存储内，则服务器计算机将元数据条目的对象状态属性更新为“正在终态化（finalizing）”。

在一些实施例中，服务器计算机将多个块从第一存储子系统的多个块存储移动到第一存储子系统的目的地块存储，以及如果对象的多个块位于第一存储子系统的目的地块存储内，则将元数据条目的对象状态属性更新为“已终态化”。

依据一些实施例，分布式存储系统由一个或多个计算机系统组成，每一个计算机系统包括一个或多个处理器；以及用于存储一个或多个程序的存储器。该一个或多个处理器被配置成在第一存储子系统处执行一个或多个程序，该一个或多个程序包括用于以下的指令：从客户端接收对不存在于第一存储子系统中的对象的第一客户端请求；将第二存储子系统识别为具有所请求的对象的复制品，其中所请求的对象包括内容和元数据；将对所请求的对象的对象复制请求提交给第二存储子系统；以及从第二存储子系统独立接收所请求的对象的内容和元数据；使用所接收的元数据和内容来在第一存储子系统处生成对象的新的复制品；以及将对象的新的复制品的元数据返回给客户端。

因此，提供了使在分布式数据库中对数据的复制更快，并且使得能够更高效使用网络资源的方法和系统。更快的复制导致更快地向用户提供更新的信息（或对信息的访问）；以及对网络带宽的更高效使用让更多带宽对其他任务可用，使其他过程运行更快。

附图说明

为了更好理解本发明的前述实施例以及本发明的另外实施例，应当结合附图参考下面的具体实施方式，在附图中，相同参考数字遍及附图指代对应部分。

图1A是根据一些实施例的用于将数据库的多个实例放置在全球各地的物理场所处的概念图。

图1B图示根据一些实施例的在每一个实例处的基本功能性。

图2是图示根据一些实施例的复制的数据库的多个实例的框图，其中为第一实例示出了示例性程序和/或过程集。

图3是图示根据一些实施例的用于系统的示例性实例以及图示根据一些实施例的在该实例内的用户与之交互的块的框图。

图4是根据一些实施例的可以用于在图1B、2和3中所图示的各种程序和过程的实例服务器的框图。

图5图示根据一些实施例的实例服务器到在图1B、2和3中所图示的各种程序或过程的典型分配。

图6图示根据一些实施例的元数据如何被存储。

图7图示根据一些实施例的用来存储改变量的数据结构。

图8A-8E图示根据一些实施例的用来存储元数据的数据结构。

图9A-9E图示根据一些实施例的用于在全球范围分布式存储系统的不同子系统之间动态复制数据的框图和数据结构。

图10A-10C图示根据一些实施例的用于在全球范围分布式存储系统的不同子系统之间动态复制数据的计算机实现的方法的流程图。

现将详细参考实施例，其示例在附图中被图示。在下面的详细描述中，阐述了许多具体细节，以提供对本发明的全面理解。然而，对本领域普通技术人员显而易见的是，在没有这些具体细节的情况下，可以实践本发明。

在本文中在对本发明的描述中所使用的术语仅用于描述特定实施例的目的，并且并不意在是对本发明的限制。如在本发明和所附权利要求的描述中所使用的，除非语境另外明确指示，单数形式不定冠词和定冠词意在还包括复数形式。还应当理解的是，如在本文中所使用的词语“和/或”是指并且包括相关联的列出项中的一个或多个的任何和所有可能组合。应当进一步理解的是，词语“包括”和/或“包含”当在本说明书中使用时，指定阐明的特征、步骤、操作、元素和/或组件的存在，但是不排除一个或多个其他特征、步骤、操作、元素、组件和/或其群组的存在或添加。

具体实施方式

本说明书描述了分布式存储系统。在一些实施例中，如图1A中所图示，分布式存储系统在全球或全球范围实现。在这些实施例中，在地球100的各种位置处存在通过网络通信链路104-1、104-2、…、104-M连接的多个实例102-1、102-2、…、102-N。在一些实施例中，实例（诸如实例102-1）对应于数据中心。在其他实施例中，多个实例物理上位于同一数据中心处。尽管图1的概念图示出了有限数量的网络通信链路104-1等，然而典型的实施例将具有更多的网络通信链路。在一些实施例中，在同一实例对之间存在两个或更多个网络通信链路，如在实例2（102-2）和实例6（102-6）之间的链路104-5和104-6所图示。在一些实施例中，网络通信链路由光缆组成。在一些实施例中，部分网络通信链路使用无线技术，诸如微波。在一些实施例中，每一个网络通信链路具有指定带宽和/或指定成本用于对该带宽的使用。在一些实施例中，维护关于跨网络通信链路中的一个或多个传输数据的统计数据，包括吞吐率、可用性次数、链路可靠性等。每一个实例典型地具有数据存储和相关联的数据库（如图2和3中所示），并且利用服务器计算机群（参见图4的“实例服务器”）来执行所有任务。在一些实施例中，存在具有有限功能性的一个或多个实例，诸如用作用于在其他实例之间的数据传输的中继器。有限功能性实例可以或可以不具有图3和4中描绘的数据存储中的任何一个。

图1B图示在实例102-i处的数据和在实例之间存储并复制数据的程序。基础数据项122-1、122-2等由一个或多个数据库单元120存储并管理。每一个实例102-i具有复制单元124，其将数据复制到其他实例以及从其他实例复制数据。复制单元124还管理一个或多个外出图134，其跟踪发送给其他实例并且由其他实例确认的数据。类似地，复制单元124管理一个或多个进入图，其跟踪在实例处从其他实例接收的数据。

每一个实例102-i具有提供准确时间的一个或多个时钟服务器126。在一些实施例中，时钟服务器126将时间提供为在过去经过定义明确的点的微秒数。在优选实施例中，时钟服务器提供保证是单调递增的时间读数。在一些实施例中，每一个实例服务器102-i存储在分布式存储系统内唯一识别其自身的实例标识符128。实例标识符可以以任何便利格式保存，诸如32位整数、64位整数或固定长度字符串。在一些实施例中，将实例标识符（直接或间接）并入在该实例处生成的其他唯一标识符。在一些实施例中，实例102-i存储行标识符种子130，其在新的数据项122被插入数据库时被使用。行标识符用来唯一识别每一个数据项122。在一些实施例中，行标识符种子用来创建行标识符，并且同时递增，使得下一个行标识符将更大。在其他实施例中，从时钟服务器126提供的时间戳创建唯一行标识符，而不使用行标识符种子。在一些实施例中，同数破除器（tie breaker）值132在为（在下面参考图6-7描述的）数据改变生成行标识符或唯一标识符时被使用。在一些实施例中，同数破除器132被永久存储在非易失性存储器（诸如磁或光盘）中。

将在图1B中描述的元素并入在图2和3中所图示的分布式存储系统200的实施例中。在一些实施例中，将在图1B中所描述的功能性包括在blobmaster（二进制大对象主控机）204和元数据存储206中。在这些实施例中，主数据存储（即，blob）在数据存储212、214、216、218和220中，并且由bitpusher（比特推送器）210管理。关于blob（二进制大对象）的元数据在元数据存储206中，并且由blobmaster 204管理。元数据对应于在图1B中识别的功能性。尽管关于blob的存储的元数据提供了本发明的示例性实施例，然而本领域普通技术人员将认识到，本发明并不限于该实施例。

图2和3中所示的分布式存储系统200包括某些全局应用和配置信息202，以及多个实例102-1、…、102-N。在一些实施例中，全局配置信息包括实例列表和关于每一个实例的信息。在一些实施例中，关于每一个实例的信息包括：在该实例处的存储节点（数据存储）集；状态信息，其在一些实施例中包括在该实例处的元数据是全局还是局部的；以及到达在该实例处的blobmaster 204和bitpusher 210的网络地址。在一些实施例中，全局配置信息202驻存在单个物理位置处，以及该信息视需被检索。在其他实施例中，将全局配置信息202的副本存储在多个位置处。在一些实施例中，将全局配置信息202的副本存储在部分或全部实例处。在一些实施例中，仅能够在单个位置处修改全局配置信息，并且通过单向复制将改变传输到其他位置。在一些实施例中，存在某些全局应用，诸如位置分配守护程序（daemon）346（参见图3），其在任何给定时间仅能够在一个位置处运行。在一些实施例中，全局应用在所选择的实例处运行，而在其他实施例中，全局应用中的一个或多个在不同于实例的服务器组上运行。在一些实施例中，全局应用正运行的位置被指定为全局配置信息202的一部分，并且随着时间的推移经受改变。

图2和3图示在每一个实例处运行或存在的示例性程序、过程和数据集，以及可以访问分布式存储系统200及部分全局应用和配置的用户系统。在一些实施例中，用户302与用户系统304交互，用户系统304可以是计算机或能够运行web浏览器306的其他设备。用户应用308在web浏览器中运行，并且使用数据库客户端310所提供的功能性来使用网络328访问存储在分布式存储系统200中的数据。网络328可以是因特网、局域网（LAN）、广域网（WAN）、无线网络（WiFi）、本地内嵌网或这些的任何组合。在一些实施例中，负载平衡器314在实例之间分发工作负载，因此，单个客户端310所发出的多个请求不一定均转到同一实例。在一些实施例中，数据库客户端310使用全局配置存储312中的信息来为请求识别适当的实例。客户端使用来自全局配置存储312的信息来找到可用的blobmaster 204和bitpusher 210集，以及联系它们的地方。Blobmaster 204使用全局配置存储312来为所有复制过程识别对等集。Bitpusher 210使用全局配置存储312中的信息来跟踪其负责哪些存储。在一些实施例中，用户应用308在用户系统304而不是web浏览器306上运行。示例性用户应用是电子邮件应用和在线视频应用。

在一些实施例中，每一个实例具有blobmaster 204，其是用作到元数据表206的外部接口的程序。例如，外部用户应用308可以使用客户端310来请求与指定的blob相对应的元数据。注意到“blob”（即，二进制大对象）是作为单个实体存储在数据库中的二进制数据集合（例如，图像、视频、二进制文件、可执行代码等）。本说明书可交替地使用词语“blob”和“对象”，以及提及“blob”的实施例也可以被应用于“对象”，反之亦然。总的来说，词语“对象”可以指“blob”或任何其他对象，诸如数据库对象、文件等，或前述对象的部分（或子集）。在一些实施例中，每个实例102在其元数据表206中具有与存储在分布式存储系统200中的任何地方的每个blob相对应的元数据。在其他实施例中，实例分为两种：带有（用于分布式存储系统200中的每个blob的）全局元数据的那些以及仅带有（仅用于为存储在实例处的blob的）局部元数据的那些。具体地，blob典型地驻存于实例的仅仅较小子集处。元数据表206包括与blob的每一个有关的信息，诸如哪些实例具有blob的副本、谁可以访问blob以及在每一个实例处使用哪种类型的数据存储来存储blob。图8A-8E中的示例性数据结构图示了在一些实施例中存储在元数据表206中的其他元数据。

当客户端310想要读取blob数据时，blobmaster 204将一个或多个读标记提供给客户端310，客户端310将该一个或多个读标记提供给bitpusher 210，以获得对相关blob的访问。当客户端310写数据时，客户端310写入bitpusher 210。Bitpusher 210返回指示该数据已被存储的写标记，客户端310然后将该写标记提供给blobmaster 204，以将该数据附着到blob。客户端310通过网络328与bitpusher 210通信，网络328可以是用来与blobmaster 204通信的同一网络。在优选实施例中，根据负载平衡器314路由在客户端和bitpusher 210之间的通信。由于负载平衡或其他因素，与在一个实例处的blobmaster 204的通信可以后跟与在不同实例处的bitpusher 210的通信。例如，第一实例可以是带有用于所有blob的元数据的全局实例，但是可能没有所期望的blob的副本。用于blob的元数据识别哪些实例具有所期望的blob的副本，因此，在该示例中，与bitpusher 210随后通信来读或写是在不同实例处。

Bitpusher 210将数据拷贝到数据存储，以及从数据存储拷贝数据。在一些实施例中，读写操作包括整个blob。在其他实施例中，每一个blob包括一个或多个块（chunk），以及由bitpusher执行的读写操作仅仅针对块。在这些实施例的部分中，bitpusher仅处理块，并且不知道blob。在优选实施例中，bitpusher不知道被读或写的数据的内容，并且并不尝试解释内容。Bitpusher 210的实施例支持一个或多个类型的数据存储。在优选实施例中，bitpusher支持多个数据存储类型，包括内嵌数据存储212、大表（BigTable）存储214、文件服务器存储216和带存储218。一些实施例支持另外的其他存储220，或被设计成当其他类型的数据存储变得可用或技术可行时适应该其他类型的数据存储。

内嵌存储212实际上使用元数据存储206中的存储空间208。内嵌存储提供对数据的更快访问，但是具有有限容量，因此内嵌存储一般用于相对“较小的”blob。在一些实施例中，将内嵌存储限制在作为单个块存储的blob。在一些实施例中，“较小”意为小于32千字节的blob。在一些实施例中，“较小”意为小于1兆字节的blob。因为存储技术促进更大的存储容量，所以即使当前被认为是较大的blob与其他blob相比也可能是“相对较小的”。

大表存储214将数据存储在位于一个或多个大表数据库服务器316上的大表中。在若干公众可获得出版物中描述了大表，包括“Bigtable:A Distributed Storage System for Structured Data”，Fay Chang等人，OSDI 2006，其通过引用以全文方式并入本文中。在优选实施例中，大表存储将数据保存在较大的服务器阵列上316。

文件存储216将数据存储在一个或多个文件服务器318上。在一些实施例中，文件服务器使用诸如UNIX的计算机操作系统所提供的文件系统。在其他实施例中，文件服务器318实现专有文件系统，诸如谷歌文件系统（GFS）。在多个公众可获得出版物中描述了GFS，包括“The Google File System”，Sanjay Ghemawat等人，SOSP'03，10月19-22,2003，其通过引用以全文方式并入本文中。在其他实施例中，文件服务器318实现NFS（网络文件系统）或不由计算机操作系统实现的其他公众可获得文件系统。在优选实施例中，文件系统跨许多单个服务器318分布，以减少任何单个计算机的损失或不可用风险。

带存储218将数据存储在物理带320上。与带备份不同，在此的带是另一种形式的存储。这在于2010年2月9日提交的、共同未决的美国临时专利申请序列号No.61/302,909“Method and System forProviding Efficient Access to a Tape Storage System”中更详细地被描述，其通过引用以全文方式并入本文中。在一些实施例中，带主应用222帮助从带进行读写。在一些实施例中，存在两个类型的带：物理上被加载在带设备中使得带可以以机器人形式被加载的那些带；以及物理上位于储存库或其他离线位置中并且需要人类动作来将带安装在带设备上的那些带。在一些情况下，后一类别的带被称为深存储或归档。在一些实施例中，使用较大读/写缓冲器来管理到带的读和写数据。在一些实施例中，该缓冲器由带主应用222管理。在一些实施例中，存在独立的读缓冲器和写缓冲器。在一些实施例中，客户端310不能直接读或写入存储在带上的数据的副本。在这些实施例中，客户端必须从替选数据源读取数据的副本，即使该数据必须传输通过较大距离。

在一些实施例中，存在以其他格式或者使用其他设备或技术来存储数据的另外的其他存储200。在一些实施例中，bitpusher 210被设计成当另外的存储技术变得可用时适应该另外的存储技术。

数据存储类型中的每一个具有特定特征，其使它们对某些目的是有用的。例如，内嵌存储提供快速访问，但是用光更昂贵的有限空间。作为另一个示例，带存储是非常廉价的，并且提供安全长期存储，但是客户端不能直接读或写入带。在一些实施例中，基于数据的特征与数据存储的特征的匹配以特定数据存储类型自动存储数据。在一些实施例中，创建文件的用户302可以指定待使用的数据存储的类型。在其他实施例中，待使用的数据存储的类型由创建blob数据的用户应用308确定。在一些实施例中，使用上面选择标准的组合。在一些实施例中，将每一个blob分配给存储策略326，以及存储策略指定存储性质。Blob策略326可以指定待存储的blob的副本的数量、blob应当以哪种类型的数据存储被保存、副本应当被保存的位置等。例如，策略可以指定在盘上应当有两个副本（大表存储或文件存储）、在带上应当有一个副本以及在不同的大都市位置应当有所有三个副本。在一些实施例中，blob策略326被存储为全局配置和应用202的一部分。

在一些实施例中，每一个实例102具有仲裁时钟服务器228，其包括带有内部时钟的一个或多个服务器。事件，包括元数据改变量608，的顺序是重要的，因此对一致时钟的维护很重要。仲裁时钟服务器定期轮询多个独立时钟，并且确定它们是否是合理一致的。如果时钟变得不一致，并且如何解决该不一致是不清楚的，则可以要求人为干预。对不一致的解决可以取决于用于仲裁的时钟数和不一致的性质。例如，如果存在五个时钟，并且仅仅一个与其他四个不一致，则该四个的一致几乎肯定是正确的。然而，如果五个时钟中的每一个具有显著不同于其他的时间，则将不会有清楚解决方案。

在一些实施例中，每一个实例具有复制模块224，其识别将被复制到其他实例的blob或块。在一些实施例中，复制模块224可以使用一个或多个队列226-1、226-2、…。将待被复制的项放置在队列226中，以及当资源可用时对项进行复制。在一些实施例中，复制队列226中的项具有分配的优先级，以及当带宽变得可用时对最高优先级项进行复制。存在可以将项添加到复制队列226的多种方式。在一些实施例中，当创建或修改blob或块数据时，将项添加到复制队列226。例如，如果最终用户302在实例1处修改blob，则该修改需要被传输给具有该blob的副本的所有其他实例。在复制队列226中具有优先级的实施例中，基于blob内容改变的复制项具有相对较高的优先级。在一些实施例中，基于对位于遥远实例处的blob的当前用户请求来将项添加到复制队列226。例如，如果在加利福尼亚的用户请求仅存在于在印度的实例处的blob，则可以将项插入复制队列226以将该blob从在印度的实例拷贝到在加利福尼亚的本地实例。即，由于无论如何必须从遥远位置拷贝数据，可能有用的是，将该数据保存在本地实例处。这些动态复制请求得到最高优先级，因为它们正对当前用户请求作出响应。

在一些实施例中，存在后台复制过程，其基于blob策略326和统计数据服务器324所提供的blob访问数据来创建及删除blob的副本。Blob策略指定期望的blob副本的数量、副本应当驻存的位置以及数据应当以哪些类型的数据存储来保存。在一些实施例中，策略可以指定另外的性质，诸如待保存的blob的世代数、或用于保存不同数量的副本的时间帧。例如，在创建后的前30天保存三个副本，在此后保存两个副本。使用blob策略326，与统计数据服务器324所提供的统计信息一起，位置分配守护程序322确定创建blob的新副本的位置以及哪些副本可以被删除。当待创建新的副本时，将记录插入复制队列226，其具有最低优先级。在于2010年2月9日提交的、共同未决的美国临时专利申请序列号No.61/302,936，“System and Method for managingReplicas of Objects in a Distributed Storage System”中更详细地描述了对blob策略326的使用和对位置分配守护程序322的操作，其通过引用以全文方式并入本文中。

图4是图示与本发明的一些实施例一致的用于在图2和3中所识别的操作的实例服务器400的框图。实例服务器400典型地包括：一个或多个处理单元（CPU）402，其用于执行存储在存储器414中的模块、程序和/或指令，从而执行处理操作；一个或多个网络或其他通信接口404；存储器414；以及用于使这些组件互连的一个或多个通信总线412。在一些实施例中，实例服务器400包括用户接口406，其包括显示设备408和一个或多个输入设备410。在一些实施例中，存储器414包括高速随机存取存储器，诸如DRAM、SRAM、DDR RAM或其他随机存取固态存储器设备。在一些实施例中，存储器414包括非易失性存储器，诸如一个或多个盘存储设备、光盘存储设备、闪存设备或其他非易失性固态存储设备。在一些实施例中，存储器414包括位于远离CPU 402的地方的一个或多个存储设备。存储器414或替选地在存储器414内的非易失性存储器设备包括计算机可读存储介质。在一些实施例中，存储器414或存储器414的计算机可读存储介质存储下面的程序、模块和数据结构、或其子集：

·操作系统416，其包括用于处理各种基本系统服务以及用于执行依赖硬件的任务的程序；

·通信模块418，其用于经由一个或多个通信网络接口404（有线或无线）以及一个或多个通信网络328，诸如因特网、其他广域网、局域网、城域网等，将实例服务器400连接到其他实例服务器或计算机；

·一个或多个服务器应用420，诸如提供到blob元数据的外部接口的blobmaster 204；提供从数据存储读写数据的权利的bitpusher 210；将数据从一个实例拷贝到另一个的复制模块224；提供稳定时钟的仲裁时钟服务器228；确定blob的副本应当位于的位置的位置分配守护程序322；以及如图2和3中所图示的其他服务器功能性。如所图示，两个或更多个服务器应用422和424可以在同一物理计算机上执行；

·一个或多个数据库服务器426，其提供到一个或多个数据库428的存储和访问。数据库428可以为元数据206、复制队列226、blob策略326、全局配置312、统计数据服务器324所使用的统计数据、以及任何其他功能性所使用的辅助数据库提供存储。每一个数据库428具有带有数据记录430的一个或多个表。在一些实施例中，一些数据库包括汇总表432，诸如统计数据服务器324所使用的统计数据；以及

·一个或多个文件服务器434，其提供读写诸如文件#1（436）和文件#2（438）的文件的权利。文件服务器功能性可以由操作系统（例如，UNIX或Linux）、或由诸如谷歌文件系统（GFS）的软件应用直接提供。

上面所识别的元素中的每一个可以被存储在前述存储器设备的一个或多个中，并且对应于用于执行上述功能的指令集。不必将在上面识别的模块或程序（即，指令集）实现为独立软件程序、过程或模块，因此，在各种实施例中，可以对这些模块的各种子集进行组合或另外重新安排。在一些实施例中，存储器414可以存储在上面识别的模块和数据结构的子集。此外，存储器414可以存储在上面没有描述的另外模块或数据结构。

尽管图4示出了用于执行如在图2和3中所图示的各种操作或存储数据的实例服务器，然而，图4更意在作为可能存在于一个或多个计算机组中的各种特征的功能描述，而不是作为在本文中描述的实施例的结构示意。实际上，并且如本领域普通技术人员所认识的，可以对独立示出的项进行组合，以及可以使一些项分离。例如，可以在单独计算机系统上实现在图4中独立示出的一些项，以及单个项可以由一个或多个计算机系统实现。用来实现操作、数据库或文件存储系统中的每一个的计算机的实际数量，以及在它们之间如何分配特征将随实施方式不同而变化，并且可以部分取决于在每一个实例处的数据量、实例在高峰使用时段必须处理的数据业务量、以及实例在平均使用时段必须处理的数据业务量。

为了提供对客户端的更快响应以及为了提供容错性，在实例处运行的每一个程序或过程一般分布在多个计算机之中。分配给程序或过程中的每一个的实例服务器400的数量能够变化，并且取决于工作负载。图5提供与分配给功能中的每一个的实例服务器400的典型数量有关的示例性信息。在一些实施例中，每一个实例具有作为blobmaster运作（502）的大约10个实例服务器。在一些实施例中，每一个实例具有作为bitpusher运作（504）的大约100个实例服务器。在一些实施例中，每一个实例具有作为大表服务器运作（506）的大约50个实例服务器。在一些实施例中，每一个实例具有作为文件系统服务器运作（508）的大约1000个实例服务器。文件系统服务器为文件系统存储216存储数据，以及为大表存储214存储基本存储介质。在一些实施例中，每一个实例具有作为带服务器运作（510）的大约10个实例服务器。在一些实施例中，每一个实例具有作为带主机运作（512）的大约5个实例服务器。在一些实施例中，每一个实例具有执行（514）包括动态和后台复制两者的复制管理的大约10个实例服务器。在一些实施例中，每一个实例具有作为仲裁时钟服务器运作（516）的大约5个实例服务器。

图6图示根据一些实施例的元数据数据项600的存储。每一个数据项600具有唯一行标识符602。每一个数据项600是行604，其具有基值606以及零个或多个改变量608-1、608-2、…、608-L。当不存在改变量时，则数据项600的值是基值606。当存在改变量时，数据项600的“值”通过以基值606开始，并且按照顺序将改变量608-1等应用到基值来计算。行因此具有单个值，其表示单个数据项或条目。尽管在一些实施例中，改变量存储整个新的值，然而，在优选实施例中，改变量存储尽可能少的数据来识别改变。例如，关于blob的元数据包括指定哪些实例具有该blob以及谁可以访问该blob。如果将该blob拷贝到另外实例，则元数据改变量仅需要指定该blob在该另外实例处可用。改变量不必指定blob已位于的位置。随着改变量的数量增加，读取数据的时间增加。压缩过程将改变量608-1等合并入基值606,来创建并入改变量中的改变的新的基值。

尽管图6中所示的存储与关于blob的元数据有关，然而，相同过程适用于其中数据以特定方式改变的其他非关系数据库，诸如柱形数据库。例如，可以将访问控制列表实现为多字节整数，其中每一个位位置表示项、位置或人。改变一条访问信息不会修改其他位，因此，对改变进行编码的改变量需要很少空间。在其中数据是较少结构化的替选实施例中，可以将改变量编码为用于如何对二进制数据流作出改变的指令。在出版物RFC 3284，“The VCDIFF Generic Differencing andCompression Data Format”，The Internet Society，2002中描述了一些实施例。本领域普通技术人员因此将认识到，在此应用于元数据的相同技术同样适用于某些其他类型的结构化数据。

图7图示保留改变量的示例性数据结构。每一个改变量应用到唯一行，因此，改变量包括其应用到的行的行标识符702。为了在多个实例处保证数据一致性，必须以定义明确的顺序将改变量应用到基值。序列标识符704是全局唯一的，并且指定应用改变量的顺序。在一些实施例中，序列标识符包括时间戳706和唯一分配给改变量在其中被创建的每一个实例的同数破除器值708。在一些实施例中，时间戳是经过时间的定义明确的点的微秒数。在一些实施例中，将同数破除器计算为运行blobmaster的物理机器以及过程id的函数。在一些实施例中，同数破除器包括仅仅或结合在实例处的其他特征的实例标识符。在一些实施例中，将同数破除器708存储为同数破除器值132。通过将时间戳706和同数破除器708组合，序列标识符既是全局唯一的又至少近似改变量被创建的顺序。在某些情况下，在不同实例处的时钟可能稍微不同，因此，序列标识符所定义的顺序可能与事件的“实际”顺序不相对应。然而，在优选实施例中，根据定义的“顺序”是序列标识符所创建的顺序。这是改变将在所有实例处被应用的顺序。

将在一个实例处对元数据的改变复制到其他实例。可以以各种格式存储对基值的实际改变712。在一些实施例中，使用与在图8A-8E中的那些相似的数据结构来存储改变，但是对结构进行修改使得大部分字段是可选的。仅仅实际改变被填入，因此，存储或传输改变量所需的空间很小。在其他实施例中，将改变存储为键/值对，其中键唯一地识别改变的数据元素，以及值是数据元素的新值。

在其中数据项是关于blob的元数据的一些实施例中，改变量可以包括关于转发的信息。由于可以在任何时间在实例之间动态复制blob，以及也可以在任何时间对元数据进行修改，所以有时候，blob的新副本最初没有所有相关联的元数据。在这些情况下，新副本的源维护“转发地址”，并且在某一时间段（例如，针对某一范围的序列标识符）将改变量传输给具有blob的新副本的实例。

图8A-8E图示在一些实施例中用来存储元数据的数据结构。在一些实施例中，这些数据结构存在于执行程序或过程的存储器空间内。在其他实施例中，这些数据结构存在于非易失性存储器中，诸如磁或光盘驱动器。在一些实施例中，这些数据结构形成协议缓冲器，便利在物理设备或过程之间传输结构化数据。例如参见在http://code.google.com/apis/protocolbuffers/docs/proto.html处可获得的ProtocolBuffer Language Guide。

总体元数据结构802包括三个主要部分：关于blob世代的数据804、关于blob引用的数据808以及内嵌数据812。在一些实施例中，还将读标记816与元数据保存在一起，但是将读标记用作访问数据而不是表示所存储的blob的特征的手段。

blob世代804可以包括每一个blob的一个或多个“世代”。在一些实施例中，所存储的blob是不可改变的，因此不可直接编辑。替代地，将blob的“改变”实现为对先前版本的删除和对新版本的创建。这些blob版本806-1、806-2等中的每一个是一个世代，并且具有其自身条目。在一些实施例中，在将最老的世代从存储物理移除之前，存储固定数量的世代。在其他实施例中，所保存的世代的数量由blob策略326设置。（策略可以将所保存的世代的数量设置为1，意为当新的世代被创建时移除老的世代。）在一些实施例中，对老的世代的移除故意“慢”，在某一时段提供恢复老的“删除的”世代的机会。在下面参考图8B描述与每一世代806相关联的特定元数据。

Blob引用808可以包括一个或多个单独引用810-1、810-2等。每一个引用是到相同基础blob内容的独立链接，以及每一个引用具有其自身访问信息集。在大多数情况下，仅存在到给定blob的一个引用。仅在用户明确请求多个引用时，才可能出现多个引用。该过程类似于在桌面文件系统中创建链接（硬链接）。在下面参考图8C描述了与每一个引用相关联的信息。

内嵌数据812包括一个或多个内嵌数据项814-1、814-2等。内嵌数据不是“元数据”——其是元数据应用到的所保存的blob的实际内容。对于相对较小的blob，对所述blob的访问可以通过将blob内容与元数据一起存储来进行优化。在这种情况下，当客户端要求读取元数据时，blobmaster返回实际blob内容，而不是读标记816和关于何处找到blob内容的信息。由于仅当blob较小时才将blob存储在元数据表中，所以对于每一个blob一般存在至多一个内嵌数据项814-1。在下面在图8D中描述了为每一个内嵌数据项814存储的信息。

如在图8B的实施例中所图示，每一世代806包括若干条信息。在一些实施例中，世代编号822（或世代ID）唯一识别世代。世代编号可以由客户端使用来指定待访问的某一世代。在一些实施例中，如果客户端没有指定世代编号，则blobmaster 204将返回关于最新世代的信息。在一些实施例中，每一世代跟踪若干时间点。具体地，一些实施例跟踪世代被创建的时间（824）。一些实施例跟踪blob被用户最后访问的时间（826）。在一些实施例中，最后访问是指最终用户访问，以及在其他实施例中，最后访问还包括管理访问。一些实施例跟踪blob被最后改变的时间（828）。在当blob被最后改变时进行跟踪的一些实施例中，改变仅应用到元数据，因为blob内容是不可改变的。一些实施例提供阻止标志830，其阻止对世代的访问。在这些实施例中，blobmaster 204将仍允许访问具有给予阻止的blob世代的权限或看见阻止的blob世代的某些用户或客户端。一些实施例提供保持标志832，其将保证世代中的数据不被移除。这可以用于例如遭受诉讼保留或法院的其他命令的数据。除这些单独的关于世代的数据外，世代具有一个或多个表示818。在下面参考图8E描述了单独表示820-1、820-2等。

图8C图示根据一些实施例的用来保留单独引用的数据结构。每一个引用810包括唯一识别引用的引用ID 834。当用户302访问blob时，用户应用308必须指定引用ID，以访问blob。在优选实施例中，每一个引用具有所有者836，其可以是创建该引用的用户或过程。每一个引用具有其自身访问控制列表（“ACL”），其可以指定谁可以访问blob以及那些访问权限的内容。例如，有权读blob的组可以大于可以编辑或删除blob的组。在一些实施例中，对引用的移除故意很慢，以提供从错误的恢复。在一些实施例中，该对引用的较慢删除由墓碑（tombstone）提供。墓碑可以以若干方式实现，包括对墓碑时间840的说明，在该点引用将被真正移除。在一些实施例中，墓碑时间是在引用被标记用于移除之后30天。在优选实施例中，具有特殊权限的某些用户或账户可以查看或修改已标记有墓碑的引用，并且具有移除墓碑（即，使blob复活）的权利。

在一些实施例中，每一个引用具有其自身blob策略，其可以由策略ID 842指定。blob策略指定blob的副本的数量、副本所位于的位置、哪些类型的数据存储待用于blob等。当存在多个引用时，适当的“策略”是相关策略的联合。例如，如果一个策略请求2个副本，其中的至少一个在欧洲，以及另一个请求3个副本，其中的至少一个在北美洲，则最小联合策略是3个副本，其中至少一个在欧洲以及至少一个在北美洲。在一些实施例中，单独引用还具有阻止标志844和保持标志846，其以与为每一世代定义的阻止和保持标志830和832相同的方式起作用。另外，blob引用的用户或所有者可以指定关于blob的另外信息，其可以包括盘上的信息850或存储器中的信息848。用户可以将关于blob的任何信息保存在这些字段中。

图8D图示根据一些实施例的内嵌数据项814。每一个内嵌数据项814被分配给特定世代，因此包括世代编号822。内嵌数据项还指定表示类型852，其结合世代编号822唯一识别表示项820。（参见图8E和在下面的相关联的描述。）在允许多个内嵌块用于一个blob的实施例中，内嵌数据项814还指定块ID 856。在一些实施例中，内嵌数据项814指定块偏移854，其指定当前块距blob开始的偏移。在优选实施例中，以字节指定块偏移。在一些实施例中，存在预加载标志858，其指定在盘上的数据是否被预加载入存储器以供更快访问。内嵌数据项814的内容860与其他数据元素一起被存储。

图8E图示根据一些实施例的用来存储blob表示的数据结构。表示是相同物理数据的不同视图。例如，数字图像的一个表示可以是较高分辨率相片。同一blob数据的第二表示可以是与该同一相片相对应的较小缩略图。每一个表示数据项820指定表示类型852，其将对应于上面示例中的“较高分辨率相片”和“缩略图”。复制品信息862识别blob已被复制的位置、存储引用列表（即，哪些块存储具有关于blob的块）。在一些实施例中，复制品信息862包括跟踪blob及其块所需的其他辅助数据。每一个表示数据项还包括blob区段864集合，其指定到blob内的每一个块的偏移，以允许对blob的重建。

当blob被最初创建时，其经历若干阶段，并且一些实施例在每一个表示数据项820中跟踪这些阶段。在一些实施例中，终态化状态字段866指示何时blob是UPLOADING（正上载）、何时blob是FINALIZING（正在终态化）以及何时blob是FINALIZED（已终态化）。大部分表示数据项820将具有FINALIZED（已终态化）状态。在一些实施例中，某些终态化数据868在终态化过程期间被存储。

如图1和3中所示的分布式存储系统200的一个主要功能是使在不同地理位置处的客户端能够访问存储在分布式存储系统内的数据。为了对客户端进行最好服务，分布式存储系统200利用后台复制过程，该过程有助于预期到来自位于相应实例附近内的客户端的潜在数据访问请求，根据blob的复制策略为blob生成复制品并且将复制品放置在分布式存储系统的不同实例处。

虽然如此，仅仅这种策略不能阻止下述发生：实例接收对没有驻存于该特定实例中而是在分布式存储系统的另一个实例或多个实例中的blob的客户端请求。当这发生时，有至少两个可能的解决方案。一个是将客户端请求转发给具有所请求的blob的复制品的实例，并且让该实例对该客户端请求进行处理。如将在下面说明的，该方法在一些情况下是可接受的，例如，如果实例和客户端离得不是非常远来引起在请求和响应之间的显著延迟，并且为了向客户端提供更好服务，与在实例和客户端之间的网络连接有关的任何另外成本是值得的。但是，随着在两个实体之间的距离增加，这可能引起更长延迟和对有限网络资源的更高压力，这种方法可能变得更少可接受。如在下面详细说明的第二解决方案是，原始实例从其他实例动态检索数据，并且在向客户端提供数据时将所检索到的数据存储在原始实例处。

特别地，图9A描绘了图示如何将客户端请求的blob从一个blobstore（二进制大对象存储）动态地复制到另一个blobstore的框图，以及图10A至10C示出了该动态复制过程的对应流程图。图9B-9E描绘了分布式存储系统的不同组件使用来支持在该两个blobstore之间的动态复制的数据结构的框图。

出于说明目的，图9A描绘了如图1和3中所示的分布式存储系统200的组件的子集，包括应用902、客户端904和三个blobstore 906、908、910。在该示例中，blobstore_A 908和blobstore_B 906是分布式存储系统的局部实例，以及blobstore_G 910是分布式存储系统200的全局实例。注意到，在本应用中的词语“blobstore”对应于系统200的实例102，因为其存储多个blob，每一个blob是由一个或多个块组成的数据对象（例如，图像、文本文档或音频/视频流）。

如图9A中所示，应用902通过将blob的元数据904-1（例如，唯一blob ID）提供给客户端904（图10A的1001），调用客户端904来从分布式存储系统读取blob。作为响应，客户端904识别负载平衡的blobstore_A 908和其blobmaster_A 908-3（图10A的1003），并且将包括所请求的blob的标识符的读请求发送给blobmaster_A 908-3（图10A的1005）。注意到，对负载平衡的blobstore的识别不需要客户端904提供所请求的blob的任何元数据。因此，不保证所识别的负载平衡的blobstore_A 908确实具有所请求的blob的复制品。

当接收到客户端的读请求时，blobmaster_A 908-3为与blob ID相对应的元数据条目查找其元数据表908-11（图10A的1007）。如在上面结合图8A-8E所描述的，元数据条目包括描述存储在分布式存储系统内的blob的各个方面的多个条目。如果元数据表908-11包括与客户端指定的blob ID相对应的条目（图10A的1009），则blobmaster_A 908-3检查应用（或调用应用的用户）是否被授权访问该blob（图10A的1011）。在一些实施例中，blobmaster_A 908-3使用blob的读标记1816来确定应用是否被授权访问该blob。如果应用被认为没有资格访问（图10A的1011，否），则blobmaster_A 908-3向客户端904返回错误消息（图10A的1013）。否则（图10A的1011，是），blobmaster_A 908-3向发出请求的客户端返回所请求的blob的元数据，其包括例如区段表和读标记集（图10A的1015）。返回给客户端904的其他元数据可以包括跨分布式存储系统的块存储列表，每一个块存储具有所请求的blob的复制品。在一些特殊情况下，如果blob的大小足够小，所返回的元数据可以包括blob的内嵌块。

当接收到元数据时，客户端904识别与blobstore_A 908相关联的负载平衡的bitpusher_A 908-5，并且为与blob相关联的块将读标记发送给bitpusher_A 908-5（图10A的1017）。Bitpusher_A 908-5然后将客户端请求的块返回给客户端以满足应用的原始读请求（图10A的1019）。注意到，在该示例中，动态复制不是必需的，因为客户端请求的blob存在于blobstore_A 908中。

图9A图示不同的情况，其中blobmaster_A 908-3没有找到与客户端请求的blob相对应的元数据条目（图10A的1009，否）。当这发生时，blobmaster_A 908-3请求附近的负载平衡的全局blobstore（例如，blobstore_G 910）帮助（图10B的1021）。与仅具有驻存于blobstore_A中的blob的元数据的局部blobstore_A不同，全局blobstore_G还具有在分布式存储系统的任何其他实例处的blob的元数据。使用blobmaster_A 908-3所提供的blob ID，blobmaster_G 910-1为客户端请求的blob的元数据查找其元数据表910-3（图10B的1024）。如果没有找到匹配的元数据条目（图10B的1024，否），则blobmaster_G 910-1向blobmaster_A 908-3返回错误消息，blobmaster_A 908-3然后将错误消息转发给客户端以拒绝客户端请求（图10B的1025）。如果找到元数据（图10B的1024，是），但是调用客户端的应用没有被授权访问blob（图10B的1027，否），则客户端同样接收拒绝其请求的错误消息（图10B的1025）。

如果找到元数据（图10B的1024，是），并且应用也被授权访问blob（图10B的1027，是），则将满足客户端的blob访问请求。在将任何blob元数据返回给blobmaster_A 908-3之前，blobmaster_G 910-1需要决定所请求的blob的新副本是否应当在blobstore_A 908处被动态复制（图10B的1029）。在一些实施例中，blobmaster_G 910-1在作出决定时考虑多个因素。第一因素是在blobstore_A 908和具有所请求的blob的复制品的最近源实例之间的距离。在一些实施例中，在两个blobstore之间的距离通过从目的地blobstore向源blobstore发送请求的第一时刻到目的地blobstore从源blobstore接收响应的第二时刻的延迟来进行测量。例如，可以如下定义预定义的阈值延迟集：对于跨城市的通信，5ms延迟；对于跨洲的通信，40ms延迟；以及对于洲际通信，80ms延迟。在源和目的地实例之间的高于对应阈值水平的延迟可以支持动态复制的决定，反之亦然。

影响blobmaster_G 910的决定的第二因素是用于在源和目的地实例之间动态复制blob的网络连接的成本。由于分布式存储系统典型地将比分配给后台复制更高的优先级分配给动态复制，所以该更高优先级可以对应于更高网络连接成本。在另一方面，该因素用所请求的blob在目的地实例邻近的受欢迎度来平衡。例如，如果在过去已存在对所请求的blob或类似物的较高需求或blobmaster_G 910预期对该blob或类似物的未来需求很高，则其可以确定与动态复制相关联的成本从长远来看是值得的。

可以影响blobmaster_G 910的决定的第三因素是分布式存储系统可能必须遵守某些管理或法定要求。例如，在美国的实例不应当维护所请求的blob的复制品的要求可以否定偏好动态复制的所有其他因素。在一些实施例中，分布式存储系统将动态复制决策过程用于blob，以调整该blob的默认复制策略。例如，客户端可以指定blob的默认复制策略是在分布式存储系统内两个复制品，以及在带存储系统上一个备份复制品。在实际中，如果必要的话，分布式存储系统可以通过动态复制添加blob的更多复制品。

如图10B中所示，假设blobmaster_G 910-1确定不需要复制blob（（图10B的1029，否），例如，在发出请求的客户端附近的至少一个实例中存在blob的复制品，blobmaster_G 910-1将blob的元数据返回给blobmaster_A 908-3（图10B的1031）。如在上面结合图8A-8E所描述的，blob的元数据包括：复制品信息1862，其可以是具有blob的复制品的存储引用的列表；以及blob区段，其是将blob的逻辑地址映射到块ID的区段表。Blobmaster_A 908-3然后将包括区段表、复制品信息和读标记的元数据返回给发出请求的客户端（图10B的1033）。

当接收到元数据时，客户端识别负载平衡的blobstore_C和其bitpusher_C（图10B的1035）。在一些实施例中，该blobstore_C是在客户端904附近的实例。在未来，客户端904将不会为与该blob有关的任何请求联系blobstore_A 908，而是将其对该blob的请求指向blobstore_C。例如，如果客户端904决定检索blob的内容，则客户端904可以将一个或多个读标记发送给bitpusher_C（图10B的1037）。Bitpusher_C然后访问在blobstore C内的对应块存储，并且将所请求的块返回给客户端904（图10B的1039）。

如图9A中所示，如果blobmaster_G 910-1确定需要对客户端请求的blob进行动态复制（图10B的1029，是），则blobmaster_G 910-1然后将是具有所请求的blob的复制品的一个远程实例的blobstore_B906识别为复制的源，并且可选地，将在blobstore_A 908内的chunkstore_A 908-7识别为复制的目的地（图10C的1041）。Blobmaster_G 910-1通过将关于该两个实体的信息和其他blob元数据返回给blobmaster_A 908-3，来触发blobmaster_A 908-3开始对所请求的blob进行动态复制（图10C的1043）。

在一些实施例中，将blob的元数据和内容从源blobstore分别复制到目的地blobstore。客户端的对blob内容的需求通常取决于其对blob元数据的处理结果。有时，客户端在读取blob元数据之后不需要访问blob内容。从blobmaster_G 910-1的响应，blobmaster_A 908-3识别源blobstore_B 906，并且将元数据复制请求发送给blobstore_B 906的blobmaster_B 906-1（图10C的1045）。Blobmaster_B 906-1在接收了该请求时，对元数据表906-5中的blob的元数据进行更新，以指示blob的局部复制品当前正用作动态复制的源，来阻止删除该复制品的任何企图。另外，blobmaster_B 906-1将blob的元数据返回给blobmaster_A908-3。使用所接收的元数据，blobmaster_A 906-3在blobstore 908的元数据表908-11中生成新的条目（图10C的1047）。在一些实施例中，blobmasterP_A 908-3例如通过将blob的终态化状态设置为“uploading（正上载）”，来对元数据表908-11中的新近生成的元数据进行更新，以指示blob的新的复制品正在blobstore 908处被生成。

在一些实施例中，blobmaster_A 908-3将其从blobmaster_B 906-1接收的元数据返回给发出请求的客户端904（图10C的1051）。如上所述，客户端在其能够请求blob内容的任何部分之前需要访问blob的区段表。另外，客户端可以在对元数据进行分析之后，选择不检索任何blob内容。这样做时，blobmaster_A 908-3可以更迅速地对客户端的请求作出响应，而不用等待blob内容从源blobstore_B 906到达目的地blobstore_A 908。从blobmaster_B 906-1所返回的元数据，blobmaster_A908-3识别blob的区段表，其将blob的逻辑范围映射到在blobstore_B906内的块存储处的一个或多个块ID。Blobmaster_A 908-3然后通知blobstore 908的repqueue_A 908-1排定块复制请求，以促使负载平衡的bitpusher_A 908-5从blobstore_B 906检索块（图10C的1049）。

图9D描绘了示例性块复制请求940，其包括多个属性：复制ID942、blob基础ID 944、blob世代ID 946、表示类型948、块列表950以及复制优先级952。在一些实施例中，复制ID 942进一步包括识别在blobstore_B 906内的块存储906-7的源块存储ID、识别在blobstore_A908内的块存储908-7的目的地块存储ID、发起复制的用户ID以及网络服务质量参数。Blob基础ID 944和blob世代ID 946的组合唯一识别待被复制的特定世代的blob。在一些实施例中，两个参数均由发起对blob的访问请求的客户端原始提供。块列表950典型地包括一个或多个块ID和块序列ID对，每一对唯一识别在对应块存储内的块。复制优先级952指示这是较高优先级实时/动态复制还是较低优先级后台复制。

Bitpusher_A 908-5从块复制请求识别待被复制的块列表，并且将该块列表转发给bitpusher_B 906-3。对于待被复制的每一个块，bitpusher_B 906-3生成包括块的元数据的块引用记录，并且将块引用记录与块内容一起返回给bitpusher_A 908-5。

图9C描绘了包括以下多个属性的示例性块引用记录930的数据结构：块ID 932、块序列ID 934、包括blobstore ID 936-1和chunkstore ID936-3的存储引用936、以及包括blob基础ID 938-1、blob世代ID 938-3、在blob内的块偏移938-5、块大小938-7和可选的表示类型938-9的blob引用元数据938。在一些实施例中，块ID 932是具有多个位（例如，64或160）的内容哈希。由于相同块可以具有与不同blob相对应的不同化身，所以块序列ID 934用于使用例如块创建时间戳来识别块的特定化身。

对于bitpusher_B 906-3所返回的每一个块，bitpusher_A 908-5将该块插入对应的目的地chunkstore_A 908-7（图10C的1053）。在一些实施例中，bitpusher_A 908-5使用bitpusher_B 906-3所提供的块引用记录来为新的块生成块索引记录，并且将该块索引记录插入chunkstore_A908-5的块索引表908-9。

图9B描绘了包括以下多个属性的示例性块索引记录920的数据结构：短块ID 922、包括blobstore ID 924-1和chunkstore ID 924-3的存储引用924、块元数据926（进一步包括长块ID 926-1、块创建时间926-3、引用计数926-5、化身（或序列）ID 926-7以及块大小926-9）以及将包括块的一个或多个blob识别为blob的端口的blob引用列表928（每一个blob引用进一步包括blob基础ID 928-1、blob世代ID928-3、在blob内的块偏移928-5以及可选的表示类型928-7）。在一些实施例中，将短块ID 922暴露于客户端，而长块ID 926-1供分布式存储系统内部使用。

注意到，最初存储在元数据表908-11中的blob的元数据是来自blobstore_B 906的元数据的副本。在一些实施例中，同一blob在不同实例处的复制品具有不同的区段表，以反映相应复制品在对应块存储内的精确物理位置。当每一个块从blobstore_B 906到达blobstore_A908，并且安置在blobstore_A 908内的特定块存储处时，对应的blob的区段表相应地需要被更新。在一些实施例中，bitpusher_A 908-5向repqueue_A 908-1通知新的块到达bitpusher_A 908-5处。Repqueue_A908-1然后生成元数据更新，并且将该元数据更新发送给blobmaster_A908-3（图10C的1054）。元数据更新包括新的块在blobstore_A 908内的实际位置（其可以或可以不是chunkstore_A 908-7）。

图9E描绘了包括以下多个属性的示例性元数据更新记录960的数据结构：blob基础ID 962、blob引用ID 964以及识别块驻存于其中的块存储的区段表改变量966。在一些实施例中，blob基础ID 954唯一识别元数据表中的对应元数据条目，以及blob引用ID 956识别元数据条目内的引用元数据子条目。在上面结合图8C提供了引用元数据子条目的更详细描述。

使用元数据更新，blobmaster_A 908-3对blob的区段表进行更新以跟踪到新近到达的块的位置。在一些实施例中，blobmaster_A 908-3检查新近到达的块是否是被排定从blobstore_B 906复制到blobstore_A908的blob的最后块。如果是这样的话，则blobmaster_A 908-3然后检查区段表来确定与同一blob相关联的所有块是否在blobstore_A 908的同一块存储（例如，chunkstore_A 908-7）内。如果是这样的话，则blobmaster_A 908-3将blob的终态化状态从“uploading”更新成“finalized”，指示成功完成客户端请求的blob从blobstore_B 906到blobstore_A 908的动态复制。随后的元数据复制对同一blob在其他实例处的复制品的元数据进行更新，以包括在blobstore_A 908处的新的复制品。

在一些实施例中，当将同一blob的多个块从源blobstore_B 906复制到目的地blobstore_A 908时，它们可以由在blobstore_A 908处的不同bitpusher最初放置入blobstore_A 908内的不同块存储。Blobmaster_A908-3可以通过检查区段表告诉这是否发生。如果与同一blob相关联的多个块位于blobstore_A 908的不同块存储内，则blobmaster_A 908-3将blob的终态化状态从“uploading”更新成“finalizing”。Blobmaster_A908-3然后指示repqueue_A 908-1促使bitpusher_A 908-5将块迁移到blobmaster_G 910-1或blobmaster_A 908-3所选择的目的地块存储。对于每一个迁移的块，repqueue_A 908-1还将元数据更新发送给blobmaster_A 908-3，以对区段表进行更新。当所有块均被发现在同一块存储内时，blobmaster_A 908-3然后将blob的终态化状态从“uploading”更新成“finalized”，指示成功完成客户端请求的blob从blobstore_B 906到blobstore_A 908的动态复制。随后的元数据复制对同一blob在其他实例处的复制品的元数据进行更新，以包括在blobstore_A 908处的新的复制品。

如上所述，块904接收blob的元数据，并且从该元数据提取其区段表。如果客户端904需要访问与blob相关联的一个或多个块，则其可以从区段表识别对应的块ID，并且为所请求的块将块ID以及对应的读标记发送给负载平衡的bitpusher_A 908-5。当接收到客户端请求（图10C的1055）时，bitpusher_A 908-5识别chunkstore_A 908-7中的对应块，并且将它们返回给客户端（图10C的1057）。在一些实施例中，块一到达bitpusher_A 908-5处（例如，如果其已接收对块的客户端请求），bitpusher_A 908-5就将所接收的块直接提供给发出请求的客户端，同时在chunkstore_A 908-7中生成块的局部副本。如上所述，做出blob的局部复制品的决定是为了更迅速地为对同一blob的未来客户端请求服务。在一些实施例中，存储在blobstore_A 908处的blob的新复制品与在blobstore_B 906处的blob的复制品相同。

出于说明目的，参考特定实施例描述了前面描述。然而，在上面的说明性论述并不意在是穷尽的或将本发明限制在公开的精确形式。鉴于上面的教导，许多修改和变化是可能的。为了最好说明本发明的原理及其实际应用，选择并描述了实施例，从而使本领域技术人员能够以适于预期的特定用途的各种修改，最好利用本发明和各种实施例。

Claims (14)

1.一种用于在分布式存储系统内复制对象的计算机实现的方法，其中所述分布式存储系统包括多个存储子系统，包括：

在具有一个或多个处理器和存储由所述一个或多个处理器执行的一个或多个程序的存储器的第一存储子系统处，

从客户端接收对不存在于所述第一存储子系统中的对象的第一客户端请求；

将第二存储子系统识别为具有所请求的对象的复制品，其中所请求的对象包括内容和元数据；

将对所请求的对象的对象复制请求提交给所述第二存储子系统，包括：

将元数据复制请求提交给所述第二存储子系统的元数据管理组件，其中所述元数据复制请求包括所请求的对象的标识符；

从所述第二存储子系统的所述元数据管理组件接收所请求的对象的所述元数据，其中所述元数据包括所请求的对象的区段表；

使用所述区段表来识别所述对象内容在所述第二存储子系统处的位置；以及

将内容复制请求提交给所述第二存储子系统的内容管理组件，其中所述内容复制请求包括所请求的对象的所识别的内容位置；

从所述第二存储子系统独立接收所请求的对象的所述内容和元数据；

当接收到所请求的对象的所述元数据时，

在所述第一存储子系统的元数据表中为所述对象生成元数据条目；

将所接收的元数据插入所述元数据表的新近生成的元数据条目；

将在所述新近生成的元数据条目中的对象状态属性设置为“正上载”；以及

将所述新近生成的元数据条目返回给发出请求的客户端；

使用所接收的元数据和内容在所述第一存储子系统处生成所述对象的新的复制品；以及

将所述对象的所述新的复制品的所述元数据返回给所述客户端。

2.根据权利要求1所述的计算机实现的方法，进一步包括：

当接收到所述第一客户端请求时，

从所述第一客户端请求提取所请求的对象的对象ID；

使用所述对象ID来查询所述第一存储子系统的元数据表；以及

根据查询结果确定所述对象是否存在于所述第一存储子系统中。

3.根据权利要求1和2中的任何一个所述的计算机实现的方法，其中识别第二存储子系统进一步包括：

将对所请求的对象的查询发送给第三存储子系统，其中所述第三存储子系统包括存储在所述多个存储子系统处的对象的元数据；以及

从所述第三存储子系统接收响应，其中所述响应将所述第二存储子系统识别为源并且将所述第一存储子系统内的块存储识别为目的地。

4.根据权利要求1所述的计算机实现的方法，其中所述内容复制请求被给予比不是由实时客户端请求触发的其他内容复制请求更高的优先级。

5.根据权利要求1所述的计算机实现的方法，其中所述对象内容包括一个或多个块，进一步包括：

从所述客户端接收访问所述对象的客户端指定的部分的第二客户端请求；

对于从所述第二存储系统接收的相应块，

如果所述块与所述对象的所述客户端指定的部分重叠，则将所述块返回给所述发出请求的客户端；

将所述块的复制品存储在所述第一存储子系统内；以及

对所述第一存储子系统中的所述元数据条目进行更新，以反映所述块在所述第一存储子系统内的存在。

6.根据权利要求5所述的计算机实现的方法，其中对所述第一存储子系统中的所述元数据条目进行更新进一步包括：

为所述块生成元数据更新，其中所述元数据更新包括所述块在所述第一存储子系统内的位置信息；

使用所述块的所述位置信息来对所述元数据条目的区段表进行更新；

如果所述对象的所述多个块位于所述第一存储子系统的一个块存储内，则将所述元数据条目的所述对象状态属性更新为“已终态化”；以及

如果所述对象的所述多个块位于所述第一存储子系统的多个块存储内，则将所述元数据条目的所述对象状态属性更新为“正在终态化”。

7.根据权利要求6所述的计算机实现的方法，进一步包括：

将所述多个块从所述第一存储子系统的所述多个块存储移动到所述第一存储子系统的目的地块存储；以及

如果所述对象的所述多个块位于所述第一存储子系统的所述目的地块存储内，则将所述元数据条目的所述对象状态属性更新为“已终态化”。

8.一种用于在分布式存储系统内复制对象的计算机系统，其中所述分布式存储系统包括多个存储子系统，包括：

一个或多个处理器；

用于存储一个或多个程序的存储器，其中所述一个或多个处理器被配置成在第一存储子系统处执行所述一个或多个程序，所述一个或多个程序包括用于以下的指令：

从客户端接收对不存在于所述第一存储子系统中的对象的第一客户端请求；

将第二存储子系统识别为具有所请求的对象的复制品，其中所请求的对象包括内容和元数据；

将对所请求的对象的对象复制请求提交给所述第二存储子系统，包括：

将元数据复制请求提交给所述第二存储子系统的元数据管理组件，其中所述元数据复制请求包括所请求的对象的标识符；

从所述第二存储子系统的所述元数据管理组件接收所请求的对象的所述元数据，其中所述元数据包括所请求的对象的区段表；

使用所述区段表来识别所述对象内容在所述第二存储子系统处的位置；以及

将内容复制请求提交给所述第二存储子系统的内容管理组件，其中所述内容复制请求包括所请求的对象的所识别的内容位置；

从所述第二存储子系统独立接收所请求的对象的所述内容和元数据；

使用从所述第二存储子系统接收的所请求的对象的所述元数据，

在所述第一存储子系统的元数据表中为所述对象生成元数据条目；

将所接收的元数据插入所述元数据表的新近生成的元数据条目；

将在所述新近生成的元数据条目中的对象状态属性设置为“正上载”；以及

将所述新近生成的元数据条目返回给发出请求的客户端；

使用所接收的元数据和内容在所述第一存储子系统处生成所述对象的新的复制品；以及

将所述对象的所述新的复制品的所述元数据返回给所述客户端。

9.根据权利要求8所述的计算机系统，进一步包括：

用于从所述第一客户端请求提取所请求的对象的对象ID的指令；

用于使用所述对象ID来查询所述第一存储子系统的元数据表的指令；以及

用于根据查询结果确定所述对象是否存在于所述第一存储子系统中的指令。

10.根据权利要求8和9中的任何一个所述的计算机系统，其中用于识别第二存储子系统的所述指令进一步包括：

用于将对所请求的对象的查询发送给第三存储子系统的指令，其中所述第三存储子系统包括存储在所述多个存储子系统处的对象的元数据；以及

用于从所述第三存储子系统接收响应的指令，其中所述响应将所述第二存储子系统识别为源并且将所述第一存储子系统内的块存储识别为目的地。

11.根据权利要求8所述的计算机系统，其中所述内容复制请求被给予比不是由实时客户端请求触发的其他内容复制请求更高的优先级。

12.根据权利要求8所述的计算机系统，其中所述对象内容包括一个或多个块，进一步包括：

用于从所述客户端接收访问所述对象的客户端指定的部分的第二客户端请求的指令；

对于从所述第二存储系统接收的相应块，

用于如果所述块与所述对象的所述客户端指定的部分重叠，则将所述块返回给所述发出请求的客户端的指令；

用于将所述块的复制品存储在所述第一存储子系统内的指令；以及

用于对所述第一存储子系统中的所述元数据条目进行更新，以反映所述块在所述第一存储子系统内的存在的指令。

13.根据权利要求12所述的计算机系统，其中用于对所述第一存储子系统中的所述元数据条目进行更新的所述指令进一步包括：

用于为所述块生成元数据更新的指令，其中所述元数据更新包括所述块在所述第一存储子系统内的位置信息；

用于使用所述块的所述位置信息来对所述元数据条目的区段表进行更新的指令；

用于如果所述对象的所述多个块位于所述第一存储子系统的一个块存储内，则将所述元数据条目的所述对象状态属性更新为“已终态化”的指令；以及

用于如果所述对象的所述多个块位于所述第一存储子系统的多个块存储内，则将所述元数据条目的所述对象状态属性更新为“正在终态化”的指令。

14.根据权利要求13所述的计算机系统，进一步包括：

用于将所述多个块从所述第一存储子系统的所述多个块存储移动到所述第一存储子系统的目的地块存储的指令；以及

用于如果所述对象的所述多个块位于所述第一存储子系统的所述目的地块存储内，则将所述元数据条目的所述对象状态属性更新为“已终态化”的指令。