CN110402429B - 复制用于管理基于云的资源的存储表以抵挡存储账户中断 - Google Patents

Abstract

跨多个数据中心复制存储账户，以便抵挡存储账户的中断。前端和应用使用被存储在存储账户中的数据以管理云计算系统的资源。除了由应用用于访问存储账户的接口之外，客户端还包括由前端用于访问存储账户的接口。确保即使头副本或者尾副本故障时读操作也存活的其他特征包括：从头副本而不是从尾副本读取两阶段准备‑提交操作，以将变化从头副本传播到尾副本，以及如果在准备‑提交操作的中间发生故障，则提供后端修复服务。

Description

复制用于管理基于云的资源的存储表以抵挡存储账户中断

技术领域

本公开总体上涉及云计算系统，并且更特别地涉及复制用于管理基于云的资源的存储表以抵挡账户中断。

背景技术

本文所提供的背景描述用于总体呈现用于本公开的上下文的目的。在该背景章节中描述的程度上，目前命名的发明人的工作以及可以不在提交时以其他方式限制为现有技术的描述的各方面既不明确地也不隐含地承认为针对本公开的现有技术。

在云计算系统中，存储账户存储用于管理云计算系统的资源的数据。被存储在存储账户中的数据允许客户访问云计算系统的资源。如果存储账户发生故障，则由云计算系统提供给客户的基于云的服务全局发生故障，并且客户不能管理其任何区域中的资源。

发明内容

一种系统包括处理器和存储器，以及被存储在存储器中的机器可读指令。机器可读指令当由处理器执行时，将处理器配置为存储数据作为一个或多个表中的实体。机器可读指令将处理器配置为经由第一接口将一个或多个表的多个副本对接到应用。应用经由第一接口访问来自多个副本之一的数据。机器可读指令将处理器配置为经由第二接口将多个副本对接到云计算系统的资源管理服务。资源管理服务基于被存储在一个或多个表中的数据来管理云计算系统的资源。

在其他特征中，数据包括结构化且非关系型数据。

在其他特征中，机器可读指令还将处理器配置为：将来自多个副本的每个副本存储在不同数据中心中，以当数据中心之一发生故障时保护数据。

在其他特征中，机器可读指令还将处理器配置为：生成一个或多个表的多个副本的有序集；通过从有序集中的第一副本到最后副本顺序写入来执行写操作；通过从最后副本到第一副本顺序验证写操作的完成来确认写操作的成功；以及当写操作在第一副本与最后副本之间发生故障时，从第一副本进行读取以防止返回不正确的数据。

在其他特征中，机器可读指令还将处理器配置为：生成新副本；以及在最后副本之后添加新副本。

在其他特征中，机器可读指令还将处理器配置为：生成包括与第一副本一致的数据的新副本；在后台中生成新副本；以及在最后副本之后添加新副本。

在其他特征中，机器可读指令还将处理器配置为：生成一个或多个表的多个副本的有序集；以及通过从有序集中的第一副本到最后副本顺序写入来执行写操作。当写操作在第一副本与最后副本之间的一个副本上发生故障时，机器可读指令还将处理器配置为在后台中对一个副本执行修复操作。

在其他特征中，机器可读指令还将处理器配置为：通过当写操作在第一副本与最后副本之间的一个副本上发生故障时将事件添加在存储队列中，并且通过激活执行后台中的修复操作的修复服务，来在后台中对一个副本执行修复操作。

在其他特征中，机器可读指令还将处理器配置为生成一个或多个表的多个副本的有序集。当有序集中的第一副本发生故障时，机器可读指令还将处理器配置为：移除第一副本，使用有序集中的最后副本作为新的第一副本，以及添加新的最后副本。

在其他特征中，机器可读指令还将处理器配置为生成一个或多个表的多个副本的有序集。当有序集中的最后副本发生故障时，机器可读指令还将处理器配置为移除最后副本，以及添加新的最后副本。

而在其他特征中，方法包括存储数据作为一个或多个表中的实体，该数据包括结构化且非关系型数据。方法还包括经由第一接口将一个或多个表的多个副本对接到应用。应用经由第一接口访问来自多个副本之一的数据。方法还包括经由第二接口将多个副本对接到云计算系统的资源管理服务。资源管理服务基于被存储在一个或多个表中的数据来管理云计算系统的资源。

在其他特征中，方法还包括将来自多个副本的每个副本存储在不同数据中心中，以当数据中心之一发生故障时保护数据。

在其他特征中，方法还包括：生成一个或多个表的多个副本的有序集；通过从有序集中的第一副本到最后副本顺序写入来执行写操作；通过从最后副本到第一副本顺序验证写操作的完成来确认写操作的成功；以及当写操作在第一副本与最后副本之间发生故障时，从第一副本进行读取以防止返回不正确的数据。

在其他特征中，方法还包括：生成新副本；以及在最后副本之后添加新副本。

在其他特征中，方法还包括：生成包括与第一副本一致的数据的新副本；在后台中生成新副本；以及在最后副本之后添加新副本。

在其他特征中，方法还包括：生成一个或多个表的多个副本的有序集；以及通过从有序集中的第一副本到最后副本顺序写入来执行写操作。当写操作在第一副本与最后副本之间的一个副本上发生故障时，方法还包括在后台中对一个副本执行修复操作。

在其他特征中，方法还包括：通过当写操作在第一副本与最后副本之间的一个副本上发生故障时将事件添加在存储队列中，并且通过激活后台中的修复操作的修复服务，来在后台中对一个副本执行修复操作。

在其他特征中，方法还包括生成一个或多个表的多个副本的有序集。当有序集中的第一副本发生故障时，方法还包括：移除第一副本，使用有序集中的最后副本作为新的第一副本，以及添加新的最后副本。

在其他特征中，方法还包括：生成一个或多个表的多个副本的有序集。当有序集中的最后副本发生故障时，方法还包括移除最后副本，以及添加新的最后副本。

而在其他特征中，一种系统包括处理器和存储器，以及被存储在存储器中的机器可读指令。机器可读指令当由处理器执行时，将处理器配置为存储数据作为一个或多个表中的实体。数据包括用于管理云计算系统的资源的结构化且非关系型数据。机器可读指令将处理器配置为：生成一个或多个表的多个副本的有序集；以及经由第一接口将多个副本对接到应用。应用经由第一接口访问来自多个副本之一的数据。机器可读指令将处理器配置为经由第二接口将多个副本对接到云计算系统的资源管理服务。资源管理服务基于被存储在一个或多个表中的数据来管理云计算系统的资源。机器可读指令将处理器配置为：通过从有序集中的第一副本到最后副本顺序写入来执行写操作；以及通过从最后副本到第一副本顺序验证写操作的完成来确认写操作的成功。机器可读指令将处理器配置为：当写操作在第一副本与最后副本之间发生故障时，从第一副本进行读取以防止返回不正确的数据。机器可读指令将处理器配置为：当写操作在第一副本与最后副本之间的一个副本上发生故障时，在后台中对一个副本执行修复操作。当有序集中的第一副本发生故障时，机器可读指令还将处理器配置为：移除第一副本，使用有序集中的最后副本作为新的第一副本，以及添加新的最后副本。当有序集中的最后副本发生故障时，机器可读指令还将处理器配置为移除最后副本，以及添加新的最后副本。

本公开的适用性的进一步的领域将从具体实施方式、权利要求和附图变得明显。具体实施方式和特定示例旨在仅出于图示的目的并且不旨在限制本公开的范围。

附图说明

图1示出了存储账户中的云存储资源之间的关系。

图2示出了存储表服务的组件的示例。

图3是云计算系统的简化示例的功能块图。

图4示出了包括存储账户的图3的云计算系统的前端。

图5示出了被布置为有序集的存储账户的副本链。

图6-8示出了被维持在存储表中的每行元数据。

图9示出了由与存储账户的副本链相关联的配置服务的恢复代理执行的方法的流程图。

图10示出了与存储账户的副本链相关联的配置服务的简化示例的功能块图。

图11示出了被存储在图10中所示的配置服务的配置存储库中的逻辑数据结构的示例。

图12示出了用于更新被存储在图10中所示的配置存储库中的副本集的方法的流程图。

图13示出了由图3中所示的云计算系统的前端用于维持不同数据中心中的存储账户的副本的复制表(RTable)系统的简化示例的功能块图。

图14示出了图13中所示的复制表(RTable)系统的复制表客户端的简化示例的功能块图。

图15示出了用于向复制表客户端提供将副本集对接到图3中所示的云计算系统的前端和应用的接口的方法的流程图。

图16示出了在副本上执行的读/写程序。

图17示出了用于从副本读取数据的获得协议的流程图。

图18示出了用于将数据写入副本的写入协议的流程图。

图19示出了用于通过首先从头副本读取数据来执行读操作的方法的流程图。

图20示出了用于在后台中执行修复操作的方法的流程图。

图21示出了当数据从尾副本读取时读/写操作的状态。

图22示出了当数据从头副本读取时读/写操作的状态。

图23示出了用于从头副本读取的方法的流程图。

图24是分布式网络系统的简化示例的功能块图。

图25是在图24的分布式网络系统中使用的客户端设备的简化示例的功能块图。

图26是在图24的分布式网络系统中使用的服务器的简化示例的功能块图。

在附图中，附图标记可以重新用来标识类似和/或相同元件。

具体实施方式

本公开提出跨多个数据中心复制云计算系统的存储账户并且维持复制存储账户链以抵挡存储账户的中断。云计算系统的前端和一个或多个应用访问复制存储账户并且使用被存储在存储账户中的数据以管理云计算系统的资源。

客户端使用对应的接口将前端和应用对接到复制存储账户。特别地，除了客户端具有并且由应用用于访问存储账户的另一接口之外，本公开向客户端提供由前端用于访问存储账户的接口，使得前端和应用二者能够使用相应接口来访问复制存储账户。

另外，如下面详细解释的，本公开提出从头副本而不是尾副本读取两阶段准备-提交操作以将变化从头副本推送或传播到尾副本，以及如果在准备-提交操作的中间发生故障，则提供后端修复服务。由本公开提出的复制架构确保即使头副本故障或者尾副本故障，读操作也存活。下面详细描述了本公开的这些和其他特征。

本公开组织如下。参考图1-2呈现了表存储和存储账户的简要概述。参考图3和4描述了根据本公开的包括复制存储账户的云计算系统的简化示例。参考图5-9解释了包括复制表(RTable)应用程序接口(RTable API)、复制表库的存储表的副本的操作、两阶段准备-提交操作、读-写操作、处理数据中心中断、以及将新副本引入在副本链中。参考图10-12解释了配置服务、复制表客户端、配置代理以及与副本相关联的配置存储库的操作，包括在运行中副本操作期间处理重新配置。

参考图13-14描述了根据本公开的复制表(RTable)系统的组件。参考图14-15描述了根据本公开的复制表客户端。参考图16-19描述了来自头副本而不是尾副本的读取，还被称为安全读操作。参考图20描述了当写操作在副本链的中间发生故障时修复副本。参考图21-23描述了读操作可以总是在本公开的复制表系统中存活而不管头副本发生故障还是尾副本发生故障的方式。此后，参考图24-26描述了分布式网络系统的简化示例，其可以用于实现包括图3-4中所示的根据本公开的复制存储账户的云计算系统。

在解释存储账户的副本之前，云存储(特别地表存储)和存储账户简要被解释以更好理解其根据本公开的副本和相关架构。此后，其中数据从尾副本读取的存储表副本被解释以理解其缺点并且理解随后描述的通过从头副本读取数据提供的改进。

云计算实现用于要求用于其数据的可扩展、耐久和高度可用存储的应用的新场景。云存储可从无论在云中、在台式电脑上、在预置服务器上还是在移动或平板设备上运行的任何类型的应用从世界上任何地方访问。云存储经由对于能够经由超文本传送协议/安全(HTTP/HTTPS)发送和接收数据的任何客户端可用的简单表述性状态转移(REST)API暴露数据资源。

云存储提供以下四个服务：二进制大对象(Blob)存储、表(Table)存储、队列(Queue)存储和文件(File)存储。二进制大对象存储装置存储非结构化对象数据。二进制大对象可以是任何类型的文本或二进制数据，诸如文档、媒体文件或应用安装器。二进制大对象存储也被称为对象(Object)存储。表存储装置存储结构化数据集。表存储是NoSQL键属性数据存储库，其允许对大量的数据的快速开发和快速访问。队列存储装置为工作流处理并且为云服务的组件之间的通信提供可靠消息。文件存储装置使用标准服务器消息块(SMB)协议为传统应用程序提供共享存储。虚拟机和云服务可以经由安装共享跨应用组件共享文件数据，并且预置应用可以经由文件服务REST API访问共享中的文件数据。

图1示出了存储账户中的云存储资源之间的关系。存储账户是给定客户对云存储2中的服务的访问权的安全账户。存储账户为客户的存储资源提供唯一命名空间。存储账户可以具有两种类型：通用存储账户和二进制大对象存储账户。通用存储账户给定客户对云存储服务(诸如在单个账户下的表、队列、文件、二进制大对象和虚拟机盘)的访问权。二进制大对象存储账户是用于存储非结构化数据作为云存储2中的二进制大对象(对象)的专用存储账户。

二进制大对象存储对于具有存储在云中的大量的非结构化对象数据的用户是有用的。客户可以使用二进制大对象存储以存储：内容，诸如文档；社交数据，诸如照片、视频、音乐和博客；文件、数据库、计算机和设备的备份；用于网络应用的图像和文本；用于云应用的配置数据；以及大数据，诸如日志和其他大型数据集。每个二进制大对象被组织到容器中。容器还可以提供将安全策略分配给对象组的有用方式。存储账户可以包含任何数目的容器，并且容器可以包含数目的二进制大对象，多达存储账户中的容量限制。

表存储是具有方案较少设计的NoSQL键/属性存储库，这使其与传统关系数据库不同。利用方案较少数据存储库，随着应用演变的需要适配数据是容易的。表存储是键属性存储库，这意味着表中的每个值与键入的特性名称一起存储。特性名称可以被用于过滤和指定选择准则。特性和其值的集合包括实体。由于表存储是方案较少的，因而相同表中的两个实体可以包含特性的不同集合，并且那些特性可以具有不同类型。

表存储可以被用于存储灵活数据集，诸如用于网络应用的用户数据、地址本、设备信息和服务要求的任何其他类型的元数据。客户可以将任何数目的实体存储在表中，并且存储账户可以包含任何数目的表，高达存储账户的容量限制。类似二进制大对象和队列，开发者可以使用标准REST协议来管理和访问表存储。表存储还支持OData协议的子集，简化高级查询能力并且实现JSON和AtomPub(基于XML的)格式二者。对于现今的基于因特网的应用，类似表存储的NoSQL数据库向传统关系数据库提供受欢迎的备选方案。

队列存储为应用组件之间的异步通信提供可靠消息方案，无论是否其在云中、在台式电脑上、在预置服务器上或在移动设备上运行。队列存储还支持管理异步任务并且建立过程工作流。存储账户可以包含任何数目的账户。队列可以包含任何数目的消息，高达存储账户的容量限制。

由于文件存储共享是标准SMB文件共享，因而在运行中运行的应用可以经由文件系统I/O API访问共享中的数据。类似其他云存储服务，文件存储暴露用于访问共享中的数据的REST API。分布式应用还可以使用文件存储来存储和共享有用的应用数据和开发和测试工具。

图2示出了存储表服务4的组件的示例。例如，存储表服务4的组件包括存储账户、表和实体。存储表服务以存储表的形式提供结构化存储。存储账户是存储系统内的全局唯一实体。存储账户是用于存储表服务的父命名空间并且是用于验证的基础。客户可以在给定存储账户内创建任何数目的存储表，只要每个表唯一命名。

存储表存储数据作为实体的集合。实体类似于行。实体具有主键和特性集。特性是类似于列的名称、键入值对。存储表服务未实施用于存储表的任何方案。因此，相同存储表中的两个实体可以具有不同的特性集。开发者可以选择在客户端侧实施方案。存储表可以包含任何数目的实体。

对于理解以下公开有用的存储账户和存储表的概要如下。存储账户：对云存储的所有访问通过存储账户。存储表：存储表是实体的集合。存储表不在实体上实施方案，这意味着单个存储表可以包含具有不同的特性集的实体。存储账户可以包含的存储表的数目仅由存储账户容量限制来限定。实体：实体是特性集，类似于数据库行。例如，实体可以在大小方面高达1MB。特性：特性是名称-值对。例如，每个实体可以包括多达252个特性以存储数据，并且每个实体可以具有指定分区键、行键和时间戳的3个系统特性。具有相同分区键的实体可以更迅速地查询，并且在原子操作中被插入/更新。实体的行键是其分区内的唯一标识符。

图3示出了根据本公开的云计算系统(CCS)10的简单化示例。云计算系统10包括云控制器12和至少一个数据中心14。虽然为了简单起见仅示出一个数据中心14，云控制器12可以与多个数据中心进行对接。此外，虽然数据中心14被示出为本地于云控制器12，但是一个或多个数据中心可以地理上远程于云控制器12，可以定位在不同地理位置(例如，在不同时区、不同国家或大陆等)中，并且可以经由各种网络与云控制器12通信。云控制器12控制一个或多个数据中心14。

每个数据中心14包括多个结构控制器32-1、32-2、...、和32-n(统称为结构控制器32)和对应的集群34-1、34-2、...和34-n(统称为集群34)。每个结构控制器32控制相应集群34。每个集群34包括多个机架(未示出)，并且每个机架包括多个节点(也未示出)，其贯穿本公开还被称为服务器、主机或者机器。每个结构控制器32与分配器36相关联，分配器36针对在集群34上托管的客户服务的实例，分配集群34内的资源。

云控制器12包括客户可以用来选择资源和请求服务部署的门户20和软件开发包(SDK)22。云控制器12还包括云资源管理器24、计算资源提供者26和前端28。前端28与一个或多个数据中心14的结构控制器32进行对接。云资源管理器24接收客户选择并且将客户选择转发给计算资源提供者26。计算资源提供者26基于客户选择生成租户模型。计算资源提供者26根据基于客户选择所生成的租户模型向客户服务提供资源。计算资源提供者26通过与云存储(Xstore)30、网络资源提供者31和结构控制器32进行对接来提供存储、联网和计算资源。

图4示出了前端28包括存储账户40。例如，存储账户40可以包括图1-2中所示的一个或多个存储账户。前端28与存储账户40的多个副本进行对接。例如，存储账户40的副本包括头副本50-1的有序集，跟随有一个或多个副本，以及尾副本50-N，其中N是大于1的整数(统称为副本50)。例如，复制50中的每一个可以定位在不同的数据中心14中。

在云计算系统(例如，图3中示出的CCS 10)中，(云计算系统10内部和外部的)许多服务使用表存储来存储和查询结构化的非关系型数据。表存储提供好并且简单的NoSQL抽象以存储数据作为表中的行，并且允许基于主键的表中的查询。

存储账户中的数据被复制以确保耐久性和高可用性。复制将数据复制在相同数据集内或者到第二数据中心，这取决于所选择的复制选项。复制在瞬态硬件故障的情况下保护数据并且保留应用运行时间。如果时间被复制到第二数据中心，则其还保护数据免于主位置中的灾难性故障。

底层云存储基础设施跨数据中心异步复制数据，其意味着其可以仅限制当存在云存储戳故障时的数据丢失量。更特别地，存储表不能防止数据丢失或者提供一致性恢复。虽然一些服务不需要严格的耐久性和一致性保证，但是数据丢失或者不一致恢复可能影响其他服务。例如，在网络或者存储中断的情况下，依赖于云存储的服务可能遭受管理层中断。

作为朝着解决该问题的步骤，本公开提供跨多个数据中心同步复制存储表以提供以下保证而不管数据中心中断的复制表(RTable)系统的设计：(1)通过防止数据丢失而不管固定数目(t)的数据中心故障的高数据耐久性，(2)通过从故障提供一致并且快速的恢复而不放弃耐久性保证的高可用性。这些保证实现立即的故障移转到二级存储戳，同时确保零数据丢失和强一致性。

复制表设计可以满足以下设计约束，同时提供以上耐久性和可用性保证。复制成本：复制表设计可以保持复制成本(存储和联网)很低。特别地，复制表设计可以使用容许具有尽可能少副本的(t)个数据中心故障的协议。为了满足耐久性保证，复制表设计不能使用少于(t+1)个副本。复制成本(不超过(t+1)个副本)和耐久性保证(无数据丢失，尽管(t)个故障)是在设计复制表系统时的主要约束。

兼容性：许多工具(例如，分析和监视)使用存储表接口从单个副本读取数据。大多数这样的服务可以甚至在复制数据之后未修改并且不中断运行。复制表协议可以确保这样的查询甚至在网络分区下读取一致性数据。

客户端库：复制表设计可以在未修改的表存储之上建立副本。特别地，仅假定被动的表存储系统，复制协议可以通过无状态客户端库运行。因此，复制表设计可以对于客户端故障是鲁棒的。

监视和配置服务：任何复制协议要求维持关于系统(副本集)的当前视图的信息的服务。这可以通过改变故障上的复制成员资格的人类操作者来完成。复制表设计可以将该服务建立到可以使监视和配置过程自动化的客户端库(使用容错的基于云存储的首项选择协议，其可以容许单个云存储戳故障)。

复制表设计可以支持复制表API中的所有表存储调用，使得客户端应用必须做出最小改变。本公开描述了复制表如何实现取回和插入或替换调用以读取并且更新复制表中的行。

复制表设计使用链复制协议。广义地说，链复制(顺序协议)和基于定额(quorum)的复制(并行协议)是用于同步复制数据的两种主要技术。选择链复制的主要原因是其低复制成本((t+1)个副本可以容许(t)个故障)、低的读开销(从单个副本读取)、读取(从任何副本读取)的更好的负载平衡、以及其简单性(关于故障的更简单的恢复机制)。在本公开中稍后详细讨论了用于选择复制表系统中的链复制的折衷和设计原理。

客户端应用使用复制表取回和插入或替换API调用来读取和写入到复制表行。内部地，复制表库跨多个数据中心同步复制数据以容许个体表故障。

现在详细描述复制表库。复制协议在存储表API顶部的客户端库内完全实现。当客户端应用调用复制表库读/写时，复制表库在使用存储表API下与个体存储表副本相互作用。复制表库使用副本被布置在有序链中的链复制，使得锁定连同写入和提交数据一起获得和释放，如图5中所示。

在图5中，N个副本(其中N是大于1的整数)的有序集中的第一副本被称为头副本(52-1)。副本的有序集中的最后副本被称为尾副本50-N。副本的有序集中的剩余副本被称为中间副本(50-2、...和50-(N-1))。

复制表库从配置服务连同在其期间副本集不能改变的租赁时间一起获得当前副本集。在租赁间隔终止之后，复制表库周期性地更新副本集(或者视图)。配置服务(下文解释的)被用于如果单独表副本是不可到达并且被认为是故障副本，则在当前租赁间隔的末尾更新视图(副本集)，并且开始在下一租赁期内提供新视图。当表故障发生时，客户端观察用于写操作的超时和故障，直到客户端一旦租赁终止就接收新视图。对于读操作，客户端可以在不存在冲突写操作在进行中的情况下从如下文解释的任何副本获取数据，或者在冲突写操作在进行中的情况下从尾副本获取数据。读操作仅在尾节点(即，尾副本)故障的情况下被阻止。

图6-8示出了复制表系统维持每行协议元数据以从客户端和数据中心故障正确恢复行。复制表系统将四个特性(列)添加到实体(行)以维持其每行复制状态：版本(V)、锁定位(L)、锁定采集时间(Ltime)和视图id(Vid)，如图6中所示。LTime是当客户端获得行上的锁时的墙锁时间集。复制表系统使用LTime检测不完整操作(由于客户端故障)，使得其他客户端(或者周期性清理过程)可以完成不完整操作并且将行解锁。复制表系统使用版本号以跟踪行的最新版本。给定底层副本可以具有用于行的不同物理电子标签，当其在行上执行读-修改写操作(诸如替换(Replace))时，复制表系统还使用版本号作为用于复制行的虚拟电子标签。视图id是由配置服务供应的索引，其将索引内部映射到当行被修改时有效的副本集。复制表系统使用该信息跟踪链成员，调节副本故障的存活副本的复制状态，并且当恢复副本被添加回副本链时使恢复副本回到一致和更新状态。

写协议如下。当客户端更新或者插入行时，复制表系统使用链复制协议在将响应发送回客户端之前跨所有副本同步复制新数据。复制表系统在两阶段协议的执行期间从头副本到尾副本在有序链中顺序地与副本相互作用，如下文解释的。

两阶段协议的以下描述使用两个假定：1)视图和版本号单调增加并且不回转。2)任何新副本总是在具有视图改变的头处引入。

第一阶段被称为准备和锁定阶段。当应用修改复制表中的行时，客户端库首先在头副本处读取该行。如果在头处读取的视图数目与当前视图相同，则客户端库试图首先在头副本处原子地设定锁定位。这可以通过使用电子标签提供读取-修改-写入语义的表替换调用完成。如果头副本处的视图高于客户端的视图，则客户端库刷新视图并且重新试图在新视图中的头副本处获得锁定。

如果客户端不能获得锁定——因为锁定位已经设定或者设置锁定位由于冲突异常故障——客户端库后退并且等待直到当前锁定所有者释放锁定或者LTime针对当前锁定终止，在该点处，客户端在获得锁定之前完成由故障客户端剩余的任何未完成的更新。

头副本充当同步点，使得当存在对于来自多个客户端的相同行的并发更新时，仅一个客户端可以继续写操作。然而，对不同行的更新可以并行发生，因为每行存在单独的锁定位。

如果并且当客户端在头副本处获得锁定时，复制表系统还沿着锁定位原子地在适当的位置重写数据(和其版本)，因为其是相同实体的一部分。复制表系统然后获得锁定并且在副本链中顺序更新其他表副本处的数据，直到其到达尾副本。锁定阶段当在所有副本处获得锁定时结束。图7示出了在该阶段的结尾处的副本的状态。

如果客户端由于冲突异常未能获得除头副本之外的副本处的锁定，则这必须归因于视图改变并且当前副本已经变为新视图中的头副本。客户端刷新其视图并且按照用于写入到新的头副本的上文所描述的协议。

第二阶段被称为提交和解锁阶段。复制表系统通过首先在尾副本处解锁和提交数据开始第二阶段。复制表系统然后通过在链的反向路径上在每个副本处顺序解锁和提交、在尾副本处开始、并且朝向头副本移动来继续。复制表系统然后将成功指示返回给用于写操作的客户端应用。图8示出了在提交阶段之后的表副本的状态。

可以执行优化如下。给定第一阶段的最后一步和第二阶段的第一步在尾节点(即，尾副本)处连续发生，准备和锁定步骤可以通过在单个步骤中在尾节点处直接提交数据在尾节点处而被跳过，并且从尾节点的前驱开始第二阶段。

尾副本具有数据的授权副本。注意，尾副本首先在任何其他副本之前原子地提交数据。因此，尾副本充当客户端可以从其读取最新提交数据并且提供强一致性(用于单行读/写的可线性化)的授权副本。

现在解释读协议。当客户端从复制表(即，副本集)读取数据时，复制表系统可以总是从尾节点(即，尾副本)获取数据。由于所有写操作首先在尾副本上提交，因而尾副本保证具有最新提交数据。

可以执行优化如下。复制表系统可以使用锁定位实现其中客户端可以从任何副本而不是仅尾副本读取的读优化。如果锁定位未设定，则复制表库返回数据。如果锁定位设定，则复制表库丢弃结果并且从尾节点获取数据。

在读和写操作期间的客户端故障处理如下。复制表系统使用被存储在行中的协议元数据从客户端故障进行恢复。恢复操作完全地在客户端运行而不要求来自外部服务的任何支持。

当读操作不改变系统中的任何状态时，在读操作的中间的客户端故障不要求任何清理。客户端在故障的读操作上重试并且保证当读操作成功时接收一致数据。

此外，读操作由于故障客户端不由不完整写操作阻止，因为尾节点将阶段1和阶段2整理为单个原子表写操作。也即，复制表不在尾节点处设定锁定位。客户端可以总是独立于其他并发写操作的状态而从尾节点进行读取。

客户端可能在写操作的中间发生故障并且使系统跨副本处于不一致状态。然而，根据本公开的恢复过程通过允许其他客户端完成由故障客户端剩余的不完整写操作而确保正确性。下面是各种故障场景并且复制表系统如何正确对其进行处理。

如果客户端在其获得头上的锁定之前发生故障，则不需要动作，因为操作从副本的视角尚未开始。然而，如果客户端在获得锁定之后但是在成功指示被返回到应用之前发生故障，则以下三种情况是可能的。

第一，客户端可能在其获得头节点上的锁定但是未在其他副本上获得锁定的第一阶段的结束之前发生故障。(注意，锁定位没有设定在尾副本上)。在这样的情况下，其他客户端不能写入到行直到用于行的Ltime(锁定终止时间)终止。直到然后写入到行尾。在Ltime的终止之后，其他客户端通过完成不完整操作来代表故障客户端清理行。其他客户端通过从故障客户端停止处开始写操作而继续，在第一阶段中获得锁定，在第二阶段中提交并且释放锁定。当在头副本处原子更新锁定和数据时，清理过程具有通过读取头副本完成操作要求的所有数据。在清理完成之后，客户端可以继续写入到相同行。

第二，客户端可能在头节点解锁并且提交数据(原子操作)之前在第二阶段中发生故障。在这种情况下，数据至少在尾节点处提交，其可能已经由一个或多个其他客户端读取。复制表系统必须保证该数据最终在其他副本处提交以确保一致性。给定头节点尚未释放锁定，无其他客户端写入到行，直到客户端运行清理过程以首先释放锁定。这意味着最终正试图获得锁定的客户端通过运行第二阶段并且在释放头副本处的锁定之前提交操作来完成操作。

第三，客户端可能在第二阶段的结束之后但是在客户端接收到确认之前发生故障。在这种情况下，操作已经在所有副本处完成，并且不需要做任何事情。由于释放头副本上的锁定，因而其他客户端未被阻止。

因此，在所有情况下，复制表系统可以最终通过其他正确客户端通过总是完成不完整写操作而正确地从客户端故障恢复，使得客户端不会看到稍后撤回的数据。一旦更新到达头，则更新不会由于客户端故障而丢失。

数据中心中断处理如下。当数据中心由于网络分区或者地理灾害不可达时，复制表系统通过改变配置服务中的视图来确保一致恢复，其从副本集移除故障副本(数据中心)。客户端从配置服务读取当前视图，将当前视图本地高速缓存，并且当视图租赁时间终止时周期性地更新其本地副本。下面描述了读可用性和写可用性。

读操作不由非尾副本故障影响，因为尾副本可以继续服务读请求而不管故障。然而，当尾副本故障时，如果锁定位未针对正访问的行设定，则其他副本可以仍然提供数据，因为其他副本可能在其他副本提交并且解锁其局部位之后进行响应。然而，如果锁定位在每个可用副本处设定时，那么对行的读操作发生故障，直到视图改变并且行写操作使用上文所描述的恢复协议完成。

当数据中心故障时，写操作发生故障，直到视图改变并且故障副本从链移除。因此，写可用性取决于(下文所描述的)监视和重新配置服务通过替换故障副本(以利用相同耐久性保证运行)或者移除故障副本(以具有较少副本的较低耐久性运行，直到故障副本替换)多么迅速地检测并且修复链。避免该约束同时满足使用仅(t+1)个副本容许(t)个数据中心故障的耐久性保证是不可能的。

现在描述引入新副本或者重新引入分区副本。复制表系统允许引入新副本或者将旧分区副本重新引入系统中。然而，新副本和旧副本不具有与链中的现有副本一致的数据。重要的是，在不影响一致性的情况下，仔细(重新)引入这些副本。

配置服务使用活动恢复机制引入新副本或者将现有副本重新引入到链中而不停止读或写操作。配置服务使用读视图(read-view)和写视图(write-view)的概念实现这一点。读视图仅具有链的现有副本并且为读操作提供一致视图。写视图使现有副本和新副本二者前缀到读视图链，使得新写操作转到这两个副本集。

客户端应用使用读视图读取数据并且使用写视图写入数据。在写操作期间(在锁定或者提交阶段期间；并且在将写操作成功指示返回给客户端之前)，如果客户端检测到复制表读视图和写视图是不同的，则客户端首先在继续其写操作之前调用图9中所示的恢复协议100。客户端仅需要调用对于行的恢复协议一次，因此其可以继续写入到相同行而不再调用恢复。

在图9中，配置服务开始恢复代理以通过在读视图的头中的行上迭代并且跟随如所示的协议来异步将数据从读视图复制到新副本。在102处，恢复代理在读视图的头处并且在写视图的头处读取行。在104处，恢复代理检查写视图的视图ID是否大于或等于当引入副本时的视图ID。如果写视图的视图ID大于或等于当引入副本时的视图ID，则恢复代理停止。在106处，如果写视图的视图ID小于当引入副本时的视图ID，则恢复代理检查行是否存在于读视图中。在108处，如果行不存在于读视图中，则恢复代理从写视图删除行，并且恢复代理停止。

在110处，如果行存在于读视图中，则恢复代理检查行是否锁定在读视图中。在112处，恢复代理试图在读视图的头处进行锁定。在114处，恢复代理检查在读视图的头处进行锁定的尝试是否成功。如果在读视图的头处进行锁定的尝试失败，则恢复代理返回102。在116处，如果在读视图的头处进行锁定的尝试成功，则恢复代理将行更新或者从读视图插入到写视图。在118处，除非其已经锁定，否则恢复代理将读视图的头解锁。在120处，如果锁定终止，则执行flush2pc操作(下文所描述的)，并且恢复代理停止。

在恢复客户端完成在行上迭代之后，新副本是最新的。在恢复在进行中时发生的任何写入已经写入到新副本。尾副本继续保持授权副本。

恢复客户端将成功指示返回到配置服务，其进而改变读视图和写视图以包括链中的所有副本。客户端获得具有包括在其中的所有副本的新的读视图和写视图。对于视图的该变化不需要原子发生并且最终被传播到所有客户端。如果一些客户端在旧视图中操作，而其他客户端在新视图中操作，协议仍然确保正确性，因为其全部从写视图开始写操作并且从相同尾副本开始读取。

多个视图变化可以在先前视图变得稳定之前发生，即，读视图和写视图具有相同副本。协议通过跟随用于前缀到读视图的链的以上程序来处理这一点。

为了插入操作，客户端首先创建用于具有设定在头副本上的锁定位的行的逻辑删除(tombstone)条目(没有任何数据)。客户端然后首先在头副本处并且然后沿着链在其他副本处插入行。由于缺乏存储表上的日落，因而这防止客户端与恢复代理之间的竞争条件。

以下场景可能发生：1)在时间T1处，在视图v1中仅存在副本R1。R1是头副本和尾副本二者。2)客户端C1发出用于副本R1上的行K1的插入。3)视图改变到v2，并且引入副本R2。4)恢复代理发现行K1不存在于副本R1上并且声明副本R2与副本R1同步。5)视图改变到v3。6)从以上步骤#2在行R1上插入在副本R1上完成。

如果未首先引入逻辑删除条目，那么恢复代理可能推断行不存在，而插入操作可能在尾副本上稍后完成。这将使尾副本在其他副本之前，其违反链协议。这通过迫使客户端C1在真行写入之前首先插入用于行K1的逻辑删除条目来固定。逻辑删除条目避免原始客户端与恢复代理之间的竞争条件。

可以执行优化如下。如果正引入的副本具有到某个视图id(M)的更新，那么恢复客户端可以通过跳过在视图<M-1中更新的任何行进行递增更新。这未处理删除，因为那些条目将不存在于读视图中。为了确保更快的恢复，可以值得的是，创建新表以跟踪所有删除条目，而复制表系统利用低副本账户运行。这可以确保当正重新引入的副本已经中断时发生的任何删除可以在将其添加回到写视图之前在副本上进行删除。

现在描述复制表设计折衷。宽泛地，存在与不同折衷同步复制数据的两种方法：链复制(顺序的)和基于定额的复制(并行的)协议。以下是折衷、初始假定和优化的度量，以仅使用复制表设计中的链复制协议来证明。折衷包括简单性、最小复制成本、读可用性和延时、以及写可用性和延时，如下文所描述的。

链复制协议具有相当简单的恢复协议。为了恢复行，恢复过程从头副本获取锁定行并且使用两阶段链复制协议通过链继续。不需要回滚不完整写入。这使完全地在客户端库中实现恢复协议作为常规读和写操作成为可能。相同协议被用于使新副本轮换而不阻止读取。

不使用并行协议的原因如下。基于定额的协议难以在客户端中完全实现。而且，其要求不同读协议，这意味着现有客户端不能原样工作。当这些协议具有串行化所有请求并且生成全局命令的附加缺点时，复制表协议通过维持细颗粒的锁定来并行执行独立请求。

链复制保持复制成本低并且满足(t+1)个副本的下限。注意，为了容许(t)个同时数据中心故障，数据需要至少复制到(t+1)个数据中心。另外，复制表系统不要求任何预写日志或者维持数据的多个版本。

此外，不使用并行协议的原因如下。基于大多数的定额系统要求(2t+1)个副本以容许(t)个故障。链复制协议可以看作特定类型的ROWA(读一个写所有)定额系统。如果应用适用于较高复制成本，则可以通过放松成本约束来使用其他协议。

与基于定额的系统相比较，链接副本向大量读取的工作量提供显著的优点。例如，优点可以包括低开销读操作、负载平衡、兼容性和读可用性。

关于低开销读操作，在复制表系统中，客户端通常从具有在网络中传送的较少字节的单个副本(或者至多两个)进行读取。相反，基于大多数的定额请求必须从(t+1)个副本进行读取，这要求更多网络带宽。关于负载平衡，复制表系统比大多数定额为读操作提供更好的负载平衡，因为当不存在并发更新时客户端可以从任何副本进行读取(下面提供细节)。关于兼容性，从未复制表读取的现有工具可以继续未修改地工作；其可以仅从尾副本读取，其总是具有最新数据。

关于读可用性，在复制表系统中，当任何或全部(t)个非尾节点故障时，读操作是非阻止的。然而，读操作当存在尾节点故障时阻止，直到检测到故障，故障尾节点从链(视图变化)选择并且另一实况副本(前驱)被选择为新尾副本。相反，大多数定额系统提供更好的读可用性，因为其不阻止任何节点故障，直到(2t+1)个副本中的(t)个副本。

关于写操作，链复制利用用于写可用性和延时的以下折衷交换以上优点。写延时：对于副本的写操作在链中顺序继续，这导致与基于定额的系统相比较更高的延时(端到端延时＝f(副本的延时之和))，其并行交换消息(端到端延时＝f(所有副本的最大延时))。复制表系统中的延时可以通过并发地写入非头节点和非尾节点而被降低，但是其使恢复机制稍微复杂。可用性：当副本故障时阻止写操作，直到链通过将其移除重新配置。注意，不可能的是，使用(t+1)个副本作为写操作避免该缺点不能将成功指示返回到应用，而不写入到所有(t+1)个副本以提供耐久性，尽管(t)个故障。复制表系统可能能够使用用于写入到中间节点的基于定额的方法并且通过付出附加的复制成本提供更好的可用性。

图10示出了现在更详细描述的上文所描述的配置服务。配置服务150包括配置存储库152、一个或多个复制表客户端154-1、...、154-N，其中N是大于或等于1的整数(统称为复制表客户端154)，以及配置代理156。

配置服务150负责存储和更新复制表系统的当前视图，同时确保数据的安全。配置服务150包括：(a)高度可用配置存储库(例如，使用复制二进制大对象存储库)152以存储当前配置；和(b)配置代理156，其负责复制表系统的故障检测和重新配置以确保进展。复制表客户端154通过读取配置存储库152学习当前配置，其通过(一个或多个)配置代理156而初始化和更新。

配置服务150使用租赁机制允许复制表客户端154读取配置状态并且将用于租赁期的配置状态高速缓存，而不在下文所描述的假定的情况下使安全折衷。因此，配置服务150通过避免读取每个读或写操作上的配置存储库152来改进复制表读/更新操作的延时并且提供关于复制表客户端154的数目的好的可扩展性。

配置服务150使用这些假定：1)配置代理156的时钟不比复制表客户端154的时钟前进更快超过已知恒定界限，被称为时钟因素(CF)。2)在租赁时间已经终止之后，无新操作被发布到副本的复制表。注意，操作可以在租赁已经终止之后完成，因为复制表系统不控制服务器端。

配置存储库152具有链副本集、相关联的租赁期和版本号。图11示出了存储在配置存储库152中的逻辑数据结构160的示例。在逻辑数据结构160中，副本链存储副本的有序列表。写视图在索引0处开始。读视图在读头索引中指定的副本索引处开始。每个副本还具有在其期间引入该副本的相关联的版本号。在关于引入新副本或者重新引入分区副本的讨论中的如上文所描述的修复操作期间，使用该版本号。

视图ID任何时候存在行的变化时被递增。例如，当将副本引入回系统中时，视图ID被递增，并且读视图和写视图是不同的。当写视图已经赶上读视图时，视图ID再次递增，并且读取-头-索引被设定为零。

租赁期是链配置从链配置被读取的时间有效的持续时间(以秒为单位)。每次复制表客户端154读取链配置时，链配置的租赁针对租赁期更新。复制表客户端154必须不使用租赁已经终止的链配置。复制表客户端154还应当负责网络中的传输延迟。

复制表客户端154读取链配置并且假定链配置的租赁对于租赁期有效。复制表客户端154在以下事件更新租赁(例如，从配置存储库读取链信息)：1)复制表客户端周期性地更新租赁，理想地在租赁已经终止之前。为了确保复制表客户端154在租赁终止之前在获得租赁时进行至少两次尝试，更新应当每隔((租赁期/2)-1)秒尝试。2)在开始新读或写事务之前，复制表客户端154应当检查当事务完成时租赁是否保持有效(基于最大事务时间)。如果租赁可能在事务完成之前终止，则复制表客户端154应当与事务并行开始异步更新请求。如果租赁当事务完成时已经终止，则复制表客户端154应当丢弃结果并且在重试事务之前等待租赁更新。

任何复制表或者外部客户端可以用作配置代理。在任何给定时间，仅一个配置代理可以更新配置。这经由可靠首项选择来确保。可靠首项选择可以使用二进制大对象租赁来完成。

推测上手动检测复制表副本的故障。一旦配置代理156被建立到复制表客户端154时，则这可以容易自动化。配置代理156可以主动和被动地监视给定链中的所有存储账户并且确定其是否向上或向下。进一步地，每个复制表客户端154可以向配置代理156发送健康报告。这允许处理其中配置代理156发现副本健康但是复制表客户端154中的一些可能不健康的情况。

一旦检测到故障，配置代理156就被用于适当地对链进行重新配置。类似地，当故障副本返回在线或者新副本将在线时，配置代理156用于将新副本添加回到副本池。配置代理156还负责使新副本达到跟随上文所描述的协议的速度(即，具有一致数据)。

图12示出了用于更新存储在配置存储库152中的副本集的方法200。被存储在配置存储库152中的副本集更新如下。假如对于租赁期L的最大时钟因素时间是CF。在一般情况下，配置从版本v1更新到v2如下：1)在202处，配置代理156从配置存储库152删除当前配置版本v1。2)在204处，配置代理156等待恒定时间L+CF。这可以确保无新事务在旧视图中开始。在v1中开始的事务可以仍然在v2完成，但是其通过修复操作处理。3)在206处，配置代理156将新配置v2写入到配置存储库152。

配置存储库152可以使用复制二进制大对象来实现。复制表系统使用大多数定额(容许(t)个故障的(2t+1)个复制二进制大对象)以存储具有高可用性的配置状态。复制表客户端154在配置存储库152上执行定额读操作以确定当前配置。在对于副本的定额读操作上，如果复制表客户端154接收具有相同版本号和配置状态的大多数二进制大对象，则复制表客户端154接受配置状态。

对于配置存储库152的写操作直到状态被写入到大多数副本才完成。配置代理156负责确保配置存储库152的所有副本最终同步(即，同步的)。为了处理副本的暂时不可用性，配置代理156可以周期性地从所有副本读取配置并且更新已经落后的任何副本。如果配置代理156很长一段时间(例如，48小时)未能更新任何副本，则配置代理156可以唤起需要由管理员注意的临界警报。

在复制表系统中，控制路径与数据路径分离。特别地，虽然复制表系统复制应用数据，但是不同配置服务被用于复制配置状态。控制路径(使用配置服务)与数据路径(使用复制表)分离，因为它们包含不同的成本-可靠性-性能折衷。特别地，复制表系统使用(t+1)个副本来存储应用状态，同时使用具有(2t+1)个副本的配置服务来存储控制数据(配置状态)。给定故障是罕见的，这样的分离给出成本和性能益处。复制表系统使用具有经改进的读取(仅需要从单个副本读取)和恢复(任何子链具有关于故障的一致状态)延时的更少的副本(与对于基于任何定额的协议的(2t+1)相反，(t+1)个)。在大多数情况下，对于(t)(<＝2)的实际值复制表系统的写延时与任何并行基于定额的协议可比较。

副本链的重新配置在运行副本操作期间处理如下。在某些故障场景中，链重新配置可能在运行写事务期间发生。进一步地，由于云存储操作在其上不具有日落时间，因而写请求可以在一个视图中发出但是在不同视图中完成。复制表写协议通过在任何写入的末尾刷新视图来处理该场景。如果新副本已经添加到链，则复制表系统调用修复协议。复制表系统然后继续新链中的写操作。

以下不变量是由复制表系统使用的写协议的设计的一部分：1)版本和视图二者是单调增加值。它们不回转。2)到达尾副本的写操作总是甚至在存在视图变化的情况下被提交。3)如果在准备阶段期间，则客户端已经获得当前视图中的头副本上的锁定，那么写操作将在两者中的至多一个—头副本和执行写操作的客户端-同时故障的情况下最终在尾副本处被提交。这是可能的，因为任何客户端可以冲洗不完整写操作。4)在准备阶段期间，当前视图中的所有副本必须具有用于每行的相同版本。5)在提交阶段期间，如果副本的锁定位是0(即，未设定)，那么该副本必须在较旧视图中。6)在提交阶段期间，如果副本的版本小于尾副本上的版本，那么该副本必须在较旧视图中。

以下不变量是由复制表系统使用的读协议的设计的一部分：1)仅提交数据从读操作返回。2)除非所有副本同时故障，否则无提交数据(可以读取的)将由并发写操作或者视图改变重写。

在图3中，云计算系统10的前端28提供云资源管理网络服务。客户可以调用前端28的网络API以全局管理其云资源，诸如托管服务、部署(PaaS/IaaS)和存储账户。云计算系统的前端通常将数据维持在单个存储账户中。如果存储账户具有任何中断，则前端服务全局故障并且客户不能在任何区域中管理其资源。

前端28使用本公开的复制表系统，使得前端28可以从具有零恢复点对象(RPO)的单个存储账户中断恢复，其是数据可能由于重大事故从服务丢失的最大目标时段。复制表系统通过链复制提供零RPO，锁定头副本以防止并发写操作，并且不增加读延时。

图13示出了根据本公开的复制表系统300。复制表系统300使用同步复制表架构防止对于前端28的单个存储账户故障。复制表系统300包括位于不同数据中心中的至少两个存储账户(副本)，其组成复制链。云计算系统10(在图3中示出)的前端28使用复制表系统300，其包括存储账户的两个或两个以上副本以管理云计算系统10。复制表系统300与上文所描述的复制系统不同之处在于，复制表系统300首先从头副本读取数据，而不是从尾副本。

如下文详细解释的，在本公开的复制表系统300中，当添加新副本时，在线修复动作由用户触发，并且后端修复服务确保新副本具有一致数据(被称为修复动作)。两阶段准备-提交协议处理一致数据的并发写和读操作(被称为Flush2pc)。

图13至图23包括由复制表系统300执行的方法。在以下方法的描述中，术语控件指代参考图24至图26下文所描述的客户端和服务器应用666和686中的一个或多个，其实现复制表系统300的一个或多个组件和下文所描述的一个或多个方面的全部或一些方面。换句话说，如使用在以下方法的描述中的术语控件表示由图3中所示的云计算系统10的一个或多个组件执行以执行所描述的功能的代码或者指令。

在图13中，在复制表系统300中，复制表302包括位于不同数据中心中的至少两个存储账户(副本)，其组成复制链。例如，复制表302包括位于第一数据中心中的头副本50-1和位于第二数据中心中的尾副本50-N。

类似于图10中所示的配置存储库152的复制表配置存储库304维持定额二进制大对象中的复制链拓扑。前端28包括部署在多个虚拟机上的分布式应用。应用服务来自客户的网络请求以管理其云资源。它们还服务管理员请求以管理前端服务自己。每个应用使用复制表客户端接口来保持数据。

复制表客户端306从复制表配置存储库304读取复制表复制链拓扑以使用复制表协议将数据保存到复制链。类似于图10中所示的配置代理156的复制表配置服务308被托管在每个应用内以出于管理员目的做出复制表配置存储库304中的配置变化，类似移除副本或者添加新副本。每当新副本被添加到复制表302中的复制表链时，复制表修复代理角色310修复不同分区键范围和表中的行。在修复作业完成之后，新副本具有与链中的任何旧副本一致的数据。

复制表302建立在存储表客户端库之上。前端28使用不同(例如，ADO.NET)接口与存储表通信。存储表客户端库与ADO.NET之间的接口是完全不同的。因此，现有的复制表接口不能由前端28直接利用。

图14示出了一种如下方式：通过除了当前由复制表客户端306使用的存储表客户端库接口314之外，向复制表客户端306提供由前端28用于与复制表302通信的ADO.NET接口316，来使复制表客户端306与存储表客户端库接口314和ADO.Net接口316二者兼容。

更特别地，由前端28使用的ADO.NET接口316从复制表客户端306暴露，如所示出的。复制表客户端306可以与存储表客户端库共享修复动作和Flush2pc的逻辑。前端28需要使用ADO.NET接口316与复制表302中的存储表通信。其他应用312可以选择存储表客户端库接口314与复制表302通信。向复制表客户端306提供附加ADO.NET接口316的目的是使应用312中的代码变化最小化。这允许应用312使用相同接口以与复制表302通信作为其用来直接与存储表通信的对象。

图15示出了用于除了由复制表客户端306使用的存储表客户端库接口314之外向复制表客户端(例如，复制表客户端3-6)提供由前端28使用的ADO.NET接口316的方法350。在352处，将由用于管理云计算系统(例如，图3中所示的CCS 10)上的资源的数据存储为一个或多个存储表中的实体。在354处，前端28创建存储表的两个或两个以上副本(例如，图14中所示的复制表302中的副本50)，其中，每个副本位于不同数据中心中。在356处，与前端28相关联的每个客户端(例如，图14中所示的复制表客户端306)将副本50对接到前端28和一个或多个应用(例如，图14中所示的应用312)。在358处，每个客户端306被提供有将一个或多个应用312对接到副本50的第一接口(例如，图14中所示的存储表客户端库接口314)。在360处，每个客户端306被提供有将前端28对接到副本50的第二接口(例如，图14中所示的ADO.NET接口316)。

如果写操作在复制表302中的头副本与尾副本之间发生故障，则读操作将返回旧数据，直到下一写操作发生。这不是正常客户期望。因此，本公开提出安全读特征如下。

图16至图19示出了根据本公开的安全读特征。本公开的安全读特征包含从头副本50-1读取而不是从尾副本50-N读取，以在写操作在头副本与尾副本之间发生故障的情况下，防止从尾副本50-N返回旧数据。特别地，在读操作期间，首先从头副本50-1读取数据。如果头副本50-1锁定，则变化首先从头副本50-1推送到尾副本50-N。此后，从头副本50-1返回数据。如果头副本50-1未锁定，则从头副本50-1返回数据。

在图16中，在安全读操作期间，首先从复制表302中的头副本50-1读取数据；如果头副本50-1锁定，则首先执行Flush2pc操作以将头副本50-1中的变化推送到尾副本50-N；并且然后从头副本50-1返回数据。否则，如果头副本50-1未锁定，则读操作简单地从头副本50-1返回数据。这不应当增加读操作的延时，因为这样的Flush2pc操作仅当先前写操作在头副本50-1与尾副本50-N之间发生故障时执行。

此外，当新副本被添加到复制表302中的副本链时，新副本被添加到尾(即，在链的结尾或者作为尾副本)以减少读延时。修复代理310设置新副本以具有与头副本50-1一致的数据。在那之后，复制表302中的复制链再次是稳定的，并且不存在单个故障点。

图17示出了由安全读特征使用的获得协议400。在402处，获得协议400从头副本(例如，图16中所示的头副本50-1)读取行。在404处，获得协议400检查行是否锁定。在406处，如果行未锁定，则获得协议400返回从来自头副本(例如，图16中所示的头副本50-1)的行读取的数据。在408处，如果行锁定，则执行Flush2PC操作，并且此后获得协议400返回从来自头副本的行读取的数据。

图18示出了由安全读特征使用的写协议410。在412处，写协议410从头副本(例如，图16中所示的头副本50-1)读取行。在414处，写协议410确定是否需要修复动作。在416处，如果需要修复动作，则写协议410执行修复动作。在418处，此后或者如果不需要修复动作，则写协议410确定行是否锁定。在420处，如果行锁定，则写协议410执行Flush2PC操作。在422处，此后或者如果行未锁定，写协议410写入并且锁定头副本(例如，图16中所示的头副本50-1)。在424处，写协议410写入并且锁定尾副本(例如，图16中所示的尾副本50-1)。在426处，写协议410解锁尾副本。在428处，写协议410解锁头副本。操作422到428构成Flush2PC操作。在430处，写协议410返回从来自头副本的行读取的数据。

图19示出了根据本公开的用于通过从头副本50-1读取数据来执行安全读操作的方法450。在452处，控件存储由应用用于管理云计算系统上的资源作为一个或多个存储表中的实体的数据。在454处，控件创建存储表的至少两个副本，其中每个副本位于不同数据中心中。在456处，控件将副本布置为有序集，其中有序集中的第一副本是头副本，并且有序集中的最后副本是尾副本。

在458处，控件检查读操作是否待执行。在460处，如果读操作待执行，则控件试图首先从头副本读取。在462处，控件检查头副本是否锁定。在464处，如果头副本锁定，则控件首先推送从头副本到尾副本的改变。在466处，此后或者如果头副本未锁定，控件从头副本读取。

在468处，控件确定是否添加新副本。在470处，如果新副本待添加，则控件设立与头副本一致的新副本。在474处，控件在副本链的末尾添加新副本作为尾副本。

图20示出了根据本公开的用于在后端中执行修复操作以改进写延时的方法500。特别地，在头副本与尾副本之间的故障的情况下，修复动作通常仅由下一写操作触发，其增加写操作的端到端时间。因此，本公开提出分离的修复服务。每当故障在Flush2pc操作的中间发生(即，当写操作在将变化从头副本50-1推送到尾副本50-N的中间发生故障)时，事件被放置在存储队列中。被放置在存储队列中的事件触发从存储队列弹出以针对故障的写操作执行Flush2pc操作(即，以将变化从头副本50-1推送到尾副本50-N)的修复服务。Flush2pc操作(即，将变化从头副本50-1推送到尾副本50-N)在后端中执行并且因此不增加下一写操作的延时。

在方法500中，在502处，控件存储由应用用于管理云计算系统上的资源的数据作为一个或多个存储表中的实体。在504处，控件创建存储表的至少两个副本，其中每个副本位于不同数据中心中。在506处，控件将副本布置为有序集，其中有序集中的第一副本是头副本，并且有序集中的最后副本是尾副本。

在508处，控件检查写操作是否待执行。在510处，如果写操作待执行，则控件从头副本顺序写入尾副本(即，将头副本中的变化从头副本推送到尾副本)。在512处，控件确定写操作是否在头副本与尾副本之间的副本中发生故障。在514处，如果写操作在头副本与尾副本之间的副本中发生故障，则控件在后台中修复副本上的故障的写操作。

图21至图23示出了复制表302的可用性模型。在图21中，虽然如果在尾副本50-N上执行读操作则前端28可以从具有零恢复点对象(RPO)的单个存储账户中断进行恢复，但是以下场景可以发生。如果头副本50-1故障，而读操作仍然存活，则写操作将故障。为了恢复，从复制表302中的副本链中移除头存储账户(即，头副本50-1)，并且稍后添加新头副本。如果尾副本50-N故障，则读和写操作二者将发生故障。为了恢复，从复制表302中的副本链移除尾存储账户(即，尾副本50-N)，并且现有头存储账户(即，头副本50-1)改变角色以变为新的尾副本50-N；并且稍后添加新的头副本。

在图22中，根据本公开，在头副本50-1上而不是在尾副本50-N上执行读操作。前端28可以从具有零恢复点对象(RPO)的单个存储账户中断恢复。另外，如果头副本50-1故障，则读操作仍然存活，同时写操作将故障。为了恢复，从复制表302中的副本链中移除头存储账户(即，头副本50-1)。现有尾存储账户(即，尾副本50-N)改变角色以变为新的头副本50-1；并且稍后添加新的尾副本。如果尾副本50-N发生故障，则读操作仍然存活，同时写操作将发生故障。为了恢复，从复制表302中的副本链中移除尾存储账户(即，尾副本50-N)；并且稍后添加新的尾副本。

图23示出了用于从头副本读取而不是从尾副本读取使得即使尾副本发生故障读操作也存活的方法550。在552处，控件存储由应用用于管理云计算系统上的资源的数据，作为一个或多个存储表中的实体。在554处，控件创建存储表的至少两个副本，其中每个副本位于不同数据中心中。在556处，控件将副本布置为有序集，其中有序集中的第一副本是头副本，并且有序集中的最后副本是尾副本。

在558处，控件确定头副本是否发生故障。在560处，如果头副本故障，则控件从副本链移除头副本。在562处，控件使用(即，重新配置或者改变其角色)尾副本作为新的头副本。在564处，控件在副本链的末尾添加新的尾副本。

在566处，控件确定尾副本是否发生故障。在568处，如果尾副本发生故障，则控件从副本链移除尾副本。在570处，控件在副本链的末尾添加新的尾副本。

下面是可以实现上文所描述的本公开的系统和方法的分布式计算环境的简单化示例。贯穿本公开，对于术语(诸如服务器、客户端设备、应用等)的引用仅出于说明的目的。术语服务器和客户端设备将被宽泛地理解为表示包括一个或多个处理器和被配置为执行机器可读指令的存储器的计算设备。术语应用和计算机程序将被宽泛地理解为表示可由计算设备执行的机器可读指令。

图24示出了分布式网络系统600的简化示例。分布式网络系统600包括网络610、一个或多个客户端设备620-1、620-2、...和620-N(统称为客户端设备620)(其中N是大于或等于一的整数)，以及服务器630。网络610可以包括局域网(LAN)、广域网(WAN)(诸如因特网)、或者其他类型的网络(共同地示出为网络610)。虽然仅示出一个服务器，但是分布式网络系统300可以包括多个服务器。客户端设备620经由网络610与服务器630通信。客户端设备620和服务器630可以使用网络610的无线和/或有线连接来连接到网络610。

一个或多个服务器630和客户端设备620可以实现图3中所示的云计算系统10的一个或多个组件。例如，一个服务器630可以实现云控制器12，而一个或多个客户端设备620可以实现结构控制器32。备选地，一个或多个服务器630可以实现云控制器12的一个或多个组件(例如，前端28)。预期了实现的许多不同配置。

服务器630可以向客户端设备620提供多种服务。例如，服务器630可以执行多个软件应用。服务器630可以托管由多个软件应用利用并且由客户端设备620使用的多个数据库。另外，服务器630和客户端设备620可以执行实现复制表系统300的一个或多个组件的应用和由上文所描述的复制表系统300使用的一个或多个方法。

图25示出了客户端设备620的简化示例。客户端设备620可以通常包括中央处理单元(CPU)或者处理器650、一个或多个输入设备652(例如，小键盘、触摸板、鼠标等)、包括显示器656的显示子系统654、网络接口658、存储器660和大容量存储装置662。

网络接口658经由网络610将客户端设备620连接到分布式网络系统600。例如，网络接口658可以包括有线接口(以太网接口)和/或无线接口(例如，Wi-Fi、蓝牙、近场通信(NFC)、或其他无线接口)。存储器660可以包括易失性或非易失性存储器、高速缓存、或其他类型的存储器。大容量存储装置662可以包括闪存、硬盘驱动器(HDD)、或其他大容量存储设备。

客户端设备620的处理器650执行操作系统(OS)364和一个或多个客户端应用666。客户端应用666包括经由网络610将客户端设备620连接到服务器630的应用。客户端设备620经由网络610访问由服务器630执行的一个或多个应用。客户端应用666还可以包括实现复制表系统300的一个或多个组件的全部或一些方面的应用以及由上文所描述的复制表系统300使用的一个或多个方法。

图26示出了服务器630的简化示例。服务器630通常包括一个或多个CPU或者处理器670、一个或多个输入设备672(例如，小键盘、触摸板、鼠标等)、包括显示器676的显示子系统674、网络接口678、存储器680和大容量存储装置682。

网络接口678经由网络610将服务器630连接到分布式网络系统600。例如，网络接口678可以包括有线接口(以太网接口)和/或无线接口(例如，Wi-Fi、蓝牙、近场通信(NFC)、或其他无线接口)。存储器680可以包括易失性或非易失性存储器、高速缓存、或其他类型的存储器。大容量存储装置682可以包括闪存、一个或多个硬盘驱动器(HDD)、或其他大容量存储设备。

服务器630的处理器670执行操作系统(OS)384和一个或多个服务器应用686。服务器应用686可以包括实现复制表系统300的一个或多个组件的全部或一些方面的应用以及由上文所描述的复制表系统300使用的一个或多个方法。大容量存储装置682可以存储一个或多个数据库688，其存储由服务器应用686用于执行相应功能的数据结构。

前述描述实际上仅是说明性的并且决不旨在限制本公开、其应用或者用途。本公开的宽泛的教导可以以各种形式实现。因此，虽然本公开包括特定示例，但是本公开的真实范围不应当是这样有限的，因为其他修改将在研究附图、说明书和权利要求书时变得明显。应当理解，在不改变本公开的原理的情况下，方法内的一个或多个步骤可以以不同的次序(或者并行地)执行。进一步地，虽然各实施例在上文被描述为具有某些特征，但是相对于本公开的任何实施例所描述的那些特征中的任何一个或多个可以在其他实施例中的任一实施例的特征中和/或组合其实现，即使该组合未明确地描述。换句话说，所描述的实施例不是互相排斥的，并且一个或多个实施例彼此的排列保持在本公开的范围内。

元件之间(例如，模块、电路元件、半导体层等之间)的空间和功能关系使用各种术语来描述，包括“连接”、“接合”、“耦合”、“邻近”、“靠近”、“在…之上”、“上面”、“下面”和“布置”。当在以上公开中描述第一元件与第二元件之间的关系时，除非明确地被描述为“直接的”，否则该关系可以是其中没有其他中间元件存在于第一元件与第二元件之间的直接关系，而且可以是其中一个或多个中间元件存在于第一元件与第二元件之间(或者空间地或者功能地)的间接关系。如在此所使用的，短语A、B和C中的至少一个应当被解释为使用非专有逻辑OR的逻辑(A或B或C)，并且不应当被解释为意味着“A中的至少一个、B中的至少一个、和C中的至少一个”。

在附图中，如由箭头所指示的箭头的方向通常证明对图示感兴趣的信息(诸如数据或者指令)的流动。例如，当元件A和元件B交换各种信息但是从元件A被传送到元件B的信息与图示有关时，箭头可以从元件A指向元件B。该单向箭头不隐含没有其他信息从元件B被传送到元件A。进一步地，对于从元件A被发送到元件B的信息而言，元件B可以针对到元件A的信息发送请求或者接收确认。

术语存储器是术语计算机可读介质或者机器可读介质的子集。如在此所使用的，术语计算机可读介质或者机器可读介质不涵盖通过介质(诸如在载波上)传播的暂态电气或者电磁信号；术语计算机可读介质或者机器可读介质可以因此被认为是有形并且非暂态的。非暂态有形计算机可读介质或者机器可读介质的非限制性示例是非易失性存储器电路(诸如闪存电路、可擦可编程只读存储器电路或者掩模只读存储器电路)、易失性存储器电路(诸如静态随机存取存储器电路、或者动态随机存取存储器电路)、磁性存储介质(诸如模拟或者数字磁带或者硬盘驱动器)和光存储介质(诸如CD、DVD或者蓝光光盘)。

在本申请中，被描述为具有特定属性或者执行特定操作的装置元件特别地被配置为具有那些特定属性并且执行那些特定操作。特别地，执行动作的元件的描述意味着元件被配置为执行动作。元件的配置可以包括元件的编程(诸如通过将指令编码在与元件相关联的非暂态有形计算机可读介质上)。

本申请中所描述的装置和方法可以由通过将通用计算机配置为执行计算机程序中实现的一个或多个特定函数创建的专用计算机来部分地或完全地实现。上文所描述的功能块、流程图部件和其他元件用作软件规范，其可以通过技术人员或者程序员的日常工作被转换为计算机程序。

计算机程序包括被存储在至少一个非暂态有形计算机可读介质上的处理器可执行指令。计算机程序还可以包括或者依赖于存储的数据。计算机程序可以涵盖：基本输入/输出系统(BIOS)，其与专用计算机的硬件相互作用；设备驱动程序，其与专用计算机的特定设备、一个或多个操作系统、用户应用、后台服务、后台应用等相互作用。

计算机程序可以包括：(i)待解析的描述文本，诸如HTML(超文本标记语言)、XML(可扩展标记语言)，或者JSON(JavaScript对象标注)、(ii)汇编代码、(iii)通过编译器根据源代码生成的目标代码、(iv)用于由解译器执行的源代码、(v)用于由即时编译器编译和执行的源代码等。仅作为示例，源代码可以使用来自语言的语法编写，包括C、C++、C#、Objective C、Swift、Haskell、Go、SQL、R、Lisp、

Fortran、Perl、Pascal、Curl、OCaml、/>

HTML5(超文本标记语言第5版)、Ada、ASP(动态服务器页面)、PHP(PHP：超文本预处理器)、Scala、Eiffel、Smalltalk、Erlang、Ruby、/>

Visual

Lua、MATLAB、SIMILINK和/>

除非元件使用短语“用于…的装置”明确地记载或者在使用短语“用于…的操作”或者“用于…的步骤”的方法权利要求的情况下，否则权利要求中记载的没有一个元件旨在是35U.S.C.§112(f)的意义内的功能模块构架元件。

Claims (17)

1.一种系统，包括：

处理器和存储器；以及

机器可读指令，其被存储在所述存储器中，所述机器可读指令当由所述处理器执行时，将所述处理器配置为：

存储数据作为一个或多个表中的实体，所述一个或多个表与所述一个或多个表的多个副本相关联，所述多个副本包括从第一副本到最后副本的有序序列的副本，所述多个副本具有读视图和写视图；

基于所述有序序列的副本来执行对所述一个或多个表中的实体的写操作，其中执行所述写操作包括：

确定所述读视图是否匹配针对所述多个副本的对应的写视图；

基于所述读视图是否匹配对应的写视图，从所述第一副本到所述最后副本顺序锁定所述多个副本，其中顺序锁定所述多个副本包括从所述第一副本到所述最后副本顺序设置针对所述多个副本中的每个副本的锁定位；

从所述最后副本到所述第一副本顺序解锁和提交数据到所述多个副本，其中顺序解锁和提交数据包括：从所述最后副本到所述第一副本以反向顺序针对所述多个副本中的每个副本反转所述锁定位和提交所述数据；以及

基于从所述最后副本到所述第一副本顺序接收到完成所述写操作的指示，确认所述写操作的成功。

2.根据权利要求1所述的系统，其中所述数据包括结构化且非关系型数据。

3.根据权利要求1所述的系统，其中所述机器可读指令还将所述处理器配置为：将来自所述多个副本的每个副本存储在不同数据中心中，以在所述数据中心中的一个数据中心发生故障时保护所述数据。

4.根据权利要求1所述的系统，其中所述机器可读指令还将所述处理器配置为：

基于确定在执行所述写操作的同时来自所述多个副本的一个或多个副本被锁定，通过从所述最后副本进行读取来执行读操作。

5.根据权利要求1所述的系统，其中所述机器可读指令还将所述处理器配置为：生成新副本，以及在所述最后副本之后向所述多个副本添加所述新副本，使得所述新副本成为新的最后副本。

6.根据权利要求1所述的系统，其中所述机器可读指令还将所述处理器配置为：生成包括与所述第一副本一致的数据的新副本，在后台中生成所述新副本，以及在所述最后副本之后向所述多个副本添加所述新副本，使得所述新副本成为新的最后副本。

7.根据权利要求1所述的系统，其中所述机器可读指令还将所述处理器配置为：

生成所述一个或多个表的所述多个副本的所述有序序列；以及

当所述有序序列中的副本发生故障时：

从所述多个副本移除所述副本，

使用所述有序序列中的所述最后副本代替被移除的所述副本，以及

向所述多个副本的所述序列添加新的最后副本。

8.根据权利要求1所述的系统，其中所述机器可读指令还将所述处理器配置为：

生成所述一个或多个表的所述多个副本的所述有序序列；以及

当所述有序序列中的所述最后副本发生故障时：

从所述多个副本移除所述最后副本，以及

添加新的最后副本以代替被移除的所述最后副本。

9.一种方法，包括：

存储数据作为一个或多个表中的实体，所述一个或多个表与所述一个或多个表的多个副本相关联，所述多个副本包括从第一副本到最后副本的有序序列的副本，所述多个副本具有读视图和写视图；

基于所述有序序列的副本来执行对所述一个或多个表中的实体的写操作，其中执行所述写操作包括：

确定所述读视图是否匹配针对所述多个副本的对应的写视图；

基于所述读视图是否匹配对应的写视图，从所述第一副本到所述最后副本以正向顺序来顺序锁定所述多个副本；

从所述最后副本到所述第一副本以反向顺序来顺序解锁和提交数据到所述多个副本；以及

基于从所述最后副本到所述第一副本以反向顺序来顺序接收到完成所述写操作的指示，确认所述写操作的成功；以及

基于确定在执行所述写操作的同时来自所述多个副本的一个或多个副本被锁定，通过从所述最后副本进行读取来执行读操作。

10.根据权利要求9所述的方法，还包括将来自所述多个副本的每个副本存储在不同数据中心中，以在所述数据中心中的一个数据中心发生故障时保护所述数据。

11.根据权利要求9所述的方法，还包括：

生成新副本；以及

在所述最后副本之后向所述多个副本添加所述新副本，使得所述新副本成为新的最后副本。

12.根据权利要求11所述的方法，其中生成所述新副本被执行为后台进程。

13.根据权利要求9所述的方法，还包括：

生成所述一个或多个表的所述多个副本的所述有序序列；

通过从所述有序序列中的第一副本到最后副本顺序写入来执行写操作；以及

当所述写操作在所述副本中的、所述第一副本与所述最后副本之间的一个副本上发生故障时，在后台中对所述副本中的所述一个副本执行修复操作。

14.根据权利要求13所述的方法，还包括：通过以下来在后台中对所述副本中的所述一个副本执行所述修复操作：

当所述写操作在所述副本中的、所述第一副本与所述最后副本之间的一个副本上发生故障时，将事件添加在存储队列中；以及

激活在所述后台中执行所述修复操作的修复服务。

15.根据权利要求9所述的方法，还包括：

生成所述一个或多个表的所述多个副本的所述有序序列；以及

当所述有序序列中的副本发生故障时：

从所述多个副本移除所述副本，

使用所述有序序列中的所述最后副本代替被移除的所述副本，以及

向所述多个副本的所述序列添加新的最后副本。

16.根据权利要求9所述的方法，还包括：

生成所述一个或多个表的所述多个副本的所述有序序列；以及

当所述有序序列中的所述最后副本发生故障时：

从所述多个副本移除所述最后副本，以及

添加新的最后副本以代替被移除的所述最后副本。

17.一种系统，包括：

处理器和存储器；以及

机器可读指令，其被存储在所述存储器中，所述机器可读指令当由所述处理器执行时，将所述处理器配置为：

存储数据作为一个或多个表中的实体，所述一个或多个表与所述一个或多个表的多个副本的有序序列相关联，所述多个副本包括从第一副本到最后副本的有序序列的副本，所述多个副本具有读视图和写视图；

基于所述有序序列的副本来执行对所述一个或多个表中的实体的写操作，其中执行所述写操作包括：

确定所述读视图是否匹配针对所述多个副本的对应的写视图；

基于所述读视图是否匹配对应的写视图，从所述有序序列中的所述第一副本到所述最后副本以正向顺序来顺序锁定所述多个副本；以及

从所述最后副本到所述第一副本以反向顺序来顺序解锁和提交数据到所述多个副本；

基于从所述最后副本到所述第一副本顺序接收到完成所述写操作的指示，确认所述写操作的成功；以及

基于确定在执行所述写操作的同时来自所述多个副本的一个或多个副本被锁定，通过从所述最后副本进行读取来执行读操作。

Images