一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

分布式跨区域的数据库事务处理的制作方法

2022-03-19 16:22:09 来源:中国专利 TAG:

分布式跨区域的数据库事务处理


背景技术:

1.分布式数据库解决了独立数据库的可扩展性问题,允许数据库系统的计算和存储容量灵活地增加,而不受单个服务器的限制。在分布式方案中,数据库可以分布到不同的物理位置,以确保高可用性。如果只有一个全局锁,那么它的物理位置可能接近某些数据库实体,但远离其他数据库实体。对于较远的数据库实体,其所遭遇的与获取时钟相关的网络延迟将会非常高,并会对这些数据库实体的吞吐量产生不利影响。如果有多个时钟位于不同的物理位置,那么就需要周期性地同步这些时钟,以抑制时钟彼此之间自然偏差的负面影响。尽管存在时钟同步协议,但仍然存在非零时钟偏差,这可能会导致数据库发出的关于事务提交的时间戳与绝对时间内事务提交的时间戳不一致。数据库发出的时间戳所指示的事务提交顺序与绝对时间内的事务提交顺序之间的差异可能导致数据库数据的读取不一致,这可能最终导致执行这类读取的应用程序出现问题。
附图说明
2.本发明的各种实施例在以下详细描述和附图中公开。
3.图1是分布式数据库方案的示意图。
4.图2是在分布于不同区域的数据库中进行事务处理的系统实施例的图。
5.图3示出hlc实施例的图。
6.图4示出示数据库服务器示例的图。
7.图5示出用于在跨区域分布的数据库中处理事务的进程的实施例的流程图。
8.图6示出用于确定某个事务是否将被跨多个区域执行的进程的示例的流程图。
9.图7示出在一个区域内的一个或多个数据库上执行事务的进程的示例的流程图。
10.图8示出在跨越多个区域的一个或多个数据库中执行事务的进程的示例的流程图。
11.图9示出基于从非本地来源接收的更新用于更新本地hlc的进程的示例的流程图。
12.图10示出了在跨多个区域的分布式数据库中执行事务处理的示例进程的序列图。
具体实施方式
13.本发明可以以多种方式实现,包括作为一个进程;一个设备;一个系统;物品的组成部分;体现在计算机可读存储介质上的计算机程序产品;和/或一种处理器,例如一种被配置为执行由耦合到所述处理器的内存提供和/或存储的指令的处理器。在本具体实施方式中,这些实现方式,或本发明可能采取的任何其他形式,可以称为技术。一般来说,所披露过程的步骤顺序可以在本发明的范围内变更。除非另有说明,所描述的被配置为执行任务的部件,如处理器或内存,可以采用被临时配置为在给定时间内执行所述任务的通用组件,或者,采用为执行所述任务的制成的特定组件。正如这里所使用的,术语“处理器”是指一个或多个设备、电路和/或配置为处理数据——例如计算机程序指令——的处理核心。
14.下面提供了本发明一个或多个实施例的详细描述,以及说明本发明原理的附图。
本发明所描述的与这些实施例相关,但本发明不限于任何实施例。本发明的范围仅受权利要求的限制,本发明涵盖许多替代选择、变型和等同物。为了提供对本发明的全面理解,以下描述中列出了许多具体细节。这些细节是为了举例的目的而提供的,发明可以根据权利要求实施,而不需要部分或全部这些具体细节。为了清晰起见,没有详细描述与本发明有关的技术领域中已知的技术内容,以避免本发明被不必要地遮盖。
15.图1是分布式数据库方案的示意图。如图1中的示例所示,数据库实体(例如,db1、db2、db3和db4)(它们分别在各自的数据库服务器上实现)分布在两个区域,区域1(dc1)和区域2(dc2)。在各实施例中,“地理区域”或仅仅“区域”包括地理区域。在各实施例中,部署在某个区域的数据库服务器被称为“数据中心”。区域之间的网络延迟通常超过100毫秒(ms)。如图1的示例所示,在一个分布式数据库系统中,每个区域可以有一个或多个数据库服务器的逻辑子组。这种数据库服务器的逻辑子组称为“子集群”。在图1中,dc1包括子集群1(sc1),它包括两个数据库服务器,db1和db2。dc2包括子集群2(sc2),它包括两个数据库服务器,db3和db4。数据库服务器(至少包括db1、db2、db3和db4)部署在不同的服务器上,但呈现给用户的却是具有单个数据库的特征。例如,在分布式数据库上读取数据和/或更新数据的事务可以在一个或多个数据库服务器上执行,这些服务器可能位于一个或多个区域。一个事务包含一个被所述数据库使用的功能,以确保操作的原子性和隔离性。
16.从高可用性的角度来看,分布式数据库可以扩展到多个子集群,从而确保在发生子集群故障时数据库的高可用性,为应用程序提供本地数据访问,以及增强用户体验。扩展到多个子集群也给分布式数据库带来了挑战,例如事务和并发管理所需的全局事件序列。在单个数据库服务器场景中,该序列仅由服务器的本地物理时钟提供;当部署一个子集群时,可以选择一个数据库服务器为子集群中的所有数据库实体提供全局物理时钟服务。当数据库服务器部署为跨越多个地区时,跨地区网络延迟非常高,使得获取集中的全局时钟的成本非常高,对高吞吐量的影响尤其大,低延迟事务负荷尤其大。
17.除了对分布在多个区域的数据库实体使用一个全局物理时钟外,还可以在各个区域实现多个物理时钟。自然偏差会存在于物理时钟系统之间,并且这些偏差会随着时间的推移而不断增加。为了确保不同时钟之间的物理时钟偏差(有时也被称为“时钟偏差”)最小化,使用gps、原子钟和其他协议(如网络时间协议“ntp”)来同步所有跨区域的不同物理时钟实体的时间。但是,考虑到所述不同时钟之间的物理时钟偏差是非零的,那么当在分布式数据库上不同的事务被执行,被准时关闭,就需要解决时钟偏差问题。
18.本文描述了在跨区域分布的数据库中的事务处理的实施例。由一个或多个语句集合组成的事务被确定在至少两个区域的多个数据库服务器上执行。在各实施例中,每个区域包括至少一个对应的集中时间服务(有时称为“cts”),该服务为该区域内的数据库服务器实现混合逻辑时钟(有时称为“hlc”)。在各实施例中,在配置为充当处理事务的协调器的数据库服务器上接收事务。所述一个或多个语句集合被执行于跨至少两个区域的多个数据库服务器上。协调器数据库服务器位于一个地区,因此依赖于该地区本地的hlc来确定时间,位于同一地区的其他数据库服务器也是如此。两阶段提交包括从跨越多个区域的多个数据库服务器获取多个基于hlc的准备时间戳。两阶段提交还包括选择最大的基于hlc的准备时间戳,作为与所述事务关联的提交时间戳。两阶段提交还包括使多个区域的多个数据库服务器使用所述提交时间戳提交与所述一个或多个语句集关联的执行结果。返回与所述
事务对应的提交结果。
19.根据下面各个实施例进一步的详细描述,一集中式时间服务时钟用于可以在单个区域的子集群中处理的事务,而混合逻辑时钟协议用于在不同区域的子集群中对跨这些区域处理的事务实施跨集中时间服务时钟的序列化。使用这些技术,基于在每个区域内使用统一的集中时间服务(混合逻辑时钟),事务处理成功地支持各个区域内的外部一致性。对于在同一会话中执行的事务(亦即,为同一会话中的事务而被数据库记录的提交时间戳的数量),外部一致性也得到了满足,因为同一会话中的事务是串行执行的。此外,这些技术确保了跨多个区域执行的事务的提交时间戳数量以及结果的观察序列是一致的。换句话说,尽管数据库所记录的所述事务提交时间戳可能不会反映它们按照绝对时间的提交时间,但它们反映了始终被观察到的一致顺序,因此绝对时间中的提交时间不再关键。此外,单个区域内的事务性能不受跨区域网络延迟和适用于跨区域事务的时钟偏差的影响(因为位于单个区域的数据库服务器依赖相同的集中时间服务系统)。在各实施例中,“跨区域”事务包括一事务,其一条或多条语句至少在位于第一区域内的数据库服务器和位于第二区域内的数据库服务器中执行。在某些实施例中,“跨区域”事务包括其至少一条语句在数据库服务器上执行的事务,该数据库服务器位于与协调器数据库所在的区域不同的区域。因此,本文描述的各实施例允许数据库跨区域分布,但仍然支持在单个区域内以高吞吐量和低延迟进行事务处理。
20.图2是在分布于不同区域的数据库中进行事务处理的系统实施例的图。
21.系统200包括多个区域,包括区域1(dc1)和区域2(dc2)。区域1和区域2位于两个不同的地理区域。区域1包括逻辑分组子集群1(sc1)中的数据库服务器db1和db2,区域2包括逻辑分组子集群2(sc2)中的数据库服务器db3和db4。从用户的角度来看,至少数据库服务器db1、db2、db3和db4可以实现一个分布式数据库。每个子集群1和子集群2都包含一个相应的集中时间服务(cts),分别生成混合逻辑时钟1(hlc1)和混合逻辑时钟2(hlc2)。在各实施例中,由cts生成的hlc是随着时间流逝而递增的物理时钟和当事件发生时递增的逻辑时钟的组合。当hlc的物理时钟部分增加时,hlc的逻辑时钟部分将重置为零。下面的图3示出hlc的一个实施例。
22.回到图2,子集群1的数据库服务器db1和db2从hlc1获取时间,hlc1作为子集群1的cts,数据库服务器db3和db4从hlc2获取时间,hlc2作为子集群2的cts。鉴于hlc1与db1和db2位于同一区域,db1和db2可以以最小的延迟从hlc1获取当前时间。类似地,鉴于hlc2与db3和db4位于同一区域,db3和db4可以以最小的延迟从hlc2获取当前时间。至少hlc1和hlc2以及来自区域1和区域2的其他子集群或其他区域的各个hlc保持的时间通过时钟同步协议(例如,ntp)进行同步,以减少这些时钟之间的时钟偏差。然而,直到最大值(例如10毫秒)的时钟偏差可能仍然存在于各个hlc之间。hlc1为db1和db2提供增量时间序列,而hlc2为db3和db4提供增量时间序列。
23.在一些实施例中,不同区域之间的网络延迟远远超过位于不同区域的各个hlc之间的最大时钟偏差。例如,各个hlc之间的最大时钟偏差为10毫秒,而由于地理距离的原因,不同区域之间的最大网络延迟为100毫秒。在各种实施例中,“不同区域之间的网络延迟”是指数据从一个区域发送到另一个区域所需要的时间长度。例如,一条消息通过网络206从区域1的一个数据库服务器传输到区域2的另一个数据库服务器,将会产生的最大的网络延迟
(例如,100毫秒)。网络206例如可以使用高速数据和/或电信网络实现。
24.分布在至少区域1和区域2的数据库的事务可能源于在客户端设备202上执行的应用程序204。在各实施例中,一个“事务”包括一个原子操作,该原子操作包括一个或多个要在分布式数据库中跨一个或多个数据库服务器执行的语句。在某些实施例中,将在其上(至少部分地)执行事务的每个数据库服务器有时被称为“参与数据库服务器”。例如,作为事务一部分的“语句”包含要应用于数据库的操作或命令。例如,语句可能包括读取操作、写入新数据的操作、删除存储在数据库中的现有数据的操作和/或更新数据库中现有数据的操作。举例来说,这些语句可能是结构化查询语言(structured query language,sql)语句/命令。
25.在各实施例中,应用程序204被配置为生成一个会话,并在会话中向分布在区域1和区域2的数据库发送一个或多个事务。由请求者(例如,应用程序204)向分布式数据库发出的事务在事务协调器处接收并处理。在各种实施例中,事务协调器是分布式数据库中的某个参与数据库服务器。事务中包含的语句集被确定为(例如,由协调器决定)由位于单个区域的数据库服务器执行还是跨多个区域执行。所述事务包含的语句集是否被位于一个地区或是被跨多个地区的数据库服务器执行,可能会取决于,例如,基于(例如,基于sql的)应用程序204发送的提示信息,或所述协调器使用的两阶段提交协议。在某些实施例中,由应用程序提供的提示信息可以指定事务或会话是否只对一个子集群或一个区域中的数据进行操作。例如,所述协调器是由分布式数据库使用的两阶段提交协议选择的。
26.如果,事务的语句集要在位于单个区域的数据库服务器上执行,则该语句集将在该区域内的一个或多个数据库服务器上执行。在各种实施例中,两阶段锁定协议(有时称为“2pl”)的第一阶段用于对受执行语句集影响的数据加锁。在一语句被执行后,任何受语句执行影响的数据库数据更改都是暂时的,直到提交操作使这些更改成为永久性的。两阶段锁定协议的第二阶段将在确定所述事务已被提交到数据库后解锁。当一个事务的语句集只影响一个区域时,在语句(集)被完成执行,整个事务的提交时间可以从协调器数据库服务器所在的子集群中的hlc中导出。例如,如果协调器数据库服务器是系统200的db1,那么事务的提交时间戳将从区域1的子集群1中的hlc1中获得。如果这组语句只在单个区域内的单个数据库服务器上执行,那么就没有必要分两个阶段执行提交。提交时间戳由协调器数据库服务器发送到受影响的数据库服务器,并由已经执行所述事务的所述语句(集)的数据库服务器记录。根据两阶段锁定协议的第二阶段,将日志写入,并解锁,以完成事务的提交。事务提交完成后,由于执行语句而对数据库数据的任何更改都将成为永久性的,并且其他事务/观察者也可以看到这些更改。但是,如果该语句集在一个区域内的多个数据库服务器上执行,则使用两阶段提交协议(有时称为“2pc”)来执行事务提交。当所述语句集由一个区域内的多个数据库服务器执行,协调器数据库服务器通过发送一个准备命令给每个参与数据库服务器,执行所述两阶段提交协议的第一阶段,然后,在收到来自每个参与数据库服务器的准备响应后,协调器数据库服务器通过向每个参与数据库服务器发送提交命令和提交时间戳来执行两阶段提交的第二阶段。执行准备命令意味着数据库将把事务的修改日志记录刷新到持久位置,比如磁盘。这确保了如果数据库崩溃,事务的修改不会丢失。执行提交命令意味着数据库将在执行准备命令后完成事务,包括将所述事务的状态设置为已提交和解锁。然后,每个参与数据库服务器记录提交时间戳,所述日志被写入,并根据所述两阶段锁
定的第二阶段解锁。随后,当从数据库读取数据时,可以使用提交时间戳。举个例子,一个读操作包括阅读时间戳,其被对比于所述被请求数据的提交时间戳,以确定哪个版本的所述被请求数据被读取(例如,被请求数据的版本的最后提交时间戳要确定为早于所述阅读时间戳)。在数据库服务器(组)记录提交时间戳并解锁之后,就认为事务成功,并将一个成功的提交结果(包括提交时间戳)发送回事务的发起者,应用程序204。对于只在一个区域内的数据库服务器上处理的事务,两阶段锁定实现了可序列化性和外部一致性。
27.如果事务的语句集将在跨多个区域的数据库服务器上执行,则该语句集将在跨多个区域的一个或多个数据库服务器上执行。在各种实施例中,两阶段锁定协议的第一阶段用于对受所执行语句集影响的数据加锁。两阶段提交协议的第一阶段也由协调器数据库服务器实施,它向跨多个区域的每个参与数据库服务器发送一个准备命令。每个参与数据库服务器将完成准备命令,并将从参与数据库服务器所属子集群的本地hlc获得的准备时间戳发送回协调器数据库服务器。协调器执行的两阶段提交协议的协调逻辑是选择从参与的数据库服务器接收到的最大/最新准备时间戳,并使用所选的准备时间戳作为所述事务的提交时间戳。例如,如果协调器数据库服务器是系统200的db1,该事务的参与数据库服务器为db2和db4,那么db2会将源自hlc1的准备时间戳返回db1,db3会将源自hlc2的准备时间戳返回db1。然后,协调器数据库服务器将向每个参与数据库服务器发送一个带有提交时间戳的提交命令。作为响应,参与数据库服务器将对受影响的数据记录所述提交时间戳,写入日志,解锁,完成所述提交,并向协调器数据库服务器发送提交返回消息。一旦协调器数据库服务器从所有参与数据库服务器接收到提交返回消息,协调器数据库服务器将所述事务的提交结果返回给应用程序204。这样,通过使用最大/最新准备时间戳作为所述事务的提交时间戳,两阶段提交为跨区域事务提供了跨多个区域的一致性。因此,在两阶段提交协议中选择/最大最新的准备时间戳作为所述事务的提交时间戳,这样,每个参与数据库服务器所记录的所述事务的提交时间戳使得位于不同区域的多个参与数据库服务器对所述事务拥有同样的提交时间戳。这样,可以使位于不同区域的多个参与数据库服务器对所述事务拥有相同的提交时间戳,从而获得一致性。如果没有选择跨所有参与数据库服务器的最大时间戳,那么在所述事务完成两阶段提交协议之后出现的事务可能会获得更大的提交时间戳,但无法读取所述完成事务的数据。
28.hlc确保在同一区域内执行且具有因果关系(例如,一个事务导致另一个事务发生)的事务的提交时间是有序的。然而,对于每个跨不同区域发生的事务,如果它们没有因果关系,那么它们在绝对时间中的顺序可能与它们的提交时间戳的顺序不同,但是,由于跨区域的网络延迟,这些事务的真实提交顺序(在绝对时间中)是不可观察的。在这种情况下,只要不同区域的hlc之间的最大时钟偏差远小于不同区域之间的网络延迟,就可以将这些事务的提交时间戳视为它们的提交顺序。
29.这里将进一步解释没有因果关系的跨区域事务的外部一致性。hlc的因果关系确保了同一数据库会话中的事务在外部是一致的,这是因为hlc的逻辑部分在响应事务处理时不断递增。在同一个会话中,事务是串行执行的,因此hlc的维持确保更大的提交时间戳肯定会用于随后发生的事务。hlc进一步确保,如果一个事务的结果被另一个事务读取,那么后一个事务的提交时间戳将大于前一个事务的提交时间戳。
30.然而,在多个/不同的数据库会话之间发生的事务之间不存在这些关系。在通常情
况下,当两个会话同时执行时,发起会话的应用程序不关心(不依赖于)两个会话分别执行的事务的发生顺序。在更特殊的情况下,当应用程序启动并管理两个数据库会话,并使用一个会话返回的结果作为决定执行另一个会话的依据,所述应用程序实际上维护一个应用程序级会话。在这种情况下,两个会话的事务执行结果之间存在依赖关系,如果两个会话在绝对时间内看到的这些事务的结果与这些事务的提交时间戳序列不一致,所述应用程序可能会产生错误的判断和结果。
31.在各种实施例中,只有在不同区域实际上同时发生(在最大时钟偏差范围内)且没有因果关系的事务才可能导致应用程序的两个会话看到不一致的结果。该场景的一个示例描述如下:
32.假设有三个区域,dc1、dc2和dc3,事务q1发生在dc1中,事务q2发生在dc2中,应用程序app3在dc3中启动两个会话r1和r2。q1和q2的提交时间戳(由数据库记录)分别为t1和t2,q1和q2的提交绝对时间分别为tabs1和tabs2,假设它们满足以下关系:
33.t1》t2
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(1)
34.tabs1《tabs2
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(2)
35.换句话说,q1和q2在绝对时间内的提交顺序和被数据库记录/执行的它们的提交时间戳的相对值是不一致的。这种不一致是由于分别在dc1和dc2执行的所述q1和q2的各自的相应时间服务系统之间的时钟偏差造成的。根据上面描述的提交时间关系,可以知道以下关系:
36.tabs1 maximum time skew》tabs2
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(3)
37.假设事务r1和事务r2分别访问dc1和dc2,访问时间分别为tabs11和tabs22,且访问时间满足以下关系:
38.tabs2》tabs22》tabs11》tabs1
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(4)
39.换句话说,r1在q1的结果提交到数据库之后访问了dc1,而r2在q2的结果提交到数据库之前访问了dc2。因此,r1能够看到q1的结果,而r2不能看到q2的结果。如果此应用程序依赖于r1的提交结果来确定r2的操作,则应用程序将看到不一致的结果。这是因为,根据数据库中的提交时间戳,当q1结果可见时,q2结果应该可见。换句话说,鉴于r1和r2的因果关系,以及r2应当在r1完成后执行,根据在绝对时间中,r2的发布是否早于q2的结果被提交到数据库,r2的操作结果会不相同。假如q2的结果提交早于r2的发出,则r2的运行可以产生一个操作结果;然而,如果q2的结果没有在r2发出之前被提交(如上面场景所描述的),则r2的运行可能产生另一个操作结果。
40.事实上,tabs2》tabs22》tabs11》tabs1不一定必须为真,这是因为跨区域的网络延迟(例如,100毫秒)远远大于不同区域的hlcs之间的时钟偏差(例如,10毫秒)。换句话说:
41.tabs22》tabs11 最大时间偏差》tabs1 最大时间偏差(5)
42.由于关系式(3)表明tabs1 最大时间偏差>tabs2,关系式(5)可以改写为:
43.tabs22>tabs11 最大时间差>tabs1 最大时间差>tabs2(6)
44.由于tabs22》tabs1 最大时间差》tabs2,以及,根据上述分析,只要跨区域中心的网络延迟远远大于位于不同区域的hlcs之间的时钟偏差,就可以保证跨区域事务的外部一致性。换句话说,鉴于跨区域中心的网络延迟远远大于位于不同区域的hlc之间的时钟偏差,被数据库锁记录的提交时间戳将反映外部可见/可观察的结果序列(实际的提交序列和
绝对时间的提交序列不再重要,因为没有观察者可以看到它们)。
45.在各种实施例中,对于仅在一个区域内执行的事务,某个hlc的逻辑时钟部分仅在事务提交时增加,以便区分不同事务的提交顺序。对于跨多个区域执行的事务,不仅hlc的逻辑时钟部分随事务被提交而增加,并且,在一些实施例中,来自其他区域的读操作被所述hlc本地的数据库服务器接收,所述hlc也需要更新。如果从另一个区域接收到一个操作(例如,与一个语句相关联的)的hlc时间戳大于接收到操作结果所在区域的本地hlc,则本地hlc相应增加。例如,来自另一个区域的操作可能包括读操作或提交命令。换句话说,当所述协调器数据库服务器接收到来自非本地的操作时,该操作携带该非本地的基于hlc的时间戳,并且,如果基于hlc的时间戳大于本地hlc,则需要更新本地hlc。例如,更新hlc可能是指增加hlc的逻辑时钟部分,以匹配被接受的时间戳,该时间戳源于对应于某个不同区域的另一hlc。在另一示例中,更新hlc可指将hlc的逻辑时钟部分增加预定量(例如,1)。在各实施例中,为每个会话维护最大hlc,以确保会话内事务的一致性。例如,如果在某个协调器数据库服务器上接收到会话级hlc,并且如果会话级hlc大于协调器数据库服务器本地的hlc,则协调器数据库服务器本地的hlc将相应地更新。
46.如上面所示,各种实施例使数据库能够跨多个区域扩展,以确保高可用性和对最近数据的访问,同时还减少仅在单个区域内执行的(例如,大部分)事务的延迟,从而在确保全局强一致性的同时,数据库不受区域间高延迟的影响。
47.图3是显示hlc实施例的图。图2中的hlc1和hlc2均可以使用图3的示例实现。hlc 300包括物理时钟302和逻辑时钟304两部分。如上所述,物理时钟302随着时间流逝而增加,逻辑时钟304随着在物理时钟302的最小时间单位(例如,微秒)发生的事件而增加。在某些实施例中,hlc 300使用64位实现,其中48位分配给物理时钟302,其余16位分配给逻辑时钟304。在某些实施例中,物理时钟302表示最高微秒粒度的物理时钟。在一些实施例中,逻辑时钟304可以被认为是一个计数器,其依赖于发生在数据库的事件而增加,以及,每次物理时钟302增加则复位为0(例如,通过其获取的时间的最小单位,例如可能是一微秒)。在某些实施例中,时钟同步协议将hlc 300的物理时钟302与一个或多个其他hlc的物理时钟302同步。逻辑时钟304通过发布事件的顺序来帮助获取分布式数据库中的时间和因果关系。
48.图4示出数据库服务器示例的图。在某些实施例中,数据库服务器db1、db2、db3和db4分别使用图4的示例实现。数据库服务器400包括协调器引擎402、语句执行引擎404、本地集中时间服务更新引擎406和数据库条目存储408。协调器引擎402、语句执行引擎404和本地集中时间服务更新引擎406都可以使用一个或多个硬件和/或软件来实现。数据库条目存储408可以使用一种或多种类型的存储介质来实现。
49.当数据库服务器400被选择(例如,通过两阶段提交协议)作为特定事务的协调器时,协调器引擎402被配置为执行与处理从应用程序接收到的事务相关的功能。所述事务是一个或多个语句的集合(例如,sql命令)。协调器引擎402被配置为确定所述事务(其中的所有语句)是在一个区域内(具体地说,是在该区域的子集群中的数据库服务器上),还是跨多个区域执行(具体地说,在多个区域的各个子集群的数据库服务器上)。例如,事务是在一个区域内执行,或者是跨多个区域执行,可以根据应用程序提供的(例如,基于sql的)提示信息来确定。
50.在要执行的事务在一个区域的情况下,协调员引擎402配置为执行在该区域跨一
个或多个参与数据库服务器的所述事务的所有语句,以及执行与该区域关联的集中时间服务(hlc)的事务时间戳。如果语句在多个数据库服务器上执行,那么协调器引擎402使用两阶段提交协议来验证所有参与数据库服务器是否准备好提交各自数据库中执行的部分。因为执行语句的所有参与数据库服务器(组)都位于同一个区域内,因此共享相同的hlc,所以在跨区域发送信息时不需要考虑时钟偏差或网络延迟。因此,在所述参与数据库服务器对受所述事务的语句影响的数据库部分记录提交时间戳之后,可以将协调器引擎402配置为向应用程序返回与所述事务关联的成功提交结果。
51.在跨多个区域执行事务的情况下,协调器引擎402被配置为执行跨多个区域的参与数据库服务器的事务的所有语句。协调器引擎402还被配置为从每个参与数据库中接收每个语句执行结束时的时间戳。每个这样的完成时间戳都是基于参与数据库服务器所在区域的子集群本地的hlc确定的。由于有多个参与数据库服务器涉及执行所述事务的所述语句,协调器引擎402被配置为使用两阶段协议以向跨多个区域的每个参与数据库服务器发送准备命令。然后,将协调器引擎402配置为从每个参与数据库服务器接收一个准备时间戳,并响应它们是否准备提交。从数据库服务器接收到的每个准备时间戳都是从数据库服务器所在区域的子集群本地hlc获取的。如果协调器引擎402从所有参与数据库服务器接收到成功准备的响应,则将协调器引擎402配置为选择与任何准备响应相关联的最大准备时间戳,以作为所述事务的提交时间戳。之后,协调器引擎402将事务提交时间戳发送到每个参与数据库服务器,参与数据库服务器记录该提交时间戳及其本地受影响的数据。一旦协调器引擎402收到来自每个参与数据库服务器的提交确认,协调器引擎402就被配置为将成功的提交结果返回给应用程序。
52.语句执行引擎404配置为执行影响存储在数据库条目存储408中的数据的语句。语句执行引擎404被配置为接收包含管理数据库数据的命令的语句。语句执行引擎404被配置为从数据库服务器接收语句,这些数据库服务器被选择作为处理事务的协调器。语句执行引擎404被配置为在数据库条目存储408的相关部分(例如,数据条目)执行每个接收到的语句。在某些实施例中,基于数据库服务器400所属区域的子集群本地hlc,语句执行引擎404记录与语句执行开始和/或结束对应的时间戳。在某个语句成功执行后,语句执行引擎404将记录的执行开始和结束时间戳发送给协调器数据库服务器,协调器数据库服务器可能与数据库服务器400位于同一区域,也可能不在同一区域。
53.对于不是仅在数据库服务器400上执行语句的事务,语句执行引擎404配置为接收来自协调器数据库服务器的准备命令,作为两阶段提交协议的第一阶段。为了响应所述准备命令,语句执行引擎404配置为执行与准备命令相关的一个或多个操作。为了响应所述准备命令,语句执行引擎404还被配置为向协调器数据库服务器回送一带有准备时间戳的准备响应,该准备时间戳是从数据库服务器400所属区域的子集群的本地hlc中获得的。在一个事务的两阶段提交的第二阶段——该事务的语句不仅仅在数据库服务器400上执行——语句执行引擎404被配置为接收来自协调器数据库服务器的提交命令,其中的提交命令包括所述事务的提交时间戳。为了响应所述准备命令,将语句执行引擎404配置为执行与提交命令相关的一个或多个操作,并记录所述事务提交时间戳。为了响应所述提交命令,还将语句执行引擎404配置为向协调器数据库服务器回送提交响应。
54.本地集中时间服务更新引擎406配置为更新数据库服务器400所属区域的子集群
的本地hlc,以响应某些事件。在各种实施例中,本地集中时间服务更新引擎406配置为确定在某些事件中是否更新数据库服务器400所属区域的子集群的本地hlc。在某些实施例中,当数据库服务器400接收到语句的执行结果,该语句包括在另一个区域执行的读取操作,并包括从另一个区域的hlc获得的读取时间戳,本地集中时间服务更新引擎406配置为对来自非本地区域的所述读取时间戳与当前本地hlc(本地数据库服务器400所属区域的子集群的本地hlc)进行比较,如果来自非本地区域的读取时间戳大于当前本地hlc,则本地集中时间服务更新引擎406配置为更新本地hlc(例如,匹配从非本地区域的hlc中获得的读取时间戳)。在某些实施例中,当数据库服务器400从位于非本区域的协调器数据库服务器接收到带有提交时间戳的提交命令时,本地集中时间服务更新引擎406配置为比较来自非本区域的所述提交时间戳与当前本地hlc,如果所述来自非本区域的所述提交时间戳大于所述当前本地hlc,则本地集中时间服务更新引擎406配置为更新所述本地hlc(例如,匹配从非本区域的hlc中获得的所述提交时间戳)。在某些实施例中,当选择数据库服务器400作为协调数据库并接收要为特定会话处理的事务时,将使用会话级hlc时间戳接收该事务。在某些实施例中,会话级hlc时间戳等价于该会话中最近执行的事务的提交时间戳或回滚时间戳。本地集中式时间服务更新引擎406配置为比较来自非本区域的所述会话级时间戳与当前本地hlc,如果所述来自非本区域的会话级时间戳大于所述当前本地hlc,则本地集中式时间服务更新引擎406配置为更新本地hlc(例如,匹配所述会话级hlc时间戳)。
55.图5示出用于在跨区域分布的数据库中处理事务的进程的实施例的流程图。在某些实施例中,流程500可以在图2中系统200的数据库服务器db1、db2、db3和db4中的任何一个上实现,该数据库服务器被选择作为某事务的协调器数据库服务器。
56.在502处,可以确定包含一个或多个语句集的事务将在多个数据库服务器上执行,这些服务器跨至少两个区域,其中每个区域都与各自的基于混合逻辑时钟(hlc)的集中时间服务相关联。例如,(例如基于sql的)来自产生事务的应用程序的提示信息用于确定事务是否是跨区域事务。每个区域包括一个使用hlc协议的集中时间服务的子集群。
57.在504处,一条或多条语句的集合将在跨至少两个区域的多个数据库服务器上执行。至少有一条语句在位于第一个区域的数据库服务器上执行,至少一条语句在位于第二个区域的数据库服务器上执行。
58.在506处,从跨至少两个区域的多个数据库服务器获得多个基于hlc的准备时间戳。
59.在508处,选择一个最大的基于hlc的准备时间戳作为与事务关联的提交时间戳。两阶段提交协议的一个版本用于提交事务。由于语句由分别位于至少两个不同区域中的至少两个数据库服务器执行,因此由参与数据库服务器回传的准备时间戳将分别从位于它们所属区域的子集群的相应的本地hlc导出。选择响应准备命令回传的最大准备时间戳作为所述事务的提交时间戳。数据库服务器使用从协调器接收到的提交时间戳提交事务。在数据库服务器执行提交之后,将返回一个包含提交时间戳的提交结果(例如,提交到事务的来源处)。
60.图6示出用于确定某个事务是否将被跨多个区域执行的进程的示例的流程图。在某些实施例中,可以在图2中系统200的数据库服务器db1、db2、db3和db4中的任何一个上实现进程600,这些数据库服务器被选择作为事务的调度数据库服务器。
61.在602处,某个包括一组语句的事务被接收。例如,所述事务作为特定会话的一部分接收自某个应用程序。
62.在604处,判断语句集是否要跨多个区域执行。如果要在单个区域内执行语句集,则将控制转移到606。否则,在跨多个区域执行语句集的情况下,控制将转移到608。在某些实施例中,根据应用程序提供的(例如,基于sql的)提示信息来确定语句集是在单个区域内执行还是跨多个区域执行。交易是否跨区域也可以根据任何其他适当的技术来确定。
63.在606处,所述事务在一个区域内的一个或多个数据库服务器上执行。
64.在608处,事务在跨多个区域的一个或多个数据库服务器上执行。
65.图7示出在单个区域内的一个或多个数据库上执行某个事务的进程的示例的流程图。在某些实施例中,可以在图2中系统200的数据库服务器db1、db2、db3和db4中的任何一个上实现进程700,这些数据库服务器被选择作为所述事务的调度数据库服务器。在某些实施例中,图6的进程600的步骤606至少部分地可以使用进程700实现。
66.在702处,确定一个包含语句集的事务将在一个区域内的一个或多个数据库服务器上执行。
67.在704处,所述语句集在一个或多个数据库服务器上执行。在这些语句在它们各自的参与数据库服务器上执行之后,对数据库数据的任何更改都是临时的,在处理中的所述事务被提交之前,这些更改对其他事务是不可见的。
68.在706处,受所述语句集影响的数据锁被一个或多个数据库服务器获得。使用两阶段锁定协议,被所述语句(集)临时更改的数据将被锁定(以便在提交处理中的所述事务之前,另一个并发事务不会再次更改该数据)。
69.在708处,从本区域的子集群的本地的集中时间服务获取提交时间戳。因为所述事务执行的语句(集)在数据库服务器(组)位于同一地区的子集群,所有这些数据库服务器(组)共享一个集中时间服务(本地hlc),在每条语句执行后,从本地hlc获取数据库中针对所述事务的提交时间戳。
70.在710处,确定所述语句集是否在多个数据库服务器上执行。在该语句集在本区域的子集群中的单个数据库服务器上执行的情况下,则控制权将转移到712。否则,在语句集在该区域的子集群中的多个数据库服务器上执行的情况下,控制将转移到720。如果这些语句(集)只在一个数据库服务器上执行,那么可以在不使用两阶段提交协议的情况下执行提交操作,并将控制权直接转移到712。否则,如果语句(集)在多个数据库服务器上执行,那么将使用两阶段提交协议执行提交操作,并首先将控制传输到720。
71.在712处,提交命令和提交时间戳被发送到数据库服务器(组)。提交命令和提交时间戳被发送到执行语句的每个参与数据库服务器。
72.在714处,执行解锁操作。一旦提交操作在每个参与数据库服务器上被执行,执行语句所做的临时更改将被永久化,并且可以在两阶段锁定协议的第二阶段对受影响数据解锁。
73.在716处,确定所述事务完成。在每个参与数据库服务器上完成提交操作并执行解锁之后,所述事务就被认定为完成。
74.在718处,返回一个成功的提交结果。在各种实施例中,一旦事务完成,就将成功提交结果消息返回给发起该事务的应用程序。
75.在720处,一个准备命令被发送到参与数据库服务器。作为两阶段提交协议的第一阶段,准备命令被发送到每个参与的数据库服务器。
76.在722处,确定所有参与数据库服务器是否成功执行了准备命令。在确定所有参与数据库服务器都已成功回送准备响应,则控制权被转移到712。否则,在成功回送的准备响应少于所有参与数据库服务器的情况,则控制将转移到724。除非所有参与数据库服务器都成功回送准备响应,否则两阶段提交协议不允许事务继续提交。
77.在724处,执行事务回滚。如果至少有一个参与数据库服务器不返回成功准备响应,则执行事务回滚,在此,执行所述事务的语句产生的临时更改被忽略或丢弃,所述数据库的数据返回到其执行语句(集)之前的状态。
78.图8示出在跨多个区域的一个或多个数据库中执行事务的进程的示例的流程图。在某些实施例中,可以在图2中系统200的数据库服务器db1、db2、db3和db4中的任何一个上实现进程800,这些数据库服务器被选择作为所述事务的协调员数据库服务器。在某些实施例中,图6的进程600的步骤608至少部分地可以使用进程800实现。
79.在802处,确定要在跨多个区域的一个或多个数据库服务器上执行一组语句。
80.在804处,所述语句集在一个或多个数据库服务器上执行。在这些语句在它们各自的参与数据库服务器上执行之后,对数据库数据的任何更改都是暂时的,在处理中的事务被提交之前,这些更改对其他事务是不可见的。
81.在806处,在一个或多个数据库服务器上获得受所述语句集影响的数据锁。使用两阶段锁定协议,语句暂时更改的数据将被锁定(以便在提交相关事务之前,另一个并发事务不会再次更改数据)。
82.在808处,准备命令被发送到跨多个区域的参与数据库服务器。作为两阶段提交协议的第一阶段,准备命令被发送到每个参与数据库服务器。
83.在810处,确定所有多个数据库服务器是否成功地执行了所述准备命令。在确定所有参与数据库服务器都已成功发回准备响应的情况下,控制权转移到814。否则,在成功发送回的准备响应少于所有参与数据库服务器的情况下,控制将转移到812。除非所有参与数据库服务器都成功回送准备响应,否则两阶段提交协议不允许事务继续提交。
84.在812处,执行事务回滚。如果至少有一个参与数据库服务器未返回成功准备响应,则执行事务回滚,在此,执行所述事务的语句产生的临时更改被忽略或丢弃,数据库的数据返回执行所述语句(集)之前的状态。
85.在814处,接收到来自参与数据库服务器的准备时间戳。各个参与数据库服务器随所述成功准备响应发送的所述准备时间戳,源自数据库服务器所在区域的子集群的本地hlc。
86.在816处,选择最大准备时间戳作为提交时间戳。选择参与数据库服务器返回的最大准备时间戳作为所述事务在所述数据库中的提交时间戳。
87.在818处,提交命令和提交时间戳被发送到参与数据库服务器。事务的提交命令和所述提交时间戳被发送到执行语句的每个参与数据库服务器。
88.在820处,实施解锁。一旦所述提交操作在每个参与数据库服务器上执行,执行语句所做的临时更改将被永久化,并且可以在两阶段锁定协议的第二阶段对受影响数据解锁。
89.在822处,确认所述交易完成。在每个参与数据库服务器上完成提交操作并解锁之后,所述事务就被认为完成了。
90.在824处,返回成功的提交结果。成功的提交结果返回给所述事务来源处的应用程序。
91.图9是一个流程图,该流程图示出了依据从本地来源接收的更新,更新本地hlc的进程的示例。在某些实施例中,可以在图2中系统200的数据库服务器db1、db2、db3和db4中的任何一个上实现进程900,无论该数据库服务器是否已被选择作为所述事务的协调器数据库服务器。
92.在各种实施例中,对于仅在单个区域内执行的事务,该区域的本地hlc的逻辑时钟充当集中式时间服务,该时间服务仅随物理时钟增加。但是,进程900描述了来自执行进程900的数据库服务器所在区域以外的来源的示例事件,在该数据库服务器中,数据库服务器被配置为更新其本地hlc。
93.在902处,确定是否从位于另一个区域的数据库服务器接收更新。在接收到这样的更新的情况下,控制就转移到904。否则,在没有接收到这样的更新的情况下,控制将转移到908。在一些实施例中,来自位于非本地区域(相对于执行进程900的数据库服务器所在的区域)的数据库服务器的更新包括操作结果(例如,通过执行read语句读取的值),所述操作结果包括从所述非本地区域对应的hlc获得的时间戳。例如,执行进程900的数据库服务器充当协调器数据库,用于处理一个事务,该事务包括读取存储在非本地区域的另一个数据库服务器上的值的语句。在某些实施例中,来自位于非本地区域的数据库服务器的更新为提交命令,该提交命令具有从对应于非本地区域的hlc获得的提交时间戳。例如,执行进程900的数据库服务器执行了一个包含在事务中的语句,协调器数据库服务器为所述事务启动了一个由两部分组成的提交阶段。
94.在904处,确定与更新相关的hlc时间戳是否大于当前本地hlc时间。在与更新相关的hlc时间戳大于当前本地hlc时间的情况下,将控制转移到906。否则,在与更新相关的hlc时间戳等于或小于当前本地hlc时间的情况下,将控制转移到908。与来自非本地区域的数据库服务器的更新相关联的基于hlc的时间戳将与当前时间进行比较,该时间戳由与执行进程900的数据库相关联的区域的子集群的本地hlc所提供。
95.在906处,更新本地hlc时间。如果基于hlc的更新时间戳大于本地hlc的时间,则更新本地hlc。在某些实施例中,本地hlc被更新以匹配所更新的所述基于hlc的时间戳。在某些实施例中,以预定的物理时间和/或逻辑时间间隔,增加所述本地hlc。例如,hlc增加了数值1。
96.在908处,决定是否接收到一个带有会话级hlc时间戳的新事务。在接收到一个新事务的情况下,将控制转移到910。否则,在没有接收到新事务的情况下,将控制转移到914。在执行进程900的数据库服务器充当某个事务的协调器的情况下,在某些情况下,会话级hlc时间戳由发起所述事务的应用程序维护。在各种实施例中,会话级hlc时间戳被设置为在会话中执行的最后一个事务的提交时间戳或回滚时间戳。
97.在910处,判断会话级hlc时间戳是否大于当前本地hlc时间。在会话级hlc时间戳大于当前本地hlc时间的情况下,将控制转移到912。否则,在会话级hlc时间戳等于或小于当前本地hlc时间的情况下,将控制转移到914。
98.在912处,更新本地hlc时间。在某些实施例中,所述本地hlc被更新以匹配所述会话级hlc时间戳。在某些实施例中,以预定的物理时间和/或逻辑时间间隔,增加所述本地hlc。例如,所述hlc增加了数值1。
99.在914处,确定是否停止更新本地hlc。在本地hlc将停止更新的情况下,结束进程900。否则,在本地hlc没有停止更新的情况下,控制返回902。例如,如果执行进程900的数据库服务器断电,所述本地hlc将停止更新。
100.图10示出了在跨多个区域的分布式数据库中执行事务处理的示例进程的序列图。在1000所示的进程示例中,在图2的系统200处接收到一个事务,其中选择区域1的子集群1的数据库服务器db1作为协调器数据库。从某个应用程序接收到包含语句s1和s2的事务。s1将在区域1的子集群1(dc1/sc1)的数据库服务器db2上执行,s2将在区域2的子集群2(dc2/sc2)的数据库服务器db3上执行,这意味着该事务是跨区域事务。由于协调器数据库服务器是位于dc1/sc1中的db1,因此dc1可能被称为本地dc/区域,而dc1/sc1本地的hlc1也可以被称为本地hlc。
101.在1002处,与某事务关联的初始化信息从所述应用程序发送到db1。
102.在1004处,db1执行初始化操作(集)。
103.在1006处,db1向所述应用程序发送确认,以表明已经执行了初始化。
104.在1008处,语句s1从所述应用程序发送到db1。
105.在1010处,db1将s1转发给db2。
106.在1012处,db1对其本地数据库数据执行s1。
107.在1014处,语句s1的完成时间戳从db2发送到db1。db1可能会记录这个完成时间戳。
108.1016处,与s1的执行结果相关联的结果从db1发送给所述应用程序。
109.在1018处,语句s2从所述应用程序发送到db1。
110.在1020处,db1将s2转发给db3。
111.在1022处,db3对其本地数据库数据执行s2。
112.在1024处,语句s2的完成时间戳从db3发送到db1。db1可能会记录这个结束时间戳,因为它是在非本地区域(dc2)执行的最后一条语句(s2)的结束时间戳。
113.在1026处,与s2的执行结果相关联的结果从db1发送给所述应用程序。
114.在1028处,所述应用程序向db1发送提交命令。
115.在1030处,一准备命令从db1发送到db2。这是两阶段提交协议的第一阶段的一部分,该协议用于在多个数据库服务器上执行事务时执行提交。
116.在1032处,准备命令从db1发送到db3。这是两阶段提交协议的第一阶段的一部分。
117.在1034处,准备时间戳从db2发送到db1。这个准备时间戳来自hlc1,并与成功的准备响应一起发送。
118.在1036处,一个准备时间戳从db3发送到db1。这个准备时间戳派生自hlc2,并与成功的准备响应一起发送。
119.在1038处,db1通过在从db2和db3接收到的准备时间戳中选择较大的时间戳来确定所述事务的提交时间戳。
120.在1040处,db1向db2发送提交命令和提交时间戳。
121.在1042处,db1向db3发送提交命令和所述提交时间戳。
122.在1044处,从db2向db1发送一个提交响应。
123.在1046处,一个提交响应从db3发送到db1。当db1从参与数据库服务器db2和db3接收到成功提交响应后,确定所述事务已完成。
124.在1048处,从db1向所述应用程序发送一个成功提交结果。
125.下面是一个新的实例,该实例描述一种场景,在该场景中,由于不同区域的子集群的各个hlc之间存在时钟偏差,访问数据库可能导致不一致的结果:
126.假设如图2所示建立分布式数据库。假设表tb1关于“foo”的记录存储在db2(dc1/sc1)中,表tb1关于“bar”的记录存储在db3(dc2/sc2)中。
127.假设事务q包含语句s1和s2。s1和s2在数据库中依次执行,其中:
128.语句s1,表示更新表tb1,设置tb1.姓名="foo."的余额tb1.balance=100;因此,s1在dc1/sc1中的db2上执行。
129.语句s2,表示更新表tb1,设置tb1.姓名="bar."的余额tb1.balance=200。因此,s2在dc2/sc2的db3上执行。
130.虽然s1在绝对时间上是在s2之前执行的,但由于dc1/sc1的hlc1和dc2/sc2的hlc2之间存在时钟偏差,s1记录的提交时间戳t1大于(晚于)s2记录的提交时间戳t2。假设如下:
131.t1(数据库为s1记录的提交时间戳)=103
132.t2(数据库为s2记录的提交时间戳)=101
133.tabs1(s1提交的绝对时间)=1000
134.tabs2(s2提交的绝对时间)=1005
135.总之,由于语句s1和s2在数据库中执行的时间很短,并且存在时钟偏差,因此它们在数据库中记录的提交时间戳(分别为t1和t2)的顺序与它们在绝对时间内的提交顺序不一致。
136.从数据库的角度来看,或者更确切地说,数据库所确认的s1和s2的提交顺序,s2在s1之前提交,因为t1>t2。但是,该数据库确认的提交顺序与s1和s2在绝对时间中的提交存在矛盾,因为tabs2》tabs1。
137.正确的(相对于被数据库确认的提交时间戳)对tb1中姓名分别为“foo”和“bar”的记录读取余额参数(tb1.balance),会返回以下三个结果之一:1)foo的余额为100和bar的余额为200;2)foo的余额为原余额数值(不是100),以及,bar的余额为200;和3)foo的余额为原余额值(不是100)和bar的余额为原余额值(不是200)。
138.但是,由于不同区域的子集群中的hlc之间存在时钟偏差,通常,一个不正确的(相对于数据库所遵循的提交时间戳)对tb1中姓名为“foo”和“bar”的记录读取的余额参数,会返回foo的余额为100,而bar的余额为原数值(不是200)。
139.应用程序创建两个观察者(会话),并使用第一个观察者的结果来确定第二个观察者的操作(也就是说,两个观察者有依赖关系)。以下是读取q1和q2结果通常可能产生的后果:
140.请求:如果观察者1看到foo的余额为100,那么观察者2将把bar的余额增加到220,要是bar当前的余额是200。。
141.观察者1在绝对时间1001去到db2 dc1/sc1,它会看到foo的余额为100,
142.观察者2在绝对时间1003到达dc2,它将看到bar的余额在它原来的值(不是200),然后应用程序将不会设置bar的余额为220。
143.然而,通过对数据库中执行的每个跨区域事务实施本文所述的技术,通过选择由参与数据库服务器之一发回的最大准备时间戳作为整个跨区域事务的提交时间戳,并考虑到跨区域网络延迟(例如,100毫秒)远远超过了位于不同区域的各个hlc之间的最大时钟偏斜(例如,10毫秒),当观察者1的成功提交结果返回到应用程序时,事务q将已经提交,并且两个语句s1和s2的执行结果将被记录为具有相同的提交时间戳。一旦语句s1和s2都提交了,观察者2就可以看到s2的正确结果。应用本文所述的技术后,两个会话将以如下方式执行:
144.观察者1启动事务a1。a1执行一条语句从tb1中选择/读取姓名为“foo”的记录的所述余额,该语句执行完成的时间戳来自hlc1。
145.当应用程序收到观察者1的a1返回的提交结果后,它知道foo的余额是100。然后应用程序通过观察者2发送事务a2(这是一个不同于观察者1的会话)。a2将按如下方式执行:从tb1中选择姓名为“bar”的余额,如果余额为200,则将余额更新为220。因此,观察者2接收bar的余额的读取结果,并检查所述余额是否为200。由于参与数据库服务器之一发送回的最大准备时间戳被用作每个整个跨区域事务的提交时间戳,并且,假设跨区域网络延迟(例如,100ms)远远超过位于不同区域的hlc之间的最大时钟偏移(例如,10ms),在执行a2时,a1将能够看到s2的提交结果,这意味着bar的余额为200,因此,a2将正确地将bar的余额更新为220。
146.尽管为了便于理解已对上述实施例进行了较为详细的描述,但本发明并不限于所提供的细节。实施本发明有许多替代方法。所公开的实施例具有说明性且不具有限制性。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献