CN111386522B - 用于数据存储的系统和方法 - Google Patents

Abstract

本文公开了一种使用混合多主设计的地域分布式系统。所述系统能够使用全局表，对于所述全局表，读取和写入都能在本地执行，但是单个区域用作主区域。所有强一致的读取和写入都可以被发送到所述主区域，而最终一致的读取和写入可以在具有副本的任何区域中执行。所述主区域可以不被静态分配，而是可以在区域之间移动。所述主区域可以通过客户端偏好来手动分配，也可以基于一天中的时间或工作负荷特性来自动分配和更新。

Description

用于数据存储的系统和方法

背景技术

计算机硬件和软件组件的商品化已经导致作为服务提供计算能力和存储能力的服务提供商的兴起。这些服务中的至少一些难以扩展，然而吞吐量和可用性需求导致这些服务在数据在不同地理区域之间异步复制的地理范围上分布。在这些设计中，数据不是在副本之间同步地维护，而是通过后台复制过程随时间实现一致性或汇聚。这种最终的汇聚可能引起重要的数据一致性考虑。如果保证给定数据访问请求所访问的数据与对存储在服务中的数据所进行的更新一致，那么可以认为所述数据具有强一致性类型，而如果不一定保证给定数据访问请求所访问的数据与对数据进行的更新一致(例如，一个或多个最近更新可能尚未应用于数据)，那么可以认为所述数据接受最终的一致性类型。因此，非常需要允许分布式服务在以满足吞吐量和可用性需求的规模实施时提供用于访问的不同一致性类型的技术。

附图说明

图1是根据一些实施例的系统架构的框图，所述系统架构实施提供数据库表的多主多区复制的基于web服务的数据存储服务。

图2是根据一些实施例绘示根据数据访问请求的数据一致性的类型处理数据访问请求的流程图。

图3是根据一些实施例绘示复制引擎的各种组件的框图。

图4是根据某些实施例绘示处理将副本提升为主副本的请求的流程图。

图5A和5B是根据一个实施例绘示将数据作为项目存储在多个表中的框图。

图6是根据一个实施例绘示包含数字属性的三个项目的框图，所述数字属性已被指定为其中存储有所述三个项目的表的主键。

图7是根据各种实施例绘示实例计算机系统的框图。

虽然本文中通过若干实施例和说明性附图的方式来描述各实施例，但是本领域技术人员将认识到实施例不限于所描述的实施例或附图。应当理解，附图及其详细描述并不旨在将实施例限于所公开的特定形式，而是相反，本发明旨在覆盖落入由所附权利要求书限定的精神和范围内的所有修改、等同物和替代方案。本文所用的标题仅用于组织目的，并不意味着用于限制说明书或权利要求书的范围。如贯穿本申请所使用的，词语“可以”以允许的意义(即，意指有潜力)使用，而不是以强制意义(即，意指必须)使用。词语“包括”表示开放性关系，且因此意味着包括但不限于。类似地，词语“具有”也指示开放性关系，且因此意味着具有但不限于。本文中使用的术语“第一”、“第二”、“第三”等用作它们后面的名词的标记，并且不暗示任何类型的排序(例如，空间的、时间的、逻辑的等)，除非这种排序另有明确说明。

如本文所使用，“基于”这个术语用于描述影响确定的一个或多个因素。此术语不排除可能影响确定的另外因素。即，确定可以仅基于那些因素或者至少部分地基于那些因素。考虑短语“基于B确定A”。虽然B可能是影响A的确定的因素，但这种短语并不排除还基于C确定A。在其它情况下，可仅基于B来确定A。

本公开的范围包括本文(明确地或隐含地)公开的任何特征或特征的组合，或其任何概括，无论其是否缓解了本文所解决的任何或所有问题。因此，在本申请(或要求其优先权的申请)的审查期间，可以对任何这样的特征组合制定新的权利要求书。具体地，参考所附权利要求书，来自从属权利要求的特征可以与独立权利要求的特征组合，并且来自各个独立权利要求的特征可以以任何适当的方式而不是仅仅以所附权利要求书中列举的特定组合来组合。

具体实施方式

公开了使用混合多主设计的地域分布式系统的各种实施例。在一些实施例中，地域分布式系统可以实施具有区域副本的全局表，对于所述全局表，读取和写入都可以在本地执行，但是单个区域用作主区域。在一些实施例中，因为区域副本可以异步更新，所以在一个区域中进行的更新随时间传播到其它区域，从而导致全局表的副本的最终一致性。在一些实施例中，主区域可以执行所有强一致类型的读取和写入，而可以在具有副本的任何区域中执行最终一致的读取和写入。在一些实施例中，主区域不是静态分配的，而是允许从一个区域移动到另一个区域，并且可以通过客户端偏好手动分配或基于一天中的时间或工作负荷特性自动分配。

在一些实施例中，通过实施用于数据库表的混合多主机，地域分布式系统可避免性能瓶颈，同时仍支持具有不同一致性类型的写入。然后，应用程序可以利用不同的所支持的一致性类型。在一些实施例中，例如，在不同区域中可以支持不同的一致性类型(例如，主区域可以支持强一致性类型)，允许来自利用给定一致性类型的应用程序的请求被路由到支持区域(例如，允许具有强一致性类型的请求被路由到主区域以被执行)。

在各种实施例中，可在一个或多个计算节点上实施可执行本文所述功能性的数据存储服务。在一些实施例中，服务可以实施为数据库服务平台，例如图1的数据库服务平台100，由多个区域120组成，包括主区域120a和一个或多个次区域120b-n，每个次区域可以执行本文所描述的一个或多个功能。在一些实施例中，区域120内的各种计算节点集合可以实施提供全局请求路由器130、本地请求路由器140、复制服务160和存储节点150。另外，在一些实施例中，数据库服务平台100可以包括全局端点190和全局元数据195

在一些实施例中，数据库服务平台120可以实施包括在每个区域120处维护的副本的全局表。在一些实施例中，一些区域120可以不维护区域副本，而是可以仅为全局表提供全局请求路由。在一些实施例中，数据库服务的应用程序105可以在全局表的任何区域处连接到数据库服务平台100。在一个实施例中，如果需要强一致的操作，则应用程序105可以明确地将适当的端点用于其本地区域，并且可能将第二端点用于主区域。在一些实施例中，如果区域变得不可访问，则应用程序可以明确地切换到不同区域中的端点。在另一实施例中，数据库系统可以基于接近度和期望的一致性将请求透明地路由到最适当的区域。在又一实施例中，数据库系统可以为全局表提供全局端点190。使用全局端点，数据库服务平台100将自动地将应用程序连接到最期望的区域，因此通过全局端点访问全局表的应用程序不需要知道所述表被复制的区域。此外，在一些实施例中，如果当前连接的区域由于区域中断而变得不可达，则应用程序可自动进行故障转移。可以设想全局端点的各种实施例。在一个实施例中，可以联系全局端点以获得用于后续通信的本地端点信息，而在另一个实施例中，全局端点可以用作继电器以用于到指定区域的通信。在又一实施例中，全局端点可以是通过路由信息动态控制的逻辑端点。然而，应当理解，可以设想全局端点的其它实施例，并且这些实例实施例并不旨在是限制性的。

在一些实施例中，每个区域120内的全局请求路由器(GRR)组件130可以在区域之间路由各请求，以便满足与所述请求相关联的一致性类型。在一些实施例中，与强一致性类型相关联或以其它方式使用强一致性类型的请求(例如包括读取请求和写入请求)可被路由到主区域120a，而能够接受最终一致性的请求可被路由到次区域或被转发到接收到请求的区域的本地请求路由器140。如果在与主区域相关联的GRR处接收到能够接受最终一致性的请求，则在一些实施例中，可以将所述请求转发到主区域的本地请求路由器140，而在其它实施例中，可以将其转发到次区域。请注意，前面讨论的一致性类型是一致性类型的实例。在一些实施例中可以实施其它一致性类型。

在一些实施例中，GRR可以使用包含请求的各种信息来确定适当的路由。这种信息的实例可包括提交请求的客户端的标识、请求的一致性的类型、请求的特定性能标准或请求所访问的数据类型，例如在图5A、5B和6中进一步描述的。然而，应当理解，这些实施例并不旨在是限制性的。

一致性类型可以与多种方式相关联。在一个实施例中，可以使用包含请求本身的字段来指定一致性类型，而在另一个实施例中，一致性类型可以与提交请求的应用或数据库服务的客户端相关联。然而，应当理解，可以设想将一致性类型与请求相关联的其它实施例，并且这些实例实施例并不旨在是限制性的。

在一些实施例中，个别区域120可以实施各种数据库架构。在一个实施例中，区域120可实施多个存储节点150，每一存储节点含有全局表的副本，所述副本与所述区域的其它副本异步地维护。单个主存储节点150a可维护区域的权威副本，并执行区域的所有写入以及需要强一致性保证的读取。在一些实施例中，存储节点150之间的复制可以由复制服务160的本地复制模块170执行，并且请求可以部分地基于请求类型和相关联的一致性类型由本地请求路由器140路由到存储节点150。在一些实施例中，本地请求路由器140还可以使用包含请求的各种信息来确定适当的路由，例如由请求访问的数据类型，如在图5A、5B和6中进一步描述的。虽然实例实施例使用异步复制和单个主存储节点，但是应当理解，可以设想用于个别区域的其它架构实施例，并且这些实例实施例并不旨在是限制性的。此外，还应当理解，不同的区域可以实施不同的架构实施例。

对于每个全局表，配置信息可以存储在全局元数据195中，如图1所示。在一些实施例中，可以为全局表维护两种类型的信息：表被复制的区域的集合以及所述表的指定主区域。在一个实施例中，全局元数据195本身是在所有区域中复制的全局表。这样，元数据保持高度可用，并且可以以低延迟进行读取。在此实施例中，可以在一个区域中控制全局元数据表。在一些实施例中，对全局元数据的更新可偶尔作为强一致写入来执行，这意味着可首先在主区域中应用所有更新。

在一些实施例中，在复制服务160中执行的复制可容忍关于全局表的副本集的过时的元数据。因此，这些功能可以使用最终一致读取来读取元数据并缓存所述元数据，仅当其发现元数据丢失或可能改变时才刷新缓存的元数据。然而，在一些实施例中，这些功能需要关于全局表的主区域的最新信息。因为对于GRR而言从全局元数据表中读取它们接收到的每个强一致的请求是不切实际的，所以在一些实施例中可以使用主租约，如图4所示。

在一些实施例中，因为在全局表中实施时，权威的全局元数据195驻留在单个主区域中，所以此元数据可能易受区域中断的影响。在一些实施例中，为了保证总是可以执行元数据更新，包括创建全局表和续订主租约，可以在全局元数据主区域不可用时使用最终一致的写入。在一些实施例中，这样的写入可以利用通过复制传播到所有其它区域的结果来更新任何区域中的元数据。在一些实施例中，使用最终一致读取来访问元数据的应用程序将不受影响。

在一些实施例中，最终一致的元数据更新可能导致一种可能性，即一些组件可以访问元数据主区域而其它组件不能访问元数据主区域。在这种情况下，每个组件可以安置在相同表的不同主机上。结果是，在一些实施例中，应用程序可向两个不同区域发出强一致写入，且强一致读取可能不会在另一区域中看到强一致写入。在一些实施例中，这不会违反汇聚，因为一旦网络分区修复，副本将最终达到相互一致的状态。然而，它可能暂时违反强一致性保证。

在一些实施例中，租赁机制可以确保在任何时间点对于每个全局表仅存在一个主机，并且允许有效地缓存主控权信息。在一些实施例中，每个主租约可以具有到期时间。在一些实施例中，当主租约到期时，所述主租约可以由同一区域续订或由作为主机接管的新区域获得。在一些实施例中，即使主区域失效并且请求了强制切换，也可以保证全局表的主控权在当前主租约到期之前不改变。

在一些实施例中，GRR和复制服务可以缓存主控权信息，直到到期时间(或在考虑时钟异步之前不久)。在一些实施例中，GRR可以在主租约到期时刷新其高速缓存，或者在租约到期之前主动刷新其高速缓存。在一些实施例中，较长的租约可以被较不频繁地刷新，由此增加了可扩展性，但也延迟了主区域的改变。在一些实施例中，因为到期时间是明确的，所以可以执行以最终一致性读取主租约元数据，并且只要租约持续时间长于跨区域复制滞后，则以最终一致性读取主租约元数据可能是有益的。

在一些实施例中，不能假设缓存和使用主控权信息的节点具有紧密同步的时钟。因此，在一些实施例中，所述节点可能不就主租约是否已到期达成一致，这可能导致不正确的行为。可以假设时钟发散的上限并且保守地处理租约。在一些实施例中，如果租约持续时间较长，则此界限可以相当高。例如，在一些实施例中，使用一秒的时钟界限，五分钟的租约持续时间可能是合理的。在一些实施例中，缓存主控权信息的客户端可以根据其本地时钟而表现得似乎租约早一秒到期。在一些实施例中，希望获得主控权的区域可以根据其时钟而表现得似乎当前租约迟一秒到期。

图2绘示根据一些实施例的根据所需类型的数据一致性对次区域处的数据访问请求进行处理。在一些实施例中，数据访问请求的实例可以包括读取请求和写入请求。在一些实施例中，当应用程序向全局表提交数据访问请求时，GRR将根据需要在各区域之间路由请求。访问全局表中的数据的请求首先在次区域处从GRR处的客户端200被接收。在一些实施例中，GRR查找用于全局表的元数据，以确定在其中复制所述元数据的区域组和当前主区域。

在一些实施例中，即使存在本地副本，也可以将具有强一致性类型的读取和写入路由到不同的区域。在一些实施例中，如果请求是强一致的读取或写入，则在本地区域并非主区域的情况下GRR将请求路由到主区域220。在一些实施例中，一旦在主区域230处接收到所述请求，就调度所述请求以在所述区域的存储节点上执行240，所述区域的存储节点可以根据强一致性类型提供强一致性保证。在一些实施例中，接着可以在步骤250中执行所述请求，并且如果需要，将一个或多个更新记录添加到主区域的更新流中，以便于复制。

在一些实施例中，如果请求是与最终一致性类型相关联的读取或写入，则可以考虑更多的情况。在一些实施例中，在最简单的情况下，本地区域包含表的副本，GRR将请求转发到其相同区域中的请求派发器210。在一些实施例中，请求派发器210接着以平常的方式路由请求。在一些实施例中，如果不存在本地副本，则GRR选择包含副本的区域，然后向所述区域发送请求。在一些实施例中，尽管可以选择任何区域，但是可以选择最接近的区域而不是随机区域，以提供最低延迟。在一些实施例中，一旦在目的地区域处接收到请求，则根据本地区域的架构来调度所述请求在本地副本上的执行260。在一些实施例中，接着在步骤270中执行所述请求，并且如果需要，将一个或多个更新记录添加到本地区域的更新流中，以便于复制。

图3是绘示复制服务的一个实施例的框图，所述复制服务适于实施本文所述的一些或全部复制技术。为了简单起见，图3示出了三个区域300a-300c。虽然示出了三个节点，但是应当理解，复制系统并不旨在限于这种方式，实施例可以仅包括两个区域，或者可以包括比图3所示的三个区域更多的节点。在一些实施例中，为全局表的每个区域副本维护更新流325。

在一些实施例中，区域的更新流325包含在所述区域中发起的每个写入请求的一个或多个更新记录。在一些实施例中，区域的全局复制模块180仅包括代表更新流325中的应用而执行的写入，并且从更新流325中排除由复制过程本身执行的写入。在一些实施例中，虽然写入请求可以是复杂的，通常包括条件更新操作、递增操作和对特定属性的更新，但是与之相比，包括在更新流325中的更新记录是简单的。对于每个成功的应用程序启动的写入，更新记录包括由写入产生的数据的完整新版本。在一些实施例中，在区域之间传播整个项目版本，而不是写入请求本身，确保了复制是确定性的，并且将导致汇聚。具体地，在一些实施例中，如果在本地区域中条件写入成功，则最终将在所有其它区域中写入所产生的数据版本(除非由经由涉及下述冲突解决组件315的冲突解决过程的不相关更新所取代)。

在一些实施例中，更新流325的个别更新记录被输出组件320推送到其它区域120的输入组件310。在一些实施例中，因为复制系统独立地推送更新，所以给定数据项的版本可无序地得到副本。例如，在一些实施例中，假设区域300a更新产生第一新版本的项目的原始版本，则区域300b从区域300a接收所述项目的第一新版本并更新产生第二新版本的项目。在一些实施例中，第三区域300c接着将接收来自区域300a的项目的第一新版本和来自区域300b的项目的第二新版本。然而，这两个推送的更新到达区域300c的输入组件310的顺序是不确定的，因为区域之间的通信延迟可能变化。因此，对于每个写入请求，区域120添加更新时间戳作为所述项目上的系统属性。在一些实施例中，此更新时间戳可以在执行或写入请求期间添加，而在其它实施例中，更新时间戳可以由全局复制模块180添加。在一些实施例中，此更新时间戳与更新记录中的项目一起传播。在一些实施例中，即使在复制期间无序地接收到项目的最新版本，时间戳也可确定这些版本。在一些实施例中，当区域在复制期间接收到新版本时，所述区域检查其已经存储的版本的时间戳。如果所存储的版本具有较旧的时间戳，则写入新版本以进行替换；否则，在一些实施例中，忽略新接收的版本。在一些实施例中，所有副本可以就最新版本达成一致，而与接收版本的顺序无关。

在一些实施例中，强一致写入(因为其可在主区域中执行)是严格有序的且可能不冲突。因此，在一些实施例中，仅发布强一致写入的应用程序无需担心写入冲突。然而，最终一致的写入可导致冲突的更新，最显著的是当相同项目由不同区域中的不同写入者指派不同值或在一个区域中被删除而在另一个区域中被更新时。在一些实施例中，最终一致的写入可与其它此类写入或与强一致写入冲突。

所有更新冲突可在复制过程期间由冲突解决组件315自动检测和解决。选择项目的冲突版本之一以保留在全局表中；在一些实施例中，丢弃其它冲突版本。在一些实施例中，如果选择删除操作作为获胜者，则在所有副本中删除项目。

在一个实施例中，可以不检测冲突。在一些实施例中，时间戳系统属性用于对项目的顺序和冲突版本两者进行排序，并且根据最后写入者获胜的策略来平静而确定地解决冲突。

在另一实施例中，可检测并解决冲突，使得可报告关于冲突更新的度量且可记录丢失版本。在一些实施例中，使用版本向量轻松地完成对同一项目的并发更新的检测。在一些实施例中，每个项目可以具有被存储为另一系统属性的附加版本向量。在一些实施例中，版本向量从概念上包含用于全局表被复制的每个区域的条目，尽管零值条目不需要被明确地存储。在一些实施例中，语义上，版本向量对每个区域中的项目已被更新的次数进行计数。在一些实施例中，当初始创建项目时，除了在其中创建了项目的区域之外，其版本向量全为零。在一些实施例中，当应用程序更新区域中的项目时(而不是当通过复制过程传播更新的项目时)，项目的版本向量的区域的分量递增。在一些实施例中，如果两个版本向量都不支配另一个项目，则所述项目的两个版本被确定为冲突。

在一些实施例中，当解决冲突时，可使用强壮-然后－最新-写入者-获胜的策略来选择赢家。例如，在一些实施例中，由强一致写入产生的项目版本可优先于来自最终一致写入的项目版本。在一些实施例中，对于涉及两个最终一致操作的冲突，可以选择最后写入的版本(由生成的时间戳确定)作为获胜者。在一些实施例中，此规则保证所有区域将以确定的方式解决冲突，即使对于冲突写入的任意集合也是如此。在一些实施例中，应用程序可以选择不同的冲突解决策略或被通知数据库系统所丢弃的丢失版本。在一些实施例中，特定于应用程序的解决功能可以采取任意动作，例如(a)重新提交丢失版本，从而覆盖获胜者，(b)忽略丢失版本，从而接受获胜者的选择，(c)用不同的关键字或不同的表写入丢失版本，从而保存两个冲突的版本，或(d)将获胜版本和丢失版本合并为回写到全局表的新项目。

在一些实施例中，复制协议可以将元数据与每个项目相关联：更新时间戳，以对项目的版本进行一致地排序；版本向量，以检测对项目的冲突的更新；以及发生戳，以区分项目的不同体现与相同的主键。在一些实施例中，此信息可以作为属性与项目本身一起存储。在一些实施例中，这种属性对于从全局表读取项目的应用程序可能是不可见的，但是对于复制引擎和GRR是可访问的。在一些实施例中，在一个实施例中，复制引擎可以将每项目元数据存储为普通项目属性。可给予这些属性与应用程序所使用的属性名称不冲突的属性名称。在一些实施例中，应用程序可以读取此类属性，但不能进行删除或修改。

在一些实施例中，即使节点具有不完全同步的时钟，更新时间戳也可以单调增加。作为可以避免的问题的实例，在一些实施例中，考虑以下场景，项目在区域300a中更新，接着在区域300b中读取，然后在区域300b中更新。在一些实施例中，假设区域300a和300b中的时钟不同步，则在区域300b中生成的更新时间戳可以小于在区域300a中针对第一更新生成的时间戳。在一些实施例中，这将导致区域300b的更新丢失，尽管没有冲突。

在一个实施例中，项目的主区域可以从其本地时钟生成更新时间戳。在一些实施例中，如果其本地时间在项目的先前时间戳之前，则主区域可以使先前时间戳递增而不是使用其自己的时钟。在另一实施例中，复制输出组件320可将时间戳属性添加到其从更新流325读取的项目，并确保新的时间戳大于流记录中的原像的时间戳。在又一实施例中，在接收到写入请求时，GRR可以生成更新时间戳，并在项目正被写入时将其添加为系统属性。这些添加的时间戳属性将由GRR剥离，用于由读取操作返回的项目。在一些实施例中，为了确保这种时间戳增加，GRR需要在生成时间戳之前读取项目，以避免给每个写入请求增加延迟。

在一些实施例中，删除操作还将记录添加到更新流。在一些实施例中，一旦删除了项目，则不保留可用于相对于仍可能在传送中的其它更新对所删除版本进行排序的时间戳。作为简单实例，假设区域300a创建新项目，然后区域300b在接收到这个项目之后删除它。当区域300a从区域300b接收到删除记录时，它也将删除所述项目，并且这两个区域将被同步。然而，区域300c将接收来自区域300a的项目和来自区域300b的删除记录。如果区域模式300c首先接收到删除记录，则其将忽略所述删除记录并随后在其本地副本中创建所述项目，从而使其与区域300a和300b中的副本不一致。在一些实施例中，为了避免这个问题，副本可以在本地删除注册表中保留加时间戳的删除无效标记。在一些实施例中，当在复制期间接收到删除记录时，将无效标记保存在区域的注册表中，然后删除所述项目。在一些实施例中，当接收到更新记录时，如果不存在当前存储的版本，则查阅注册表以查看所述项目是否先前已被删除。如果存在无效标记，则接收到的版本由于过期而被忽略。在一些实施例中，如果并未找到无效标记，则在表中创建接收到的版本。在一些实施例中，一旦复制引擎确定项目已经被所有副本删除并且没有版本保留在任何更新流中，就可以从注册表中移除无效标记。

在一些实施例中，另外的问题在于删除的项目可以用相同的主键重新创建。在这种情况下，忽略新产生的版本可能是不适当的。相反，在一些实施例中，每个创建操作可以将唯一的发生戳作为系统属性附加到所创建的项目上。在一些实施例中，具有相同主键的项目的不同体现可以具有不同的发生戳。发生戳可以是GUID或简单时间戳。在一些实施例中，删除操作删除记录在所生成的无效标记中的具有特定发生戳的项目。在一些实施例中，复制引擎可以忽略具有存在无效标记的发生戳的项目的版本。

图4绘示根据一些实施例的将区域提升为主区域的请求的处理。在一些实施例中，例如因为当前主机已变得不可用，所以可由于客户端请求而接收提升区域的请求，而在其它实施例中，可基于一天中的时间或基于工作负荷来接收所述请求。在一些实施例中，当接收到将新的副本提升为主机的请求时400，首先在元数据表中创建过渡租约410。例如，在一些实施例中，可以连同此下一租约的到期时间一起写入正在接管的区域的名称。在一些实施例中，新的主机的租约可以从当前租约到期的时间开始直到下一个租约到期的时间。在一些实施例中，当现有的主租约到期420时，过渡租约可以成为新的主租约440，并且新的主控权开始。在一些实施例中，当新的主控权开始时，创建新时期450，并且在先前时期中的强一致读取可能无法保证。

过渡租约可以将过渡信息传送到分布式系统的不同组件。例如，当前主机使用条件写入来更新其租约的尝试可能失效，从而通知当前主机即将到来的过渡。在另一实例中，请求路由器在用租约信息刷新其高速缓存时可发现主控权变化正在进行中。

在一些实施例中，当GRR确定租约可能已经到期时，GRR可以停止对当前主机的强一致的读取和写入的路由，并且它将在等待一小段时间之后开始使用新的主机，以确保新的主机已经接管。在一些实施例中，在旧的主控权到期与新的主控权生效之间的时间段可以基于时钟异步的界限。在一些实施例中，在此期间，强一致的读取和写入可能被拒绝。在一些实施例中，这确保了在新时期接受任何读取和写入之前，在前一时期完成所有读取和写入。

在一些实施例中，区域可能变得不可用。在一些实施例中，因为跨区域复制过程将使不能被复制到区域的项目进行排队，并且在所述区域恢复时发送那些项目，所以不管暂时失效如何，都保证了最终的副本汇聚。类似地，在一些实施例中，在失效的区域恢复之后，在区域中写入但在区域失效之前未复制的项目被传播到其它区域。

在一些实施例中，如果非主区域变得不可用，则强一致的读取和写入以及对其它区域的最终一致的读取和写入可能不受影响。在一些实施例中，如果客户端使用失效区域的端点发出最终一致的操作，则所述客户端可以手动切换到另一区域的端点(或者可以等待直到所述区域恢复)。

在一些实施例中，如果全局表的主区域失效，则客户端可以手动地将主区域改变为新区域。在一些实施例中，为了确保清楚的过渡，新的主机可以在承担其职责之前等待一段时间。在一些实施例中，在前一主机不可用并且尚未发生到新主机的切换的过渡周期期间，强一致的读取和写入可能失败。

在一些实施例中，当执行到新的主机的切换时，创建新时期。在一些实施例中，在新的时期，新的主机可以接受强一致的读取和写入。然而，在一些实施例中，不能保证强一致读取观察前一时期的写入，仅观察当前时期的强一致写入。

在一些实施例中，在先前时期中的写入可能未丢失(除非所述区域经历多个不可恢复的驱动器故障)，并且当区域恢复时，所述写入可以被复制。在一些实施例中，此类写入可能与当前时期的写入冲突。在冲突的情况下，可以选择当前时代的写入作为获胜者。在一些实施例中

本文描述的作为数据存储服务基础的系统可以代表存储服务客户端(例如，客户端应用程序、用户和/或订户)将数据存储在包含具有一个或多个属性的项目的表中。在一些实施例中，数据存储服务可以向客户端呈现数据模型，其中代表客户端维护的每个表包含一个或多个项目，并且每个项目包括属性集合。项目的属性可以是按任何顺序的名称-值对的集合。在一些实施例中，项目中的每个属性可以具有名称、类型和值。一些属性可以是单值的，使得属性名称被映射到单个值，而其它属性可以是多值的，使得属性名称被映射到两个或更多个值。在一些实施例中，属性的名称可以总是字符串，但是其值可以是字符串、数字、字符串集合或数字集合。以下是属性的所有实例：“图像ID”＝1、“标题”＝“花”、“标记”＝{“花”、“茉莉”、“白色”}、“评级”＝{3、4、2}。可通过向每一项目分配主键值(其可包括一个或多个属性值)来管理所述项目，且此主键值还可用于唯一地识别所述项目。在一些实施例中，可以在表中的项目中定义大量属性，但是每个项目可以包含这些属性的稀疏集(其中为一个项目指定的特定属性与同一表中的另一项目的属性无关)，并且除了主键属性之外的所有属性都可以是可选的。换句话说，与传统数据库不同，由数据存储服务(和底层存储系统)维护的表可能除了依赖于主键之外并无预先定义的模式。注意，在一些实施例中，如果属性被包括在项目中，则其值不能为零或空(例如，属性名称和值不能为空字符串)，并且在单个项目中，其属性的名称可以是唯一的。

可在数据存储系统中采用各种类型以支持经排序索引中的数据排序。在一些实施例中，数据存储服务可以仅支持少量类型(例如，字符串和十进制数)，并且所有属性值可以具有标量或集合(多值)类型。例如，在一些实施例中，服务(和/或实施所述服务的底层系统)可以仅支持两种标量数据类型：字符串和数字(例如十进制数字)。在此类实施例中，日期可以被编码为整数(例如作为Unix期时间戳)，而不是使用“日期”数据类型。在其它实施例中，可以支持更多、更少或不同的数据类型。如上所述，在一些实施例中，属性名称可以总是数据类型“字符串”。在一些实施例中，服务(和/或底层系统)可以支持从所支持的标量类型导出的多值类型，如在以下实例中：

标题类型：＝{N|S}

多值类型：＝{NS|SS}

在此实例中，N表示数字，S表示字符串，NS表示一组数字，而SS表示一组字符串。在各种实施例中，类型“字符串”的属性可以是关键字的一部分或索引的一部分，并且字符串的最大大小可以受到索引键的大小(例如，对于范围键累积的1024字节或对于每个散列键的2048字节)或项目大小(例如，64K)的限制。在各种实施例中，类型“数字”的属性可用于存储精确值十进制和整数，并且可具有可变宽度编码。在一些实施例中，可由这种类型的属性占据的空间量可限于预定量。还应注意，在各种实施例中，数字可以具有精度P(表示可以被存储的有效数字的最大数目)和/或标度S(表示从小数点到最低有效数字的数字数目)。在一些情况下，数字的精度和标度可以由服务自动推断，并且适当的存储大小可以用于所述数字。在一些实施例中，可以使用在数字的开始处的负号来指定负数，但是可以不存储在数字之前指定的正号。在不同的实施例中，前导零和/或尾随零可以被存储或可以不被存储。以下是可由本文所述的服务(和底层系统)采用的数字格式的实例：

数字格式＝[+|-][{整数}][{.整数}]

如上所述，项目可以包括一个或多个属性。每个属性可以具有两个部分：属性名称(例如，UTF8字符串)和属性值(可以表示为类型和值对象的组合，其中所述类型描述值的类型)。在一些实施例中，单值属性可具有名称和标量值，并且属性的类型可被编码在属性值中，如以下实例中所示：

{“我的字符串属性”:{“S”:“我的字符串值”}}#字符串类型

{“我的字符串属性”:{“N”:123456.7}}#数字类型

在一些实施例中，多值属性可具有名称以及指定类型的一个或多个值。在此类实施例中，所述值可以是唯一的，如在以下实例中：

{“大小”:{“SS”:[“XL”,“L”,“M”,“S”]}#字符串集合

{“单一数字质数”:{“NS”:[2,3,5,7]}#数字集合

在一些实施例中，本文描述的系统可以采用稍受限制的索引和/或查询模型，以便为用户/订户或客户端应用程序提供大量(即，实际上无限制)的缩放、可预测性和简单性。例如，在一些实施例中，数据可以仅由主键来索引和分区(例如，在底层数据库中分区)。在此类实施例中，可以由用户在代表用户创建表时指定用于索引用户表中的数据的主键。此后，用户数据的分区可由系统处理，并从用户中提取。在一些实施例中，用于索引数据的主键可以由单个属性散列键组成。在其它实施例中，用于对数据进行索引和/或分区的主键可以是包含散列键组件和另一组件(在本文中有时称为范围键组件)的复合键。如本文更详细描述的，在各种实施例中，可以支持针对索引化属性的查询，并且可以提供全表扫描功能(例如，以支持故障排除)。在一些实施例中，用户可以基于不同于主键的那些属性的一个或多个属性来定义表的次索引，然后可以使用其已经定义的索引来查询项目。例如，在一些实施例中，系统可以支持在运行中创建次索引的创建(例如，使用创建索引API)，并且这些次索引可以基于存储需求(例如，增加或减少数据量)和/或读取/写入业务量来自动缩放。在一些实施例中，当更新表中的项目时，可以异步地更新此类次索引。

如前所述，在一些实施例中，对由数据存储服务所维护的每个表中的项目的数量可能并无预定义的限制。从概念上讲，每一项目可被认为是属性名称到对应属性值的映射。使用这个类比，映射中的每个条目都是属性。在各个实施例中，每个项目可包括关键字属性、加上零个或多个非关键字属性。在一些实施例中，关键字属性可以是单值属性，而非关键字属性可以是单值属性或多值属性。以下是具有五个属性的项目的实例：图片Id(字符串类型)、客户Id(数字类型)、标题(字符串类型)和标记(多值字符串属性)。

在各种实施例中，服务(和/或底层系统)可以对表格名称、项目、属性值、主键值和/或属性名称实施预定大小的限制。例如，在一些实施例中，可以限制项目中的所有属性名称和值的总大小(即，行大小)。

图5A和5B绘示根据一个实施例在多个表中的数据存储。如图5A所示和如上所述，多个表(示为表520a-520n)中的每一个可存储多个项目。在所示实例中，表520a存储项目521a-521n，而表520n存储项目522a-522n。如图5B所示，存储在表中的每个项目可包括多个属性，并且每个属性可包括属性名称和标量或设定类型值。在此实例中，项目521a(存储在表620a中)包括其值为1的数字“图像ID”属性、其值为20100915的数字“日期”属性、其值为“花”的名为“标题”的字符串属性，以及其值为包含字符串“花”、“茉莉”和“白色”的集合的名为“标记”的字符串属性。在此实例中，项目521b(其也被存储在表520a中)包括其值为2的数字“图像ID”属性、其值为包含数字值3、4和2的集合的名为“评级”的数字属性、其值为“书橱”的名为“标题”的字符串属性、其值为1024的数字“宽度”属性，以及其值为768的数字“深度”属性。在此实例中，项目521n(其也存储在表520a中)包括其值为n的数字“图像ID”属性、其值为20110327的数字“日期”属性，以及其值为包含字符串“法国”和“建筑”的集合的名为“标记”的字符串属性。注意，即使项目521a、521b和521n都存储在相同的表(表520a)中，所述项目也不都包括相同的属性集。相反，每个项目包括来自已经为存储在表520a中的项目集合指定的所有属性的稀疏属性集。在一些实施例中，除了用户数据之外，例如本文描述的表还可用于存储和管理系统元数据。

上述稀疏填充的项目可以通过下面的表1中的网格表示来进一步绘示。注意，下面的表1的网格格式仅仅是用于绘示以下事实的方便机制，即单个表中的各种项目可以包括在表中的项目集合中所包括的项目属性的不同子集。这并不意味着暗示用于在本文描述的非关系型数据库系统中维护的表的任何特定结构，或者用于项目本身的任何特定结构。因此，下面的表1的行和列的选择和排列可以被认为是任意的并且仅用于说明的目的。如本文所述，由本文所述的系统维护的表可能不具有固定模式。这样，项目可能不包括用于未被包括在其中的属性的占位符(即，空元素)，并且属性(以及其值)可被添加到一个或多个项目而不必将所述属性添加到所有其它项目。

表1-稀疏填充的项目属性的实例

在一些实施例中，由数据存储服务代表客户端维护的表可以具有标识其项目的主键。在各种实施例中，可在一个属性上定义主键(且可为单值的，如上所述)或在若干属性上定义主键(即，其可为复合主键，如上所述)。关键字属性可以是不可变的、可以具有固定类型，并且可以对于每个项目是强制性的，因为所述关键字属性唯一地标识表内的项目。在一些实施例中，主键是索引表的唯一部分，并且在创建表时可以指定索引类型。例如，当创建项目表时，可以将属性指定为所述表的主键属性(或者可以为复合主键指定两个属性)。表中的所有项目可以包括为主键指定的属性，并且数据存储服务(和/或底层系统)可以确保那些属性名称的值(或值的组合)对于表中的每个项目是唯一的。例如，如果试图添加具有与现有项目相同的主键值的新项目，则所述新项目可替换表中的现有项目。

图6绘示根据一个实施例的可存储在表(对此名为“图像ID”的数字属性已被指定为主键)中的三个项目。在此实例中，项目600a包括图像ID属性(其值为1)以及至少三个其它属性(例如，日期属性、标题属性和标记属性)的值。类似地，项目600b包括图像ID属性(其值为2)和至少三个其它属性(例如，专辑属性、评级属性和标记属性)的值。在此实例中，项目600c包括图像ID属性(其值为3)以及至少三个其它属性(例如，日期属性、价格属性和作者属性)的值。在此实例中，存储在表中的项目可根据其主键值来索引。换言之，这些项目中的每一个可以单独由其主键值唯一地标识，并且检索已经由其主键值标识的项目的操作可以包括检索其一些或所有其它属性的值。

如上所述，数据存储服务(和/或底层系统)可基于主键创建索引。索引的类型可取决于表使用简单主键还是复合主键。例如，数据存储服务可以将主键索引为散列索引或散列和范围索引，如下所示：

·散列-A可以是字符串或数字。简单的主键可以具有一个索引值：散列索引，其可以是字符串或数字。

·范围-A范围可以是字符串或数字。范围可允许对表项目进行排序，使得数据查询可基于所述范围来细化结果。复合主键可以包含两个索引值：散列索引(在本文中有时被称为散列键值)和范围索引(在本文中有时被称为范围键值)。

简单的主键可能足以用于表数据的数据收集和不频繁扫描(例如，使用下面描述的扫描API)。复合主键可以允许更精确地组织表数据，并且可以允许使用下面描述的查询API来进行更有效的数据检索。以下地址表(表2)绘示了使用单个属性作为主键来唯一地标识表中的每一项目。

表2-使用简单的主键(字符串)

在此实例中，主键(即称为用户ID的属性)在每个项目中是必需的，并且其类型(“字符串”)对于每个项目是固定的。然而，每个项目也可以包括附加属性的任何组合。在一些实施例中，数据存储系统可以确保用户ID的值对于表中的每个项目是唯一的。如上所述，在一些实施例中，属性值不能为零或空。在此类实施例中，在表中不存在属性，直到/除非其具有与之相关联的值。下表(表3)将数字属性(在这种情况下，为图像ID)指定为主键，通过主键可以唯一地标识表中的项目：

表3-使用简单的主键(数字)

在此实例中，主键图像ID在每个项目中是必需的，并且其类型(“数字”)对于每个项目是固定的，但是每个项目可以包括其它属性的任何组合。如在前面的实例中，在一些实施例中，数据存储系统可以确保图像ID的值对于表中的每个项目是唯一的。如上所述，在一些实施例中，属性值不能为零或空。在此类实施例中，在表中不存在属性，直到/除非其具有与之相关联的值。

各种计算机系统中的任何一个都可以被配置为实施与用于多区多主数据库复制的技术相关联的过程，如以上关于各个图讨论的。图7是绘示计算机系统的一个实施例的框图，所述计算机系统适于实施本文所述的一些或所有技术和系统。在一些情况下，主计算机系统可以代管实施服务器、请求路由器、存储服务、控制系统或客户端的多个虚拟例子。然而，此处所描述的技术可在任何合适的计算机环境(例如，云计算环境，基于网络的服务，企业环境等)中执行。

各种所示实施例可包括例如图7所示的一个或多个计算机系统700，或以与针对计算机系统800所述的相同或类似方式工作的计算机系统700的一个或多个组件。

在所示实施例中，计算机系统700包括经由输入/输出(I/O)接口730耦合到系统存储器720的一个或多个处理器710。计算机系统700还包括耦合到I/O接口730的网络接口740。在一些实施例中，计算机系统700可以说明实施企业逻辑或可下载应用程序的服务器，而在其它实施例中，服务器可以包括比计算机系统700更多、更少或不同的元件。

在各种实施例中，计算机系统700可以是包括一个处理器710的单处理器系统，或包括若干处理器710(例如，两个、四个、八个或另一合适数目)的多处理器系统。处理器710可以是能够执行指令的任何合适的处理器。例如，在各种实施例中，处理器710可以是实施各种指令集架构(ISA)中的任何一种(例如x106、PowerPC、SPARC或MIPS ISA或任何其它合适的ISA)的嵌入式处理器。在多处理器系统中，每个处理器810可以共同地，但不是必须地实施相同的ISA。

系统存储器720可以存储可由处理器710访问的指令和数据。在各种实施例中，系统存储器720可使用任何合适的存储器技术来实施，例如静态随机存取存储器(SRAM)、同步动态RAM(SDRAM)、非易失性/快闪类型存储器或任何其它类型的存储器。在所示实施例中，实施所需功能的程序指令和数据(例如上述用于可下载软件或提供商网络的那些方法和技术)被示为作为程序指令725存储在系统存储器720中。在一些实施例中，系统存储器720可包括可如本文所述配置的数据存储器745。

在一个实施例中，I/O接口730可以协调处理器710、系统存储器720和系统中的任何外围设备之间的I/O业务量，包括通过网络接口740或其它外围接口。在一些实施例中，I/O接口730可以执行任何必要的协议、定时或其它数据变换，以将来自一个组件(例如，系统存储器720)的数据信号转换成适于由另一组件(例如，处理器710)使用的格式。在一些实施例中，I/O接口730可以包括对通过各种类型的外围总线附接的装置的支持，所述外围总线例如外围组件互连(PCI)总线标准或通用串行总线(USB)标准的变体。在一些实施例中，I/O接口730的功能可以被分成两个或更多个单独的组件，例如北桥和南桥。而且，在一些实施例中，I/O接口730的一些或全部功能(例如到系统存储器720的接口)可以直接并入到处理器710中。

网络接口740可允许数据在计算机系统700与附接到网络的其它装置之间(例如，在客户端设备与其它计算机系统之间或在主机之间)交换。特别地，网络接口740可以允许计算机系统800和/或各种其它装置760(例如，I/O装置)之间的通信。其它装置760可包括扫描装置、显示装置、输入装置和/或其它通信装置，如本文所述。网络接口740可通常支持一个或多个无线联网协议(例如，Wi-Fi/IEEE 802.7或另一无线联网标准)。然而，在各种实施例中，网络接口740可支持经由任何合适的有线或无线通用数据网络(例如，其它类型的以太网)的通信。另外，网络接口740可以支持经由例如模拟语音网络或数字光纤通信网络的电信/电话网络、经由例如光纤通道SAN的存储区域网络，或经由任何其它合适类型的网络和/或协议的通信。

在一些实施例中，系统存储器720可以是存储如上所述的程序指令和数据的计算机可访问介质的一个实施例。然而，在其它实施例中，可以在不同类型的计算机可访问介质上接收、发送或存储程序指令和/或数据。一般而言，计算机可访问介质可以包括计算机可读存储介质或例如磁性介质或光学介质的存储介质，例如经由I/O接口830耦合到计算机系统700的光盘或DVD/CD-ROM。计算机可读存储介质还可以包括任何易失性或非易失性介质，例如RAM(例如，SDRAM、DDR SDRAM、RDRAM、SRAM等)、ROM等，所述介质可被包括在计算机系统800的一些实施例中作为系统存储器720或另一类型的存储器。此外，计算机可访问介质可以包括经由例如网络和/或无线链路的通信介质传送的传输介质或信号(例如电信号、电磁信号或数字信号)，例如可以经由网络接口740实施的传输介质或信号。

在一些实施例中，I/O装置可以是相对简单或“瘦”的客户端设备。例如，I/O装置可以被实施为哑(dumb)终端，所述哑终端具有显示能力、数据输入能力和通信能力，但是具有很少的计算功能。然而，在一些实施例中，I/O装置可以是类似于计算机系统700实施的计算机系统，包括一个或多个处理器710和各种其它装置(尽管在一些实施例中，实施I/O装置750的计算机系统700可以具有稍微不同的装置，或不同类别的装置)。

在各种实施例中，根据各种实施例，I/O装置(例如，扫描仪或显示装置以及其它通信装置)可以包括但不限于以下中的一个或多个：手持式装置、由人佩戴或附接到人的装置，以及整合到或安装在任何移动设备或固定设备上的装置。I/O装置还可以包括但不限于以下中的一个或多个：个人计算机系统、台式计算机、机架式计算机、膝上型或笔记本计算机、工作站、网络计算机、“哑”终端(即，具有很少或没有集成处理能力的计算机终端)、个人数字助理(PDA)、移动电话或其它手持装置、专有装置、打印机或适于与计算机系统700通信的任何其它装置。通常，I/O装置(例如，光标控制装置、键盘或显示器)可以是能够与计算系统700的元件通信的任何装置。

还可以根据以下条款来描述本公开的实施例：

条款1.一种系统，其包含：

多个计算节点，所述多个计算节点实施分布式数据库的多个地域分布式数据库组，所述地域分布式数据库组中的每一个包含多个存储节点，包括主节点和一个或多个次节点，其中所述地域分布式数据库组中的每一个代管所述分布式数据库的相应副本，其中所述多个地域分布式数据库组包含主组和一个或多个次级组，所述多个计算节点用于：

在所述多个地域分布式数据库组中的次级组处接收写入请求；以及

响应于所述写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第一类型的写入一致性相关联，将所述写入请求转发到所述多个地域分布式数据库组的所述主组，其中所述第一类型的写入一致性是强一致性。

条款2.如条款1所述的系统，其中所述多个计算节点进一步：

在所述多个地域分布式数据库组中的所述次级组处接收第二写入请求；

响应于所述第二写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第二类型的写入一致性相关联，在所述多个地域分布式数据库组的所述次级组处执行所述第二写入请求，其中所述第二类型的写入一致性是最终一致性。

条款3.如条款2所述的系统，其中所述多个计算节点进一步：

在执行所述第二写入请求之后，使所述多个地域分布式数据库组中的所述主组和次级组的所述相应副本同步，其中所述同步被配置成汇聚所述相应副本，使得所述第二写入请求的结果被传送到所述多个地域分布式数据库组中的所述主组。

条款4.如条款1所述的系统，其中所述多个计算节点进一步：

接收将所述多个地域分布式数据库组中的次级组提升为所述主组的请求，其中所述主组由主租约标识；

响应于提升所述次级组的所述请求，创建将所述多个地域分布式数据库组中的所述次级组标识为下一主组的过渡租约。

条款5.一种方法，其包含：

在多个节点中的第一节点处接收写入请求，所述多个节点各自托管分布式数据库的相应副本；以及

向所述多个节点中的第二节点转发所述写入请求，所述第二节点托管所述分布式数据库的主副本；

其中，响应于所述写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第一类型的写入一致性相关联，并且响应于所述第一节点未托管所述主副本，执行所述转发。

条款6.如条款5所述的方法，其进一步包含：

使包括所述第二节点的所述多个节点中的两个或更多个的相应副本同步，所述第二节点托管所述分布式数据库的所述主副本，其中所述同步汇聚所述相应副本，使得数据在所述相应副本之间一致，并且其中在所述同步中使用的冲突解决策略与所述分布式数据库的客户端应用程序相关联。

条款7.如条款5所述的方法，其进一步包含：

在所述多个节点中的所述第一节点处接收第二写入请求；

响应于所述第二写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第二类型的写入一致性相关联，在所述多个节点中的所述第一节点处执行所述第二写入请求。

条款8.如条款7所述的方法，其进一步包含：

在执行所述第二写入请求之后，使所述多个节点中的所述第一节点和所述第二节点的所述相应副本同步，其中所述同步汇聚所述相应副本，使得所述第二写入请求的结果被传送到所述多个节点中的所述第二节点的所述主副本。

条款9.如条款5所述的方法，其进一步包含：

接收将托管在所述多个节点中的第三节点处的副本提升为所述主副本的请求，其中所述主副本通过主租约来标识；

响应于提升托管在第三节点处的所述副本的所述请求，创建将托管在所述第三节点处的所述副本标识为下一个主副本的过渡租约。

条款10.如条款5所述的方法，其进一步包含响应于所述主租约的到期将所述过渡租约转换为新的主租约。

条款11.如条款7所述的方法，其中在多个存储组中的所述第一节点处执行所述第二写入请求包含：

调度要在多个节点中的所述第一节点处执行的所述第二写入请求；以及

在所述多个节点中的所述第一节点处执行所述第二写入请求。

条款12.如条款5所述的方法，其中所述分布式数据库是地域分布式数据库，其中所述多个节点中的所述第一节点和所述第二节点被实施为包含一个或多个节点的区域存储组的一部分，并且其中所述第一节点和所述第二节点驻留在不同的地理区域中。

条款13.一种存储程序指令的非暂时性计算机可读介质，所述程序指令在由一个或多个处理器执行时使得所述一个或多个处理器：

在多个节点中的第一节点处接收写入请求，所述多个节点各自托管分布式数据库的相应副本；以及

向所述多个节点中的第二节点转发所述写入请求，所述第二节点托管所述分布式数据库的主副本；

其中，响应于所述写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第一类型的写入一致性相关联，并且响应于所述第一节点未托管所述主副本，执行所述转发。

条款14.如条款13所述的非暂时性计算机可读介质，其中当由所述一个或多个处理器执行时，所述程序指令使得所述一个或多个处理器进一步：

使包括所述第二节点的所述多个节点中的两个或更多个的相应副本同步，所述第二节点托管所述分布式数据库的主副本，其中所述同步汇聚所述相应副本，使得数据在所述相应副本之间一致，并且其中在所述同步中使用的冲突解决策略与所述分布式数据库的客户端应用程序相关联。

条款15.如条款13所述的非暂时性计算机可读介质，其中当由所述一个或多个处理器执行时，所述程序指令使得所述一个或多个处理器进一步：

在所述多个节点中的所述第一节点处接收第二写入请求；

响应于所述第二写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第二类型的写入一致性相关联，在所述多个节点中的所述第一节点处执行所述第二写入请求。

条款16.如条款15所述的非暂时性计算机可读介质，其中当由所述一个或多个处理器执行时，所述程序指令使得所述一个或多个处理器进一步：

在执行所述第二写入请求之后，使所述多个节点中的所述第一节点和所述第二节点的所述相应副本同步，其中所述同步汇聚所述相应副本，使得所述第二写入请求的结果被传送到所述多个节点中的所述第二节点的所述主副本。

条款17.如条款15所述的非暂时性计算机可读介质，其中，为了在所述多个节点中的所述第一节点处执行所述第二写入请求，所述程序指令在由一个或多个处理器执行时使得所述一个或多个处理器调度要在与所述多个节点中的所述第一节点相关联的存储节点处执行的所述第二写入请求。

条款18.如条款13所述的非暂时性计算机可读介质，其中当由所述一个或多个处理器执行时，所述程序指令使得所述一个或多个处理器进一步：

接收将托管在所述多个计算节点中的第三节点处的副本提升为所述主副本的请求，其中所述主副本通过主租约来标识；

响应于提升托管在第三节点处的所述副本的所述请求，创建将托管在所述第三节点处的所述副本标识为下一个主副本的过渡租约。

条款19.如条款18所述的非暂时性计算机可读介质，其中所述程序指令在由所述一个或多个处理器执行时使得所述一个或多个处理器响应于所述主租约的到期而将所述过渡租约进一步转换为新的主租约。

条款20.如条款13所述的非暂时性计算机可读介质，所述分布式数据库是地域分布式数据库，其中所述多个节点中的所述第一节点和所述第二节点是包含一个或多个节点的区域存储组，并且其中所述第一节点和所述第二节点驻留在不同的地理区域中。

如在附图中所示和本文中所描述的各种方法表示方法的说明性实施例。所述方法可手动地在软件中、在硬件中或其组合中实施。任何方法的顺序可以改变，并且各个元素可以被添加、重新排序、组合、省略、修改等。举例来说，在一个实施例中，所述方法可由计算机系统实施，所述计算机系统包括执行存储在耦合到处理器的计算机可读存储介质上的程序指令的处理器。所述程序指令可经配置以实施本文所描述的功能性。

对于受益于本公开内容的本领域技术人员显而易见的是，可以进行各种修改和改变。本发明旨在涵盖所有这些修改和变化，并且因此，以上描述应被视为说明性的而非限制性的。

各种实施例可进一步包括接收、发送或存储根据以上描述在计算机可访问介质上实施的指令和/或数据。一般而言，计算机可访问介质可以包括存储介质或存储器介质(例如磁性介质或光学介质，例如光盘或DVD/CD-ROM)、易失性或非易失性介质(例如RAM(例如SDRAM、DDR、RDRAM、SRAM等)、ROM等)，以及经由例如网络和/或无线链路的通信介质传送的传输介质或例如电信号、电磁信号或数字信号的信号。

Claims (15)

1.一种用于数据存储的系统，其包含：

多个计算节点，所述多个计算节点各自托管分布式数据库的相应副本，所述多个计算节点被配置成：

在多个节点中的第一节点处接收写入请求，所述多个节点各自响应于从所述分布式数据库的客户端接收到写入请求而执行所述写入请求，其中，所述写入请求包括对所述分布式数据库的至少一部分的更新；

由所述第一节点根据与所述写入请求相关联的第一类型的写入一致性来确定是执行还是转发所接收到的写入请求，所述第一类型的写入一致性是由所述分布式数据库提供的多种不同类型的写入一致性之一；以及

向所述多个节点中的第二节点转发所述写入请求，所述第二节点托管所述分布式数据库的主副本；

其中，响应于确定所述第一类型的写入一致性指示应当转发而不是执行所述写入请求，并且响应于所述第一节点未托管所述主副本，执行所述转发。

2.根据权利要求1所述的系统，其中所述多个计算节点进一步被配置成：

使包括所述第二节点中的所述多个节点中的两个或更多个节点的相应副本同步，所述第二节点托管所述分布式数据库的所述主副本，其中所述同步汇聚所述相应副本，使得数据在所述相应副本之间一致，并且其中在所述同步中使用的冲突解决策略与所述分布式数据库的客户端应用程序相关联。

3.根据权利要求1所述的系统，其中所述多个计算节点进一步被配置成：在多个节点中的所述第一节点处接收第二写入请求；

响应于所述第二写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第二类型的写入一致性相关联，在多个节点中的所述第一节点处执行所述第二写入请求，其中所述第二类型的写入一致性是最终一致性。

4.根据权利要求3所述的系统，其中所述多个计算节点进一步被配置成：

在执行所述第二写入请求之后，使所述多个节点中的所述第一节点和所述第二节点的所述相应副本同步，其中所述同步被配置成汇聚所述相应副本，使得所述第二写入请求的结果被传送到所述多个节点中的所述第二节点。

5.根据权利要求1所述的系统，其中所述多个计算节点进一步被配置成：

接收将托管在所述多个节点中的第三节点处的副本提升为所述主副本的请求，其中所述主副本通过主租约来标识；

响应于提升次级组的所述请求，创建将多个地域分布式数据库组中的所述次级组标识为下一主组的过渡租约。

6.根据权利要求1所述的系统，其中所述分布式数据库是地域分布式数据库，其中所述多个节点中的所述第一节点和所述第二节点被实施为包含一个或多个节点的区域存储组的一部分，并且其中所述第一节点和所述第二节点驻留在不同的地理区域中。

7.一种用于数据存储的方法，其包含：

在多个节点中的第一节点处接收写入请求，所述多个节点各自托管分布式数据库的相应副本，并且所述多个节点各自响应于从所述分布式数据库的客户端接收到写入请求而执行所述写入请求，其中，所述写入请求包括对所述分布式数据库的至少一部分的更新；

由所述第一节点根据与所述写入请求相关联的第一类型的写入一致性来确定是执行还是转发所接收到的写入请求，所述第一类型的写入一致性是由所述分布式数据库提供的多种不同类型的写入一致性之一；以及

向所述多个节点中的第二节点转发所述写入请求，所述第二节点托管所述分布式数据库的主副本；

其中，响应于确定所述第一类型的写入一致性指示应当转发而不是执行所述写入请求，并且响应于所述第一节点未托管所述主副本，执行所述转发。

8.根据权利要求7所述的方法，其进一步包含：

使包括所述第二节点的所述多个节点中的两个或更多个节点的相应副本同步，所述第二节点托管所述分布式数据库的所述主副本，其中所述同步汇聚所述相应副本，使得数据在所述相应副本之间一致，并且其中在所述同步中使用的冲突解决策略与所述分布式数据库的客户端应用程序相关联。

9.根据权利要求7所述的方法，其进一步包含：

在所述多个节点中的所述第一节点处接收第二写入请求；

响应于所述第二写入请求与由所述分布式数据库提供的多种类型的写入一致性中的第二类型的写入一致性相关联，在所述多个节点中的所述第一节点处执行所述第二写入请求。

10.根据权利要求9所述的方法，其进一步包含：

在执行所述第二写入请求之后，使所述多个节点中的所述第一节点和所述第二节点的所述相应副本同步，其中所述同步汇聚所述相应副本，使得所述第二写入请求的结果被传送到所述多个节点中的所述第二节点的所述主副本。

11.根据权利要求9所述的方法，其中在多个存储组的所述第一节点处执行所述第二写入请求包含：

调度要在所述多个节点中的所述第一节点处执行的所述第二写入请求；以及

在所述多个节点中的所述第一节点处执行所述第二写入请求。

12.根据权利要求7所述的方法，其进一步包含：

接收将托管在所述多个节点中的第三节点处的副本提升为所述主副本的请求，其中所述主副本通过主租约来标识；

响应于提升托管在第三节点处的所述副本的所述请求，创建将托管在所述第三节点处的所述副本标识为下一个主副本的过渡租约。

13.根据权利要求12所述的方法，其进一步包含响应于所述主租约的到期将所述过渡租约转换为新的主租约。

14.根据权利要求7所述的方法，其中所述分布式数据库是地域分布式数据库，其中所述多个节点中的所述第一节点和所述第二节点被实施为包含一个或多个节点的区域存储组的一部分，并且其中所述第一节点和所述第二节点驻留在不同的地理区域中。

15.一种存储程序指令的非暂时性计算机可读介质，所述程序指令在由一个或多个处理器执行时使得所述一个或多个处理器：

在多个节点中的第一节点处接收写入请求，所述多个节点各自托管分布式数据库的相应副本，并且所述多个节点各自响应于从所述分布式数据库的客户端接收到写入请求而执行所述写入请求，其中，所述写入请求包括对所述分布式数据库的至少一部分的更新；

由所述第一节点根据与所述写入请求相关联的第一类型的写入一致性来确定是执行还是转发所接收到的写入请求，所述第一类型的写入一致性是由所述分布式数据库提供的多种不同类型的写入一致性之一；以及

向所述多个节点中的第二节点转发所述写入请求，所述第二节点托管所述分布式数据库的主副本；

其中，响应于确定所述第一类型的写入一致性指示应当转发而不是执行所述写入请求，并且响应于所述第一节点未托管所述主副本，执行所述转发。