CN115098229A - 事务处理方法、装置、节点设备及存储介质 - Google Patents

Abstract

本申请公开了一种事务处理方法、装置、节点设备及存储介质，属于数据库技术领域。本申请可应用于云技术、人工智能、智慧交通、辅助驾驶等各类场景，通过在分布式数据库系统中，向主副本节点设备分发子事务后，在准备阶段仅指示主副本节点设备进行数据异常检测但无需进行主从副本间的数据同步，在提交阶段后才指示主副本节点设备本地提交子事务并将重做日志同步到从副本节点设备，仅需要进行一轮通信就能够实现主从副本间的数据一致，极大降低了主从副本的同步次数，压缩了副本同步开销，从而尽量消除由于多副本机制对系统内事务处理性能的不良影响。

Description

事务处理方法、装置、节点设备及存储介质

技术领域

本申请涉及数据库技术领域，特别涉及一种事务处理方法、装置、节点设备及存储介质。

背景技术

随着数据库技术的发展和进步以及云环境的普及，使用分布式数据库来为大规模在线应用提供数据服务逐渐称为了一种流行趋势。当前，为了提供高可用的数据服务，分布式数据库普遍引入了多副本机制，即，在数据存储集群中，将数据切分成多个数据分区分别存储在不同数据节点上，每个数据分区都会在主从副本之间进行数据同步，通常一个主副本对应于多个从副本。

在引入多副本机制的情况下，涉及到操作粒度的副本同步技术，即，在事务执行过程中，对事务所涉及的每个写入操作，主副本都会将写入的数据同步到从副本上，但由于大数据场景下，可能会出现同一时间并行事务都要进行大量写入操作的情况，此时集群内主从副本间同步次数激增，副本同步开销很大，容易对数据库系统的事务处理性能造成不良影响。

发明内容

本申请实施例提供了一种事务处理方法、装置、节点设备及存储介质，能够降低集群内主从副本间的同步次数、压缩副本同步开销、改善由于副本同步对系统事务处理性能的不良影响。该技术方案如下：

一方面，提供了一种事务处理方法，由分布式数据库系统的协调节点设备执行，所述方法包括：

确定目标事务所涉及执行的数据库操作对应的主副本节点设备；

向所述主副本节点设备分发所述目标事务在所述主副本节点设备上的子事务；

向所述主副本节点设备发送准备请求，所述准备请求用于指示所述主副本节点设备对所述子事务进行数据异常检测；

在符合事务提交条件的情况下，向所述主副本节点设备发送提交请求，所述提交请求用于指示所述主副本节点设备提交所述子事务，以及将所述子事务的重做日志发送至对应的从副本节点设备。

一方面，提供了一种事务处理方法，由分布式数据库系统的主副本节点设备执行，所述方法包括：

响应于目标事务在所述主副本节点设备上的子事务，执行所述子事务对应的数据库操作；

响应于所述目标事务的准备请求，对所述子事务进行数据异常检测；

响应于所述目标事务的提交请求，提交所述子事务；

将所述子事务的重做日志发送至对应的从副本节点设备，以使所述从副本节点设备在回放所述重做日志时重做所述子事务。

一方面，提供了一种事务处理装置，所述装置为分布式数据库系统的协调节点设备，所述装置包括：

确定模块，用于确定目标事务所涉及执行的数据库操作对应的主副本节点设备；

分发模块，用于向所述主副本节点设备分发所述目标事务在所述主副本节点设备上的子事务；

发送模块，用于向所述主副本节点设备发送准备请求，所述准备请求用于指示所述主副本节点设备对所述子事务进行数据异常检测；

所述发送模块，还用于在符合事务提交条件的情况下，向所述主副本节点设备发送提交请求，所述提交请求用于指示所述主副本节点设备提交所述子事务，以及将所述子事务的重做日志发送至对应的从副本节点设备。

在一种可能实施方式中，所述确定模块用于：

确定所述数据库操作所对应数据项所属的数据分区；

基于分区信息表，查询得到所述数据分区对应的所述主副本节点设备，所述分区信息表用于记录数据分区与主副本节点设备的对应关系。

在一种可能实施方式中，所述协调节点设备存储有所述目标事务的操作日志列表，所述操作日志列表包括所述目标事务当前已执行的数据库操作的操作记录；

所述装置还包括：添加模块，用于响应于所述主副本节点设备返回的子事务执行结果，在所述操作日志列表中，添加所述子事务已执行的数据库操作的操作记录，所述操作记录表征所述数据库操作的操作类型和涉及操作的数据项。

在一种可能实施方式中，在所述分布式数据库系统中，所述协调节点设备和至少一个其他协调节点设备构成协调节点组，所述发送模块还用于：

每间隔第一目标时长，向所述协调节点组中的所述至少一个其他协调节点设备发送已存储的至少一个事务的操作日志列表。

在一种可能实施方式中，所述发送模块还用于：

在所述目标事务的子事务的操作记录均添加至所述操作日志列表，且所述操作日志列表已同步至任一其他协调节点设备的情况下，向所述主副本节点设备发送所述准备请求。

在一种可能实施方式中，所述操作日志列表还用于存储所述目标事务的准备操作记录或提交操作记录中至少一项，所述准备操作记录用于记录所述目标事务在准备阶段所处的状态，所述提交操作记录用于记录所述目标事务的提交阶段所处的状态。

在一种可能实施方式中，所述确定模块还用于：若所述主副本节点设备发生故障，确定从所述主副本节点设备对应的至少一个从副本节点设备中选举得到的目标节点设备；

所述确定模块还用于：确定所述目标节点设备对应的目标子事务，所述目标子事务是指原本由所述主副本节点设备执行但由于故障正在等待恢复的子事务；

所述发送模块还用于：向所述目标节点设备发送所述目标子事务的待恢复操作队列，所述待恢复操作队列包括所述目标子事务在操作日志列表中对应的至少一条操作记录。

在一种可能实施方式中，所述目标节点设备是从所述至少一个从副本节点设备中随机选举得到的；或，所述目标节点设备是所述至少一个从副本节点设备中负载最低的节点设备。

在一种可能实施方式中，在所述分布式数据库系统中，所述协调节点设备和至少一个其他协调节点设备构成协调节点组，若所述协调节点组中任一其他协调节点设备发生故障后，所述协调节点设备接管发生故障的其他协调节点设备上原本正在执行的事务，所述装置还包括：

查询模块，用于对所述发生故障的其他协调节点设备上原本正在执行的任一事务，查询所述事务的操作日志列表的同步进度参数，所述同步进度参数用于指示所述协调节点设备是否同步了所述事务全量的操作日志列表；

协调模块，用于在所述同步进度参数指示已同步所述事务全量的操作日志列表的情况下，基于已同步的操作日志列表，对所述事务进行协调；

所述协调模块，还用于在所述同步进度参数指示未同步所述事务全量的操作日志列表的情况下，通知发起所述事务的终端重新发送所述事务的请求语句；基于所述终端返回的请求语句，对所述事务进行协调。

一方面，提供了一种事务处理装置，所述装置为分布式数据库系统的主副本节点设备，所述装置包括：

执行模块，用于响应于目标事务在所述主副本节点设备上的子事务，执行所述子事务对应的数据库操作；

检测模块，用于响应于所述目标事务的准备请求，对所述子事务进行数据异常检测；

提交模块，用于响应于所述目标事务的提交请求，提交所述子事务；

发送模块，用于将所述子事务的重做日志发送至对应的从副本节点设备，以使所述从副本节点设备在回放所述重做日志时重做所述子事务。

在一种可能实施方式中，当所述主副本节点设备作为另一主副本节点设备的从副本节点设备时，若所述另一主副本节点设备发生故障后，所述主副本节点设备被选举为目标节点设备，所述装置还包括：

接收模块，用于接收任一协调节点设备发送的目标子事务的待恢复操作队列，所述目标子事务是指原本由所述协调节点设备分配给所述另一主副本节点设备执行、但由于故障正在等待恢复的子事务；

确定模块，用于基于所述待恢复操作队列，从所述目标子事务中，确定符合事务提交条件的第一子事务、符合事务回滚条件的第二子事务以及剩余的第三子事务；

重做模块，用于基于所述待恢复操作队列，重做所述第一子事务和所述第三子事务；

丢弃模块，用于丢弃所述第二子事务相关联的操作记录。

在一种可能实施方式中，所述确定模块用于：

在所述待恢复操作队列中，查询任一目标子事务所对应父事务的准备操作记录；

若所述准备操作记录指示所述父事务在准备阶段所处的状态为准备完成状态，将所述目标子事务确定为第一子事务；

若所述准备操作记录指示所述父事务在准备阶段所处的状态为准备失败状态，将所述目标子事务确定为第二子事务；

若所述准备操作记录指示所述父事务在准备阶段所处的状态既不是准备完成状态也不是准备失败状态，将所述目标子事务确定为第三子事务。

在一种可能实施方式中，所述重做模块包括：

第一重做单元，用于基于所述待恢复操作队列，重做所述第一子事务；

第二重做单元，用于在接收到所述分布式数据库系统中多个协调节点组中任一协调节点设备发送的重做完成指令的情况下，基于所述待恢复操作队列，重做所述第三子事务，所述重做完成指令用于表征对应协调节点组所负责协调的第一子事务重做完毕。

在一种可能实施方式中，所述第一重做单元用于：

在所述目标节点设备已对所述第一子事务的重做日志回放完毕的情况下，维护对所述第一子事务进行并发控制所需的信息，提交所述第一子事务；或，

在所述目标节点设备尚未回放所述第一子事务的重做日志的情况下，基于所述待恢复操作队列，执行所述第一子事务对应的至少一条操作记录，维护对所述第一子事务进行并发控制所需的信息，提交所述第一子事务。

在一种可能实施方式中，所述第二重做单元用于：

基于所述待恢复操作队列，执行所述第三子事务对应的至少一条操作记录，维护对所述第三子事务进行并发控制所需的信息；

响应于对所述第三子事务的提交请求，提交所述第三子事务，向所述目标节点设备对应的至少一个从副本节点设备发送所述第三子事务的重做日志；

响应于对所述第三子事务的回滚指令，回滚所述第三子事务。

一方面，提供了一种节点设备，该节点设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条计算机程序，该至少一条计算机程序由该一个或多个处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法。

一方面，提供了一种存储介质，该存储介质中存储有至少一条计算机程序，该至少一条计算机程序由处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法。

一方面，提供一种计算机程序产品或计算机程序，所述计算机程序产品或所述计算机程序包括一条或多条程序代码，所述一条或多条程序代码存储在计算机可读存储介质中。节点设备的一个或多个处理器能够从计算机可读存储介质中读取所述一条或多条程序代码，所述一个或多个处理器执行所述一条或多条程序代码，使得节点设备能够执行上述任一种可能实施方式的事务处理方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过在分布式数据库系统中，向主副本节点设备分发子事务后，在两阶段提交算法的准备阶段，协调节点设备下发准备请求，仅指示主副本节点设备进行数据异常检测但无需进行主从副本间的数据同步，在符合事务提交条件进入到提交阶段后，协调节点设备下发提交请求，才指示主副本节点设备本地提交子事务并将重做日志同步到从副本节点设备，因此仅需要在提交阶段进行一轮通信就能够实现主从副本间的数据一致，从而极大降低了系统内主从副本间的同步次数，压缩了多副本机制下的副本同步开销，从而尽量消除由于多副本机制对系统内事务处理性能的不良影响。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还能够根据这些附图获得其他的附图。

图1是本申请实施例提供的一种采用多副本机制的分布式数据库系统的原理性架构图；

图2是本申请实施例提供的一种操作粒度的副本同步的原理性示意图；

图3是本申请实施例提供的一种操作粒度同步下故障恢复技术的原理性示意图；

图4是本申请实施例提供的一种事务粒度的副本同步的原理性示意图；

图5是本申请实施例提供的一种事务处理方法的实施环境示意图；

图6是本申请实施例提供的一种事务处理方法的流程图；

图7是本申请实施例提供的一种事务处理方法的交互流程图；

图8是本申请实施例提供的一种轻量级的事务粒度副本同步机制的原理性流程图；

图9是本申请实施例提供的一种轻量级的事务粒度副本同步机制的原理性示意图；

图10是本申请实施例提供的一种结合OCC算法的轻量级的事务粒度副本同步机制的原理性流程图；

图11是本申请实施例提供的一种主副本节点设备故障时的故障恢复流程的交互流程图；

图12是本申请实施例提供的一种故障恢复机制的原理性流程图；

图13是本申请实施例提供的一种事务恢复流程的原理性示意图；

图14是本申请实施例提供的一种协调节点设备故障时的故障恢复流程的交互流程图；

图15是本申请实施例提供的一种事务执行流程的原理性示意图；

图16是本申请实施例提供的一种事务处理装置的结构示意图；

图17是本申请实施例提供的一种事务处理装置的结构示意图；

图18是本申请实施例提供的一种节点设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。

本申请中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个第一位置是指两个或两个以上的第一位置。

本申请中术语“包括A或B中至少一项”涉及如下几种情况：仅包括A，仅包括B，以及包括A和B两者。

本申请中涉及到的用户相关的信息(包括但不限于用户的设备信息、个人信息、行为信息等)、数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)以及信号，当以本申请实施例的方法运用到具体产品或技术中时，均为经过用户许可、同意、授权或者经过各方充分授权的，且相关信息、数据以及信号的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。例如，本申请中涉及到的数据项(若与用户相关)都是在经过充分授权和单独同意的情况下获取的。

在介绍本申请实施例之前，需要引入一些云技术领域内的基本概念：

云技术(Cloud Technology)：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也即是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，均能通过云计算来实现。

云存储(Cloud Storage)：是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

数据库(Database)：简而言之可视为一种电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

以下，对本申请实施例涉及的术语进行解释说明：

分布式数据库：分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有数据库管理系统的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。

事务(Transaction)：事务是数据库管理系统在执行操作的过程中的一个逻辑单位，由一个有限的数据库操作序列构成，是数据库系统操作的最小执行单位。在一个系统的内部，每个操作系列的单位，称为一个事务，单个操作也可以称为一个事务。

数据库操作：一个数据库操作由操作类型、事务、变量版本三部分构成，即是指事务对哪个版本的变量执行何种类型的数据库操作，其中，操作类型包括读(Read)和写(Write)两种，而变量是数据库操作的作用者(或者说操作对象)，一个变量可以包含若干变量版本(也称为版本)，每当事务对变量进行更新时，则会添加新的变量版本，变量的各个变量版本通常以自然数作为版本号标识，版本号越大，则表示变量版本越新。

并发控制：在计算机科学，特别是程序设计、操作系统、多重处理和数据库等领域，并发控制是确保及时纠正由并发操作导致的错误的一种机制。并发控制的基本单位是事务。并发控制指的是：当多个用户同时更新运行时，用于保护数据库完整性的各种技术。并发机制不正确可能导致脏读、幻读和不可重复读等此类问题。

锁机制：在数据库系统中，会存在同时有不同的事务需要修改同一个数据项的现象，通过锁机制来保证这些数据项在不同并发的事务中的修改正确性，换言之，锁机制能够保证在多并发事务环境中，在某一个时间点上，只能有一个事务能够获得某一个数据项的锁，从而保证数据的一致性。

乐观并发控制(Optimistic Concurrency Control，OCC)：OCC算法是一种应用于事务系统(比如关系型数据库管理系统与软件内存事务)的并发控制方法。在OCC算法中，假设大多数的事务可以在不互相干扰的情况下完成。当事务运行时，事务不需要申请资源的锁，便可以使用这些资源；在提交之前，每一个事务都会验证没有其他的事务修改了它所读取的数据项；如果检测到显式存在冲突修改，这一事务将被回滚。

两阶段提交(Two-Phase Commit，2PC)：也称为二阶段提交，在计算机网络以及数据库领域内，两阶段提交是指为了使基于分布式数据库系统架构下的所有节点设备在进行事务提交时保持一致性而设计的一种算法。通常，两阶段提交也被称为是一种协议。在分布式数据库系统中，涉及到一类跨节点操作的分布式事务，每个节点设备虽然可以知晓自己的数据库操作是成功还是失败，却无法知道其他节点设备的数据库操作是成功还是失败。当一个事务跨越多个节点设备时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点设备(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据项写入磁盘即数据落盘等)。因此，两阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。其中，ACID是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的所必须具备的四个特性：原子性(Atomicity，或称不可分割性)、一致性(Consistency)、隔离性(Isolation，又称独立性)、持久性(Durability)。

随着数据库技术的发展和进步以及云环境的普及，使用分布式数据库来为大规模在线应用提供数据服务逐渐称为了一种流行趋势。当前，为了提供高可用的数据服务，分布式数据库普遍引入了多副本机制，即，在数据存储集群中，将数据切分成多个数据分区分别存储在不同数据节点上，每个数据分区都会在主从副本之间进行数据同步，通常一个主副本对应于多个从副本。需要说明的是，在多副本机制中，主从副本是相对数据分区而言的，即，分布式数据库系统中可能会包含至少一个节点设备，每个节点设备上可能存储有多个数据分区的数据，但是，仅对部分数据分区提供主副本功能，对剩余数据分区则提供从副本功能，换言之，同一物理机可能相对于某些数据分区承担主副本，对另一些数据分区承担从副本。

图1是本申请实施例提供的一种采用多副本机制的分布式数据库系统的原理性架构图，如图1所示，在分布式数据库系统100中，可以将系统内的节点设备分解成两层：协调层和存储层，协调层由系统内的多个协调节点设备(Coordinator)组成，例如，协调层包括协调节点设备111～113，协调节点设备是指两阶段提交算法中的协调者，协调节点设备负责独立地对事务进行协调，并将事务执行结果返回给客户端；存储层由系统内的多个数据节点设备(Data Server)组成，例如，存储层包括数据节点设备121～124，数据节点设备是指两阶段提交算法中的参与者，数据节点设备负责存储和读写数据项。

在分布式数据库系统100中，会将数据水平划分成多个数据分区(Partition)，每个数据分区中都包含特定数量的数据项，并按照一定规则(如散列分区)分布在各个数据节点设备上。对每个数据分区而言，在分布式数据库系统100中都会对应有一个副本组(Replica Group)，即同一数据分区会在不同数据节点设备上存储多个数据副本，在一个副本组中有且仅有一个主副本(Leader，图1中使用实线框表示)，协调节点设备会将涉及到该数据分区的数据请求即读写请求均发送到主副本上，同时，副本组中除了主副本之外的其余副本均为从副本(Follower，图1中使用虚线框表示)，从副本的数量可以有一个或多个，主从副本之间通过副本同步机制(一般采用共识协议，如Paxos、Raft等一致性协议)，使得从副本与主副本之间保持数据同步。

示意性地，数据节点设备121上存储有数据分区1、2和3的数据，数据节点设备121仅作为数据分区1的主副本，对剩余的数据分区2和3则作为从副本；同理，数据节点设备122上存储有数据分区1和2的数据，数据节点设备122作为数据分区1的从副本，作为数据分区2的主副本；同理，数据节点设备123上存储有数据分区2和3的数据，数据节点设备123作为数据分区2的从副本，作为数据分区3的主副本；同理，数据节点设备124上存储有数据分区1和3的数据，数据节点设备124充当数据分区1和3的从副本。对于同一数据分区来说，以数据分区1为例，任一事务对数据分区1中数据的变更，将在主副本(即数据节点设备121)和其两个从副本(即数据节点设备122和124)之间进行数据同步(Replication)。

示意性地，在上述分布式数据库系统100中，事务执行的整体流程包括：在接收到外部的发起事务的数据请求后，系统随机为该事务分配一个协调节点设备，例如，针对外部的事务1(Txn 1)分配至协调节点设备111，那么协调节点设备111则负责协调事务1的后续操作。接着，协调节点设备111将事务1分解成一个或多个子事务，将每个子事务都分发到对应的数据节点设备，比如，事务1的某个子事务要操作数据分区3上的数据，协调节点设备111根据分区信息表，确定子事务所涉及数据项所在的数据分区3，接着，找到数据分区3的主副本即数据节点设备123，再将该子事务相关的数据库操作语句发送到数据节点设备123上，以便于数据节点设备123执行该子事务。最终，当事务1的所有子事务的读写操作完成后，事务将遵循两阶段提交算法在分布式数据库系统100内进行全局提交，此时，协调节点设备111会发起2PC请求，来与事务1所及到的各个数据节点设备进行通信，通过准备阶段(Prepare)和提交阶段(Commit)这两个阶段，来完成对事务1的全局提交。

在上述分布式数据库系统的框架下，可知，对任一分布式数据库系统(如Spanner、CockroachDB等)，在逻辑上可以划分成协调层和数据层，协调层由多个协调节点设备组成，协调节点设备负责处理数据请求，并将数据请求对应事务拆解成子事务，并实现子事务的分发，同时还负责向客户端返回事务执行结果；数据层由多个数据节点设备组成，数据节点设备负责存储和读写数据项，比如，每个数据节点设备的数据库中可以存储有一个或多个数据表，每个数据表可以用于存储一个或多个数据项。

在一些实施例中，上述分布式数据库系统可被提供为一种基于区块链技术的数据库系统(以下简称为“区块链系统”)，上述区块链系统在本质上属于一种去中心化式的分布式数据库系统，采用共识算法保持区块链上不同节点设备所记载的账本数据一致，通过密码算法保证不同节点设备之间账本数据的加密传送以及不可篡改，通过脚本系统来拓展账本功能，通过网络路由来进行不同节点设备之间的相互连接。

在区块链系统中可以包括一条或多条区块链，区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

区块链系统中节点设备之间可以组成点对点(Peer To Peer，P2P)网络，P2P协议是一个运行在传输控制协议(Transmission Control Protocol，TCP)协议之上的应用层协议。在区块链系统中，任一节点设备可以具备如下功能：1)路由，节点设备具有的基本功能，用于支持节点设备之间的通信；2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成账本数据，在账本数据中携带数字签名以表示数据来源，将账本数据发送至区块链系统中的其他节点设备，供其他节点设备在验证账本数据来源以及完整性成功时，将账本数据添加至临时区块中，其中，应用实现的业务可以包括钱包、共享账本、智能合约等；3)区块链，包括一系列按照先后的时间顺序相互接续的区块，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点设备提交的账本数据。

在一些实施例中，每个区块中可以包括本区块存储交易记录的哈希值(本区块的哈希值)以及前一区块的哈希值，各区块通过哈希值连接形成区块链，另，区块中还可以包括有区块生成时的时间戳等信息。

在上述分布式数据库系统的框架下，可知引入多副本机制时，必然涉及到要在事务执行过程中实现主从副本之间的副本同步，如操作粒度的副本同步、事务粒度的副本同步或者其他副本同步技术，下面一一进行说明。

A)操作粒度的副本同步

操作粒度的副本同步，是指在事务执行过程中，对于每个写入操作，主副本都会将写入的数据项同步到从副本上。图2是本申请实施例提供的一种操作粒度的副本同步的原理性示意图，如图2所示，在操作粒度的副本同步情况下，假设事务T1涉及到写入(Write)数据项X1和Y1，此时协调节点设备201会将写操作(如写数据版本X1)发送到X1所在数据分区的主副本211，然后主副本211在X1所在数据分区的副本组210中发起副本同步，将要写入的数据项X1同步到从副本212和213上，最终在副本组210中，保持主副本211和从副本212及213都将数据项X0更新成了X1，保持数据一致性。同理，协调节点设备201也会将写操作(如写数据版本Y1)发送到Y1所在数据分区的主副本，然后主副本发起副本同步，将要写入的数据项Y1同步到从副本上，与X1的副本同步过程类似，这里不做赘述。

基于这一同步机制，可知，当副本组中主副本发生节点故障时，由于从副本已经同步到了主副本上每次写操作的数据项，因此，只需要在副本组中重新选举一个主副本，并基于已同步的数据继续在新选举的主副本上进行数据读写，即可实现故障恢复。图3是本申请实施例提供的一种操作粒度同步下故障恢复技术的原理性示意图，如图3所示，如果副本组210中的主副本211在事务T1读数据项X前发生故障，副本组210会选择一个从副本替代其作为新的主副本，假设选举了原本的从副本212作为新的主副本，由于旧的主副本211在写入数据项X1时已经将X1同步到了从副本212上，因此在从副本212被选举为新的主副本之后，事务T1可以继续在新的主副本(即从副本212)上执行读X的操作，并能够保证读到故障发生前后一致的数据项X1，使得事务T1不会因为节点故障而回滚。

B)事务粒度的副本同步

事务粒度的副本同步，是指在事务进行两阶段提交时进行副本同步，即，在两阶段提交算法的准备阶段(Prepare)先同步一个准备日志(Prepare Log)，准备日志包含了这个事务需要写入的数据；然后在提交阶段(Commit)再同步一个提交日志(Commit Log)，提交日志包含了这个事务的提交信息。

图4是本申请实施例提供的一种事务粒度的副本同步的原理性示意图，如400所示，假设某一事务的协调节点设备为C1，事务涉及到操作数据分区1和2中的数据项，其中，数据分区1包括主副本P1和从副本P1’，数据分区2包括主副本P2和从副本P2’，那么在该事务进入准备阶段时，协调节点设备C1向该事务所涉及的所有数据项所在数据分区的主副本P1和P2发送准备请求，主副本P1会将收到的准备日志同步到从副本P1’上，并向协调节点设备C1返回准备完成响应，同理，主副本P2会将收到的准备日志同步到从副本P2’上，并向协调节点设备C1返回准备完成响应。协调节点设备C1收到所有数据分区的主副本返回的准备完成响应后，假设所有主副本都返回准备成功，则进入提交阶段；否则，任一主副本返回准备失败，该事务会被回滚。接着，在事务的提交阶段，协调节点设备C1向该事务所涉及的所有数据项所在数据分区的主副本P1和P2发送提交请求，主副本P1会将收到的提交日志同步到从副本P1’上，并向协调节点设备C1返回提交完成响应，同理，主副本P2会将收到的提交日志同步到从副本P2’上，并向协调节点设备C1返回提交完成响应，协调节点设备C1收到所有数据分区的主副本返回的提交完成响应后，如果所有主副本都返回提交成功，则事务提交完成。

基于这一事务粒度的副本同步策略，在发生节点故障时，正在执行的事务会被回滚，比如，在发生如图3所示的故障时，由于尚未进入到两阶段提交算法中，仍处于事务执行期间，主副本211发生故障，此时从副本212上没有事务T1所写入的数据项X1(仍然为旧版本X0)，会导致事务T1无法继续执行，因此事务T1会被回滚。

C)其他副本同步技术

传统的基于主备技术的数据库，一般采用事务提交时，会将事务产生的日志同步到备机上面，保持主备数据的一致性。如果出现节点故障，这类做法会将故障节点上正在执行的事务进行回滚，然后由备机继续提供服务。此外，还有一些系统使用懒复制(LazyReplication)来进行副本同步，提升事务处理的性能。懒复制技术是指：在事务提交后，生成额外的更新事务在从副本上异步的回放已提交事务所写入的数据项，然而，如果某一节点设备发生故障，这种机制会导致该节点设备上已提交事务所写入的数据项丢失，因此无法做到可用性。

综上所述，针对操作粒度的副本同步策略，由于每次执行写入操作都需要进行副本同步，在大数据场景下，可能会出现同一时间并行事务都要进行大量写入操作的情况，此时集群内主从副本间同步次数激增，副本同步开销很大，事务性能必然受到不良影响；针对事务粒度的副本同步策略，由于只有当进入到两阶段提交时才进行副本同步，可能存在较多事务会因为在进入两阶段提交之前发生节点故障而导致被回滚的情况。

有鉴于此，本申请实施例提供一种事务处理方法，即一种轻量级的副本同步机制，且提供了快速故障恢复方法，能够改善多副本机制下副本同步影响事务处理性能以及系统故障会导致事务被大量回滚这两大难题，实现了面向分布式数据库系统的高可用性以及高处理性能。

一方面，提供了轻量级的事务粒度副本同步机制，来提升分布式数据库系统的事务处理性能，即，仅在每个事务提交时，将事务写入的数据项打包进行副本同步，因此每个事务在进行副本同步时，无需在准备阶段和提交阶段均进行两轮同步，而是只需要在提交阶段进行一轮同步，因此能够将每个事务进行副本同步的网络开销减少至一轮，从而将由于副本同步对事务性能的影响降到最低。

另一方面，提供了一种快速故障恢复算法，来提升事务粒度副本同步机制的可用性，通过构建协调节点组，利用在协调节点组中其他协调节点设备上暂存的事务操作(即操作日志列表)以及多副本的特性，尽可能地保证了事务不会因为节点故障而被回滚，并且，在发生节点故障时，仅对故障节点上的子事务进行重做，而不会对整个父事务的所有子事务进行重做，从而提升了事务重做效率。

以下，对本申请实施例的系统架构进行说明。

图5是本申请实施例提供的一种事务处理方法的实施环境示意图。参见图5，本申请实施例适用于任一分布式数据库系统，如Spanner、CockroachDB等，在该分布式数据库系统中可以包括网关服务器501、分布式存储集群502以及分布式协调系统503(例如ZooKeeper)，分布式存储集群502相当于存储层，包括多个数据节点设备，该数据节点设备负责存储和读写数据项，分布式协调系统503相当于协调层，包括多个协调节点设备，该协调节点设备负责独立地对事务进行协调，并将事务执行结果返回给应用客户端。

网关服务器501用于接收外部的数据请求，并将数据请求对应的读写事务发送至分布式协调系统503，比如，用户在登录终端上的应用客户端之后，触发应用客户端生成数据请求，调用分布式数据库系统提供的API(Application Programming Interface，应用程序编程接口)将该数据请求发送至网关服务器501，比如，该API可以是MySQL API(一种关系型数据库系统提供的API)。

可选地，用户侧使用的终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、智能语音交互设备、智能家电、车载终端等，但并不局限于此。

在一些实施例中，该网关服务器501可以与分布式协调系统503的任一协调节点设备合并在同一个物理机上，也即是，让某个协调节点设备充当网关服务器501。

分布式协调系统503包括多个协调节点组，每个协调节点组中包括多个协调节点设备，针对网关服务器501转发过来的数据请求，会将该数据请求随机分配一个协调节点组中的一个协调节点设备，协调节点设备解析该数据请求得到对应的读写事务，再将读写事务进行拆解得到一个或多个子事务，将每个子事务转发到分布式存储集群502中对应数据分区的主副本(某个数据节点设备)上，同时，协调节点设备还负责对该读写事务进行两阶段提交的协调工作，最终协调节点设备将本读写事务的事务执行结果返回给网关服务器501，经由网关服务器501再将事务执行结果转发至应用客户端。

可选地，技术人员可以通过终端上的调度器(Scheduler)访问该分布式协调系统503，从而基于前端的调度器来控制后端的分布式协调系统503，实现对各个集群或服务器的管理。例如，技术人员可以通过调度器来控制ZooKeeper将某一个数据节点设备从分布式存储集群502中删除，也即是使得某一个数据节点设备失效。

分布式存储集群502包括多个数据节点设备，数据会被水平划分成多个数据分区，每个数据分区中都包含特定数量的数据项，并按照一定规则(如散列分区)分布在各个数据节点设备上，对每个数据分区都会对应于一个副本组，在副本组中包含多个数据副本，在副本组中有且仅有一个主副本，协调节点设备会将涉及到该数据分区的数据请求均发送到主副本上，同时，副本组中除了主副本之外的其余副本均为从副本，从副本的数量可以有一个或多个，主从副本之间通过副本同步机制(一般采用共识协议，如Paxos、Raft等一致性协议)，使得从副本与主副本之间保持数据同步。

示意性地，每个副本组中包括一个主副本和多个从副本，如图1所示，以副本组中包括一个主副本和两个从副本为例进行示意，主副本所在数据节点设备可称为主机，从副本所在数据节点设备可称为备机，每个主机或备机都对应配置有代理(Agent)设备，代理设备可以与主机或备机是物理独立的，当然，代理设备还可以作为主机或备机上的一个代理模块，以数据分区1的副本组1为例，副本组1包括一个主数据库及代理设备(主Database+agent，简称主DB+agent)，此外还包括两备数据库及代理设备(备Database+agent，简称备DB+agent)。

在一个示例性场景中，每个副本组所对应的主机或备机的数据库实例集合称为一个SET(集合)，例如，假设某一副本组采用一主两备集群架构，那么该副本组的SET为主机数据库实例以及两个备机数据库实例的集合，此时可以如Paxos、Raft等一致性协议来保证主机的数据与备机的副本数据之间的一致性，可选地，每个SET可以进行线性扩容，以应付大数据场景下的业务处理需求，在一些金融业务场景下，全局事务通常是指跨SET的转账。

上述图5提供的分布式数据库系统可以看作是共同维护一个逻辑上的大表，这个大表中存储的数据通过主键被打散到分布式存储集群502中的各个数据分区对应的副本组中，每个副本组上存储的数据分区是独立于其他副本组的，从而实现了对逻辑大表的水平切分。由于在上述系统中能够将各个数据库中各个数据表水平切分后进行分布式地存储，因此，这种系统也可以形象地称为具有“分库分表”的架构。

这一分库分表架构是分布式数据库的通用架构，在金融、互联网等场景下都具有广泛应用，产业影响力极大，如果存在跨节点的分布式事务，分布式数据库系统还可以通过两阶段提交算法等技术进行支持，保证了写操作时数据的原子性和一致性。

在一些实施例中，上述网关服务器501、分布式存储集群502以及分布式协调系统503所构成的分布式数据库系统，可以视为一种向用户终端提供数据服务的服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

用户侧使用的终端以及上述服务器可以通过有线或无线通信方式进行直接或间接地连接，且本申请可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等，本申请在此不做限制。

以下，对本申请实施例的副本同步机制进行简单介绍。

本申请实施例涉及的事务处理方法，可适用于各类分库分表类似架构的分布式数据库系统，在产品侧应用该方法，能够对分布式数据库产品提升事务处理性能，以满足当前互联网应用对数据库的性能的严苛要求，高性能的事务能力对产品竞争力的提升尤为重要。

图6是本申请实施例提供的一种事务处理方法的流程图。参见图6，该实施例由分布式数据库系统的协调节点设备执行，该实施例包括下述步骤：

601、协调节点设备确定目标事务所涉及执行的数据库操作对应的主副本节点设备。

其中，协调节点设备是分布式数据库系统中位于协调层的节点设备，协调节点设备负责独立地对事务进行协调，并将事务执行结果返回给终端侧的应用客户端。

其中，该目标事务基于数据请求解析得到，该数据请求包括DDL(Data DefinitionLanguage，数据定义语言)请求和DML(Data Manipulate Language，数据操纵语言)请求，DML请求是指业务请求，例如查询请求是一种典型的业务请求，在金融场景下，该查询请求为查询余额、查询流水等，在智慧交通场景下，该查询请求为查询附近空闲停车位、查询目的地附近的路况等，本申请实施例不对数据请求的内容进行具体限定。

在一些实施例中，该数据请求是由用户通过终端上的应用客户端向分布式数据库系统发送的请求，示意性地，用户在终端上登录应用客户端，触发应用客户端生成该数据请求，调用MySQL API将该数据请求发送至分布式数据库系统。

在一些实施例中，协调节点设备接收到任一请求后，解析该请求的头字段，当该头字段指示该请求为数据请求时，解析该数据请求的数据字段，得到该数据请求所对应的目标事务的SQL语句(或者，该数据请求也可以是NoSQL请求，此时解析到的通常是针对某一Key-Value键值对的数据结构的访问)。其中，SQL的英文全称为Structured QueryLanguage，中文全称为结构化查询语言。

可选地，协调节点设备可以直接接收应用客户端侧的数据请求，或者，协调节点设备接收到的是网关服务器转发的数据请求，网关服务器作为应用客户端和协调节点设备之间的中转，比如，网关服务器将新到的数据请求随机地转发到分布式协调系统中任一协调节点设备，或者，网关服务器将数据请求转发到分布式协调系统中负载较低的协调节点设备，以更好地实现系统负载均衡，本申请实施例对此不进行具体限定。

在一些实施例中，协调节点设备解析数据请求得到该目标事务的SQL语句之后，确定该目标事务所操作的至少一个数据项，本申请实施例涉及的数据项是指数据表中的一行数据记录(也称为元组)，数据项中存储了数据表的定义中所有数据列的实例化信息(即每个数据列对应的字段数据)，并按照数据列定义的顺序排列，组成一个连续的内容。其中，该目标事务对该数据记录的“操作”是指数据库操作，数据库操作的操作类型包括读操作和写操作，两者合并称为读写操作。

由于目标事务通常是由一个数据库操作序列构成的，即目标事务可能涉及到多个数据库操作，这些数据库操作也可能指向相同或不同的数据项，并且在分布式数据库系统中，不同的数据项还可能位于不同的数据分区中，不同的数据分区又各自对应于不同的主副本节点设备，从而导致很可能涉及到跨节点操作，本申请实施例涉及到针对跨节点操作的分布式事务的处理流程及副本同步机制。

在一些实施例中，对该目标事务所涉及执行数据库操作的任一数据项，确定该数据项所属的数据分区，接着，基于分区信息表，查询得到该数据分区所对应的主副本节点设备，其中该分区信息表用于记录数据分区与主副本节点设备的对应关系，对目标事务所涉及操作的每个数据项都执行上述操作，能够确定出至少一个数据项各自对应的至少一个主副本节点设备。

602、协调节点设备向该主副本节点设备分发该目标事务在该主副本节点设备上的子事务。

在一些实施例中，对上述步骤601确定出的至少一个主副本节点设备，协调节点设备将目标事务拆解成在至少一个主副本节点设备上各自的子事务，比如，对任一主副本节点设备，基于目标事务在该主副本节点设备所对应数据分区上操作的数据项以及对应的数据库操作，确定出在该主副本节点设备上的子事务，在一个示例中，目标事务涉及写入数据项X1和写入数据项Y1，数据项X属于数据分区1，数据项Y属于数据分区2，那么针对数据分区1的主副本节点设备1，拆解到该主副本节点设备1上的子事务就是写入数据项X1(即将数据项X从版本X0更新为版本X1)，针对数据分区2的主副本节点设备2，拆解到该主副本节点设备2上的子事务就是写入数据项Y1(即将数据项Y从版本Y0更新为Y1)。

在一些实施例中，对任一主副本节点设备，协调节点设备向该主副本节点设备发送携带对应子事务的数据库操作序列，从而实现对主副本节点设备分发子事务，以使得主副本节点设备在接收到分发的子事务时，按照分发该子事务的数据库操作序列，执行该子事务对各个数据项各自所对应的数据库操作。

在一个示例中，针对上述主副本节点设备1，拆解到的子事务是写入数据项X1，这一子事务的数据库操作序列为{(Write,X1)}，因此向主副本节点设备1发送对应子事务的数据库操作序列{(Write,X1)}，同理，向主副本节点设备2发送对应子事务的数据库操作序列{(Write,Y1)}。

603、协调节点设备向该主副本节点设备发送准备请求，该准备请求用于指示该主副本节点设备对该子事务进行数据异常检测。

在一些实施例中，每个主副本节点设备在接收到分发的子事务后，都会基于该子事务的数据库操作序列，执行该子事务对各个数据项各自所对应的数据库操作，在子事务执行完毕后，主副本节点设备向协调节点设备返回子事务执行结果。

由于同一目标事务可拆解成多个子事务，不同子事务通常对应于不同主副本节点设备，因此，协调节点设备接收各个主副本节点设备返回的子事务执行结果，如果收到了目标事务的所有子事务的子事务执行结果，代表可以进入到两阶段提交算法的准备阶段，因此协调节点设备向各个主副本节点设备发送准备请求，该准备请求用于指示主副本节点设备在本地开启对该子事务的数据异常检测，得到异常检测结果，并向协调节点设备返回与所得异常检测结果对应的准备完成响应。

示意性地，在OCC机制下，主副本节点设备在接收到准备请求后，对子事务的本地写集中的数据项进行加锁(即申请一把写锁)，再对子事务的本地读集中的数据项进行验证，判别数据项是否已经被其他事务修改，如果数据项已经被其他事务修改，则子事务对应的目标事务需要回滚，将异常检测结果置为存在异常，返回指示准备失败的准备完成响应，如果数据项没有被其他事务修改，继续检测下一个数据项，在遍历读集中所有数据项之后，如果所有数据项都没有被其他事务修改，将异常检测结果置为不存在异常，返回指示准备成功的准备完成响应。

604、协调节点设备在符合事务提交条件的情况下，向该主副本节点设备发送提交请求，该提交请求用于指示该主副本节点设备提交该子事务，以及将该子事务的重做日志发送至对应的从副本节点设备。

在一些实施例中，每个主副本节点设备在接收到准备请求之后，都会对子事务进行数据异常检测，得到一个异常检测结果，并向协调节点设备返回与该异常检测结果对应的准备完成响应，这一准备完成响应可以指示在本主副本节点设备上准备成功或者准备失败，如果异常检测结果为不存在异常，那么返回指示准备成功的准备完成响应，如果异常检测结果为存在异常，那么返回指示准备失败的准备完成响应。

在一些实施例中，协调节点设备在接收到目标事务所对应所有主副本节点设备返回的准备完成响应后，如果所有准备完成响应都指示准备成功，则确定符合事务提交条件；否则，任一准备完成响应指示准备失败时，则确定符合事务回滚条件。

在一些实施例中，为避免某一主副本节点设备迟迟不返回准备完成响应，导致协调节点设备一直处于等待准备完成响应的状态，技术人员预先设置一个超时阈值，协调节点设备在向各个主副本节点设备发出准备请求之后开始计时，在计时不超过超时阈值时，一直等待各个主副本节点设备返回的准备完成响应，在计时到达超时阈值时，不再等待，如果此时接收到了所有主副本节点设备返回的准备完成响应，且所有准备完成响应都指示准备成功，则确定符合事务提交条件；否则，如果任一主副本节点设备没有返回准备完成响应(即等待超时)，或者接收到的任一主副本节点设备返回的准备完成响应指示准备失败，则确定符合事务回滚条件。其中，该超时阈值是任一大于0的数值，比如超时阈值为3秒、5秒、10秒等，本申请实施例对超时阈值不进行具体限定。

在一些实施例中，在符合事务提交条件的情况下，协调节点设备向各个主副本节点设备都发送一个提交请求，这一提交请求用于指示每个主副本节点设备在本地提交对应的子事务，以实现本地数据落盘，同时为保证主从副本之间数据一致，该提交请求还用于指示每个主副本节点设备将该子事务的重做日志(Redo Log)发送到所属副本组的各个从副本节点设备上，以便于每个从副本节点设备在接收到该子事务的重做日志之后，能够异步回放该子事务的重做日志，从而在从副本节点设备上回放该子事务所涉及的对各个数据项的数据库操作，在回放完毕后能够保证主从副本之间的数据版本保持一致。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过在分布式数据库系统中，向主副本节点设备分发子事务后，在两阶段提交算法的准备阶段，协调节点设备下发准备请求，仅指示主副本节点设备进行数据异常检测但无需进行主从副本间的数据同步，在符合事务提交条件进入到提交阶段后，协调节点设备下发提交请求，才指示主副本节点设备本地提交子事务并将重做日志同步到从副本节点设备，因此仅需要在提交阶段进行一轮通信就能够实现主从副本间的数据一致，从而极大降低了系统内主从副本间的同步次数，压缩了多副本机制下的副本同步开销，从而尽量消除由于多副本机制对系统内事务处理性能的不良影响。

在上一实施例中，简单介绍了本申请轻量级的事务粒度副本同步机制，这一机制能够保证每个事务在需要进行副本同步时，其网络通信轮数最多为一轮，使得副本同步的开销降到最低。接下来，将结合在分布式数据库系统中构建协调节点组(CoordinatorGroup)，来介绍协调节点设备和数据节点设备间具体如何通信交互，以实现这一轻量级的事务粒度副本同步机制。

图7是本申请实施例提供的一种事务处理方法的交互流程图，如图7所示，该实施例适用于分布式数据库系统，由协调层中的协调节点设备和存储层中的数据节点设备之间交互实现，下面进行说明：

701、协调节点设备确定目标事务所涉及执行的各个数据库操作对应的主副本节点设备。

在本申请实施例中，引入协调节点组的概念，在分布式数据库系统的分布式协调系统中，涉及多个协调节点组，每个协调节点组由若干个(两个或两个以上)协调节点设备组成。

对于外部的数据请求，网关服务器将数据请求随机转发到任一协调节点组的任一协调节点设备中，以简化请求处理逻辑，或者，网关服务器将数据请求随机转发到任一协调节点组中负载最低的协调节点设备，以均衡系统内负载，或者，网关服务器将该数据请求转发到总负载最低的协调节点组中任一协调节点设备，以均衡系统内负载，或者，网关服务器将数据请求转发到总负载最低的协调节点组中负载最低的协调节点设备，以均衡系统内负载，本申请实施例对此不进行具体限定。

本申请实施例涉及的协调节点设备，是指协调节点组中负责处理目标事务的节点设备，该协调节点组中除了该协调节点设备以外的协调节点设备称作其他协调节点设备。

本申请实施例涉及的目标事务，是指分布式数据库系统所处理的任一事务，这一事务可以是读事务或者写事务，可以是单机事务也可以是分布式事务，由于单机事务不涉及到使用两阶段提交算法进行提交，因此这里以分布式事务为例进行说明。

在一些实施例中，协调节点设备接收到数据请求后，解析该数据请求得到目标事务的SQL语句，接着创建该目标事务，申请该目标事务的事务开始时间戳，同时在内存中初始化本目标事务的上下文信息，该上下文信息用于存储事务运行过程中所需要维护的信息。

在一些实施例中，在对该目标事务的上下文信息初始化完毕后，基于目标事务的SQL语句，确定该目标事务的数据库操作序列，该数据库操作序列用于指示目标事务要对哪些数据项执行哪类数据库操作，数据库操作可划分为读操作或者写操作，由于目标事务可能涉及到对不同数据项执行相同或不同的数据库操作，而不同数据项可能属于不同数据分区，不同数据分区对应于不同主副本节点设备，因此，协调节点设备需要将该目标事务拆解成与不同主副本节点设备各自对应的子事务。

在一些实施例中，协调节点设备先确定目标事务所涉及执行数据库操作的至少一个数据项，接着，对该目标事务所涉及执行数据库操作的任一数据项，确定该数据项所属的数据分区；接着，基于分区信息表，查询得到该数据分区对应的主副本节点设备，其中，该分区信息表用于记录数据分区与主副本节点设备的对应关系。对目标事务所涉及操作的每个数据项都执行上述操作，能够确定出至少一个数据项各自对应的至少一个主副本节点设备。

702、协调节点设备向各个主副本节点设备分发该目标事务在该主副本节点设备上的子事务。

在一些实施例中，上述步骤701中确定主副本节点设备的过程，也可视为是将目标事务拆解成与不同主副本节点设备各自对应的子事务的过程，比如，基于目标事务的SQL语句，确定目标事务所涉及执行数据库操作的至少一个数据项，接着，对每个数据项，确定该数据项所属的数据分区，然后基于分区信息表，查询到该数据分区对应的主副本节点设备，对该主副本节点设备创建一个子事务的数据库操作序列，并将当前数据项以及对应的数据库操作添加到该子事务的数据库操作序列中，重复执行上述操作，在对目标事务的SQL解析完毕之后，能够对每个主副本节点设备都生成一个对应子事务的数据库操作序列，比如，目标事务的SQL语句指示要写入数据项X1和Y1，同时读取数据项Z1，假设数据项X1和Z1都属于数据分区1，Y1属于数据分区2，那么在拆解子事务时，在分区信息表中，找到数据项X1所属数据分区1的主副本节点设备1，对主副本节点设备1创建子事务1的数据库操作序列{(Write,X1)}，找到数据项Y1所属数据分区2的主副本节点设备2，对主副本节点设备2创建子事务2的数据库操作序列{(Write,Y1)}，同时找到数据项Z1所属数据分区1仍然对应于主副本节点设备1，那么将子事务1的数据库操作序列更新成{(Write,X1),(Read,Z1)}。

在一些实施例中，基于目标事务的SQL语句，确定目标事务涉及到操作哪几个数据分区中的数据项，接着，对每个数据分区，确定目标事务涉及到对该数据分区的各个数据项执行对应的各项数据库操作，然后从分区信息表中查询得到该数据分区的主副本节点设备，将上述确定得到的信息添加到当前主副本节点设备的子事务的数据库操作序列中，则完成了对当前主副本节点设备上子事务的拆解过程，以此类推，直到目标事务所涉及执行数据库操作的所有数据项都已经添加到了对应子事务的数据库操作序列中，此时对目标事务拆解完毕，向各个主副本节点设备分发对应的子事务(即下发对应子事务的数据库操作序列)。

换言之，在拆解子事务时，对同一主副本节点设备，确定在该主副本节点设备所对应数据分区中需要对哪些数据项执行哪类数据库操作，确定出来的结果代表了在该主副本节点设备上所需要执行的子事务的数据库操作序列，可选地，协调节点设备向每个主副本节点设备分发对应子事务的数据库操作序列，从而相当于分发了从目标事务中拆解得到的子事务。

703、主副本节点设备响应于目标事务在该主副本节点设备上的子事务，执行该子事务对应的数据库操作，向协调节点设备返回子事务执行结果。

在一些实施例中，主副本节点设备接收到协调节点设备分发的子事务(即子事务的数据库操作序列)之后，基于该子事务的数据库操作序列，串行或者并行地对该数据库操作序列中的各个数据项执行对应的数据库操作，比如，假设接收到的子事务的数据库操作序列为{(Write,X1),(Read,Z1)}，主副本节点设备则需要将数据项X从版本X0修改为版本X1，此外还需要读取数据项Z1，写入数据项X1和读取数据项Z1可以是串行操作或者并行操作，本申请实施例对此不进行具体限定。

在一些实施例中，在遍历了子事务的数据库操作序列后，代表了主副本节点设备已经执行完毕了子事务，此时向协调节点设备返回子事务执行结果，如果对子事务的数据库操作序列中所有数据项都成功执行了对应的数据库操作，则返回的子事务执行结果指示执行成功，如果由于某种故障导致无法对子事务的数据库操作序列中任一数据项执行对应的数据库操作，则返回的子事务执行结果指示执行失败。

704、协调节点设备响应于任一主副本节点设备返回的子事务执行结果，在该操作日志列表中，添加该子事务已执行的数据库操作的操作记录。

本申请实施例涉及的操作日志列表，也称为操作日志、操作记录表等，操作日志列表是存储在目标事务的上下文信息中的一个内存链表结构ops，操作日志列表用于在协调节点设备中暂存本目标事务要对哪些数据项执行哪些数据库操作，同时，协调节点设备还会异步地将该操作日志列表发送到协调节点组中的至少一个其他协调节点设备中，使得其他协调节点设备也能够暂存该操作日志列表，以便于在该协调节点设备发生故障时，及时由其他协调节点设备接管本协调节点设备上原本负责协调的事务，并根据事务对应的操作日志列表来继续协调原本阻塞的事务，关于故障恢复机制将在下一实施例中详细说明，这里不做赘述。

示意性地，操作日志列表是在目标事务的上下文信息中维护的内存链表结构ops，用于在协调节点设备上对目标事务中已执行的数据库操作进行维护，比如，内存链表结构ops中每个链表节点代表一个数据库操作op＝<type,data>，数据库操作由两个字段构成：type字段，即操作类型字段，比如包含4种操作类型，即读(Read)、写(Write)、准备(Prepare)和提交(Commit)；data字段，即操作数据项字段，表征数据库操作的操作对象。在一个示例中，假设目标事务涉及到写入数据项X1和Y1，那么在协调节点设备上将维护有操作日志列表ops＝{<Write,X1>,<Write,Y1>}。在另一个示例中，假设目标事务要读取数据项Z，在执行Read(Z)操作时读到了Z0版本，那么本次Read(Z)操作所存入ops的操作记录为<Read,Z0>。

需要说明的是，对于type字段为写(Write)操作的情况，其data字段为本目标事务所要写入的新值；对于type字段为读(Read)操作的情况，其data字段为执行读操作所读取到的数据版本(即数据项的最新可见版本)；对于type字段为准备(Prepare)或提交(Commit)的情况，在准备或提交操作未完成时，其data字段取值为Null，代表正在等待各个主副本节点设备返回响应，在准备或提交操作成功时，其data字段取值为True，在准备或提交操作失败(此时目标事务需要回滚)时，其data字段取值为False。

在一些实施例中，协调节点设备在目标事务的上下文信息中，创建并存储一个目标事务的操作日志列表，该操作日志列表包括该目标事务当前已执行的数据库操作的操作记录，每条操作记录表征该数据库操作的操作类型和涉及操作的数据项。接着，每当接收到任一主副本节点设备返回的子事务执行结果时，如果子事务执行结果指示执行成功，那么将子事务已执行的数据库操作的操作记录添加到操作日志列表中。

在一些实施例中，由于引入了协调节点组的概念，换言之，在该分布式数据库系统中，该协调节点设备和至少一个其他协调节点设备构成了一个协调节点组，为了避免在该协调节点设备故障后集体重做原本该协调节点设备负责协调的所有事务，可以每间隔第一目标时长，该协调节点设备向该协调节点组中的该至少一个其他协调节点设备发送已存储的至少一个事务的操作日志列表，换言之，每间隔第一目标时长，协调节点组中各个协调节点设备之间互相执行一次操作日志列表的同步。其中，该第一目标时长是任一大于0的数值，例如该第一目标时长是10秒、20秒、30等，本申请实施例对第一目标时长不进行具体限定。这样，在该协调节点设备发生故障时，同一协调节点组中的其他协调节点设备能够利用该协调节点设备已同步的操作日志列表，继续协调对应的事务，或者，在同一协调节点组中任一其他协调节点设备发生故障时，该协调节点设备能够利用发生故障的协调节点设备已同步的操作日志列表，继续协调对应的事务，关于相关故障恢复流程，将在后续几个实施例中详细介绍，这里不做说明。

705、协调节点设备在目标事务的所有子事务的操作记录均添加至操作日志列表后，向所属协调节点组中的至少一个其他协调节点设备发送该操作日志列表。

在一些实施例中，协调节点设备在接收到所有主副本节点设备返回的子事务执行结果后，如果所有子事务执行结果都指示执行成功，在上述步骤704的处理逻辑下，会将所有子事务的操作记录都添加到操作日志列表，此时操作日志列表中包含了目标事务所涉及执行的所有数据库操作的操作记录，即此时已经在协调节点设备上暂存了目标事务所涉及执行的所有数据库操作。接着，协调节点设备将该操作日志列表同步至同一协调节点组中的至少一个其他协调节点设备，在进行操作日志列表的同步时，可以在检测到操作日志列表包含所有子事务的操作记录时，立即向同一协调节点组中的至少一个其他协调节点设备同步该操作日志列表，从而能够快速进入到两阶段提交算法的准备阶段中，或者，按照定时同步机制，每间隔第一目标时长同步一次当前存储的包括目标事务在内的至少一个事务的操作日志列表，从而能够异步对操作日志列表进行数据同步，使得其他协调节点设备上也会暂存目标事务的操作日志列表。

706、协调节点设备在该操作日志列表已同步至任一其他协调节点设备的情况下，向各个主副本节点设备发送准备请求，该准备请求用于指示该主副本节点设备对对应子事务进行数据异常检测。

在一些实施例中，在进入到两阶段提交算法的准备阶段之前，首先要确认目标事务的操作日志列表已经在所属协调节点组中的至少一个其他协调节点设备上进行暂存，换言之，在该操作日志列表已同步至所属协调节点组中任一其他协调节点设备的情况下，目标事务进入到两阶段提交算法的准备节点，协调节点设备向各个主副本节点设备发送准备请求。

在一些实施例中，通过上述步骤704对操作日志列表ops的介绍可知，每条操作记录的type字段除了真实对数据项的读(Read)和写(Write)两种操作类型之外，还提供了描述事务处于两阶段提交算法的哪个阶段的准备(Prepare)和提交(Commit)两种操作类型，因此，可以将type字段取值为准备(Prepare)的操作记录称作准备操作记录，将type字段取值为提交(Commit)的操作记录称作提交操作记录，换言之，该操作日志列表还用于存储目标事务的准备操作记录或提交操作记录中至少一项。

可选地，目标事务的准备操作记录用于记录该目标事务在准备阶段所处的状态，比如，在type字段取值为准备(Prepare)时，其data字段取值为Null代表正在等待各个主副本节点设备返回准备完成响应，其data字段取值为True代表准备成功，其data字段取值为False代表准备失败。

可选地，目标事务的提交操作记录用于记录该目标事务的提交阶段所处的状态，比如，在type字段取值为提交(Commit)时，其data字段取值为Null代表正在等待各个主副本节点设备返回提交完成响应，其data字段取值为True代表提交成功，其data字段取值为False代表提交失败。

在一些实施例中，协调节点设备在向各个主副本节点设备发送准备请求之后，在该目标事务的操作日志列表中插入一条准备操作记录<Prepare,Null>，代表已发送完毕了准备请求，但尚未收到所有主副本节点设备返回的准备完成响应。

707、主副本节点设备响应于目标事务的准备请求，对该主副本节点设备对应的子事务进行数据异常检测，得到异常检测结果。

在一些实施例中，任一主副本节点设备在接收到目标事务的准备请求后，开启对目标事务在该主副本节点设备上的子事务的数据异常检测，即检测子事务是否与并发事务之间存在数据冲突，得到子事务的异常检测结果。

示意性地，在OCC机制下，主副本节点设备在接收到准备请求后，对子事务的本地写集中的数据项进行加锁(即申请一把写锁)，再对子事务的本地读集中的数据项进行验证，判别数据项是否已经被其他事务修改，如果数据项已经被其他事务修改，则子事务对应的目标事务需要回滚，将异常检测结果置为存在异常，如果数据项没有被其他事务修改，继续检测下一个数据项，在遍历读集中所有数据项之后，如果所有数据项都没有被其他事务修改，将异常检测结果置为不存在异常。

708、主副本节点设备向协调节点设备返回与该异常检测结果对应的准备完成响应。

在一些实施例中，在异常检测结果为存在异常时，主副本节点设备向协调节点设备返回指示准备失败的准备完成响应，例如，指示准备失败的准备完成响应是一串错误码；在异常检测结果为不存在异常时，主副本节点设备向协调节点设备返回指示准备成功的准备完成响应，例如，指示准备成功的准备完成响应是一个ACK(Acknowledge Character，确认字符)消息。

在另一些实施例中，主副本节点设备直接将异常检测结果作为准备完成响应返回至协调节点设备，由协调节点设备根据异常检测结果确定本次是准备成功还是准备失败，本申请实施例准备完成响应的内容不进行具体限定。

709、协调节点设备接收各个主副本节点设备的准备完成响应，在各个准备完成响应均指示准备成功时，确定符合事务提交条件。

在一些实施例中，协调节点设备在接收到目标事务所对应所有主副本节点设备返回的准备完成响应后，如果所有准备完成响应都指示准备成功，则确定符合事务提交条件，进入下述步骤710；否则，任一准备完成响应指示准备失败时，则确定符合事务回滚条件，向各个主副本节点设备发送目标事务的回滚指令。

在一些实施例中，协调节点设备在接收到目标事务所对应所有主副本节点设备返回的异常检测结果后，如果所有异常检测结果都指示不存在异常，则确定符合事务提交条件，进入下述步骤710；否则，任一异常检测结果指示存在异常时，则确定符合事务回滚条件，向各个主副本节点设备发送目标事务的回滚指令。

在一些实施例中，为避免某一主副本节点设备迟迟不返回准备完成响应，导致协调节点设备一直处于等待准备完成响应的状态，技术人员预先设置一个超时阈值，协调节点设备在向各个主副本节点设备发出准备请求之后开始计时，在计时不超过超时阈值时，一直等待各个主副本节点设备返回的准备完成响应，在计时到达超时阈值时，不再等待，如果此时接收到了所有主副本节点设备返回的准备完成响应，且所有准备完成响应都指示准备成功，则确定符合事务提交条件，进入下述步骤710；否则，如果任一主副本节点设备没有返回准备完成响应(即等待超时)，或者接收到的任一主副本节点设备返回的准备完成响应指示准备失败，则确定符合事务回滚条件，向各个主副本节点设备发送目标事务的回滚指令。其中，该超时阈值是任一大于0的数值，比如超时阈值为3秒、5秒、10秒等，本申请实施例对超时阈值不进行具体限定。

在一些实施例中，协调节点设备在向各个主副本节点设备发出准备请求之后开始计时，在计时不超过该超时阈值时，一直等待各个主副本节点设备返回的异常检测结果，在计时到达该超时阈值时，不再等待，如果此时接收到了所有主副本节点设备返回的异常检测结果，且所有异常检测结果都指示不存在异常，则确定符合事务提交条件，进入下述步骤710；否则，如果任一主副本节点设备没有返回异常检测结果(即等待超时)，或者接收到的任一主副本节点设备返回的异常检测结果指示存在异常，则确定符合事务回滚条件，向各个主副本节点设备发送目标事务的回滚指令。

710、协调节点设备在符合事务提交条件的情况下，向各个主副本节点设备发送提交请求，该提交请求用于指示该主副本节点设备提交该子事务，以及将该子事务的重做日志发送至对应的从副本节点设备。

在一些实施例中，在符合事务提交条件的情况下，协调节点设备向各个主副本节点设备都发送一个提交请求，这一提交请求用于指示每个主副本节点设备在本地提交对应的子事务，以实现本地数据落盘，同时为保证主从副本之间数据一致，该提交请求还用于指示每个主副本节点设备将该子事务的重做日志(Redo Log)发送到所属副本组的各个从副本节点设备上，以便于每个从副本节点设备在接收到该子事务的重做日志之后，能够异步回放该子事务的重做日志，从而在从副本节点设备上回放该子事务所涉及的对各个数据项的数据库操作，在回放完毕后能够保证主从副本之间的数据版本保持一致。

在一些实施例中，协调节点设备在向各个主副本节点设备发送提交请求之后，在该目标事务的操作日志列表中插入一条提交操作记录<Commit,Null>，代表已发送完毕了提交请求，但尚未收到所有主副本节点设备返回的提交完成响应。

711、主副本节点设备响应于该目标事务的提交请求，提交该子事务。

在一些实施例中，任一主副本节点设备在接收到协调节点设备发送的提交请求后，在本地提交该目标事务在该主副本节点设备上的子事务，将子事务所进行的数据项修改进行数据落盘，同时本地释放子事务的读集和写集所占用的内存，此时也释放掉对子事务进行并发控制所维护的信息(如申请到的锁资源)。

712、主副本节点设备将该子事务的重做日志发送至对应的从副本节点设备，以使该从副本节点设备在回放该重做日志时重做该子事务。

在一些实施例中，主副本节点设备在接收到提交请求之后，除了执行上述步骤711提交子事务的操作之外，还需要将子事务的重做日志发送至对应的至少一个从副本节点设备，比如，基于分区信息表，查询该主副本节点设备所对应数据分区的副本组中有哪些从副本节点设备，并向查询得到的各个从副本节点设备发送该子事务的重做日志，以实现主副本节点设备和从副本节点设备之间的副本同步操作。从副本节点设备在接收到主副本节点设备发送的子事务的重做日志之后，将会在本地回放该重做日志，从而将子事务所进行的数据项修改也同步到本地，保证主从副本之间的数据一致。

在一些实施例中，子事务的重做日志主要包括子事务本次要写入的数据项，重做日志是通过物理复制的方法在从副本上进行回放，物理复制是指：数据流中传输的最小单位为物理数据块或物理日志块，物理数据块中存储有物理数据记录，物理日志块中存储有物理日志记录，物理复制基于物理数据块或物理日志块进行。

在本申请实施例中，提出了一种轻量级的事务粒度副本同步机制，在事务执行阶段仍然遵循两阶段提交算法，通过准备阶段和提交阶段两个阶段，保证事务提交的原子性，根据之前介绍的分布式数据库系统的框架，每个数据分区都会对应于一个副本组，包括一个主副本(Leader)和多个从副本(Follower)，本申请实施例仅在任一目标事务进入到提交阶段时，主副本将目标事务在本地的子事务的重做日志(相当于子事务写入的数据项)打包同步到从副本上，可知，如果目标事务操作了多个数据分区上的数据项，那么每个数据分区的主副本都会将本地子事务的重做日志(相当于子事务在对应数据分区上写入的数据项)发送给对应的从副本。由于副本间的数据同步是通过传递重做日志实现的，因此在每个目标事务提交时，会在每个数据分区的主副本上生成本地子事务的重做日志，该重做日志的结构主要包括了子事务要写入的新值。

下面，对轻量级的事务粒度副本同步机制的两阶段算法的通信流程进行介绍，图8是本申请实施例提供的一种轻量级的事务粒度副本同步机制的原理性流程图，如800所示，假设目标事务的协调节点设备为C1，在协调节点设备C1所属的协调节点组中还包括其他协调节点设备C2，假设目标事务涉及到操作数据分区1和2中的数据项，其中，数据分区1包括主副本P1和从副本P1’，数据分区2包括主副本P2和从副本P2’，那么在目标事务的各个子事务均执行完毕后、该目标事务进入准备阶段之前，协调节点设备C1会实现将目标事务的操作日志列表ops发送到其他协调节点设备C2上进行暂存，接着进入到两阶段提交算法的准备阶段，协调节点设备C1向该目标事务所涉及的所有数据项所在数据分区的主副本P1和P2发送准备请求，需要注意的是，主副本P1和P2仅需要在本地对对应子事务进行数据异常检测，而无需与各自的从副本P1’和P2’产生任何副本同步，主副本P1和P2各自在完成数据异常检测后向协调节点设备C1返回准备完成响应。协调节点设备C1收到所有数据分区的主副本P1和P2返回的准备完成响应后，假设所有主副本P1和P2都返回准备成功，则进入到两阶段提交算法的提交阶段；否则，任一主副本P1或P2返回准备失败，该目标事务会被回滚。接着，在目标事务的提交阶段，协调节点设备C1向该目标事务所涉及的所有数据项所在数据分区的主副本P1和P2发送提交请求，主副本P1会在本地提交对应子事务，并将对应子事务的重做日志打包发送到从副本P1’上，并向协调节点设备C1返回提交完成响应，同理，主副本P2会在本地提交对应子事务，并将对应子事务的重做日志打包发送到从副本P2’上，并向协调节点设备C1返回提交完成响应，协调节点设备C1收到所有数据分区的主副本P1和P2返回的提交完成响应后，如果所有主副本P1和P2都返回提交成功，则事务提交完成。

下面，对轻量级的事务粒度副本同步机制的副本同步原理进行介绍，图9是本申请实施例提供的一种轻量级的事务粒度副本同步机制的原理性示意图，如图9所示，在轻量级的事务粒度副本同步机制下，假设事务T1涉及到写入(Write)数据项X1和Y1，此时协调节点设备901会将写操作(如写数据版本X1)发送到X1所在数据分区的主副本911，主副本911在本地将数据项X从版本X0修改为版本X1，在事务T1进入到两阶段算法的准备阶段之前，协调节点设备901会将事务T1的操作日志列表ops打包发送到同一协调节点组900中的其他协调节点设备902上，使得其他协调节点设备902上也会暂存事务T1的操作日志列表ops，然后协调节点设备901向X1所在数据分区的主副本911以及Y1所在数据分区的主副本921发送事务T1的准备请求，以指示主副本911和921分别对事务T1在本地的子事务进行数据异常检测，返回对应的准备完成响应。在符合事务T1的事务提交条件(即所有主副本都返回准备成功，不存在数据异常)时，进入到两阶段提交算法的提交阶段，协调节点设备901向主副本911和921发送事务T1的提交请求，主副本911提交事务T1在本地的子事务，对数据项X1进行数据落盘，并将子事务的重做日志(包含事务T1写入的数据项X1)打包发送给所在数据分区的副本组910中的从副本912和913上，同理，主副本921也会提交事务T1在本地的子事务，对数据项Y1进行数据落盘，并将子事务的重做日志(包含事务T1写入的数据项Y1)打包发送给所在数据分区的副本组920中的从副本922和923上，从而能够仅在提交阶段保持一轮副本同步的通信开销的情况下，在每个副本组中，仍然能够保持主从副本之间的数据版本一致。

在本申请实施例中，通过提出轻量级的事务粒度副本同步机制，能够提升整个分布式数据库系统的事务处理性能。本申请实施例仅在每个事务提交时，将事务写入的数据项打包进行副本同步，因此将每个事务进行副本同步的网络开销减少至一轮，从而将副本同步对事务性能的影响降到最低。

需要说明的是，在目标事务提交完成后，协调节点组中各个协调节点设备上对目标事务暂存的操作日志列表ops也会被随之释放，即，在目标事务提交完毕后，目标事务的上下文信息会被释放，由于操作日志列表ops也存储在上下文信息中，因此操作日志列表ops所占用的内存也会随着上下文信息一起被释放。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过在分布式数据库系统中，向主副本节点设备分发子事务后，在两阶段提交算法的准备阶段，协调节点设备下发准备请求，仅指示主副本节点设备进行数据异常检测但无需进行主从副本间的数据同步，在符合事务提交条件进入到提交阶段后，协调节点设备下发提交请求，才指示主副本节点设备本地提交子事务并将重做日志同步到从副本节点设备，因此仅需要在提交阶段进行一轮通信就能够实现主从副本间的数据一致，从而极大降低了系统内主从副本间的同步次数，压缩了多副本机制下的副本同步开销，从而尽量消除由于多副本机制对系统内事务处理性能的不良影响。

上一实施例提供的轻量级的事务粒度副本同步机制，也可视为重做日志级的副本同步机制，事务在2PC算法的提交阶段对重做日志进行同步，需要说明的是，这一轻量级的事务粒度副本同步机制与任意并发控制算法是正交的，即该轻量级的事务粒度副本同步机制能够与各类并发控制算法进行有机结合，即保证事务处理的正确性，例如并发控制算法包括但不限于：OCC(Optimistic Concurrency Control，乐观并发控制)、2PL(Two-PhaseLocking，两阶段锁)等。在事务处理流程中，可整体划分为三个阶段：读写阶段、准备阶段和提交阶段，下面将以轻量级的事务粒度副本同步机制与OCC并发控制算法结合为例，介绍两者结合时的事务处理流程。

图10是本申请实施例提供的一种结合OCC算法的轻量级的事务粒度副本同步机制的原理性流程图，如1000所示，以目标事务为分布式事务为例说明，假设协调节点组包括协调节点设备C1和C2，其中协调节点设备C1负责协调分布式事务，同时，分布式事务涉及到操作2个数据分区，数据分区1的副本组中包括主副本P1和从副本P1’，数据分区2的副本组中包括主副本P2和从副本P2’。

那么，针对任一分布式事务，在该分布式事务的读写阶段，系统内执行如下流程：协调节点设备C1根据分区信息表，获取读写操作(即数据库操作)对应的数据节点设备，即找到读写操作的数据项所属数据分区的主副本P1和P2，接着，协调节点设备C1调用remoteRW()函数将读写操作(即子事务)发送到对应数据节点设备，数据节点设备上执行对应的读写操作，换言之，协调节点设备C1调用remoteRW()函数分别将不同子事务分发到主副本P1和P2上，主副本P1和P2各自执行对应的读写操作，同时调用addToRWSet()函数维护子事务的读写集合(读写集合包括一个读集和一个写集，均是OCC算法中要求维护的数据结构)，接着，数据节点设备即主副本P1和P2向协调节点设备C1返回子事务执行结果(即读写操作的读写结果)。

示意性地，在读写阶段相关函数的伪代码如下所示：

其次，在该分布式事务的准备阶段，系统内执行如下流程：协调节点设备C1调用replicateRWOp()函数，将事务读写操作(即事务的操作日志列表ops)备份到同一协调节点组内的其他协调节点设备C2上；接着，协调节点设备C1调用prepare()函数来向各个数据节点设备(即主副本)下发目标事务的准备请求；数据节点设备接收到准备请求后，本地调用lockAndValidate()函数进行子事务的数据异常检测，并向协调节点设备返回结果，例如返回异常检测结果，或者返回异常检测结果对应的准备完成响应，这里不做限定。

示意性地，在准备阶段相关函数的伪代码如下所示：

最后，在该分布式事务的提交阶段，系统内执行如下流程：如果所有数据节点设备上返回成功，即所有主副本节点设备返回的准备完成响应都指示准备成功，那么事务可以提交，否则，只要有任一数据节点设备返回Prepare失败，即任一主副本节点设备返回的准备完成响应指示准备失败，那么事务就会回滚；假设事务可以提交，协调节点设备C1获取事务提交时间戳tid，这一事务提交时间戳tid可以是物理时间戳、逻辑时间戳或者两者的结合；接着，协调节点设备调用commit()函数，向各个数据节点设备即主副本节点设备发送提交请求；接着，数据节点设备调用writeAndReplicate()函数，在Leader主副本上写入数据项，并同步Redo重做日志到所属副本组中的其他Follower从副本；接着，数据节点设备回复协调节点设备Commit完成，即主副本节点设备向协调节点设备返回提交完成响应。

示意性地，在提交阶段相关函数的伪代码如下所示：

在上一实施例中，详细介绍了结合OCC并发控制算法的情况下，本申请提供的轻量级的事务粒度副本同步机制的事务处理流程，而在本申请实施例中，将对上述轻量级的事务粒度副本同步机制下，系统内的快速故障恢复算法进行介绍，下面将分别讨论主副本节点设备故障、协调节点设备故障以及两者都故障这三种情况下各自的故障恢复算法。

图11是本申请实施例提供的一种主副本节点设备故障时的故障恢复流程的交互流程图，如图11所示，该实施例适用于分布式数据库系统，假设在目标事务的执行期间，目标事务涉及的任一主副本节点设备发生故障，其故障恢复流程包括下述步骤：

1101、协调节点设备确定从发生故障的主副本节点设备对应的至少一个从副本节点设备中选举得到的目标节点设备。

在一些实施例中，分布式存储集群内各个数据节点设备(可以是主副本节点设备，也可以是从副本节点设备)之间通过心跳机制，定期检测节点故障，从而能够及时发现发生故障的主副本节点设备。当目标事务涉及的任一主副本节点设备发生故障后，与该主副本节点设备保持心跳连接的其他数据节点设备都能够通过心跳机制发现这一故障，比如，当其他数据节点设备在超过第二目标时长时仍然没有接收到来自该主副本节点设备的心跳消息，或者其他节点设备向该主副本节点设备发送的心跳消息超过第三目标时长没有得到回复，都能够发现该主副本节点设备发生故障，其中，该第二目标时长和第三目标时长可以相同或者不同，该第二目标时长和第三目标时长都是大于0的任一数值，本申请实施例对此不进行具体限定。

在一些实施例中，主副本节点设备发生故障之后，可以对发生故障的主副本节点设备(后续简称为故障节点设备)所在数据分区进行重新选主，比如，故障节点设备所在数据分区的副本组中，如果从副本节点设备通过心跳机制发现主副本节点设备发生故障，可以通知其他从副本节点设备开启投票选举下一位新的主副本节点设备，即，故障节点设备所在数据分区的副本组中的各个从副本节点设备之间会独立进行重新选主操作，最终投票选举出一个票数最高的从副本节点设备作为新的主副本节点设备，这一新当选的主副本节点设备也就是本申请实施例涉及的目标节点设备。

在一些实施例中，在选举目标节点设备时，可以进行随机选举，以简化选举流程，或者优选选择负载最低的节点设备，以实现系统内负载均衡，本申请实施例对目标节点设备的选举方式不进行具体限定。

示意性地，该目标节点设备是从该至少一个从副本节点设备中随机选举得到的，即，从故障节点设备所在数据分区的副本组中的各个从副本节点设备中，随机选择一个作为目标节点设备。

示意性地，该目标节点设备是该至少一个从副本节点设备中负载最低的节点设备，即，从故障节点设备所在数据分区的副本组中的各个从副本节点设备中，选择负载最低的节点设备作为目标节点设备。

在一些实施例中，故障节点设备所在数据分区的副本组中选举出来目标节点设备之后，向协调层中的各个协调节点设备的分区信息表中更新该数据分区的主副本节点设备的节点标识或设备标识，比如，在分区信息表中，将该数据分区的主副本节点设备的节点标识或设备标识，从故障节点设备修改成目标节点设备。

需要说明的是，在目标节点设备被选举完毕后，优先进入到对原本正在执行目前等待恢复的事务进行故障恢复流程中，而不会直接执行新发来的事务操作，这是由于原本正在执行目前等待恢复的事务处于阻塞状态中，因此更加亟需被恢复，以保证这部分事务的执行成功率，降低这些事务由于等待超时而被回滚的可能性。

在一些实施例中，在目标节点设备选举完毕、并对分区信息表更新完毕后，协调节点设备查询更新完毕的分区信息表，能够查询到故障节点设备所在数据分区新选举得到的目标节点设备。

1102、协调节点设备确定该目标节点设备对应的目标子事务，该目标子事务是指原本由该主副本节点设备执行但由于故障正在等待恢复的子事务。

在一些实施例中，协调节点设备将本协调节点设备所负责协调的、原本由故障节点设备执行但由于故障正在等待恢复的所有子事务作为目标子事务，可选地，在故障节点设备宕机后，协调节点设备正在运行的事务中，符合以下两种情况的事务会被判定为需要进行恢复的事务(以下称为待恢复事务)：Ⅰ)通过心跳机制感知到所操作的数据节点设备(指主副本节点设备)故障；Ⅱ)在执行操作时，操作超时没有返回结果。在协调节点设备判定完毕，找到本协调节点设备上所有的待恢复事务之后，对每个待恢复事务，检索该待恢复事务的上下文信息中暂存的操作日志列表ops，接着，在该操作日志列表ops中，将涉及到故障节点设备所在数据分区的操作记录确定为目标子事务(或者认为是目标子事务的数据库操作序列，即待恢复操作队列)，在遍历所有待恢复事务之后，能够找到每个待恢复事务分解出来的、需要由目标节点设备重做的目标子事务。

1103、协调节点设备向该目标节点设备发送该目标子事务的待恢复操作队列，该待恢复操作队列包括该目标子事务在操作日志列表中对应的至少一条操作记录。

在一些实施例中，协调节点设备读取更新后的分区信息表，找到故障节点设备所在数据分区新选举得到的目标节点设备的节点标识或设备标识，接着基于该目标节点设备的节点标识或设备标识，查询到目标节点设备的IP(Internet Protocol，网际互连协议)地址和通信端口，并将上述步骤1102中确定得到的所有目标子事务的数据库操作序列作为目标子事务的待恢复操作队列，打包发送到该目标节点设备的IP地址和通信端口。

需要说明的是，由于故障节点设备可能会同时处理不同协调节点设备发来的事务，因此分布式协调系统中的各个协调节点设备均可以通过上述步骤1101-1103来向目标节点设备打包发送所有目标子事务的待恢复操作序列。

1104、目标节点设备接收任一协调节点设备发送的目标子事务的待恢复操作队列。

其中，该目标子事务是指原本由该协调节点设备分配给该另一主副本节点设备执行、但由于故障正在等待恢复的子事务。

需要说明的是，由于在分布式存储集群中，同一个节点设备，可能充当某个数据分区的主副本节点设备，同时还充当其他数据分区的从副本节点设备，因此，本申请实施例涉及的目标节点设备，可以和上述各个实施例中负责处理目标事务的主副本节点设备是同一个物理机，换言之，当上一实施例中涉及的主副本节点设备作为另一主副本节点设备的从副本节点设备时，若该另一主副本节点设备发生故障后，该主副本节点设备被选举为目标节点设备，那么此时上一实施例中主副本节点设备和本申请实施例的目标节点设备可以是同一物理机，当然，上一实施例中主副本节点设备和本申请实施例的目标节点设备也可能不是同一物理机，即两者是互相独立的物理机，又或者，上一实施例中主副本节点设备还可以充当本申请实施例的故障节点设备，本申请实施例对此不做具体限定。

在一些实施例中，目标节点设备接收各个协调节点设备发送的各个目标子事务的待恢复操作队列，需要说明的是，每个协调节点设备都有可能打包发送过来一个或多个目标子事务的待恢复操作队列中，因此，目标节点设备收集所有目标子事务的待恢复操作队列，相当于收集所有待恢复的目标子事务，方便对这些目标子事务的数据库操作进行重做。

1105、目标节点设备基于该待恢复操作队列，从该目标子事务中，确定符合事务提交条件的第一子事务、符合事务回滚条件的第二子事务以及剩余的第三子事务。

在一些实施例中，为了保持数据一致性，对在发生故障被阻塞前处于不同阶段的目标子事务，采取不同的恢复策略，可选地，优先重做已经进入了提交阶段的目标子事务(即第一子事务)，然后重做处于其他阶段(如读写阶段或者准备阶段)的目标子事务(即第三子事务)，而对于需要回滚的目标子事务(即第二子事务)则无需进行重做。

在一些实施例中，对接收到的任一目标子事务的待恢复操作队列，目标节点设备在该待恢复操作队列中，查询该目标子事务所对应父事务的准备操作记录，即在该目标子事务的待恢复操作队列ops中查询type字段取值为Prepare(准备)的准备操作记录。

可选地，若该准备操作记录指示该父事务在准备阶段所处的状态为准备完成状态，即准备操作记录记作<Prepare,True>，代表在故障发生前已经准备成功，需要进入到2PC算法的提交阶段，因此符合事务提交条件，将该目标子事务确定为第一子事务。

可选地，若该准备操作记录指示该父事务在准备阶段所处的状态为准备失败状态，即准备操作记录记作<Prepare,False>，代表在故障发生前已经准备失败，需要回滚目标子事务(即父事务分解的其他子事务)，因此符合事务回滚条件，将该目标子事务确定为第二子事务。

可选地，若该准备操作记录指示该父事务在准备阶段所处的状态既不是准备完成状态也不是准备失败状态，即准备操作记录记作<Prepare,Null>，代表在故障发生前仍处于等待各个主副本节点设备返回准备完成响应的状态，或者，待恢复操作队列ops中没有查询到type字段取值为Prepare(准备)的准备操作记录，代表在故障发生前处于读写阶段而没有进入到准备阶段，那么，将该目标子事务确定为第三子事务。

在一些实施例中，对每个目标子事务，都基于其待恢复操作队列中的准备操作记录，确定出来该目标子事务是否为第一子事务，以及该目标子事务是否为第二子事务，如果既不是第一子事务也不是第二子事务，那么确定为第三子事务。

1106、目标节点设备丢弃该第二子事务相关联的操作记录。

在一些实施例中，对于符合事务回滚条件的第二子事务，即需要回滚第二子事务，然而在故障发生前，故障节点设备上所执行的操作尚未同步到目标节点设备上，这是由于轻量级的事务粒度副本同步机制，仅在提交阶段原本作为主副本的故障节点设备才会发起副本同步，由于第二子事务对应父事务需要全局回滚，就不可能进入提交阶段，因此第二子事务不可能会从原本作为主副本的故障节点设备同步到原本作为从副本的目标节点设备上，即，此时目标节点设备上仍然存储的是第二子事务尚未修改前的数据版本，因此无需进行任何修改操作，直接丢弃掉第二子事务相关联的操作记录，即可完成第二子事务的事务回滚。

1107、目标节点设备基于该待恢复操作队列，重做该第一子事务，向对应协调节点设备返回第一子事务的提交完成响应。

在一些实施例中，针对符合事务提交条件的第一子事务，代表第一子事务在故障发生前已经进入到了2PC算法的提交阶段，即第一子事务是一定能够提交成功的，因此目标节点设备优先重做所有检测到的第一子事务。

在一些实施例中，对任一第一子事务，由于第一子事务在故障发生前已经进入到了2PC算法的提交阶段，此时存在两种情况，第一种情况是故障节点设备在发生故障前已经把第一子事务的重做日志同步到了目标节点设备上，第二种情况是故障节点设备在发生故障前尚未把第一子事务的重做日志同步到目标节点设备上。

针对上述第一种情况，故障节点设备在发生故障前已经把第一子事务的重做日志同步到了目标节点设备上，此时目标节点设备有可能已经对第一子事务的重做日志回放完毕了，这时不需要对第一子事务的数据库操作进行重新执行，因为第一子事务要写入的新值已经随着重做日志的回放进行落盘了，此时目标节点设备只需要在内存中创建第一子事务的上下文信息，并在上下文信息中维护对该第一子事务进行并发控制所需的信息，并提交该第一子事务，向负责协调该第一子事务的父事务的协调节点设备返回提交完成响应即可。可选地，对该第一子事务进行并发控制所需的信息，是指在对应并发控制算法的约束下，为保证并发控制所需要维护的信息，不同并发控制算法所需要维护的信息是不同的，比如，2PL并发控制算法需要对操作的数据项进行加锁，OCC并发控制算法需要维护事务操作的读写集合；或者，故障节点设备在发生故障前已经把第一子事务的重做日志同步到了目标节点设备上，但是目标节点设备尚未对第一子事务的重做日志回放完毕，此时目标节点设备只需要对第一子事务的重做日志进行回放，在回放完毕后执行上述操作，就能够实现对第一子事务的故障恢复，这里不做赘述。

针对上述第二种情况，故障节点设备在发生故障前尚未把第一子事务的重做日志同步到目标节点设备上，那么目标节点设备需要从头遍历并执行该第一子事务的待恢复操作队列中的每个待恢复的数据库操作，同时维护对该第一子事务进行并发控制所需的信息，接着，提交该第一子事务，向负责协调该第一子事务的父事务的协调节点设备返回提交完成响应，并基于每个待恢复的数据库操作生成第一子事务的重做日志，将生成的第一子事务的重做日志发送到所属副本组的其他各个从副本节点设备上。需要说明的是，由于第一子事务已经完成了2PC算法的准备阶段、进入了2PC算法的提交阶段，因此第一子事务的所有读写阶段的数据库操作均已经得到了读写结果，因此第一子事务执行完成后的数据状态(或者这读到的数据版本以及写入的数据版本)都是已经确定的。

需要说明的是，为了保证写写冲突不会发生，对于任一个数据项来说，在事务处理流程中保证最多只有一个包含对该数据项写操作的事务可以进入2PC算法的提交阶段(可以通过对数据项加锁等机制保证，此处不做展开)。因此，不存在多个并发事务对同一个数据项进行写操作后均进入2PC算法的提交阶段的情况。假设存在事务T1对数据项X进行写操作<Write,X1>，事务T2对数据项X进行了读操作<Read,X0>，且这两个事务T1和T2均进入了2PC算法的提交阶段，那么基于本申请实施例的故障恢复算法，在经过恢复后事务T1和T2的执行结果不会发生改变。换言之，本申请实施例的故障恢复算法，能够保证进入2PC算法的提交阶段的事务在故障恢复后，其读写操作的执行结果不会发生改变，即不存在事务T2在故障发生前读到了X0版本，在故障发生后读到了X1版本的情况，并且检测到出现了这种故障恢复前后操作版本不一致的情况，那么直接回滚掉事务T2即可。

在上述过程中，相当于在该目标节点设备尚未回放该第一子事务的重做日志的情况下，如果目标节点设备上存储了已同步的重做日志，则基于重做日志回放来重做第一子事务，如果目标节点设备上没有存储重做日志，则基于该待恢复操作队列，执行该第一子事务对应的至少一条操作记录，同时维护对该第一子事务进行并发控制所需的信息，提交该第一子事务，向负责协调该第一子事务的父事务的协调节点设备返回提交完成响应，并生成该第一子事务的重做日志，将该重做日志发送到对应的从副本节点设备上。

需要说明的是，在提交第一子事务时，涉及到将第一子事务所写入的数据项进行落盘，并释放掉对该第一子事务进行并发控制所需的信息(如释放锁资源、清空存储的读写集合等)，释放第一子事务的上下文信息等操作，这里不做赘述。

由于针对已经进入提交阶段的第一子事务优先进行重做，这些第一子事务是必定能够提交的，因此能够极大提升第一子事务的父事务的执行成功率，减少这些父事务由于故障而被整体回滚的概率，更好地保证了轻量级的事务粒度副本同步机制的高可用性。

1108、对分布式数据库系统中每个协调节点组，该协调节点组中任一协调节点设备响应于该第一子事务的提交完成响应，向目标节点设备发送重做完成指令。

其中，该重做完成指令用于表征对应协调节点组所负责协调的第一子事务重做完毕。

在一些实施例中，由于分布式数据库系统中会存在多个协调节点组，每个协调节点组内均可能存在已经进入到2PC算法的提交阶段的第一子事务，因此，可以针对每个协调节点组设置一个重做进度变量is_commit，该重做进度变量is_commit用于记录在当前协调节点组中待重做的第一子事务的事务数，由于第一子事务代表已经进入提交阶段的待恢复的目标子事务，因此重做进度变量is_commit实际代表了所属协调节点组中待重做的已提交事务数，接着，对该协调节点组来说，每当任一协调节点设备接收到目标节点设备返回的任一第一子事务的提交完成响应，代表已经对进入到提交阶段的第一子事务重做完毕，就将该重做进度变量is_commit减1，换言之，将该重做进度变量is_commit赋值为原有值减1所得的数值，当重做进度变量is_commit减为0时，代表当前协调节点组中不存在没有重做的第一子事务了，此时协调节点组中任一协调节点设备都可以向目标节点设备额外发送一个重做完成指令(记为commit_done)，代表本协调节点组内负责协调的进入提交阶段的所有第一子事务都已经重做完毕。

1109、目标节点设备在接收到多个协调节点组中任一协调节点设备发送的重做完成指令的情况下，基于该待恢复操作队列，重做该第三子事务。

在一些实施例中，如果目标节点设备已经接收到了每个协调节点组中至少一个协调节点设备发来的重做完成指令commit_done，即，目标节点设备需要接收到故障时涉及操作本数据分区上数据项的所有协调节点组发来的重做完成指令commit_done，但每个协调节点组只需要至少一个协调节点设备返回重做完成指令commit_done即可，而无需等待每个协调节点组的所有协调节点设备都返回重做完成指令commit_done，并在每个协调节点组中可能会有不止一个协调节点设备都发来重做完成指令commit_done。这是由于对每个协调节点组来说，该协调节点组内的每个协调节点设备上都会暂存表征该协调节点组内所有待重做的第一子事务的事务数的重做进度变量is_commit，因此，该协调节点组有任一个协调节点设备获知该重做进度变量is_commit变为0时，则表明当前协调节点组内已经进入提交阶段的第一子事务全部重做完成。

在目标节点设备接收到故障时涉及操作本数据分区上数据项的所有协调节点组发来的重做完成指令commit_done后，代表整个分布式数据库系统中在本数据分区上所有已进入提交节点的第一子事务都进行重做完毕，因此，可以开始重做发生故障前没有进入提交阶段的第三子事务。

在一些实施例中，目标节点设备基于该待恢复操作队列，执行该第三子事务对应的至少一条操作记录，比如，目标节点设备从头遍历并执行该第三子事务的待恢复操作队列中的每个待恢复的数据库操作，同时维护对该第三子事务进行并发控制所需的信息，如果第三子事务在发生故障前已经进入了2PC算法的准备阶段，那么可以开启对第三子事务的数据异常检测，得到异常检测结果，向负责协调该第三子事务的父事务的协调节点设备返回该异常检测结果对应的准备完成响应，或者，如果该第三子事务在发生故障前没有进入到准备阶段，仍处于读写阶段，那么目标节点设备向协调节点设备返回第三子事务的子事务执行结果，等待协调节点设备下发的父事务的准备请求，在接收到该准备请求后，再开启对第三子事务的数据异常检测，得到异常检测结果，向协调节点设备返回该异常检测结果对应的准备完成响应。

在一些实施例中，在目标节点设备返回了准备完成响应之后，第三子事务的父事务有可能会进入提交阶段，也有可能检测到父事务的任一子事务准备失败从而全局回滚，即第一子事务由于已经进入到提交阶段因此一定会提交，但第三子事务由于未进入到提交阶段(尚未确定是否准备成功)因此有可能提交也可能回滚。

在一些实施例中，目标节点设备在接收到协调节点设备下发的父事务的提交请求时，目标节点设备提交该第一子事务，向协调节点设备返回提交完成响应，并生成第三子事务的重做日志，将生成的第三子事务的重做日志发送到所属副本组的其他各个从副本节点设备上。需要说明的是，在提交第三子事务时，涉及到将第三子事务所写入的数据项进行落盘，并释放掉对该第三子事务进行并发控制所需的信息(如释放锁资源、清空存储的读写集合等)，释放第三子事务的上下文信息等操作，这里不做赘述。

在一些实施例中，目标节点设备在接收到对该第三子事务的回滚指令的情况下，回滚该第三子事务，回滚第三子事务是指将第三子事务所修改的各个数据项恢复至未修改之前的数据版本，通过第三子事务的回滚日志即可实现事务回滚。可选地，该回滚指令在该第三子事务所涉及数据库操作对应的数据项发生变化，或者第三子事务所对应父事务的异常检测结果为存在数据异常的情况下触发。

需要说明的是，针对第三子事务需要增加一个约束：即保证第三子事务在恢复前后的读写结果保持一致，因此，如果检测到第三子事务所涉及数据库操作对应的数据项发生变化，比如读取到的数据项发生了改变(如故障前读到了X0版本，重做后读到了X1版本)，则当前的第三子事务需要回滚，从而保证事务状态在故障恢复前后保持一致。

通过增加上述约束，能够保证第三子事务的事务状态在故障恢复前后保持一致，第三子事务属于未进入提交阶段的未提交事务，而由于优先重做了第一子事务(属于已进入提交阶段的已提交事务)，而这部分第一子事务可能会修改了部分数据项，导致第三子事务在重做后读取到的数据版本与重做前读取到的数据版本不一致，因此，通过在协调节点设备上记录第三子事务在重做前读取的数据版本(在其父事务的操作日志列表ops中记载)，然后协调节点设备在接收到目标节点设备重做后返回的子事务执行结果后，将操作日志列表ops中记载的数据版本与接收到的子事务执行结果的数据版本进行比较，从而就能够判断出第三子事务所涉及数据库操作对应的数据项是否发生变化。需要说明的是，在操作日志列表ops中，任一数据库操作的操作记录中记载的数据版本可能是旧版本数据，若记载了旧版本数据，则认为重做前的第三子事务读取到的是旧版本数据；此外，操作记录上还可能无记录内容(即操作记录上没有记载数据版本)，则认为重做前的第三子事务读取到的是新版本数据。

在上述步骤1107-1109中，提供了目标节点设备基于该待恢复操作队列，重做该第一子事务和该第三子事务的一种可能实施方式，通过在协调节点设备上暂存操作日志列表ops，并利用分布式数据库系统中多副本机制的特性，尽可能地保证了事务不会因为节点故障而被回滚，并且，在故障恢复流程中仅对故障节点设备上正在执行的子事务进行重做，而不会对整个父事务进行重做，相当于节约了在父事务的非故障节点设备上重做对应子事务的耗时，极大提升了事务重做效率。

进一步的，通过优先重做第一子事务，在第一子事务重做完毕后再重做第三子事务，能够保证一定能够提交的第一子事务优先重做，即极大保障了第一子事务不会因为故障而回滚，进而重做第三子事务，并增加保证第三子事务在恢复前后的读写结果保持一致的约束，使得第三子事务在重做前后，如果能够顺利提交，那么其事务一致性得到了极大保障。

下面，将结合一个具体事务的示例，介绍本申请实施例的故障恢复流程。

给出任一个事务，假设该事务在多个数据分区上共进行N(N≥1)次读写操作，若在执行第M(1≤M≤N)个操作时，某一数据节点设备(可能第M个操作所在的主副本，还可能是本事务其他操作对应的主副本)发生了故障。如果本事务回滚并重启，那么本事务的前M个操作都需要重做一遍，这必将浪费大量的系统资源。为了使得事务恢复效率尽可能高，对于数据节点设备(即主副本节点设备)发生故障的情况，可以利用事务在协调节点设备上暂存的操作日志列表ops，仅对故障节点设备(即发生故障的主副本节点设备)上已经执行的操作进行重做，从而恢复事务的执行状态。

示意性地，当某一数据分区所属副本组的主副本节点设备发生故障时，在该副本组内对该数据分区进行重新选主(即在从副本节点设备中选择一个作为新的主副本节点设备)，这一重新选举的新的主副本节点设备称为目标节点设备。接着，在目标节点设备上对涉及到该数据分区的目标子事务的数据库操作进行重做。此时，在目标子事务重做完毕后，目标子事务对应的父事务即可继续执行而不用被回滚。

在一个示例中，假设在执行第M个操作某一主副本节点设备(后面称为故障节点设备)发生故障，在该事务在故障节点设备所对应的数据分区上进行了K次操作的情况下，那么传统整体回滚事务并重启事务的情况下，前M次操作都需要重做，而在本申请实施例的故障恢复机制下，仅需要重做故障节点设备上的K次操作，因此，一共节省了M-K次操作重做的系统开销。通过只对涉及到故障节点设备的目标子事务的数据库操作进行重做，其他健康节点设备上的数据库操作不进行重做的故障恢复方案，能够省去对涉及健康节点设备上数据项的数据库操作进行重做的开销，从而减少事务重做时间，提高事务重做效率。

图12是本申请实施例提供的一种故障恢复机制的原理性流程图，如图12所示，示出了一个事务快速故障恢复算法的执行示例，假设事务T1涉及到写入数据项X1和Y1并读取数据项Z0，其中，数据项X1属于数据分区1，数据项Y1属于数据分区2，数据项Z0属于数据分区3。假设事务T1在执行到Read(Z)操作时，数据分区1的主副本节点设备1201发生了故障，那么涉及数据分区1的目标子事务Write(X1)就需要重做，其余健康节点设备上的子事务Write(Y1)和Read(Z)则不需要重做。换言之，虽然事务T1对数据分区1、2、3上的数据项都进行了操作，但在数据分区1的主副本节点设备1201发生故障时，只需要找到事务T1在数据分区1上的目标子事务Write(X1)，再将目标子事务Write(X1)重新发给数据分区1中选举出来的新的主副本节点设备1202进行执行，等到新的主副本节点设备1202上Write(X1)的操作重做完成后，事务T1即可继续执行其后续操作，而不需要被回滚。

由于仅对故障节点设备上的目标子事务进行重做，这对保证重做前后的数据一致性带来挑战，通过优先重做已进入提交阶段的第一子事务，并对后来重做的未进入提交阶段的第三子事务，增加保证第三子事务在恢复前后的读写结果保持一致的约束，能够保证在任意目标子事务恢复完成后，事务的执行结果(即读写结果)不会因为故障而发生改变。需要说明的是，目标子事务的重做均采用逻辑重做方式，通过执行数据库操作的形式来进行数据回放。

图13是本申请实施例提供的一种事务恢复流程的原理性示意图，如图13所示，提供了一种事务恢复流程的示例性说明，假设分布式数据库系统中，协调节点设备1负责协调事务T1和T2，协调节点设备2负责协调事务T3和T4，事务T1涉及操作数据分区1和3的数据项，事务T2涉及操作数据分区2的数据项，事务T3涉及操作数据分区1和3的数据项，事务T4负责操作数据分区1和2的数据项。在上述事务T1～T4的执行过程中，数据分区1的主副本节点设备1301发生故障，此时需要进行恢复的事务包括T1、T4和T3，由于事务T2不涉及操作数据分区1的数据项，因此事务T2不需要进行恢复。接着，假设在需要进行恢复的事务T1、T4和T3中，事务T1已经进入了提交阶段，而事务T4和T3尚未进入到提交阶段，那么在数据分区1选举出来新的主副本节点设备1302之后，为了保证事务恢复的正确性，新的主副本节点设备1302将优先重做事务T1在该数据分区1上的目标子事务(即第一子事务)，等到全部已经进入提交阶段的第一子事务都重做完成后，才能够继续重做事务T4和T3在该数据分区1上的目标子事务(即第三子事务)。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过利用分布式数据库系统中多副本机制的特性，在任一主副本节点设备发生故障后，从副本组中选举出新的主副本节点设备即目标节点设备，同时由于在协调节点设备上暂存了操作日志列表，使得目标节点设备能够按照协调节点设备从操作日志列表中拆分出的待恢复操作队列，对由于故障处于阻塞状态的各个子事务进行重做，尽可能地保证了事务不会因为节点故障而被回滚，并且，在故障恢复流程中仅对故障节点设备上正在执行的子事务进行重做，而不会对整个父事务进行重做，相当于节约了在父事务的非故障节点设备上重做对应子事务的耗时，极大提升了事务重做效率。

进一步的，在金融场景下，这对分布式数据库系统在金融领域保证数据服务的可靠性起到了至关重要的作用，例如，在商品秒杀场景下，由于同一时刻海量订单交易蜂拥而至，即秒杀时交易量激增，代表了系统内并发的交易事务量也会激增，因此系统负载一般较重，系统如果发生故障，将会导致大量事务受到影响，如果这些交易事务由于故障被强制回滚，将不可避免地造成经济损失。因此，本申请实施例涉及的故障恢复机制，对提升分布式数据库系统的产品竞争力、技术影响力均具有较强的现实意义。

在上一实施例中，详细介绍了数据节点设备(尤其是主副本节点设备)发生故障时的事务故障恢复机制，即，在主副本节点设备发生故障后，对应数据分区在副本组内进行重新选主，并对涉及到故障节点设备的目标子事务进行重做，以保证事务恢复的正确性。

以下，将事务的故障恢复流程划分成两个阶段分别进行说明：

a)主副本切换阶段：在主副本(Leader)切换阶段，故障节点设备所属数据分区的副本组内，将在健康的各个从副本之间，执行重新选取主副本Leader的操作。

b)子事务重做阶段：在已选举完毕的新的主副本节点设备(即目标节点设备)上，优先重做已经进入提交阶段的目标子事务(即第一子事务)，再重做处于读写阶段或准备阶段的目标子事务(即第三子事务)，使得受到故障影响的事务均能够继续执行而不会因为故障而回滚(但仍然可能会因为读到数据版本不一致或者存在数据异常而回滚)。

上述两个阶段，保证了在数据节点设备发生故障时，如何对故障节点设备上的数据库操作进行重做，从而保证事务恢复的正确性。

以下，将分别从不同阶段时协调节点设备和数据节点设备的处理逻辑，详细介绍一种故障恢复的可能实施方式。

协调节点设备主要负责事务的协调，并且维护一些事务的元信息，此外，协调节点设备还会在操作日志列表ops中记录每次操作的数据项(相当于mark记录一下重做前的读写结果)，若发生故障，可以在重做的时候对比数据的版本，即对比重做后子事务执行结果与操作日志列表ops中记录的重做前的读写结果，比较操作结果的数据版本是否发生变化(这是由于事务重做时可能会出现部分事务在重做前后读到的值版本不一致的情况，通过协调节点设备对比能够及时发现这种类型的异常)。此外，协调节点设备还会存储当前已经准备成功的事务，即在事务的操作日志列表ops中插入一条准备操作记录，这类事务的信息即操作日志列表ops会在同一协调节点组的各个协调节点设备之间进行同步，同步方式可以是主动同步，或者定时同步，这里不做具体限定。

数据节点设备包括主副本节点设备和从副本节点设备，主从副本是按照数据分区来进行划分的，不以物理机作为划分标准，换言之，某一数据节点设备(指物理机)可能充当某一数据分区的主副本的同时，还充当另一数据分区的从副本。在事务执行过程中，数据节点设备上可以创建执行者(Executor)和检查者(Checker)两种线程，Executor线程负责读写数据项并生成读写集合，相当于事务执行进程，Checker线程负责检测数据节点设备的故障情况，相当于维护心跳机制的检查线程。

在主副本切换阶段，系统内的数据节点设备间执行如下操作：

当任一个数据节点设备产生故障时，阻塞住所有涉及故障节点设备的子事务。其他数据节点设备的Checker线程可以通过心跳机制发现该数据节点设备已经故障，例如，其他数据节点设备发现无法接受该故障节点设备的心跳消息时，便认为检测到该故障节点设备发生故障。

在故障节点设备为某一数据分区的主副本节点设备的情况下，该数据分区所对应副本组中，其余健康的从副本节点设备调用switch_leader函数，根据分区信息表(也称为分区元信息)来从副本组中投票选举产生新的主副本节点设备，比如，可以在健康的从副本节点设备上随机选择一个作为新的主副本节点设备，又比如，优先选择负载较低(如负载低于预设阈值，或者负载在副本组内最低等)的健康的从副本节点设备作为新的主副本节点设备，从而尽可能做到系统内的负载均衡。在新主选举完毕后，可以在数据节点设备间同步更新后的分区信息表，同时也需要通知协调层中的各个协调节点设备间同步更新后的分区信息表，例如，数据节点设备通过发送分区更新消息的方式通知协调节点设备更新分区信息表，比如，该分区更新消息中携带更新后的分区信息表。

示意性地，在主副本切换阶段涉及到的相关函数的伪代码如下所示：

在子事务重做阶段，系统内的协调节点设备和数据节点设备分别执行如下操作：

协调节点设备确定与故障节点设备相关的各个待恢复事务，并找到各个待恢复事务在故障节点设备上分解出的目标子事务，将各个目标子事务的待恢复操作队列(即待重做的数据库操作)打包发送给新选举出来的主副本节点设备，新选举出来的主副本节点设备即是上一实施例涉及的目标节点设备。可选地，协调节点设备通过超时重发消息的机制，将各个目标子事务的待恢复操作队列发给新选举出来的主副本节点设备。

可选地，协调节点设备对故障节点设备所在数据分区，收集所有待重做的、已经进入Commit阶段的目标子事务(即第一子事务)，由于系统内可能会有多个协调节点组，每个协调节点组内均可能存在第一子事务需要重做，因此，在每个协调节点组上设置一个重做进度变量，记作is_commit，来记录在当前协调节点组中待重做的第一子事务的事务数(相当于待重做的已提交事务数，对应下述算法伪代码第13-16行)，接着，每重做完成一个第一子事务，就将重做进度变量is_commit减1。当重做进度变量is_commit减为0时，当前协调节点组中任一协调节点设备都可以向新的主副本节点设备额外发送一个重做完成指令(记为commit_done)，通知自身协调节点组中第一子事务均重做完毕。如果新的主副本节点设备收到了每个协调节点组中至少一个协调节点设备发来的重做完成指令commit_done，则代表系统内所有第一子事务均已经重做完毕。需要说明的是，由于每个协调节点组内的协调节点设备上均暂存有当前协调节点组内所有第一子事务，因此，有一个协调节点设备获知重做进度变量is_commit变为0时，则代表所属协调节点组内的所有第一子事务全部重做完成。

可选地，处于其他阶段(如读写阶段或准备阶段)的第三子事务需要从头开始重做，对于这部分未提交的第三子事务，在重做前后读取到的数据版本可能会发生不一致的情况，这是由于优先重做了已经进入提交阶段的第一子事务，而部分第一子事务可能会修改了第三子事务想要读取的数据项。为了解决这种读到数据版本不一致的问题，可以在协调节点设备上记录每个事务重做前读取的数据版本，通过查询第三子事务的父事务暂存的重做前数据版本，再与重做后数据版本进行比对，就能够很快发现是否存在不一致的情况，如果发现数据版本不一致，则回滚第三子事务的父事务。示意性地，通过事务的操作日志列表ops来记录，若协调节点设备上记录的是旧版本数据，则认为重做前事务读取到的是旧版本数据，若协调节点设备上无记录内容，则认为重做前事务读取的是新版本数据。示意性地，还可以通过writeset和readset两个数据结构，暂存任一事务所有执行过的数据库操作转化得到的读写集合，这里对暂存重做前数据版本的方式不做具体限定。

对于新选举出来的主副本节点设备，也称为上一实施例中涉及的目标节点设备，会根据重做的优先级逻辑，先重做已经进入Commit阶段的目标子事务(即第一子事务)，这部分第一子事务只须重做Commit阶段即可，重做代价较小，接着，在故障节点设备对所有第一子事务重做完毕后，再重做处于其他阶段(读写阶段或准备阶段)的目标子事务(即第三子事务)。

当故障节点设备修复故障、恢复正常后，可以通过重做日志同步机制，将新的主副本节点设备上在故障恢复期间产生的增量数据，以重做日志的方式同步到刚恢复的故障节点设备上，接着，恢复正常的故障节点设备可以通过物理复制的方式，根据重做日志将增量数据进行回放，此后可充当从副本节点设备继续提供服务。

在上述实施例中，详细介绍了在数据节点设备如主副本节点设备发生故障时，分别在主副本切换阶段和子事务重做阶段，协调节点设备和新选举出来的主副本节点设备需要执行哪些操作。而在本申请实施例中，将详细讨论假设协调节点设备发生故障的时候，系统内如何进行故障恢复。

图14是本申请实施例提供的一种协调节点设备故障时的故障恢复流程的交互流程图，如图14所示，该实施例适用于分布式数据库系统，假设任一协调节点组中包括负责协调目标事务的协调节点设备和至少一个其他协调节点设备，若该协调节点组中任一其他协调节点设备发生故障后，该协调节点设备接管发生故障的其他协调节点设备上原本正在执行的事务，其故障恢复流程包括下述步骤：

1401、协调节点设备对发生故障的其他协调节点设备上原本正在执行的任一事务，查询该事务的操作日志列表的同步进度参数，该同步进度参数用于指示该协调节点设备是否同步了该事务全量的操作日志列表。

在一些实施例中，同一协调节点组内的各个协调节点设备之间，也会通过心跳机制来保持通信，当协调节点设备的Checker线程发现无法收到某一其他协调节点设备的心跳消息时，确认该其他协调节点设备发生故障，在协调节点组内广播该其他协调节点设备发生故障，接着，在该协调节点组中选择一个协调节点设备，代替发生故障的该其他协调节点设备来继续对原本正在执行的事务进行协调，本申请实施例，则以接管原本正在执行的事务的协调节点设备为例进行说明。

在一些实施例中，由于协调节点设备之间对事务的操作日志列表ops的信息同步是异步的，比如定时发送机制下必然会存在一定时延，因此，对于发生故障的其他协调节点设备上原本正在执行的事务，协调节点设备中不一会存储该事务全量的操作日志列表ops，这一操作日志列表ops用于记录该事务已经执行完毕的数据库操作的全部信息(即操作记录)。

在一些实施例中，协调节点设备对每个事务，都维护一个用于表征操作日志列表ops是否同步完毕的同步进度参数txn.complete_ops，接着，针对发生故障的其他协调节点设备上原本正在执行的每个事务，查询该事务的同步进度参数txn.complete_ops，就能够得知在本协调节点设备上是否已经同步了该事务全量的操作日志列表ops。

需要说明的是，在未同步该事务全量的操作日志列表时，有可能是因为该事务本身就没有执行完毕全部的数据库操作，导致操作日志列表本身就不是全量的，比如在读写阶段中其他协调节点设备发生故障，其他协调节点设备故障前自身就没有全量的操作日志列表，更不可能向本协调节点设备同步全量的操作日志列表，还有可能是该事务本身读写阶段都已经执行完毕、其他协调节点设备故障前持有全量的操作日志列表，但是还没有来得及向本协调节点设备同步完毕，此时有可能本协调节点设备上存储的是一部分已同步的操作日志列表，但还存在另一部分未同步的操作日志列表丢失了。

在一些实施例中，同步进度参数txn.complete_ops可以是一个二值数据，即同步进度参数txn.complete_ops取值为1时，代表本协调节点设备上存储了该事务的全量的操作日志列表ops，同步进度参数txn.complete_ops取值为0时，代表本协调节点设备上没有存储该事务的全量的操作日志列表ops。在这种情况下，如果查询得到同步进度参数txn.complete_ops＝1，进入下述步骤1402，如果查询得到同步进度参数txn.complete_ops＝0，进入下述步骤1403-1405。

在一些实施例中，同步进度参数txn.complete_ops可以是一个布尔型数据，即同步进度参数txn.complete_ops取值为True时，代表本协调节点设备上存储了该事务的全量的操作日志列表ops，同步进度参数txn.complete_ops取值为False时，代表本协调节点设备上没有存储该事务的全量的操作日志列表ops。在这种情况下，如果查询得到同步进度参数txn.complete_ops＝True，进入下述步骤1402，如果查询得到同步进度参数txn.complete_ops＝False，进入下述步骤1403-1405。

1402、在该同步进度参数指示已同步该事务全量的操作日志列表的情况下，协调节点设备基于已同步的操作日志列表，对该事务进行协调。

在一些实施例中，在同步进度参数txn.complete_ops指示本协调节点设备已同步该事务全量的操作日志列表ops时，代表本协调节点设备能够直接利用已同步的全量的操作日志列表ops，继续负责协调该事务，由于操作日志列表ops是全量的并且也从故障的其他协调节点设备同步到了本协调节点设备上，这代表该事务至少已经读写阶段执行完毕，此时本协调节点设备查询操作日志列表是否存在准备操作记录，如果不存在准备操作记录，代表读写节点完毕、尚未开始2PC算法的准备阶段就发生故障了，本协调节点设备开启2PC算法的准备阶段，即向本事务的各个主副本节点设备发送准备请求，后续协调流程与前述实施例中未发生故障时的协调流程类似，这里不做赘述；此外，如果存在准备操作记录，假设准备操作记录为<Prepare,Null>，代表已进入准备阶段，尚在等待各个主副本节点设备的准备完成响应，那么通知各个主副本节点设备向本副本节点设备重新发送准备完成响应，即可继续执行后续协调流程，假设准备操作记录为<Prepare,True>，代表已经准备成功，则直接进入2PC算法的提交阶段，接管后续提交阶段的协调流程，假设准备操作记录为<Prepare,False>，代表已经准备失败，该事务需要进行回滚，则向各个主副本节点设备发送该事务的回滚指令，接管后续回滚阶段的协调流程。

1403、在该同步进度参数指示未同步该事务全量的操作日志列表的情况下，协调节点设备通知发起该事务的终端重新发送该事务的请求语句。

在一些实施例中，在同步进度参数txn.complete_ops指示本协调节点设备未同步该事务全量的操作日志列表ops时，代表本协调节点设备本地没有存储该事务全量的操作日志列表ops，此时，有可能是因为该事务本身就没有执行完毕全部的数据库操作，导致操作日志列表ops本身就不是全量的，比如在读写阶段中其他协调节点设备发生故障，其他协调节点设备故障前自身就没有全量的操作日志列表ops，更不可能向本协调节点设备同步全量的操作日志列表ops，还有可能是该事务本身读写阶段都已经执行完毕、其他协调节点设备故障前持有全量的操作日志列表ops，但是还没有来得及向本协调节点设备同步完毕，此时有可能本协调节点设备上存储的是一部分已同步的操作日志列表ops，但还存在另一部分未同步的操作日志列表ops丢失了。

在这种情况下，协调节点设备可以通知发起该事务的终端上的应用客户端，以使应用客户端重新发送一次该事务的请求语句(比如重新发送一次该事务的数据请求，或者重新发起该事务)，又比如，以使应用客户端仅重新发送尚未同步的数据库操作序列，换言之，本协调节点设备上既然已经存储了部分已同步的操作日志列表ops，只需要通知应用客户端将尚未同步的数据库操作序列发过来就能够获知该事务的全部操作信息了，这样能够节约通信开销。

1404、终端向协调节点设备重新发送该事务的请求语句。

在一些实施例中，终端上的应用客户端接收到重新发送该事务的请求语句的通知，须知这里仅仅是重新发送请求语句，不代表要向用户侧通知事务执行失败、重新发起事务，因此事务没有确认执行失败，只是在尝试进行故障恢复，因此此时重新发送请求语句，不等于事务回滚后重新发起事务，事务仍然处于执行过程中，可能会顺利提交也可能后续会被回滚。

在一些实施例中，应用客户端向该协调节点设备重新发送该事务的请求语句，比如重新发送一次该事务的数据请求，或者重新发起该事务(但无需用户侧感知)，这样能够简化处理逻辑。

在一些实施例中，应用客户端仅重新发送尚未同步的数据库操作序列，换言之，本协调节点设备上既然已经存储了部分已同步的操作日志列表ops，只需要通知应用客户端将尚未同步的数据库操作序列发过来就能够获知该事务的全部操作信息了，这样能够节约通信开销。可选地，协调节点设备在向应用客户端发送通知消息的时候，在该通知消息中携带最新的已同步的数据库操作，以使应用客户端将该事务中最新的已同步的数据库操作之后的所有尚未同步的数据库操作序列发送给协调节点设备。

在一个示例中，假设某事务共执行N(N≥1)次操作，但本协调节点设备仅同步了包含前M(1≤M≤N)次操作的操作记录的操作日志列表ops，那么协调节点设备只需要通知应用客户端重新发送从第M+1次至第N次操作的数据库操作序列，这样能够极大节约通信开销。

1405、协调节点设备基于该终端返回的请求语句，对该事务进行协调。

在一些实施例中，协调节点设备接收到终端返回的请求语句之后，能够基于该请求语句，获取到尚未同步的数据库操作序列，接着，可以通知各个主副本节点设备重做尚未同步的数据库操作序列，在对尚未同步的数据库操作序列重做完毕后，再继续对该事务执行阶段进行协调。

需要说明的是，本申请实施例以同一协调节点组中其他协调节点设备发生故障、本协调节点设备接管阻塞事务为例说明，假设本协调节点设备发生故障，其他协调节点设备也可以通过类似的方式接管阻塞事务，这里不做赘述。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过在协调节点组中各个协调节点设备之间定时同步事务的操作日志列表，使得当任一协调节点设备发生故障时，对于需要恢复的事务，其他协调节点设备能够利用本次暂存的操作日志列表来继续对该事务进行协调，从而能够快速实现协调节点设备故障时的故障恢复，从而尽可能的保证事务不会由于协调节点设备故障而被回滚。

以下，将对故障发生在不同时机、不同节点的事务故障恢复机制进行总结。

图15是本申请实施例提供的一种事务执行流程的原理性示意图，如1500所示，在整个事务的执行流程中，可以划分成如下5个阶段：①读写阶段；②准备阶段，但事务的操作日志列表ops同步未完成；③准备阶段，但事务的操作日志列表ops同步已完成；④提交阶段，主从副本间同步未完成；⑤提交阶段，主从副本间同步完成。

以下，将在图15所示的事务所处不同阶段①至⑤的基础上，对协调节点设备故障时的事务故障恢复机制进行详细说明。

协调节点设备负责协调管理事务的整个生命周期，在事务的整个生命周期结束前，协调节点设备随时可能发生故障。假设某个时刻，分布式数据库系统中某个协调节点设备发生故障，故障节点设备所在的协调节点组中其他协调节点设备都处于活跃状态，那么由任一活跃节点设备接替故障节点设备继续对原本正在执行的事务进行协调，上述能够接替协调的关键在于，活跃节点设备上必须要有事务的完整操作数据和执行状态，上述操作数据和执行状态均能够通过事务的操作日志列表ops来进行标识，操作数据体现为数据库操作的数据记录，执行状态则体现为准备操作记录和提交操作记录。

接着，以协调节点设备发生故障时，事务所处于上述图15中①至⑤不同阶段来划分故障情况，并针对不同情况采取不同的故障恢复策略：

事务处于①阶段，协调节点设备正在协调事务在各个主副本节点设备上进行读写操作，如果此时协调节点设备发生故障，其他协调节点设备上没有待恢复事务(即正在执行的事务)的完整操作信息，即由于读写操作尚未执行完毕，不可能同步全量的操作日志列表ops，这时其他协调节点设备无法直接接替故障节点设备继续协调待恢复事务，因此需要通知客户端重新发起待恢复事务，新的协调节点设备结合待恢复事务已经同步的操作信息即当前已同步的操作日志列表ops，从未执行的数据库操作开始继续执行待恢复事务。

事务处于②阶段，待恢复事务已经结束读写阶段进入准备阶段，全量的操作日志列表ops已经生成，但全量的操作日志列表ops还未在协调节点设备间完全同步，如果此时协调节点设备发生故障，仍然需要通知客户端重新发起待恢复事务，新的协调节点设备基于客户端返回的请求语句，能够获得事务的完整操作信息，即在已同步的操作日志列表ops中补全尚未同步的数据库操作的操作记录，得到全量的操作日志列表ops，接着，结合数据分片的元数据即分区信息表，就可以获得参与待恢复事务的主副本节点列表，因此新的协调节点设备可以继续对事务进行协调。

事务处于③阶段，协调节点设备正在协调待恢复事务进行2PC算法的Prepare准备阶段，还未能决定提交或中止待恢复事务，由于在开启准备阶段前必须要求操作日志列表ops在至少一个其他协调节点设备上暂存，代表待恢复事务的操作日志列表ops已经在协调节点设备间完全同步，如果此时协调节点设备发生故障，在故障节点设备所在的协调节点组中选择一个其他协调节点设备，通过在其上的暂存的完整操作信息即全量的操作日志列表ops，即可继续协调待恢复事务进行两阶段提交。

事务处于④阶段，协调节点设备已经协调待恢复事务完成了2PC算法的Prepare准备阶段，而且已经决定了提交或中止待恢复事务，且待恢复事务的全量操作日志列表ops也已经在协调节点设备间完全同步，如果此时协调节点设备发生故障，在故障节点设备所在的协调节点组中选择一个其他协调节点设备，通过在其上的暂存的完整操作信息即全量的操作日志列表ops，即可继续协调待恢复事务进行2PC算法的Commit提交阶段。

事务处于⑤阶段，协调节点设备已经收到所有主副本节点设备返回的同步成功消息(即提交完成响应)，如果此时协调节点设备发生故障，待恢复事务已经处于成功提交状态，因此不需要对其进行恢复。

总的来说，当某个协调节点设备发生故障时，如果故障节点设备上的待恢复事务已经将其全量操作日志列表ops同步到协调节点组中的其他活跃节点设备上了，那么就可以由包含该待恢复事务的全量操作日志列表ops的活跃节点设备接替故障节点设备进行协调工作；如果活跃节点设备上没有存储待恢复事务的完整操作信息，即全量操作日志列表ops尚未生成，或全量操作日志列表ops已生成但未同步完毕，就需要由客户端重新发送待恢复事务的请求语句到新的协调节点设备，从而通过逻辑重做或其他方式，在操作日志列表ops中补全未同步的操作信息后就可以继续协调事务。

进一步的，当某个协调节点设备发生故障时，其他活跃的协调节点设备需要快速感知故障并尽可能地将故障节点设备原本负责协调的事务(即待恢复事务)继续执行下去。因此，协调节点设备间可以采用心跳机制来快速感知故障，此外，在事务进入2PC算法的Prepare准备阶段时，还可以在协调节点设备间同步事务元数据(即全量操作日志列表ops)，保证协调节点设备具有高可用性。

示意性地，故障感知及事务恢复的流程如下：

故障感知：协调节点设备间的故障感知机制与数据节点设备间的故障感知机制相同。可选地，每个协调节点设备上创建Checker线程，Checker线程定时地向其他协调节点设备发送心跳消息来维持其活跃状态，如果其他协调节点设备超过一段时间未收到某个协调节点设备的心跳消息，就认为该协调节点设备发生了故障，其他活跃的协调节点设备则会尝试接替该故障节点设备对待恢复事务进行协调。

示意性地，协调节点设备上Checker线程定时地调用Check()函数，向其他协调节点设备发送心跳消息来维持活跃状态。当前协调节点设备发现某个其他协调节点设备故障时，该活跃的协调节点设备可以调用txn_recovery()函数尝试接管故障节点设备上正在执行的事务即待恢复事务(对应于下述算法1伪代码的第6行)。

协调节点设备切换：协调节点设备保持高可用性的关键在于，事务操作信息即操作日志列表ops在协调节点设备间的信息同步。当其他活跃的协调节点设备发现某个协调节点设备发生了故障，可以在本地搜索待恢复事务的操作信息，比如搜索待恢复事务的操作日志列表ops的同步进度参数txn.complete_ops。活跃的协调节点设备可以通过分区信息表，以及待恢复事务的操作日志列表ops来恢复内存中协调待恢复事务所需要用到的数据，至少包括待恢复事务涉及的主副本节点列表。在协调待恢复事务所需要用到的数据恢复后，即可认为已经对待恢复事务完成了协调节点设备切换的过程。

示意性地，活跃的协调节点设备根据故障节点设备的节点标识或设备标识，调用get_backup_txns()函数，以获取故障节点设备上正在执行的事务的列表{Ti}(对应于下述算法2伪代码的第2行)，相当于新的协调节点设备获取到故障节点设备上各个待恢复事务构成的列表。

故障恢复：当活跃的协调节点设备在内存中恢复完毕了协调待恢复事务所需要用到的数据后，就可以继续协调待恢复事务进行准备或提交等操作。

示意性地，对于上述获取到的待恢复事务列表{Ti}中的任一事务txn，在操作日志列表ops的同步进度参数txn.complete_ops为布尔型数据的情况下，如果事务txn的同步进度参数txn.complete_ops为真True，代表活跃的协调节点设备上存储有该事务txn的完整操作信息即全量操作日志列表ops，则可以直接通过全量操作日志列表ops进行事务恢复；如果事务txn的同步进度参数txn.complete_ops为假False，活跃的协调节点设备上没有该事务txn的完整操作信息即存储的操作日志列表ops是非全量的，则该活跃的协调节点设备需要调用request_ops_from_client()函数，以向客户端请求再次发送事务txn的完整操作信息，比如请求重新发起事务txn，或者请求仅发生尚未同步的数据库操作序列，在该活跃的协调节点设备获得到完整的操作信息，补全了全量操作日志列表ops后才可以进行事务恢复(对应于下述算法2伪代码的第4-9行)。

接着，根据操作日志列表ops中记录的事务txn读写的数据项，以及协调节点设备中数据分区的分区信息表，能够获得事务txn涉及的主副本节点设备，然后将主副本节点设备逐一添加到事务txn相关的主副本节点列表txn.datanodes中(对应于下述算法2伪代码的第7-8行)。

接着，活跃的协调节点设备对事务txn调用recover()函数进行恢复(对应于下述算法2伪代码的第9行)。根据待恢复事务txn在发生故障时所处的事务状态txn.status，可以决定事务txn的事务恢复策略：

如果故障时事务txn处于读写阶段，那么发生故障的协调节点设备还未协调该事务txn完成在各个主副本节点设备上的读写操作，因此恢复时活跃的协调节点设备需要调用redo_unfinished_ops()函数，先在对应主副本节点设备上继续执行故障前尚未完成的读写操作，再进入到两阶段提交(对应于下述算法3伪代码的第3行)。

如果故障时事务txn处于2PC算法的Prepare准备阶段，那么协调节点设备还未决定提交或中止该事务txn，因此恢复时活跃的协调节点设备可以调用redo_2PC()函数，即事务恢复需要重做整个2PC过程(对应于下述算法3伪代码的第5行)。

如果故障时事务txn处于2PC算法的Commit提交阶段，那么协调节点设备已经决定提交或中止该事务txn，因此恢复时活跃的协调节点设备可以调用redo_commit()函数，即事务恢复只需要重做2PC算法中的Commit提交阶段(对应于下述算法3伪代码的第7行)。

示意性地，故障节点故障恢复的伪代码如下：

在上述实施例中，结合相关算法的伪代码，详细介绍了协调节点设备在事务执行的不同时机发生故障时，如果通过协调节点组中另一活跃的协调节点设备来接管待恢复事务，并继续对待恢复事务进行协调的故障恢复机制。下面，将对不同故障发生时机、不同故障发生位置下各自的故障恢复策略进行总结，表1示出了故障发生情况及对应故障恢复策略的总结，如表1所示：

表1

以下，在上述协调节点设备或数据节点设备单独发生故障时的故障恢复流程的基础上，将针对协调节点设备和数据节点设备(即主副本节点设备)均发生故障的情况来进行分析。

当协调节点设备和数据节点设备均发生故障时，待恢复事务可以根据其涉及的故障节点设备的设备类型分为三类，针对不同类型的待恢复事务采取不同的故障恢复策略：

考虑只涉及数据节点设备故障的待恢复事务，由于协调节点设备故障所导致的待恢复事务只需要切换到活跃的协调节点设备继续执行，不会影响到只涉及数据节点设备故障的待恢复事务的恢复操作，因此，对于这类只涉及数据节点设备故障的待恢复事务，可以采用只有数据节点设备发生故障情况下的故障恢复策略进行恢复。

考虑只涉及协调节点设备故障的待恢复事务，由于数据节点设备故障所导致的待恢复事务只需要在其涉及的数据分区切换主副本完成后就能继续执行，不会影响到只涉及协调节点设备故障的待恢复事务的恢复操作，因此，对于这类只涉及协调节点设备故障的待恢复事务，可以采用只有协调节点设备发生故障情况下的故障恢复策略进行恢复。

当待恢复事务同时涉及数据节点设备故障和协调节点设备故障时，此时需要同时考虑两类故障对故障恢复流程的影响，下面将按照发生故障时事务执行所处于①至⑤中哪个阶段来进行分类讨论：

故障发生时待恢复事务处于①阶段，此时协调节点设备正在协调待恢复事务在各个数据节点设备上进行读写操作。故障发生后，其他活跃的数据节点设备和其他活跃的协调节点设备均能通过心跳机制及时发现故障，但两类节点设备完成从故障节点设备到活跃节点设备切换的时间可能不一致。由于待恢复事务的读写操作还未执行完成，协调节点设备在切换完成后，先向客户端请求重发待恢复事务的请求语句，在收到客户端返回的请求语句后，得到待恢复事务的完整数据库操作序列，并基于本地已同步的操作日志列表ops，两者对比能够找到故障前未完成的待恢复操作队列，此时立即通知对应数据节点设备尝试执行故障前未完成的读写操作，但该过程必须在相关数据分区全部切主完成(即从故障主副本切换成活跃主副本完毕)后才能正常执行，如果某个读写操作涉及的数据分区切主未完成，协调节点设备需要多次重发执行待恢复事务在该数据分区上目标子事务的待恢复操作队列，直到该数据分区切主完成并成功执行该目标子事务的待恢复操作队列，此时待恢复事务的目标子事务成功恢复，在待恢复事务的各个目标子事务都成功恢复后，待恢复事务整体成功恢复。

故障发生时待恢复事务处于②阶段，待恢复事务的全量操作日志列表ops还未在协调节点设备间完全同步。故障发生后，其他活跃的数据节点设备和其他活跃的协调节点设备均能通过心跳机制及时发现故障，之后涉及故障的数据分区进行切主，协调节点设备先完成切换任务再向客户端请求待恢复事务的请求语句，以根据返回的请求语句补全得到全量操作日志列表ops，两个过程都完成后，待恢复事务成功恢复并继续进行两阶段提交。

故障发生时待恢复事务处于③阶段，待恢复事务操作已经在协调节点设备间完全同步。故障发生后，其他活跃的数据节点设备和其他活跃的协调节点设备均能通过心跳机制及时发现故障，两类节点设备及时进行从故障节点设备到活跃节点设备的切换，在两类节点设备均切换完成后，待恢复事务成功恢复并重新进行两阶段提交。

故障发生时待恢复事务处于④阶段，协调节点设备在故障发生前已经协调待恢复事务完成了2PC算法的Prepare准备阶段，而且已经决定提交或中止待恢复事务，事务的操作信息即全量操作日志列表ops也已经在协调节点设备间完全同步。故障发生后，其他活跃的数据节点设备和其他活跃的协调节点设备均能通过心跳机制及时发现故障，两类节点设备及时进行从故障节点设备到活跃节点设备的切换，在两类节点设备均切换完成后，待恢复事务成功恢复并重新进行两阶段提交的Commit提交阶段。

故障发生时待恢复事务处于⑤阶段，由于待恢复事务已经成功提交，不需要进行恢复。

通过以上分析，可以看出，在各类故障情况下，本申请实施例设计的事务恢复策略都能够利用客户端和其他活跃节点设备的信息，对待恢复事务进行正确地恢复。因此，本申请实施例提供的事务快速恢复算法，能够对故障发生时正在执行的事务进行重做，使得事务尽可能不会因为节点故障(不管是协调节点设备故障、数据节点设备故障还是两类节点设备均故障)而被回滚。

综合上述各个实施例的说明，本申请实施例一方面提出了轻量级的事务粒度副本同步机制，能够改善由于副本同步影响事务处理性能的情况，将副本同步对系统内事务性能的影响降到最低，从而保证分布式事务处理的性能。另一方面设计了在这一轻量级的事务粒度副本同步机制下，若任一节点在任一时机发生故障时的事务快速故障恢复算法，尽可能地保证了事务不会因为节点故障而被回滚，提升了事务重做的效率，进而提升了分布式数据库系统可用性。

图16是本申请实施例提供的一种事务处理装置的结构示意图，如图16所示，该装置为分布式数据库系统的协调节点设备，该装置包括：

确定模块1601，用于确定目标事务所涉及执行的数据库操作对应的主副本节点设备；

分发模块1602，用于向该主副本节点设备分发该目标事务在该主副本节点设备上的子事务；

发送模块1603，用于向该主副本节点设备发送准备请求，该准备请求用于指示该主副本节点设备对该子事务进行数据异常检测；

该发送模块1603，还用于在符合事务提交条件的情况下，向该主副本节点设备发送提交请求，该提交请求用于指示该主副本节点设备提交该子事务，以及将该子事务的重做日志发送至对应的从副本节点设备。

本申请实施例提供的装置，通过在分布式数据库系统中，向主副本节点设备分发子事务后，在两阶段提交算法的准备阶段，协调节点设备下发准备请求，仅指示主副本节点设备进行数据异常检测但无需进行主从副本间的数据同步，在符合事务提交条件进入到提交阶段后，协调节点设备下发提交请求，才指示主副本节点设备本地提交子事务并将重做日志同步到从副本节点设备，因此仅需要在提交阶段进行一轮通信就能够实现主从副本间的数据一致，从而极大降低了系统内主从副本间的同步次数，压缩了多副本机制下的副本同步开销，从而尽量消除由于多副本机制对系统内事务处理性能的不良影响。

在一种可能实施方式中，该确定模块1601用于：

确定该数据库操作所对应数据项所属的数据分区；

基于分区信息表，查询得到该数据分区对应的该主副本节点设备，该分区信息表用于记录数据分区与主副本节点设备的对应关系。

在一种可能实施方式中，该协调节点设备存储有该目标事务的操作日志列表，该操作日志列表包括该目标事务当前已执行的数据库操作的操作记录；

基于图16的装置组成，该装置还包括：添加模块，用于响应于该主副本节点设备返回的子事务执行结果，在该操作日志列表中，添加该子事务已执行的数据库操作的操作记录，该操作记录表征该数据库操作的操作类型和涉及操作的数据项。

在一种可能实施方式中，在该分布式数据库系统中，该协调节点设备和至少一个其他协调节点设备构成协调节点组，该发送模块1603还用于：

每间隔第一目标时长，向该协调节点组中的该至少一个其他协调节点设备发送已存储的至少一个事务的操作日志列表。

在一种可能实施方式中，该发送模块1603还用于：

在该目标事务的子事务的操作记录均添加至该操作日志列表，且该操作日志列表已同步至任一其他协调节点设备的情况下，向该主副本节点设备发送该准备请求。

在一种可能实施方式中，该操作日志列表还用于存储该目标事务的准备操作记录或提交操作记录中至少一项，该准备操作记录用于记录该目标事务在准备阶段所处的状态，该提交操作记录用于记录该目标事务的提交阶段所处的状态。

在一种可能实施方式中，该确定模块1601还用于：若该主副本节点设备发生故障，确定从该主副本节点设备对应的至少一个从副本节点设备中选举得到的目标节点设备；

该确定模块1601还用于：确定该目标节点设备对应的目标子事务，该目标子事务是指原本由该主副本节点设备执行但由于故障正在等待恢复的子事务；

该发送模块1603还用于：向该目标节点设备发送该目标子事务的待恢复操作队列，该待恢复操作队列包括该目标子事务在操作日志列表中对应的至少一条操作记录。

在一种可能实施方式中，该目标节点设备是从该至少一个从副本节点设备中随机选举得到的；或，该目标节点设备是该至少一个从副本节点设备中负载最低的节点设备。

在一种可能实施方式中，在该分布式数据库系统中，该协调节点设备和至少一个其他协调节点设备构成协调节点组，若该协调节点组中任一其他协调节点设备发生故障后，该协调节点设备接管发生故障的其他协调节点设备上原本正在执行的事务，基于图16的装置组成，该装置还包括：

查询模块，用于对该发生故障的其他协调节点设备上原本正在执行的任一事务，查询该事务的操作日志列表的同步进度参数，该同步进度参数用于指示该协调节点设备是否同步了该事务全量的操作日志列表；

协调模块，用于在该同步进度参数指示已同步该事务全量的操作日志列表的情况下，基于已同步的操作日志列表，对该事务进行协调；

该协调模块，还用于在该同步进度参数指示未同步该事务全量的操作日志列表的情况下，通知发起该事务的终端重新发送该事务的请求语句；基于该终端返回的请求语句，对该事务进行协调。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

需要说明的是：上述实施例提供的事务处理装置在处理事务时，仅以上述各功能模块的划分进行举例说明，实际应用中，能够根据需要而将上述功能分配由不同的功能模块完成，即将节点设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的事务处理装置与事务处理方法实施例属于同一构思，其具体实现过程详见事务处理方法实施例，这里不再赘述。

图17是本申请实施例提供的一种事务处理装置的结构示意图，请参考图17，该装置为分布式数据库系统的主副本节点设备，该装置包括：

执行模块1701，用于响应于目标事务在该主副本节点设备上的子事务，执行该子事务对应的数据库操作；

检测模块1702，用于响应于该目标事务的准备请求，对该子事务进行数据异常检测；

提交模块1703，用于响应于该目标事务的提交请求，提交该子事务；

发送模块1704，用于将该子事务的重做日志发送至对应的从副本节点设备，以使该从副本节点设备在回放该重做日志时重做该子事务。

本申请实施例提供的装置，通过在分布式数据库系统中，接收到协调节点设备分发的子事务后执行该子事务，在接收到准备请求时进入两阶段提交算法的准备阶段，主副本节点设备仅进行数据异常检测但无需进行主从副本间的数据同步，在接收到提交请求时进入两阶段提交算法的提交阶段，主副本节点设备本地提交子事务并将重做日志同步到从副本节点设备，因此仅需要在提交阶段进行一轮通信就能够实现主从副本间的数据一致，从而极大降低了系统内主从副本间的同步次数，压缩了多副本机制下的副本同步开销，从而尽量消除由于多副本机制对系统内事务处理性能的不良影响。

在一种可能实施方式中，当该主副本节点设备作为另一主副本节点设备的从副本节点设备时，若该另一主副本节点设备发生故障后，该主副本节点设备被选举为目标节点设备，基于图17的装置组成，该装置还包括：

接收模块，用于接收任一协调节点设备发送的目标子事务的待恢复操作队列，该目标子事务是指原本由该协调节点设备分配给该另一主副本节点设备执行、但由于故障正在等待恢复的子事务；

确定模块，用于基于该待恢复操作队列，从该目标子事务中，确定符合事务提交条件的第一子事务、符合事务回滚条件的第二子事务以及剩余的第三子事务；

重做模块，用于基于该待恢复操作队列，重做该第一子事务和该第三子事务；

丢弃模块，用于丢弃该第二子事务相关联的操作记录。

在一种可能实施方式中，该确定模块用于：

在该待恢复操作队列中，查询任一目标子事务所对应父事务的准备操作记录；

若该准备操作记录指示该父事务在准备阶段所处的状态为准备完成状态，将该目标子事务确定为第一子事务；

若该准备操作记录指示该父事务在准备阶段所处的状态为准备失败状态，将该目标子事务确定为第二子事务；

若该准备操作记录指示该父事务在准备阶段所处的状态既不是准备完成状态也不是准备失败状态，将该目标子事务确定为第三子事务。

在一种可能实施方式中，基于图17的装置组成，该重做模块包括：

第一重做单元，用于基于该待恢复操作队列，重做该第一子事务；

第二重做单元，用于在接收到该分布式数据库系统中多个协调节点组中任一协调节点设备发送的重做完成指令的情况下，基于该待恢复操作队列，重做该第三子事务，该重做完成指令用于表征对应协调节点组所负责协调的第一子事务重做完毕。

在一种可能实施方式中，该第一重做单元用于：

在该目标节点设备已对该第一子事务的重做日志回放完毕的情况下，维护对该第一子事务进行并发控制所需的信息，提交该第一子事务；或，

在该目标节点设备尚未回放该第一子事务的重做日志的情况下，基于该待恢复操作队列，执行该第一子事务对应的至少一条操作记录，维护对该第一子事务进行并发控制所需的信息，提交该第一子事务。

在一种可能实施方式中，该第二重做单元用于：

基于该待恢复操作队列，执行该第三子事务对应的至少一条操作记录，维护对该第三子事务进行并发控制所需的信息；

响应于对该第三子事务的提交请求，提交该第三子事务，向该目标节点设备对应的至少一个从副本节点设备发送该第三子事务的重做日志；

响应于对该第三子事务的回滚指令，回滚该第三子事务。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

需要说明的是：上述实施例提供的事务处理装置在处理事务时，仅以上述各功能模块的划分进行举例说明，实际应用中，能够根据需要而将上述功能分配由不同的功能模块完成，即将节点设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的事务处理装置与事务处理方法实施例属于同一构思，其具体实现过程详见事务处理方法实施例，这里不再赘述。

图18是本申请实施例提供的一种节点设备的结构示意图，该节点设备1800可因配置或性能不同而产生比较大的差异，该节点设备1800包括一个或一个以上处理器(CentralProcessing Units，CPU)1801和一个或一个以上的存储器1802，其中，该存储器1802中存储有至少一条计算机程序，该至少一条计算机程序由该一个或一个以上处理器1801加载并执行以实现上述各个实施例提供的事务处理方法。可选地，该节点设备1800还具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该节点设备1800还包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条计算机程序的存储器，上述至少一条计算机程序可由节点设备中的处理器执行以完成上述各个实施例中的事务处理方法。例如，该计算机可读存储介质包括ROM(Read-Only Memory，只读存储器)、RAM(Random-Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-Only Memory，只读光盘)、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，包括一条或多条程序代码，该一条或多条程序代码存储在计算机可读存储介质中。节点设备的一个或多个处理器能够从计算机可读存储介质中读取该一条或多条程序代码，该一个或多个处理器执行该一条或多条程序代码，使得节点设备能够执行以完成上述实施例中的事务处理方法。

本领域普通技术人员能够理解实现上述实施例的全部或部分步骤能够通过硬件来完成，也能够通过程序来指令相关的硬件完成，可选地，该程序存储于一种计算机可读存储介质中，可选地，上述提到的存储介质是只读存储器、磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (20)

1.一种事务处理方法，其特征在于，由分布式数据库系统的协调节点设备执行，所述方法包括：

确定目标事务所涉及执行的数据库操作对应的主副本节点设备；

向所述主副本节点设备分发所述目标事务在所述主副本节点设备上的子事务；

向所述主副本节点设备发送准备请求，所述准备请求用于指示所述主副本节点设备对所述子事务进行数据异常检测；

在符合事务提交条件的情况下，向所述主副本节点设备发送提交请求，所述提交请求用于指示所述主副本节点设备提交所述子事务，以及将所述子事务的重做日志发送至对应的从副本节点设备。

2.根据权利要求1所述的方法，其特征在于，所述确定目标事务所涉及执行的数据库操作对应的主副本节点设备包括：

确定所述数据库操作所对应数据项所属的数据分区；

基于分区信息表，查询得到所述数据分区对应的所述主副本节点设备，所述分区信息表用于记录数据分区与主副本节点设备的对应关系。

3.根据权利要求1所述的方法，其特征在于，所述协调节点设备存储有所述目标事务的操作日志列表，所述操作日志列表包括所述目标事务当前已执行的数据库操作的操作记录；

所述向所述主副本节点设备分发所述目标事务在所述主副本节点设备上的子事务之后，所述方法还包括：

响应于所述主副本节点设备返回的子事务执行结果，在所述操作日志列表中，添加所述子事务已执行的数据库操作的操作记录，所述操作记录表征所述数据库操作的操作类型和涉及操作的数据项。

4.根据权利要求3所述的方法，其特征在于，在所述分布式数据库系统中，所述协调节点设备和至少一个其他协调节点设备构成协调节点组，所述方法还包括：

每间隔第一目标时长，向所述协调节点组中的所述至少一个其他协调节点设备发送已存储的至少一个事务的操作日志列表。

5.根据权利要求4所述的方法，其特征在于，所述向所述主副本节点设备发送准备请求包括：

在所述目标事务的子事务的操作记录均添加至所述操作日志列表，且所述操作日志列表已同步至任一其他协调节点设备的情况下，向所述主副本节点设备发送所述准备请求。

6.根据权利要求3至5中任一项所述的方法，其特征在于，所述操作日志列表还用于存储所述目标事务的准备操作记录或提交操作记录中至少一项，所述准备操作记录用于记录所述目标事务在准备阶段所处的状态，所述提交操作记录用于记录所述目标事务的提交阶段所处的状态。

7.根据权利要求1所述的方法，其特征在于，若所述主副本节点设备发生故障，所述方法还包括：

确定从所述主副本节点设备对应的至少一个从副本节点设备中选举得到的目标节点设备；

确定所述目标节点设备对应的目标子事务，所述目标子事务是指原本由所述主副本节点设备执行但由于故障正在等待恢复的子事务；

向所述目标节点设备发送所述目标子事务的待恢复操作队列，所述待恢复操作队列包括所述目标子事务在操作日志列表中对应的至少一条操作记录。

8.根据权利要求7所述的方法，其特征在于，所述目标节点设备是从所述至少一个从副本节点设备中随机选举得到的；或，所述目标节点设备是所述至少一个从副本节点设备中负载最低的节点设备。

9.根据权利要求1所述的方法，其特征在于，在所述分布式数据库系统中，所述协调节点设备和至少一个其他协调节点设备构成协调节点组，若所述协调节点组中任一其他协调节点设备发生故障后，所述协调节点设备接管发生故障的其他协调节点设备上原本正在执行的事务，所述方法还包括：

对所述发生故障的其他协调节点设备上原本正在执行的任一事务，查询所述事务的操作日志列表的同步进度参数，所述同步进度参数用于指示所述协调节点设备是否同步了所述事务全量的操作日志列表；

在所述同步进度参数指示已同步所述事务全量的操作日志列表的情况下，基于已同步的操作日志列表，对所述事务进行协调；

在所述同步进度参数指示未同步所述事务全量的操作日志列表的情况下，通知发起所述事务的终端重新发送所述事务的请求语句；基于所述终端返回的请求语句，对所述事务进行协调。

10.一种事务处理方法，其特征在于，由分布式数据库系统的主副本节点设备执行，所述方法包括：

响应于目标事务在所述主副本节点设备上的子事务，执行所述子事务对应的数据库操作；

响应于所述目标事务的准备请求，对所述子事务进行数据异常检测；

响应于所述目标事务的提交请求，提交所述子事务；

将所述子事务的重做日志发送至对应的从副本节点设备，以使所述从副本节点设备在回放所述重做日志时重做所述子事务。

11.根据权利要求10所述的方法，其特征在于，当所述主副本节点设备作为另一主副本节点设备的从副本节点设备时，若所述另一主副本节点设备发生故障后，所述主副本节点设备被选举为目标节点设备，所述方法还包括：

接收任一协调节点设备发送的目标子事务的待恢复操作队列，所述目标子事务是指原本由所述协调节点设备分配给所述另一主副本节点设备执行、但由于故障正在等待恢复的子事务；

基于所述待恢复操作队列，从所述目标子事务中，确定符合事务提交条件的第一子事务、符合事务回滚条件的第二子事务以及剩余的第三子事务；

基于所述待恢复操作队列，重做所述第一子事务和所述第三子事务；丢弃所述第二子事务相关联的操作记录。

12.根据权利要求11所述的方法，其特征在于，所述基于所述待恢复操作队列，从所述目标子事务中，确定符合事务提交条件的第一子事务、符合事务回滚条件的第二子事务以及剩余的第三子事务包括：

在所述待恢复操作队列中，查询任一目标子事务所对应父事务的准备操作记录；

若所述准备操作记录指示所述父事务在准备阶段所处的状态为准备完成状态，将所述目标子事务确定为第一子事务；

若所述准备操作记录指示所述父事务在准备阶段所处的状态为准备失败状态，将所述目标子事务确定为第二子事务；

若所述准备操作记录指示所述父事务在准备阶段所处的状态既不是准备完成状态也不是准备失败状态，将所述目标子事务确定为第三子事务。

13.根据权利要求11或12所述的方法，其特征在于，所述基于所述待恢复操作队列，重做所述第一子事务和所述第三子事务包括：

基于所述待恢复操作队列，重做所述第一子事务；

在接收到所述分布式数据库系统中多个协调节点组中任一协调节点设备发送的重做完成指令的情况下，基于所述待恢复操作队列，重做所述第三子事务，所述重做完成指令用于表征对应协调节点组所负责协调的第一子事务重做完毕。

14.根据权利要求13所述的方法，其特征在于，所述基于所述待恢复操作队列，重做所述第一子事务包括：

在所述目标节点设备已对所述第一子事务的重做日志回放完毕的情况下，维护对所述第一子事务进行并发控制所需的信息，提交所述第一子事务；或，

在所述目标节点设备尚未回放所述第一子事务的重做日志的情况下，基于所述待恢复操作队列，执行所述第一子事务对应的至少一条操作记录，维护对所述第一子事务进行并发控制所需的信息，提交所述第一子事务。

15.根据权利要求13所述的方法，其特征在于，所述基于所述待恢复操作队列，重做所述第三子事务包括：

基于所述待恢复操作队列，执行所述第三子事务对应的至少一条操作记录，维护对所述第三子事务进行并发控制所需的信息；

响应于对所述第三子事务的提交请求，提交所述第三子事务，向所述目标节点设备对应的至少一个从副本节点设备发送所述第三子事务的重做日志；

响应于对所述第三子事务的回滚指令，回滚所述第三子事务。

16.一种事务处理装置，其特征在于，所述装置为分布式数据库系统的协调节点设备，所述装置包括：

确定模块，用于确定目标事务所涉及执行的数据库操作对应的主副本节点设备；

分发模块，用于向所述主副本节点设备分发所述目标事务在所述主副本节点设备上的子事务；

发送模块，用于向所述主副本节点设备发送准备请求，所述准备请求用于指示所述主副本节点设备对所述子事务进行数据异常检测；

所述发送模块，还用于在符合事务提交条件的情况下，向所述主副本节点设备发送提交请求，所述提交请求用于指示所述主副本节点设备提交所述子事务，以及将所述子事务的重做日志发送至对应的从副本节点设备。

17.一种事务处理装置，其特征在于，所述装置为分布式数据库系统的主副本节点设备，所述装置包括：

执行模块，用于响应于目标事务在所述主副本节点设备上的子事务，执行所述子事务对应的数据库操作；

检测模块，用于响应于所述目标事务的准备请求，对所述子事务进行数据异常检测；

提交模块，用于响应于所述目标事务的提交请求，提交所述子事务；

发送模块，用于将所述子事务的重做日志发送至对应的从副本节点设备，以使所述从副本节点设备在回放所述重做日志时重做所述子事务。

18.一种节点设备，其特征在于，所述节点设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条计算机程序，所述至少一条计算机程序由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求9或权利要求10至权利要求15任一项所述的事务处理方法。

19.一种存储介质，其特征在于，所述存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求9或权利要求10至权利要求15任一项所述的事务处理方法。

20.一种计算机程序产品，其特征在于，所述计算机程序产品包括至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求9或权利要求10至权利要求15任一项所述的事务处理方法。

Images