CN113704361A - 事务执行方法、装置、计算设备及存储介质 - Google Patents

Abstract

本申请公开了一种事务执行方法、装置、计算设备及存储介质，属于数据库技术领域。本申请通过对划分至本计算设备的目标事务，完成对目标事务所操作的所有主键记录和该主键记录对应的二级索引记录的处理，从而以单机事务的方式来提交目标事务，而无需采用2PC算法与其他计算设备进行多轮通信，并由存储设备对目标事务的提交日志进行异步回放即可实现数据落盘，例如，针对金融场景下发起转账、智慧交通场景下查询附近空闲停车位等事务，均可在计算设备中以单机事务方式提交，因此能够在保证数据一致性的前提下，大大提升分布式数据库系统的事务执行性能。

Description

事务执行方法、装置、计算设备及存储介质

技术领域

本申请涉及数据库技术领域，特别涉及一种事务执行方法、装置、计算设备及存储介质。

背景技术

随着数据库技术的发展，由于存储计算分离的分布式数据库系统能够满足高吞吐量的业务需求，逐渐成为一项研究热点。在存储计算分离的分布式数据库系统中，大部分事务都必须采用二阶段提交（Two Phase Commit，2PC）算法来确保数据库内在任一时刻下的数据记录都处于一致性状态。由于二阶段提交算法会大大降低事务执行的性能，因此，亟需一种能够提高分布式数据库系统的事务执行性能的方法。

发明内容

本申请实施例提供了一种事务执行方法、装置、计算设备及存储介质，能够提高分布式数据库系统的事务执行性能。该技术方案包括如下内容。

一方面，提供了一种事务执行方法，由分布式数据库系统中的计算设备执行，该方法包括：

响应于目标事务，获取所述目标事务所对应的至少一条数据记录，所述数据记录为主键记录或所述主键记录关联的二级索引记录；

基于所述目标事务，处理所述至少一条数据记录；

在提交所述目标事务时，生成所述目标事务的提交日志，以使所述分布式数据库系统中的存储设备对所述至少一条数据记录进行相同的处理。

一方面，提供了一种事务执行装置，所述装置位于分布式数据库系统中，该装置包括：

获取模块，用于响应于目标事务，获取所述目标事务所对应的至少一条数据记录，所述数据记录为主键记录或所述主键记录关联的二级索引记录；

处理模块，用于基于所述目标事务，处理所述至少一条数据记录；

生成模块，用于在提交所述目标事务时，生成所述目标事务的提交日志，以使所述分布式数据库系统中的存储设备对所述至少一条数据记录进行相同的处理。

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

第一确定单元，用于确定所述目标事务所对应的至少一个索引，所述索引为主键索引或二级索引；

查询单元，用于基于所述至少一个索引，从事务缓存区中查询得到所述至少一条数据记录。

在一种可能实施方式中，所述查询单元用于：

在所述至少一条数据记录全部缓存在所述事务缓存区中的情况下，基于所述至少一个索引，从所述事务缓存区中读取对应的所述至少一条数据记录；

在所述至少一条数据记录未全部缓存在所述事务缓存区中的情况下，从所述存储设备中将未缓存的数据记录读取到所述事务缓存区中；基于所述至少一个索引，从所述事务缓存区中读取对应的所述至少一条数据记录。

在一种可能实施方式中，所述获取模块还包括：

获取单元，用于获取所述事务缓存区的数据加载信息，所述数据加载信息用于记录所述事务缓存区中已缓存的数据记录；

第二确定单元，用于基于所述数据加载信息，确定所述至少一条数据记录是否全部缓存在所述事务缓存区中。

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

在所述目标事务中携带第一计算设备的哈希值的情况下，基于所述第一计算设备的哈希值，查询与所述第一计算设备对应的提交日志，所述第一计算设备为发生故障的计算设备；

对所述至少一条数据记录中的每条数据记录，在所述提交日志中包含所述数据记录的日志记录的情况下，从所述提交日志中读取所述数据记录；

在所述提交日志中不包含所述数据记录的日志记录的情况下，从所述数据记录所在的存储设备中读取所述数据记录。

在一种可能实施方式中，所述装置还包括：

第一确定模块，用于确定所述目标事务所对应的至少一条数据记录的分区列；

所述处理模块，还用于在所述至少一条数据记录的分区列与所述计算设备具有映射关系的情况下，由所述计算设备处理所述目标事务；

发送模块，用于在所述至少一条数据记录的分区列与所述计算设备不具有映射关系的情况下，将所述目标事务转发至第二计算设备，所述第二计算设备与所述至少一条数据记录的分区列具有映射关系。

在一种可能实施方式中，所述分布式数据库系统中的多个计算设备与多个哈希值一一对应，所述装置还包括：

第二确定模块，用于在所述计算设备的哈希值大于所述至少一条数据记录的分区列的哈希值，且与所述至少一条数据记录的分区列的哈希值最接近的情况下，确定所述至少一条数据记录的分区列与所述计算设备具有映射关系。

在一种可能实施方式中，对所述至少一条数据记录中的任一条数据记录，在所述数据记录的键值对中的键值后增加所述数据记录的分区列。

在一种可能实施方式中，所述装置还包括：

接收模块，用于接收所述分布式数据库系统中第三计算设备发送的数据加载请求，所述数据加载请求用于加载所述计算设备中已缓存的至少一条目标数据记录；

加锁标记模块，用于对所述至少一条目标数据记录加锁，将所述至少一条目标数据记录标记为失效状态；

发送释放模块，用于将所述至少一条目标数据记录发送至所述第三计算设备，释放所述至少一条目标数据记录的锁资源。

在一种可能实施方式中，所述分布式数据库系统在符合目标条件时新增计算设备；其中，所述目标条件包括下述至少一项：接收到对计算设备的新增指令；或，所述分布式数据库系统中任一计算设备的计算负载超过负载阈值；或，所述分布式数据库系统中任一计算设备的故障时长超过时长阈值。

在一种可能实施方式中，在所述目标条件包括所述分布式数据库系统中任一计算设备的计算负载大于负载阈值的情况下，新增的计算设备的哈希值小于第一哈希值且大于第二哈希值，所述第一哈希值为计算负载大于负载阈值的计算设备的哈希值，所述第二哈希值为所述分布式数据库系统中原本小于所述第一哈希值且与所述第一哈希值最接近的哈希值。

在一种可能实施方式中，新增的计算设备为虚拟计算设备，且所述虚拟计算设备关联于所述分布式数据库系统的目标计算设备。

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

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

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

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

通过对划分至本计算设备的目标事务，获取该目标事务对应的至少一条数据记录，该至少一条数据记录包括目标事务所操作的所有主键记录和该主键记录对应的二级索引记录，使得能够在分布式数据库系统中的单个计算设备中，完成对目标事务所操作的所有主键记录和该主键记录对应的二级索引记录的处理，从而以单机事务的方式来提交目标事务，而无需采用2PC算法与其他计算设备进行多轮通信，并由存储设备对目标事务的提交日志进行异步回放即可实现数据落盘，能够在保证数据一致性的前提下，大大提升分布式数据库系统的事务执行性能。

附图说明

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

图1是本申请实施例提供的一种分库分表架构的分布式数据库系统的示意图；

图2是本申请实施例提供的一种存储计算分离的非分库分表架构的分布式数据库系统的示意图；

图3是本申请实施例提供的一种分布式数据库系统的实施环境示意图；

图4是本申请实施例提供的一种事务执行方法的流程图；

图5是本申请实施例提供的一种一致性哈希算法的原理性示意图；

图6是本申请实施例提供的一种数据记录的数据结构的原理图；

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

图8是本申请实施例提供的一种事务执行方法的交互流程图；

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

图10是本申请实施例提供的一种一致性哈希算法的原理性示意图；

图11是本申请实施例提供的一种事务执行装置的结构示意图；

图12是本申请实施例提供的一种计算设备的结构示意图；

图13是本申请实施例提供的一种计算设备的结构示意图。

具体实施方式

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

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

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

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

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

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

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

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

计算设备：即计算节点或计算引擎节点，是指数据库（通常指集群数据库，对于单机数据库来说单机设备本身就是一个计算设备）中用来处理用户特定计算请求（简称用户请求），并主要负责执行用户请求的节点设备，亦可称为SQL引擎（SQL Engine），其中，SQL的英文全称为Structured Query Language，中文全称为结构化查询语言。

可选地，用户请求包括DML（Data Manipulate Language，数据操纵语言）请求和DDL（Data Definition Language，数据定义语言）请求等，通常DML请求是指业务请求，例如业务请求为查询请求，在金融场景下，如查询账户余额，在智慧交通场景下，如查询附近空闲停车位。

存储设备：即存储节点或存储引擎节点（Storage Engine），是指数据库中用来处理存储数据记录，并完成分布式事务（Transaction）执行与提交的节点。

计算存储设备：即计算存储节点，是指数据库中既能够处理用户请求，也能够存储数据记录，并完成分布式事务执行与提交的节点，相当于一个全功能的数据库节点。

事务缓存区：即事务Cache（高速缓冲存储区，简称高速缓存），在本申请实施例提出的一种专门用于缓存事务执行过程中的数据记录各种更新后可用版本的缓存区，在分布式数据库系统中的每个计算设备上均在内存中开辟了事务缓存区。

在分布式数据库系统中的多个计算设备上启动事务Cache功能，能够大大提升事务执行的性能，同时还支持基于每个计算设备的负载情况，动态调整事务Cache中已缓存的各个事务的容量，即，将当前较为繁忙的计算设备中部分事务迁移到较为空闲的计算设备上执行，达到整个数据库系统中计算设备间的负载均衡。

二阶段提交（Two Phase Commit，2PC）：2PC算法是一种经典的强一致性、中心化的原子提交协议，是在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有计算设备在进行事务提交时保持一致性而设计的一种算法。

事务的ACID：是指数据库管理系统（Data Base Management System，DBMS）在写入或更新数据记录的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

预写日志系统（Write-Ahead Logging，WAL）：数据库中一种高效的日志算法，对于非内存数据库而言，磁盘I（Input，输入）/O（Output，输出）操作是数据库效率的一大瓶颈。在相同的数据量下，采用WAL日志的数据库系统在事务提交时，磁盘写操作只有传统的回滚日志的一半左右，大大提高了数据库磁盘I/O操作的效率，从而提高了数据库的性能。

数据记录（Tuple）：通常是指关系型数据库中的数据表中的某一行数据记录，这个数据记录存储了数据表的定义中所有列的实例化信息，并按照列定义的顺序排列，组成一个连续的内容，也即是说，这段连续的内容被称为数据表的一条数据记录，即Tuple。

Linux虚拟服务器（Linux Virtual Server，LVS）：Linux虚拟服务器是一个虚拟的四层交换器集群系统，根据目标地址和目标端口实现用户请求的转发，本身不产生流量，只做用户请求转发，是目前负载均衡性能最好的集群系统，并且负载均衡实现了很好地可伸缩性，节点数目可增长到几千甚至几万。后期由许多用户参与开发LVS辅助工具和辅助组件，例如Alexandre（亚历山大）为LVS编写的Keepalived组件，Keepalived组件最初专门用于监控LVS，之后又加入VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）实现高可用功能。

一致性哈希算法（Consistent Hashing）：一致性哈希算法在1997年由麻省理工学院提出，是一种特殊的哈希算法，目的是解决分布式缓存的问题。在移除或者添加一个计算设备时，能够尽可能小地改变已存在的用户请求与处理用户请求的计算设备之间的映射关系。一致性哈希算法解决了简单哈希算法在分布式哈希表（Distributed Hash Table，DHT）中存在的动态伸缩等问题。

以下，将对分布式数据库系统的架构方式进行具体说明。

一、分布式数据库系统的分库分布架构

在一些分布式数据库系统中，采用的是分库分表架构。分库分表架构下，用户在定义数据表的SQL语句中设置好分布键（Key），通常使用数据表中的一个或多个列作为分布键，基于分布键提前将数据记录分布在不同的存储设备中。后续执行事务的时候，根据事务涉及的数据记录的分布，来决定如何路由到不同的分区来执行事务，因此，如果事务涉及的数据记录都位于同一个分区内，相当于事务从分布式事务转化为了单机事务，那么整个事务的执行就能够从2PC提交方式转化为单机事务提交方式。

图1是本申请实施例提供的一种分库分表架构的分布式数据库系统的示意图，如图1所示，分布式数据库系统100中包含计算集群110和计算存储集群120，计算集群110中包括多个计算设备，图1中仅示出了其中3个计算设备111~113，计算存储集群120中包含多个计算存储设备，图1中仅示出了其中4个计算存储设备121~124，其中，计算设备相当于计算节点，计算存储设备相当于计算存储节点。

在分库分表架构下，用户在对T1表（Table 1）进行定义的时候，需要预先定义好针对T1表的分库分表规则，使得T1表包含的数据记录按照该分库分表规则在所有的计算存储设备中分布。示意性地，T1表包含的数据记录会根据用户在创建T1表时指定的分库分表规则，分成T1-1、T1-2、T1-3、T1-4共4个分表，并将T1-1、T1-2、T1-3、T1-4这4个分表分布存储到上述计算存储设备121~124中。

上述计算集群110中的计算设备承担了两部分职责：a）部分计算功能，主要是指计算涉及到多个计算存储设备上的数据记录，且不能在单个计算存储设备上完成的那部分功能，例如Join（对数据库中两张或两张以上的数据表进行连接操作）、排序等操作；b）路由功能，在事务涉及的数据记录位于单个计算存储设备时，将该事务相应的事务语句分发到该计算存储设备来执行并完成事务，或者，在事务涉及的数据记录位于多个计算存储设备时，开启2PC算法并由计算设备开启协调者事务、多个计算存储设备开启参与者事务。

上述计算存储集群120中的计算存储设备相当于一个全功能的数据库节点。示意性地，在将T1表的T1-1、T1-2、T1-3、T1-4这4个分表分别存储到计算存储设备121~124中的情况下，某一时刻计算设备112接收到事务1，事务1所需要操作的数据记录位于T1-2分表中，因此计算设备112将事务1相关的查询语句发送到T1-2分表所在的计算存储设备122中，以使得计算存储设备122来完成事务1。示意性地，某一时刻计算设备113接收到事务2，事务2所需要操作的数据记录位于T1-3和T1-4分表中，因此整个事务2的执行需要经过计算设备113以2PC算法的方式来提交，即，计算设备113作为2PC算法的协调者，计算存储设备123和124作为2PC算法的参与者。

二、存储计算分离的非分库分表架构

上述分库分表架构中，存在一类计算存储设备作为全功能的数据库节点，既用于处理计算设备转发过来的用户请求相关的事务语句，又用于存储数据记录并进行事务的执行和提交，因此分库分表架构下并未实现存储计算分离。

在一些分布式数据库系统中，采用存储计算分离的非分库分表架构。在存储计算分离的非分库分表架构下，无需用户来关心如何划分数据表中数据记录的分区，而是由数据库存储引擎按照一定策略来划分数据表中数据记录的分区。

图2是本申请实施例提供的一种存储计算分离的非分库分表架构的分布式数据库系统的示意图，如图2所示，分布式数据库系统200中包含计算集群210和存储集群220，计算集群210中包含多个计算设备，图2中仅示出了其中3个计算设备211~213，存储集群220中包含多个存储设备，图2中仅示出了其中4个存储设备221~224，其中，计算设备相当于计算节点，存储设备相当于存储节点。

对比图1与图2可以看出，首先图2所示的存储计算分离的非分库分表架构中，不再包含计算存储设备，而是由计算设备来处理用户请求，存储设备来存储数据记录，因此能够实现存储计算的分离；其次图2所示的存储计算分离的非分库分表架构中，无需用户在对表进行定义时，设置对表的分库分表规则，用户只需要对表进行定义，数据库引擎按照一定策略将数据表中的数据记录划分至相同或不同的存储设备，例如，数据库引擎针对T1表，分成T1-1、T1-2、T1-3、T1-4共4个分表，并将T1-1、T1-2、T1-3、T1-4这4个分表分布存储到上述存储设备221~224中。

在存储计算分离的非分库分表架构下，虽然不需要用户关心如何划分数据表的分区，但是依然不能很好地控制采用2PC算法提交的分布式事务在系统事务中的总量，其中，是否采用2PC算法提交是根据事务执行涉及到的事务分布来决定的，即根据事务所操作的数据记录是否分布在多个存储设备来判断是否采用2PC算法提交，另外，针对事务的执行过程，存储计算分离架构也相对于存储计算一体架构（如分库分表架构）增加了计算设备和存储设备之间的通信开销，因此，在存储计算分离的非分库分表架构下，整个分布式数据库系统的吞吐能力受限。

综上所述，不管是分库分表架构的分布式数据库系统，还是存储计算分离的分布式数据库系统，由于在各类业务场景下分布式事务都是普遍存在的，比如金融场景下的异地转账等，因此大部分事务都必须采用2PC算法进行提交，来确保分布式事务的ACID，即确保数据库内在任一时刻下的数据记录都处于一致性状态。由于2PC算法需要在协调者和参与者之间进行多次通信，从而对分布式数据库系统的事务执行性能和吞吐性能带来不良影响。

有鉴于此，本申请实施例提供一种事务执行方法，能够通过在分布式数据库系统的计算设备上开辟事务缓存区（事务Cache），以在计算设备上实现事务Cache功能，以提升计算设备处理事务的吞吐能力，并且还能够方便地根据计算设备的负载，灵活地转移热点计算设备上的事务到相对空闲的计算设备上执行，最终在整个分布式数据库系统内实现动态负载均衡。

需要说明的是，本申请实施例涉及的分布式数据库系统，既能够像分库分表架构一样支持用户自定义表的分区，也能够像存储计算分离架构一样在用户没有指定划分方式的情况下，对表的分区进行智能划分。

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

在区块链系统中可以包括一条或多条区块链，区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。示意性地，在存储计算分离架构下，由各个已完成事务的提交日志作为账本数据构建区块链系统，在每个计算设备的事务缓存区中相对独立地包含一批次的网络交易信息（即提交日志），将网络交易信息上链之后由对应的各个存储设备通过链上的网络交易信息来追赶本地磁盘中数据记录的最新版本。

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

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

以下，对本申请实施例的实施环境进行说明。

图3是本申请实施例提供的一种分布式数据库系统的实施环境示意图。参见图3，分布式数据库系统300中包括LVS服务器301、代理服务器302、分布式计算集群303和分布式存储集群304，分布式计算集群303中包含多个计算设备（计算节点），分布式存储集群304中包含多个存储设备（存储节点），换言之，在分布式数据库系统300中能够实现存储计算分离的效果。

LVS服务器301是一个虚拟的四层交换器集群系统，根据目标地址和目标端口实现用户请求的转发，本身不产生流量，只做用户请求转发，即，LVS服务器301负责接收外部的应用客户端发送的用户请求，并将用户请求转发到代理服务器302。可选地，用户请求包括DML请求或者DDL请求等，通常DML请求是指业务请求，例如业务请求为查询请求，在金融场景下，如查询账户余额，在智慧交通场景下，如查询附近空闲停车位，本申请实施例对用户请求的内容不进行具体限定。

应用客户端和LVS服务器301能够通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

其中，应用客户端是指用户侧的终端上安装和运行的能够发起用户请求的客户端，可选地，应用客户端的类型包括但不限于：支付应用、社交应用、音视频应用、直播应用、购物应用、外卖应用或者打车应用等，本申请实施例不对应用客户端的类型进行具体限定。

在一些实施例中，用户侧的终端也称为用户设备、终端设备、用户终端、移动终端、智能终端、通信设备等。可选地，终端的设备类型包括：智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端、智能家电、智能语音交互设备等，但并不局限于此。

其中，LVS服务器301是目前负载均衡性能最好的集群系统，并且负载均衡实现了很好地可伸缩性，节点数目可增长到几千甚至几万。后期由许多用户参与开发LVS辅助工具和辅助组件，例如Alexandre为LVS编写的Keepalived组件，Keepalived组件最初专门用于监控LVS，之后又加入VRRP实现高可用功能。

需要说明的是，LVS服务器301并非是分布式数据库系统300中必须的节点，即，在分布式数据库系统300中也支持不设置LVS服务器301，而是直接由代理服务器302来接收外部的用户请求。

代理服务器302用于针对用户请求解析得到事务，并按照事务来进行数据记录的划分，并将事务路由到对应的计算设备去完成计算，上述划分过程是指：将事务涉及的数据记录划分至分布式计算集群303中对应的计算设备来进行处理，其中，数据记录包括主键记录和对应的二级索引记录。

可选地，上述划分过程的划分方式采用一致性哈希算法，为分布式计算集群303中的每个计算设备和分布式存储集群304中的每个存储设备都计算一个哈希值，同时，对每一个主键记录和对应的二级索引记录的分区列也计算一个哈希值，这样，只要主键记录和对应的二级索引记录共享相同的分区列，就能够保证主键记录和对应的二级索引记录具有相同的哈希值（哈希值是根据分区列计算的），从而能够保证将某事务涉及的主键记录和对应的二级索引记录路由到同一个计算设备中去完成计算，为消除2PC事务提供数据位置的基础保证。

在一些实施例中，代理服务器302中存储一个路由表，该路由表用于记录分区列和计算设备的映射关系，从而当确定某一事务操作的数据记录的分区列时，能够根据路由表查找并确定出负责处理该事务的计算设备，然后将该事务转发至该计算设备。

需要说明的是，代理服务器302可以是单独的物理机，或者，还能够与分布式计算集群303中的计算设备合并到同一物理机上，即，将代理服务器302的代理功能与计算设备的功能进行合并，在这种情况下，计算设备在发现新到的事务所操作的数据记录不在本计算设备的时候，需要分解出新的查询事务（查询对应范围的数据记录），并将新的查询事务转移到对应的计算设备中执行。

分布式计算集群303中包括多个计算设备，每个计算设备在接收到代理服务器302转发的事务之后，如果该事务所操作的数据记录全部都路由到了本计算设备，那按照单机事务的方式进行执行并提交，如果该事务所操作的数据记录路由到了多个计算设备，则仍需要按照2PC算法来进行执行并提交，以保证分布式事务的ACID和数据一致性。

每个计算设备的内存中都开辟有一个事务缓存区（即事务Cache），事务缓存区用于为将划分到本计算设备的事务（即用户负载）所涉及的数据记录提供缓存服务。由于事务缓存区的实际大小通常都（内存大小通常小于磁盘存储的大小）小于划分到本计算设备负责处理的事务所涉及的全部的数据记录，因此可采取数据淘汰机制，例如，针对已提交事务所操作的数据记录所占的存储空间，能够直接被其他未提交事务所操作的数据记录占用，即直接进行数据记录的覆盖，这是由于已提交事务在提交时已经向对应的存储设备内写入了提交日志，而已提交事务对数据记录的修改或操作都被记录在提交日志中，因此即使在事务缓存区中删除，也能够随时从对应存储设备的提交日志中读取到最新的修改或操作，从而能够保证数据一致性。

可选地，每个事务缓存区都维护有一个数据加载信息，该数据加载信息用于记录该事务缓存区中已缓存的数据记录，即，通过这一数据加载信息，能够方便、快速地确定出当前事务所操作的数据记录是否位于事务缓存区中，如果在事务缓存区中则直接从事务缓存区中读取，如果不在事务缓存区中则需要从分布式存储集群304中对应的存储设备中读取，例如，该数据加载信息采用Map数据结构，此时亦称为已加载数据Map。

在每个计算设备对分配到自身的事务执行并提交完毕之后，生成该事务的提交日志（Commit Log），并将提交日志转移到该事务所操作的数据记录在分布式存储集群304中对应的一个或多个存储设备上，以使得存储设备能够对计算设备针对数据记录的修改或操作进行同步更新。

分布式存储集群304中包括多个存储设备，每个存储设备中都配置有提交日志组件，该提交日志组件专门用于保存操作了本存储设备上存储的数据记录的事务的提交日志，提交日志组件和事务缓存区之间是一一对应的，以便于提升事务提交性能，降低本技术方案的实现复杂度。

在一些实施例中，代理服务器302采用一致性哈希算法，对分布式存储集群304中的每个存储设备都计算一个哈希值，从而通过哈希值之间的大小关系，也能够将存储设备与计算设备进行一一对应，建立了存储设备与计算设备的映射关系，可选地，该映射关系也可以存储于一张路由表中，以保证整个分布式数据库系统300的用户热点均衡和故障恢复功能的实现。

在建立了上述存储设备与计算设备的映射关系之后，在每个计算设备对自身事务缓存区中的任一事务提交时，只需要将针对本事务生成的提交日志发送到对应的存储设备的提交日志组件中，就能够完成事务的提交工作，使得后续存储设备能够异步对提交日志组件中存储的各条提交日志进行回放，以实现数据记录落盘（落盘完毕后可清理掉提交日志组件中的提交日志，以节约存储空间），达到存储、计算解耦的效果。

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

图4是本申请实施例提供的一种事务执行方法的流程图。参见图4，该实施例由分布式数据库系统中的计算设备执行，该实施例包括下述步骤。

401、计算设备响应于目标事务，获取该目标事务所对应的至少一条数据记录，该数据记录为主键记录或该主键记录关联的二级索引记录。

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

在一些实施例中，该用户请求是由用户通过应用客户端向分布式数据库系统发送的，示意性地，用户在终端上登录应用客户端，触发应用客户端生成该用户请求，调用API（Application Programming Interface，应用程序编程接口）将该用户请求发送至分布式数据库系统，比如，该API可以是MySQL API（一种关系型数据库系统提供的API）。

在一些实施例中，当分布式数据库系统中配置有LVS服务器和代理服务器时，LVS服务器接收应用客户端的用户请求，并将该用户请求转发至代理服务器。当代理服务器接收到任一请求时，解析该请求的头字段，当该头字段指示该请求为用户请求时，解析该用户请求的数据字段，得到该用户请求所对应的目标事务的SQL语句（或者，也可以是NoSQL请求，通常是Key-Value的访问）。

在一些实施例中，在代理服务器获取到目标事务的SQL语句之后，基于该SQL语句，确定该目标事务所对应的至少一条数据记录，并基于该至少一条数据记录的分区列，根据一致性哈希算法，将该目标事务划分至对应的计算设备来执行，在下一实施例中将详细介绍如何为事务分配用于执行该事务的计算设备，这里不再赘述。

需要说明的是，代理服务器无需读取该至少一条数据记录，只需要确定出该至少一条数据记录所属的数据处理范围，即可基于该数据处理范围来将目标事务划分对应的计算设备，示意性地，当该用户请求为查询请求时，在SQL语句中会携带一个查询条件，该查询条件中会指定待查询的数据处理范围，比如，在查询条件中指定一个主键范围和二级索引。

由于通常数据库中的一张用户表是由主键记录和二级索引记录共同组成的，其中，主键记录是指用户定义的数据表（即用户表）中每一行的各个字段数据即主键数据，因此，如果目标事务涉及到修改主键记录的某一字段，这一主键记录修改的字段如果涉及到二级索引的相应字段，那么数据库在执行该目标事务的时候，不但需要修改主键记录的指定字段，还需要同步修改该主键记录对应的二级索引记录的相应字段，才能够保证二级索引记录和主键记录的数据一致性。由于二级索引的Key和数据表的主键不是同一个字段，因此，如果代理服务器如果不能将主键记录和对应的二级索引记录划分到同一个计算设备中处理，那么目标事务就仍然是一个分布式事务，需要采用2PC算法提交，反之，代理服务器如果将主键记录和对应的二级索引记录划分到同一个计算设备中处理，由于在计算设备上开辟了事务缓存区，使得目标事务能够像单机事务一样在事务缓存区中以单机事务的方式进行提交（无需使用2PC算法提交），相当于将分布式事务转化成了单机事务，降低了采用2PC算法提交的分布式事务的总量，从而提升了整个分布式数据库系统的事务执行性能。

使用一致性哈希算法，能够尽量将目标事务涉及的主键记录和对应的二级索引记录作为一个整体联动划分到同一个计算设备的事务缓存区中，以在事务缓存区中采取单机事务的方式提交。但是，由于总是会存在一些目标事务涉及的数据记录会跨越多个计算设备，即采用2PC算法提交的分布式事务总是会存在的，例如，银行转账的跨省转账是一种典型的分布式事务，换言之，无论如何进行划分，上述分布式事务都无法在分布式数据库系统中完全消除，因此上述划分方式能够尽可能减少的分布式事务的数量，以将整个系统中的分布式事务的数量下降至最低，从而将分布式事务的2PC算法提交给整个系统带来的性能影响控制在最低，最终让整个系统的集群吞吐能力达到最大。

在代理服务器根据一致性哈希算法，将该目标事务划分至对应的计算设备来执行之后，相当于代理服务器从分布式计算集群中查找到与该目标事务具有映射关系的计算设备，这时只需要将目标事务路由到对应的计算设备上执行并提交即可完成计算，可选地，代理服务器将目标事务的SQL语句转发到对应的计算设备上，或者，代理服务器将用户请求转发到对应的计算设备上，本申请实施例对此不进行具体限定。

在上述过程中，介绍了用户请求如何从应用客户端产生，并经由LVS服务器、代理服务器，最终被分配到对应的计算设备上进行处理。在本申请实施例中，仅关注通过一致性哈希算法将分布式事务成功转化为单机事务的情况。由于LVS服务器在目前能够实现较好的负载均衡性能，且具有良好的可伸缩性，因此有利于整个系统的负载均衡，提高了整个系统的可拓展性。

在一些实施例中，分布式数据库系统中不设置LVS服务器，那么直接由代理服务器接收外部的用户请求，并将解析得到的目标事务划分至对应的计算设备，能够简化分布式数据库系统的架构，或者，将LVS服务器的功能集成到代理服务器中，本申请实施例对此不进行具体限定。

在一些实施例中，分布式数据库系统中不单独设置代理服务器，而是将代理服务器的功能集成到分布式计算集群的计算设备中，由计算设备来接收外部的用户请求，解析该用户请求得到目标事务，并判断该目标事务是否与本计算设备存在映射关系，即判断该目标事务是否应该路由到本地来进行处理。如果目标事务与本计算设备具有映射关系，则在本地的事务缓存区中拉取目标事务操作的所有数据记录，对各个数据记录执行目标事务所指示的处理，并以单机事务的方式提交目标事务。如果目标事务与本计算设备不具有映射关系，则需要将该目标事务转发到具有映射关系的另一计算设备（即第二计算设备）中完成计算。

对于计算设备来说，可能接收到的是原始的用户请求，如果系统内设置了代理服务器，则可能是代理服务器转发的，如果将代理服务器的功能集成在计算设备中，则计算设备直接接收应用客户端发送的用户请求，如果接收的是原始的用户请求，那么解析该用户请求，得到该目标事务的SQL语句。可选地，计算设备还有可能接收到的是代理服务器转发的目标事务的SQL语句（代理服务器已经对用户请求完成了解析）。

计算设备在获取到目标事务的SQL语句之后，需要获取该目标事务所对应的至少一条数据记录，这些数据记录是指目标事务涉及操作的全部的主键记录和对应的二级索引记录。计算设备将该至少一条数据记录存储到事务缓存区中，以保证目标事务能够在事务缓存区中以单机事务的方式提交。在后续的实施例中，将对计算设备如何获取该至少一条数据记录的过程进行详细说明，这里不做赘述。

402、计算设备基于该目标事务，处理该至少一条数据记录。

在一些实施例中，计算设备基于目标事务的SQL语句，创建一个进程或线程来处理该至少一条数据记录，或者，计算设备复用已创建的进程或线程来处理该至少一条数据记录，例如，若目标事务为查询事务，则创建或复用DML进程或线程来执行该查询事务。

由于用户表是由主键记录和二级索引记录共同组成的，因此计算设备在上述步骤401中获取到的该至少一条数据记录中，包括该目标事务所操作的所有主键记录和该主键记录关联的二级索引记录。计算设备基于该目标事务的SQL语句，处理该至少一条数据记录中的每一条数据记录时，如果当前处理的数据记录为主键记录，则需要对该主键记录关联的二级索引记录进行同样地处理，才能够保证数据一致性。

可选地，计算设备在处理该至少一条数据记录时，采用单个进程或线程对该至少一个数据记录进行串行处理，或者，计算设备采用多个进程或线程对该至少一个数据记录进行并行处理，这时需要为每个进程或线程初始化各自的并行任务，保证所有并行任务的执行完毕相当于目标事务执行完毕，本申请实施例不对目标事务是串行处理还是并行处理进行具体限定。根据目标事务的事务类型的不同，对数据记录进行的处理类型也不同，若目标事务为读事务，则只需要进行读操作，若目标事务为写事务，则需要进行读操作和写操作。

403、计算设备在提交该目标事务时，生成该目标事务的提交日志，以使该分布式数据库系统中的存储设备对该至少一条数据记录进行相同的处理。

当计算设备对该至少一条数据记录中的每一条数据记录都处理完毕之后，目标事务进行提交阶段，此时可将目标事务置为提交中状态，并生成该目标事务的提交日志（Commit Log），在对提交日志生成完毕之后，将该目标事务置为已提交状态，在存储计算分离架构下只要提交日志生成完毕，就代表目标事务已经提交完成，此后，计算设备将提交日志转移到该至少一条数据记录在分布式存储集群中对应的一个或多个存储设备中进行异步回放，在各个存储设备中对该提交日志回放完毕时，才代表已经将该目标事务操作的真实数据落盘，也即是说，目标事务的提交和真实数据的修改之间是异步实现的，与WAL系统的概念类似，由于实现了事务缓存区中的事务提交和真实的存储设备数据的修改之间解耦，能够大大提升分布式数据库系统的事务提交性能。

在一些实施例中，计算设备将上述步骤403生成的提交日志（包括重做日志RedoLog和回滚日志Undo Log），发送到分布式存储集群中对应的一个或多个存储设备的提交日志组件，可选地，计算设备与存储设备之间也通过一致性哈希算法建立映射关系，使得能够基于该映射关系，确定出与该计算设备对应的存储设备。

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

本申请实施例提供的方法，通过对划分至本计算设备的目标事务，获取该目标事务对应的至少一条数据记录，该至少一条数据记录包括目标事务所操作的所有主键记录和该主键记录对应的二级索引记录，使得能够分布式数据库系统中的单个计算设备中，完成对目标事务所操作的所有主键记录和该主键记录对应的二级索引记录的处理，从而以单机事务的方式来提交目标事务，而无需采用2PC算法与其他计算设备进行多轮通信，并由存储设备对目标事务的提交日志进行异步回放即可实现数据落盘，能够在保证数据一致性的前提下，大大提升分布式数据库系统的事务执行性能。

在上个实施例中提到的一致性哈希算法，既能够实现将目标事务划分至某一计算设备，还能够实现建立计算设备与存储设备的映射关系，两者之间的原理是相同的，下面将对一致性哈希算法进行简要说明，以方便理解本申请实施例的基础数据结构和算法实现。

图5是本申请实施例提供的一种一致性哈希算法的原理性示意图，如图5所示，以分布式计算集群中包含4个计算设备501~504为例，代理服务器通过哈希算法，对每个计算设备都计算出一个唯一的哈希值，保证计算设备和哈希值之间一一对应，图5中计算设备501~504各自指向的较大的圆点511~514分别代表了各自的哈希值，其中，圆圈上的数值大小按照顺时针递增，即，计算设备501的哈希值511最小，计算设备504的哈希值514最大。此外，在每一条数据记录的数据结构中增加一个分区列的信息，对每一条数据记录的分区列也计算一个唯一的哈希值，图5中分区列505~506各自指向的较小的圆点515~516分别代表了各自的哈希值。在一致性哈希算法的约束下，对每一条数据记录来说，基于该数据记录的分区列的哈希值，在分布式计算集群中所有计算设备的哈希值中，找到第一个比该分区列的哈希值大的目标哈希值（即大于该分区列的哈希值且最接近该分区列的哈希值），将该数据记录划分至目标哈希值所对应的计算设备。

经分析知，对于目标事务来说，在保证每条主键记录和本主键记录关联的二级索引记录共享相同的分区列的基础上，由于目标事务可能会操作多条主键记录，只需要控制目标事务所操作的所有主键记录的分区列的哈希值位于任意两个相邻的计算设备的哈希值所构成的取值区间内，就能够将该目标事务所操作的所有主键记录和该主键记录对应的二级索引记录分配到同一个计算设备，从而将目标事务从2PC算法提交转化为单机事务提交。

下面将对本申请实施例中数据记录的数据结构进行说明，通过引入数据记录的分区列，是为了能够将二级索引记录和其关联的主键记录整体划分到同一个计算设备中，以尽可能多的消除掉分布式数据库系统中以2PC算法提交的分布式事务的数量。

图6是本申请实施例提供的一种数据记录的数据结构的原理图，如600所示，假设每条数据记录都以键值对（Key-Value）格式存储。对于主键记录，会将主键索引（PrimaryKey）和字段数据（Value）对应存储，在引入分区列时，需要在字段数据（Value）后面增加一个分区列。同理，对于二级索引记录，会将二级索引（Key）和字段数据（Value）对应存储，在引入分区列时，需要在字段数据（Value）后面增加一个分区列。其中，分区列是指数据记录中的一列或者多列的组合。

可选地，任一主键记录和该主键记录关联的二级索引记录具有相同的分区列，使得每个主键记录和其关联的二级索引记录计算出与分区列相关的一个相同的哈希值，对于待执行的目标事务，只需要保证目标事务所操作的所有主键记录的分区列的哈希值位于同一取值区间内，就能够实现将主键记录和二级索引记录同步划分至单一的计算设备。

在一些实施例中，采用主键索引作为分区列，由于二级索引记录中的最后一部分本身就会包含主键索引，用于在需要的时候通过二级索引记录来定位到主键记录，此时如果采用主键索引作为分区列，则无需额外增加分区列。在一些实施例中，也可以不采用主键索引作为分区列，本申请实施例对此不作具体限定。

通过对每一条数据记录增加分区列，能够更好地通过用户运行时对事务中涉及的数据记录进行关联学习，即根据用户业务使用数据记录的特性，更好地为用户的数据记录进行计算设备的划分。可选地，增加分区列的操作，可由计算设备上的事务缓存区在执行过程中动态为数据记录进行指定，通常伴随着事务对数据记录的增加、删除、修改操作而一起进行，因此不会额外增加系统的负担，能够为整个系统达到动态高效率调整负载提供坚实基础。

在上述一致性哈希算法和对数据记录增加分区列的基础上，还需要对每个计算设备增加一个事务缓存区，利用事务缓存区对事务所操作的数据记录的缓存与动态平衡，使得2PC算法提交的分布式事务在整个分布式系统中的数量降到最低。对每个计算设备的事务缓存区，可增加一个额外的配置参数：缓存区尺寸Trx_Cache_size (M,G)，该配置参数用于控制每个计算设备中的事务缓存区所使用内存的大小。可选地，分布式计算集群中每个计算设备具有相同的缓存区尺寸Trx_Cache_size (M,G)，或者，分布式计算集群中不同计算设备具有不同的缓存区尺寸Trx_Cache_size (M,G)，本申请实施例对此不进行具体限定。以MySQL数据库为例，可通过show global variable like '%cache_size%' 语句来在控制台上显示该配置参数。

图7是本申请实施例提供的一种事务执行方法的交互流程图，如图7所示，本申请实施例中，将对分布式数据库系统内部不同集群之间信息交互流程进行详细说明。

701、LVS服务器接收应用客户端的用户请求，将该用户请求转发至代理服务器。

该用户请求包括DDL请求和DML请求，DML请求是指业务请求，例如查询请求是一种典型的业务请求，在金融场景下，该查询请求为查询余额、查询流水等，在智慧交通场景下，该查询请求为查询附近空闲停车位、查询目的地附近的路况等，本申请实施例不对用户请求的内容进行具体限定。

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

在一些实施例中，分布式数据库系统通过LVS服务器接收应用客户端的用户请求，并将该用户请求转发至代理服务器。由于LVS服务器在目前能够实现较好的负载均衡性能，且具有良好的可伸缩性，因此有利于整个系统的负载均衡，提高了整个系统的可拓展性。

在一些实施例中，分布式数据库系统中不设置LVS服务器，那么直接由代理服务器接收外部的用户请求，执行下述步骤702，能够简化分布式数据库系统的架构，或者，将LVS服务器的功能集成到代理服务器中，本申请实施例对此不进行具体限定。

702、代理服务器解析该用户请求，得到目标事务。

当代理服务器接收到任一请求时，解析该请求的头字段，当该头字段指示该请求为用户请求时，解析该用户请求的数据字段，得到该用户请求所对应的目标事务的SQL语句（或者，也可以是NoSQL请求，通常是Key-Value的访问）。

在代理服务器获取到目标事务的SQL语句之后，基于该SQL语句，确定该目标事务所对应的至少一条数据记录，并基于该至少一条数据记录的分区列，根据一致性哈希算法，将该目标事务划分至对应的计算设备来执行，请参考下述步骤703-704。

703、代理服务器确定该目标事务所对应的至少一条数据记录的分区列。

由于用户表是由主键记录和二级索引记录共同组成的，因此计算设备在上述步骤703所描述的该至少一条数据记录，包括该目标事务所操作的所有主键记录和该主键记录关联的二级索引记录。例如，用户请求为转账请求，在SQL语句中携带了转账操作的发起人账号ID（Identification，标识）和收款人账号ID，即转账事务涉及到操作2条主键记录：将发起人的用户表中新增一条扣除转账金额的记录，并在收款人的用户表中新增一条增加转账金额的记录，由于上述2条主键记录可能会存在相关联的二级索引记录，比如，二级索引的key为地区和账户余额时，如果发起人和收款人都在北京市，那么需要在这条二级索引记录中同步更新发起人和收款人各自的账户余额，因此目标事务实际操作的数据记录的数量不仅仅是2条主键记录，还需要在主键记录关联的二级索引记录中进行同步更新。

在一些实施例中，在分布式数据库系统中的每一条数据记录都以键值对（Key-Value）格式存储，则在每一条数据记录的键值对中的键值（Value）后增加该数据记录的分区列，键值对格式的数据结构参见图6。由于该至少一条数据记录都是存储在分布式数据库系统中的，因此相当于对该至少一条数据记录中的任一条数据记录，在该数据记录的键值对中的键值后增加该数据记录的分区列。其中，分区列是指数据记录中的一列或者多列的组合。

可选地，如果数据记录是主键记录，在传统的数据结构中，主键索引（PrimaryKey）和字段数据（Value）对应存储，在引入分区列时，需要在字段数据（Value）后面增加一个分区列。

可选地，如果数据记录是二级索引记录，在传统的数据结构中，会将二级索引（Key）和字段数据（Value）对应存储，在引入分区列时，需要在字段数据（Value）后面增加一个分区列。

在上述过程中，通过增加分区列，能够对每个主键记录和二级索引记录都计算一个与分区列相关的哈希值，可选地，每个主键记录和该主键记录关联的二级索引记录具有相同的分区列，使得每个主键记录和其关联的二级索引记录计算出的哈希值相同，此时只需要保证目标事务所操作的所有主键记录的分区列的哈希值位于同一取值区间内，就能够在一致性哈希算法的约束下，实现将主键记录和二级索引记录同步划分至单一的计算设备。

在一些实施例中，如果采用主键索引作为每条数据记录的分区列，由于主键记录中自身包含有主键索引，而二级索引记录中的最后一部分本身就会包含主键索引，用于在需要的时候通过二级索引记录来定位到主键记录，因此在这种特定情况下，主键记录和二级索引记录都不需要在数据结构中额外增加分区列。

在一些实施例中，如果采用数据记录中除了主键索引之外的一列或者多列的组合作为分区列，那么需要在每一条数据记录的字段数据（Value，即键值对中的键值）后面增加一个分区列，本申请实施例不对分区列的内容进行具体限定。

在上述数据结构的基础上，代理服务器基于目标事务的SQL语句，能够确定出目标事务所涉及操作的该至少一条数据记录，比如，SQL语句中直接指定操作的主键ID，此时能够直接定位到该主键ID对应的主键记录，接着，从定位到的主键记录的数据结构中，读取到该主键记录的分区列（该主键记录关联的二级索引记录具有相同的分区列，无需重复执行确定二级索引记录的分区列的步骤），对SQL语句中指定的所有主键ID重复执行上述流程，即可完成对所有数据记录的分区列的获取步骤。

在一些实施例中，目标事务的SQL语句并不会直接指定目标事务所涉及操作的该至少一条数据记录，而是会指定目标事务所涉及操作的数据记录所属的数据处理范围，这时，代理服务器可基于该数据处理范围，确定出位于该数据处理范围内的数据记录的分区列区间（需要保证数据记录的分区列是随着主键ID单调递增的）。比如，谓词读事务的SQL语句中携带查询条件，该查询条件用于指定待查询的主键范围和二级索引，由于数据记录的分区列是随着主键ID单调递增的，只需要读取主键范围中具有最大主键ID的主键记录的分区列，和具有最小主键ID的主键记录的分区列，即可确定出上述分区列区间。可选地，如果经过哈希计算后无法保证数据记录的分区列随着主键ID单调递增，只需要构建出分区列和计算设备对应的路由表，从而基于谓词读事务的SQL语句中携带的查询条件中的主键范围，与路由表中存储的分区列对应的主键范围进行计算，即可确定该谓词读事务是否会涉及到路由表命中的分区列对应的某一个或多个计算设备，这种情况相较于数据记录的分区列随着主键ID单调递增的情况，会在路由表上消耗略多的存储资源，并在计算时会多用一些计算资源，但对分区列的取值无需要求单调递增因此对分区列的计算要求较低。

在一些实施例中，如果以主键索引作为分区列，由于不会在数据结构中增加分区列，这时，针对主键记录直接提取主键索引即可得到主键记录的分区列，同理，针对二级索引记录直接提取二级索引记录的最后一部分即可得到二级索引记录的分区列，可选地，如果二级索引以B+树结构存储，会将主键值按顺序存储在叶子结点中，如果二级索引以Key-Value结构存储，会将主键值接在二级索引的Key后面来唯一决定一个Key-Value对，因此不管是B+树结构还是Key-Value结构，二级索引记录的最后一部分（叶子结点或最后一个字段）都会关联到对应的主键记录。

通过对每一条数据记录增加分区列，能够更好地通过用户运行时对事务中涉及的数据记录进行关联学习，即根据用户业务使用数据记录的特性，更好地为用户的数据记录进行计算设备的划分，将在下述步骤704中说明。可选地，增加分区列的操作，可由计算设备上的事务缓存区在执行过程中动态为数据记录进行指定，通常伴随着事务对数据记录的增加、删除、修改操作而一起进行，因此不会额外增加系统的负担，能够为整个系统达到动态高效率调整负载提供坚实基础。

704、代理服务器将该目标事务发送至与该至少一条数据记录的分区列具有映射关系的计算设备。

可选地，代理服务器基于一致性哈希算法，为分布式计算集群中的每个计算设备都计算一个哈希值，并保证计算设备与哈希值之间一一对应。此外，对每一个主键记录和其关联的二级索引记录的分区列也计算一个哈希值，这样，只要主键记录和其关联的二级索引记录共享相同的分区列，就能够保证主键记录和对应的二级索引记录具有相同的哈希值（哈希值是根据分区列计算的），从而能够主键记录和其关联的二级索引记录路由到同一个计算设备中去完成计算。

在一些实施例中，代理服务器基于上述步骤703中确定的该至少一条数据记录的分区列，获取该至少一条数据记录的分区列的哈希值，接着，对该至少一条数据记录中每一条数据记录，在分布式计算集群中所有计算设备的哈希值中，找到第一个比该数据记录的分区列的哈希值大的目标哈希值（即大于该数据记录的分区列的哈希值且最接近该数据记录的分区列的哈希值），将该数据记录划分至目标哈希值所对应的计算设备，即，将目标哈希值所对应的计算设备确定为与该数据记录的分区列具有映射关系的计算设备。对该至少一条数据记录中每一条数据记录，重复执行上述操作，如果该至少一条数据记录中的所有数据记录都映射至同一个计算设备，代表目标事务能够由分布式事务转化为单机事务，将目标事务发送到与该至少一条数据记录的分区列具有映射关系的计算设备，而无需采用2PC算法进行全局提交，执行下述步骤705；如果该至少一条数据记录中存在任意至少两个数据记录映射到了两个或两个以上的计算设备，那么仍然需要采用2PC算法进行分布式事务的执行和提交。

可选地，在上述过程中，对每一条数据记录确定目标哈希值时，假设分布式数据库系统中包含多个计算设备，该多个计算设备一一对应于多个哈希值，在该多个哈希值中，确定大于当前的该数据记录的分区列的哈希值的至少一个哈希值，将该至少一个哈希值中最小的哈希值确定为当前的数据记录对应的目标哈希值。

可选地，在上述过程中，对每一条数据记录确定目标哈希值时，假设分布式数据库系统中包含多个计算设备，该多个计算设备一一对应于多个哈希值，将该多个哈希值和当前的该数据记录的分区列的哈希值一起按照从小到大的顺序进行排序，将在排序中位于当前的该数据记录的分区列的哈希值的下一个哈希值确定为当前的数据记录对应的目标哈希值。

可选地，在上述过程中，对每一条数据记录确定目标哈希值时，假设分布式数据库系统中包含多个计算设备，该多个计算设备一一对应于多个哈希值，将该多个哈希值和当前的该数据记录的分区列的哈希值一起按照从大到小的顺序进行排序，将在排序中位于当前的该数据记录的分区列的哈希值的上一个哈希值确定为当前的数据记录对应的目标哈希值。

在一些实施例中，代理服务器中预先存储一个路由表，该路由表用于记录分区列和计算设备的映射关系，从而当基于上述步骤703确定出目标事务所涉及操作的至少一条数据记录的分区列时，能够根据路由表快速查找并确定出负责处理该目标事务的计算设备（即与该目标事务所涉及操作的至少一条数据记录的分区列具有映射关系的计算设备），然后将该目标事务转发至路由表中查询得到的该计算设备。

在一些实施例中，由于数据记录的分区列可能会随着事务对数据记录的增加、删除、修改操作而动态变化，因此在该路由表中仅存储各个计算设备的哈希值，从而在基于上述步骤703确定出目标事务所涉及操作的至少一条数据记录的分区列之后，计算出该至少一条数据记录的分区列的哈希值，在路由表中查找并确定出负责处理该目标事务的计算设备（即与该目标事务所涉及操作的至少一条数据记录的分区列具有映射关系的计算设备），然后将该目标事务转发至路由表中查询得到的该计算设备。

705、计算设备响应于目标事务，获取事务缓存区的数据加载信息，该数据加载信息用于记录该事务缓存区中已缓存的数据记录。

可选地，在分布式计算集群中每个计算设备的内存中开辟一个事务缓存区，事务缓存区所占的内存大小取决于配置参数Trx_Cache_size (M,G)。在启动事务缓存区时，需要确认底层数据记录的数据结构（即底层数据存储格式），使用存储引擎来构造并初始化相应的缓存存储结构，这里需要保证两者的存储结构是相匹配的。

可选地，对每个计算设备中的事务缓存区都维护有一个数据加载信息，该数据加载信息用于记录该事务缓存区中已缓存的数据记录，可选地，该数据加载信息和配置参数Trx_Cache_size (M,G)都存储在事务缓存区，如果事务缓存区崩溃，即事务缓存区中加载的数据记录都丢失，只需要在计算设备重启之后，根据后续事务的需求，重新生成一个新的数据加载信息即可。

可选地，该数据加载信息采用Map数据结构（即动态数组），此时亦称为已加载数据Map，已加载数据Map中记录事务缓存区中已缓存的各个数据记录的索引，其中，如果缓存的是主键记录，则添加主键索引到已加载数据Map中，如果是二级索引记录，则添加二级索引到已加载数据Map中，或者，也可以采用其他数据结构：哈希表、队列、堆栈、位图等。

通过这一数据加载信息，能够方便、快速地确定出目标事务所操作的该至少一条数据记录中的每一条数据记录是否位于本计算设备的事务缓存区中，遍历目标事务所操作的全部数据记录，即能够确定出该至少一条数据记录是否全部缓存在该事务缓存区中，详细请参考下述步骤706。

由于事务缓存区中缓存的各个数据记录，实际上都是从底层的存储设备中读取上来的，为事务缓存区维持该数据加载信息，能够快速知道哪些数据记录被加载到了事务缓存区中，哪些数据记录仍在存储设备中持久化存储。由于事务缓存区的大小通常小于本计算设备负责处理的全量数据记录的数据量，代表事务缓存区通常无法存放本计算设备负责处理的全量数据记录，即只能加载全量数据记录中的一部分到事务缓存区中，通过维护数据加载信息，不用每次在读取目标事务所操作的至少一条数据记录时，都访问底层的存储设备，能够快速、方便地发现哪些能够从事务缓存区中直接读到，哪些需要从存储设备中加载，也能够避免漏读数据记录所带来的查询数据性能的下降，并且，由于所有的针对数据记录的读取、删除、修改等操作都是从事务缓存区中执行的，因此也不会出现没有获取到最新数据记录的情况。

进一步的，为了提高事务缓存区的服务能力，单次仅加载一小部分数据记录，以满足当前事务的处理需求，在通过数据加载信息记录了已加载的数据记录的范围之后，如果后续事务需要处理的数据记录存在一部分不在数据加载信息所记录的范围中，才需要继续到底层存储设备中读取到。

706、计算设备基于该数据加载信息，确定该至少一条数据记录是否全部缓存在该事务缓存区中。

在一些实施例中，计算设备基于该目标事务的SQL语句，确定该目标事务所对应的至少一个索引，遍历该数据加载信息，对该至少一个索引中的任一索引，如果在该数据加载信息中能够命中任一元素，说明该索引对应的数据记录位于事务缓存区中，如果在该数据记载信息中不能命中所有元素，说明该索引对应的数据记录不位于事务缓存区中，遍历该目标事务所对应的所有索引，从而能够确定该目标事务所对应的该至少一条数据记录是否全部缓存在事务缓存区中。

707、计算设备在该至少一条数据记录全部缓存在该事务缓存区中的情况下，基于该目标事务所对应的至少一个索引，从该事务缓存区中读取对应的该至少一条数据记录。

其中，该索引为主键索引或二级索引，该数据记录为主键记录或该主键记录关联的二级索引记录，通过主键索引能够定位到对应的主键记录，通过二级索引能够定位到对应的二级索引记录。

在一些实施例中，由于事务缓存区中缓存的各条数据记录，都是从底层的存储设备中读取上来的，因此，在将数据记录从底层的存储设备中读取到事务缓存区之后，需要针对读取上来的数据记录（包括主键记录和二级索引记录）进行重新组织，相当于对划分至本计算设备的数据记录，建立一个与原表相关的子表，在子表中记录划分至本计算设备的数据记录。可选地，针对主键记录，可按照对应的存储引擎，在事务缓存区中按照主键ID进行顺序排列。可选地，针对二级索引记录，可按照二级索引的结构，利用属于本事务缓存区的数据记录，组成新的局部二级索引结构。上述在事务缓存区中对主键记录和二级索引记录的重新组织，相当于对划分至本计算设备的数据记录，在该事务缓存区中进行了一次数据记录的重分布。

如果在上述步骤706中，计算设备确定该至少一条数据记录全部缓存在事务缓存区中，那么基于该至少一个索引，从该事务缓存区中直接读取对应的该至少一条数据记录，而无需访问任何底层的存储设备，能够加快目标事务的执行性能。可选地，对该至少一个索引中的任一索引，如果在该事务缓存区中能够命中任一条数据记录，则读取被该索引命中的数据记录，如果是主键索引，则命中的是主键记录，如果是二级索引，则命中的是二级索引记录，遍历该目标事务所对应的所有索引，从而能够基于该至少一个索引，从该事务缓存区中查询得到该至少一条数据记录。

上述步骤707介绍了该至少一条数据记录全部缓存在事务缓存区中的情况下的处理，在一些实施例中，在该至少一条数据记录未全部缓存在该事务缓存区中的情况下，计算设备从存储设备中将未缓存的数据记录读取到该事务缓存区中，再执行基于该至少一个索引，从该事务缓存区中读取对应的该至少一条数据记录的步骤，与上述过程同理，这里不作赘述。在上述过程中，同样可以基于一致性哈希算法，来将每条数据记录划分至对应的存储设备，与上述步骤704类似，或者，还可以基于一致性哈希算法，建立存储设备和计算设备两者之间的映射关系，从而先定位到与本计算设备具有映射关系的一个或多个存储设备，然后查询该一个或多个存储设备中每个存储设备所存储的数据记录的主键范围，从而根据未缓存的数据记录的主键范围，查询未缓存的数据记录所在的存储设备（同样可以是一个或多个）。

在上述步骤705-707中，示出了计算设备响应于目标事务，获取该目标事务所对应的至少一条数据记录的一种可能实施方式，其中，该数据记录为主键记录或该主键记录关联的二级索引记录。

在另一些实施例中，计算设备基于该目标事务所对应的至少一个索引，遍历该数据加载信息，对该至少一个索引中的任一索引，如果在该数据加载信息中能够命中任一元素，说明该索引对应的数据记录位于事务缓存区中，从事务缓存区中按照该索引来查询得到对应的数据记录；如果在该数据记载信息中不能命中所有元素，说明该索引对应的数据记录不位于事务缓存区中，则需要在分布式存储集群中确定该索引对应的数据记录所在的存储设备，在从该存储设备中拉取该索引对应的数据记录到事务缓存区，然后再进行读取。

708、计算设备基于该目标事务，处理该至少一条数据记录。

上述步骤708与上述步骤402类似，这里不做赘述。

709、计算设备提交该目标事务。

当计算设备对该至少一条数据记录中的每一条数据记录都处理完毕之后，目标事务进行提交阶段，此时可将目标事务置为提交中状态，并生成该目标事务的提交日志（Commit Log），在对提交日志生成完毕之后，将该目标事务置为已提交状态，在存储计算分离架构下只要提交日志生成完毕，就代表目标事务已经提交完成，此后，计算设备将提交日志转移到该至少一条数据记录在分布式存储集群中对应的一个或多个存储设备中进行异步回放，在各个存储设备中对该提交日志回放完毕时，才代表已经将该目标事务操作的真实数据落盘，也即是说，目标事务的提交和真实数据的修改之间是异步实现的，与WAL系统的概念类似，由于实现了事务缓存区中的事务提交和真实的存储设备数据的修改之间解耦，能够大大提升分布式数据库系统的事务提交性能。

710、计算设备生成该目标事务的提交日志。

其中，该提交日志用于使得该分布式数据库系统中的存储设备对该至少一条数据记录进行相同的处理。

计算设备可基于对目标事务的该至少一条数据记录的每一步处理，生成该目标事务的提交日志，可选地，根据目标事务是否提交成功，可将提交日志划分为重做日志和回滚日志，当目标事务提交成功时，生成的提交日志称为重做日志，存储设备基于重做日志可实现对目标事务对该至少一条数据记录所执行的处理进行重做，当目标事务提交失败时，生成的提交日志称为回滚日志，存储设备基于回滚日志能够将自身存储的数据记录回滚到某个版本。

711、计算设备将该提交日志发送至该至少一条数据记录所对应的存储设备。

在一些实施例中，基于一致性哈希算法，来将每条数据记录划分至对应的存储设备，即，为分布式存储集群中的每个存储设备都计算一个哈希值，并保证存储设备与哈希值之间一一对应。此外，对每一个主键记录和其关联的二级索引记录的分区列也计算一个哈希值，这样，只要主键记录和其关联的二级索引记录共享相同的分区列，就能够保证主键记录和对应的二级索引记录具有相同的哈希值（哈希值是根据分区列计算的），从而能够主键记录和其关联的二级索引记录路由到同一个存储设备中去完成数据落盘。对每一条数据记录选择其路由的存储设备的过程，与上述步骤704中对每一条数据记录选择其路由的计算设备的过程类似，这里不再赘述。

在一些实施例中，基于一致性哈希算法，建立存储设备和计算设备两者之间的映射关系，从而先定位到与本计算设备具有映射关系的一个或多个存储设备，然后查询该一个或多个存储设备中每个存储设备所存储的数据记录的主键范围，从而根据该至少一条数据记录的主键范围，查询该至少一条数据记录所在的存储设备（同样可以是一个或多个）。

在一些实施例中，将分布式计算集群中所有计算设备的哈希值和分布式存储集群中所有存储设备的哈希值存放到同一张路由表中，后续从代理服务器到计算设备的路由，和从计算设备到存储设备的路由，都访问同一张路由表。或者，将分布式计算集群中所有计算设备的哈希值存放到第一路由表，将分布式存储集群中所有存储设备的哈希值存放到第二路由表，后续从代理服务器到计算设备的路由访问第一路由表，从计算设备到存储设备的路由访问第二路由表，本申请实施例对此不进行具体限定。

712、存储设备基于该提交日志，对该至少一条数据记录执行与计算设备相同的处理。

在一些实施例中，分布式存储集群的每个存储设备中都配置有提交日志组件，该提交日志组件专门用于保存操作了本存储设备上存储的数据记录的事务的提交日志，提交日志组件和事务缓存区之间是一一对应的，以便于提升事务提交性能，降低本技术方案的实现复杂度。

存储设备接收计算设备发送的提交日志，并将提交日志存储到自身的提交日志组件中，通过增加提交日志组件，能够使得存储设备异步对提交日志组件中存储的各条提交日志进行回放，以实现数据记录落盘（落盘完毕后可清理掉提交日志组件中的提交日志，以节约存储空间），达到存储、计算解耦的效果。

在一些实施例中，存储设备的提交日志组件中每新到一个提交日志，就对新到的提交日志进行回放，能够实现及时进行数据落盘。

在一些实施例中，存储设备每间隔目标时长，对提交日志组件中存储的各个提交日志进行回放，能够避免某一提交日志长期未进行数据落盘。

在一些实施例中，当有计算设备从该提交日志组件中的提交日志中读取数据记录时，将被读取的数据记录所在的提交日志进行回放，以对本数据记录及时进行数据落盘。

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

本申请实施例提供的方法，通过对划分至本计算设备的目标事务，获取该目标事务对应的至少一条数据记录，该至少一条数据记录包括目标事务所操作的所有主键记录和该主键记录对应的二级索引记录，使得能够分布式数据库系统中的单个计算设备中，完成对目标事务所操作的所有主键记录和该主键记录对应的二级索引记录的处理，从而以单机事务的方式来提交目标事务，而无需采用2PC算法与其他计算设备进行多轮通信，并由存储设备对目标事务的提交日志进行异步回放即可实现数据落盘，能够在保证数据一致性的前提下，大大提升分布式数据库系统的事务执行性能。

在上述实施例中，介绍了包含LVS服务器、代理服务器、分布式计算集群、分布式存储集群的分布式数据库系统的事务执行流程，而在一些实施例中，代理服务器的功能可集成在分布式计算集群的计算设备中，在本申请实施例中，将针对这种架构的分布式数据库系统的事务执行流程进行说明。

图8是本申请实施例提供的一种事务执行方法的交互流程图，如图8所示，本申请实施例中，将对分布式数据库系统内部不同集群之间信息交互流程进行详细说明。

801、LVS服务器接收应用客户端的用户请求，将该用户请求转发至计算设备。

上述步骤801与上述步骤701类似，这里不作赘述。

802、该计算设备解析该用户请求，得到目标事务。

上述步骤802与上述步骤702类似，这里不作赘述。

803、该计算设备确定该目标事务所对应的至少一条数据记录的分区列。

上述步骤803与上述步骤703类似，这里不作赘述。

804、在该至少一条数据记录的分区列与该计算设备具有映射关系的情况下，由该计算设备处理该目标事务。

在一些实施例中，计算设备基于上述步骤803中确定的该至少一条数据记录的分区列，获取该至少一条数据记录的分区列的哈希值，接着，对该至少一条数据记录中每一条数据记录，在分布式计算集群中所有计算设备的哈希值中，找到第一个比该数据记录的分区列的哈希值大的目标哈希值（即大于该数据记录的分区列的哈希值且最接近该数据记录的分区列的哈希值），如果该目标哈希值与本计算设备对应（即目标哈希值等于本计算设备的哈希值），即代表该数据记录应划分至本计算设备，对该至少一条数据记录中每一条数据记录，重复执行上述操作，如果该至少一条数据记录中的所有数据记录都映射至本计算设备，代表该至少一条数据记录的分区列与该计算设备具有映射关系，也即是说，在本计算设备的哈希值大于该至少一条数据记录的分区列的哈希值，且与该至少一条数据记录的分区列的哈希值最接近的情况下，确定该至少一条数据记录的分区列与该计算设备具有映射关系。在这种情况下，由本计算设备执行与上述步骤705-711类似的操作，完成对该目标事务的执行和提交流程。

805、在该至少一条数据记录的分区列与该计算设备不具有映射关系的情况下，该计算设备将该目标事务转发至第二计算设备，由第二计算设备处理该目标事务，该第二计算设备与该至少一条数据记录的分区列具有映射关系。

在一些实施例中，如果该至少一条数据记录中的所有数据记录都映射至同一个第二计算设备，但是映射到的第二计算设备不是本计算设备，则进入下述步骤805，需要将该目标事务转发至第二计算设备，由第二计算设备执行与上述步骤705-711类似的步骤，完成对该目标事务的执行和提交流程。

在另一些实施例中，如果该至少一条数据记录中存在任意至少两个数据记录映射到了两个或两个以上的计算设备，那么仍然需要采用2PC算法进行分布式事务的执行和提交，此时可由本计算设备充当2PC算法的协调者，并将目标事务分解成多个局部事务，将每个局部事务分发至对应的计算设备（2PC算法的参与者）进行处理，并通过二阶段提交流程进行全局提交。

示意性地，以目标事务为读事务为例进行分析，如果读事务所涉及读取的数据记录都能够路由到单个计算设备（本计算设备或者第二计算设备），那么则直接在单个计算设备中完成计算，并以单机事务的方式在事务缓存区中完成提交，通过提交日志异步进行数据落盘。如果读事务所涉及读取的数据记录无法路由到单个计算设备，即涉及到了多个计算设备各自的多个事务缓存区的存储范围，则需要对读事务的读取范围进行拆分查询，即拆分成多个子范围，使得每个子范围都能够路由到单个计算设备中完成计算，并采用2PC算法进行全局提交。

在本申请实施例中，示出了将代理服务器集成到计算设备之后，分布式数据库系统整体的事务执行流程，由于无需设置中心化的代理服务器，因此能够对整个分布式数据库系统进行去中心化，从而进一步提高了分布式数据库系统的事务执行性能。

在上面两个实施例中，介绍了不同架构下的分布式数据库系统各自针对能够以单机事务方式提交的事务的执行流程，但考虑到分布式事务是无法完全消除的，本申请实施例只是尽量将整个系统内分布式事务的总量降到最低，因此，在本申请实施例中，将结合判断是否为分布式事务来介绍一个计算设备针对任一类型的事务的执行流程。

图9是本申请实施例提供的一种事务执行流程的原理性流程图，请参考图9，该实施例适用于分布式数据库系统中的任一计算设备，在计算设备开启事务执行流程之前，需要先与应用客户端建立连接，然后由代理服务器选择本计算设备处理的事务。该实施例包括下述步骤。

步骤1、计算设备开始执行事务。

步骤2、根据事务涉及的数据记录是否跨越多个计算设备，决定是否启动2PC事务执行方式。如果跨越多个计算设备，进入步骤3；如果没有跨越多个计算设备，进入步骤4。

步骤3、将事务分解为多个参与者事务（即分解查询），在对应的该多个计算设备上启动参与者事务，参与者事务执行流程和本事务执行流程一致，只是进入步骤2之后，由于数据记录都存储在对应的计算设备中，因此不会再会启动2PC执行方式。

步骤4、根据已加载数据Map判断数据记录是否已经加载到事务缓存区中。如果全部加载到事务缓存区中，进入步骤6；如果尚未全部加载到事务缓存区中，进入步骤5。

其中，可根据数据加载信息（如已加载数据Map）来确定数据记录是否已经加载到事务缓存区中。

步骤5、从底层的存储设备中加载对应的数据记录。

步骤6、计算设备开始执行事务的SQL语句。

步骤7、提交事务，其中，如果在步骤2中启动了2PC事务执行方式的话，则需要完成2PC的提交算法；否则，在事务缓存区中以单机事务的方式进行提交。

在本申请实施例中，实现了事务Cache机制，使得事务对数据记录的操作流程与数据记录实际存储流程解耦，因此最大限度地在整个分布式数据库系统中，将以2PC算法执行的分布式事务的数量降到最低，从而提升了整个分布式数据库系统的处理能力和吞吐能力。

进一步地，通过事务Cache机制，还能够以数据记录级别的划分，来解决当在热点数据表中修改某一小段数据记录，所带来的存储设备瓶颈问题和负载均衡问题，这是由于事务Cache机制能够做到数据记录级别的负载均衡，同时不受数据记录物理存储的影响，即，通过将在热点数据表中的某一小段数据记录缓存在事务缓存区中，后续直接修改缓存的这一小段数据记录即可，而无需反复访问到底层的存储设备。

在上述各个实施例中，详细介绍了分布式数据库系统中，如果基于事务Cache机制，将分布式事务转化成单机事务在事务缓存区中进行提交，同时实现事务对数据记录的操作流程与数据记录实际存储流程解耦。基于本申请实施例涉及的分布式数据库系统，通过事务Cache机制，还能够灵活地根据计算设备的负载情况，对整个系统进行负载均衡和故障修复，即以事务为单位进行负载均衡和故障恢复，能够达到较快速度的负载均衡和故障修复。

以下，首先结合一致性哈希算法描述动态负载均衡的原理。

图10是本申请实施例提供的一种一致性哈希算法的原理性示意图，如图10所示，以分布式计算集群中原本包含4个计算设备501~504为例，代理服务器通过哈希算法，对每个计算设备都计算出一个唯一的哈希值，保证计算设备和哈希值之间一一对应，图10中计算设备501~504各自指向的较大的圆点511~514分别代表了各自的哈希值，其中，圆圈上的数值大小按照顺时针递增，即，计算设备501的哈希值511最小，计算设备504的哈希值514最大。此外，在每一条数据记录的数据结构中增加一个分区列的信息，对每一条数据记录的分区列也计算一个唯一的哈希值，图10中分区列505~506各自指向的较小的圆点515~516分别代表了各自的哈希值，此外还示出了其余的8条数据记录的分区列的哈希值517~524。

在一致性哈希算法的约束下，对每一条数据记录来说，基于该数据记录的分区列的哈希值，在分布式计算集群中所有计算设备的哈希值中，找到第一个比该分区列的哈希值大的目标哈希值（即大于该分区列的哈希值且最接近该分区列的哈希值），将该数据记录划分至目标哈希值所对应的计算设备。可以看出，原本分布式计算集群中最繁忙是计算设备504，因为共有5条数据记录的哈希值517~521均指向了计算设备504。

假设需要通过扩容方式，来对计算设备504进行负载均衡，只需要新增一个计算设备530，并使得计算设备530的哈希值能够插入到计算设备502和计算设备504的哈希值之间，就能够将原本划分至计算设备504中的部分负载重新划分到新增的计算设备530中，也就达到了计算能力扩容的效果。

在一些实施例中，上述新增的计算设备530可以是实体节点或者虚拟节点，新增的计算设备530如果是实体节点，则确实达到了计算能力扩容的效果，新增的计算设备530如果是虚拟节点，则可以将该虚拟节点指向已有的较为空闲的其他实体节点（如指向原本最空闲的计算设备503），从而达到在原有计算能力的基础上，做到整个计算集群内部的负载均衡。

本申请实施例仅以增加单个计算设备扩容为例，在一些实施例中，还能够一次性增加更多虚拟节点，达到更细粒度控制负载分布的效果，能够避免将热点计算设备的较多负载一下子转移到空闲计算设备之后，产生了新的热点计算设备。

与扩容相反的，如果需要对分布式计算集群进行计算能力缩容，只需要将计算设备530及其哈希值从分布式计算集群中移除，后续划分到计算设备530的事务，会被重新划分到计算设备504上面。

基于上述一致性哈希算法以实现动态负载均衡的原理，可通过向分布式数据库系统中新增计算设备的方式，来实现计算能力扩容、热点均衡或故障恢复，在新增计算设备之后，会对原本系统内部分计算设备所负责处理的事务进行重分布，新增计算设备的功能可集成在代理服务器中，或者与代理服务器一起集成到计算设备中，本申请实施例对此不进行具体限定。

在一些实施例中，分布式数据库系统在符合目标条件时新增计算设备，新增的计算设备可以是实体计算设备或者虚拟计算设备，如果新增的计算设备为虚拟计算设备，那么可将该虚拟计算设备关联于该分布式数据库系统中已有的目标计算设备，例如，目标计算设备是计算负载最小的计算设备。

其中，该目标条件包括下述至少一项：接收到对计算设备的新增指令，适用于主动新增计算节点的场景；或，该分布式数据库系统中任一计算设备的计算负载超过负载阈值，适用于热点分裂（或称为热点均衡、负载均衡）的场景；或，该分布式数据库系统中任一计算设备的故障时长超过时长阈值，适用于故障恢复的场景，下面将分别进行说明。其中，该负载阈值大于0。

（一）新增计算设备

在这一类场景下，目标条件为接收到对计算设备的新增指令，比如，管理员出于扩容需求或者热点均衡需求，输入了对计算设备的新增指令，触发代理服务器与新增的计算设备建立连接，并在需要热点均衡的计算设备的哈希值和前一个计算设备的哈希值之间，为新增的计算设备生成一个中间哈希值。接着，对于后来的事务，需要根据新增的计算设备的中间哈希值，重新分发事务，划分至原来热点计算设备的事务继续执行，不发生变化，划分至新增计算设备的事务，需要去原来热点计算设备中加载数据记录，并需要在数据加载过程中添加对应的锁资源，并在事务缓存区中将申请锁的数据资源标记为失效，在数据迁移完毕（请求加载的数据记录已经全部在新增计算设备上缓存）后，释放锁资源，从而完成负载均衡。

也即是说，对于任一计算设备，接收该分布式数据库系统中第三计算设备发送的数据加载请求，该数据加载请求用于加载该计算设备中已缓存的至少一条目标数据记录；对该至少一条目标数据记录加锁，将该至少一条目标数据记录标记为失效状态；将该至少一条目标数据记录发送至该第三计算设备，释放该至少一条目标数据记录的锁资源。

需要说明的是，不仅是将目标数据记录从热点计算设备迁移到新增计算设备，实际上分布式数据库系统内的任意两个计算设备直接都能够以上述方式实现目标数据记录的迁移过程，该第三计算设备可以是系统内新增的实体计算设备，还可以是系统内新增的虚拟计算设备所指向的某一已有的计算设备，本申请实施例对此不进行具体限定。

（二）热点分裂

在这一类场景下，目标条件为该分布式数据库系统中任一计算设备的计算负载超过负载阈值，该负载阈值大于0，例如，采用划分至每个计算设备的事务数量作为计算负载的指标。

示意性地，代理服务器在检测到，某个计算设备的当前的计算负载超过负载阈值时，基于热点分裂策略，选取哈希值落入一定范围的数据记录准备进行数据迁移，代理服务器找寻该计算设备的前一个计算设备，在该计算设备和前一个计算设备的哈希值之间插入一个新增的计算设备的哈希值。换言之，在该目标条件包括该分布式数据库系统中任一计算设备的计算负载大于负载阈值的情况下，新增的计算设备的哈希值小于第一哈希值且大于第二哈希值，该第一哈希值为计算负载大于负载阈值的计算设备的哈希值，该第二哈希值为该分布式数据库系统中原本小于该第一哈希值且与该第一哈希值最接近的哈希值。

在上述热点分裂的基础上，对于划分至新增的计算设备的事务，需要携带原本计算负载超过负载阈值的该计算设备（简便起见，后续称为热点计算设备）的哈希值，这时，针对新增的计算设备，如果接收到的某一事务同时携带了热点计算设备的哈希值，说明需要从携带的哈希值对应的热点计算设备中去加载本事务涉及的数据记录，此时热点计算设备对新增的计算设备所请求的数据记录加锁，并将新增的计算设备所请求的数据记录标记为失效状态，直到新增的计算设备对本事务涉及的数据记录记载完毕，通知热点计算设备释放对应的锁资源。

换言之，对于任一计算设备，如果代理服务器分配过来的目标事务没有携带热点计算设备的哈希值，执行上述各个实施例中从本地的事务缓存区或者底层存储设备中读取该目标事务所对应的该至少一条数据记录的操作。如果代理服务器分配过来目标事务携带了热点计算设备的哈希值，那么需要从热点计算设备中加载该目标事务所对应的该至少一条数据记录。

此外，在上述场景（一）和（二）都涉及到新增的计算设备从热点计算设备中将重分布的目标数据记录进行加载的过程，先对目标数据记录加锁是为了确保目标数据记录在迁移过程中不会被热点计算设备的其他事务占用，同时将目标数据记录置为失效状态是为了防止后续热点计算设备的其他事务在目标数据记录迁移完成之后再读取到了过时的字段数据（Value），能够避免数据不一致问题，最后释放锁资源即可完成数据迁移。

（三）故障恢复

在这一类场景下，目标条件为该分布式数据库系统中任一计算设备的故障时长超过时长阈值，其中，该时长阈值为任一大于0的数值。通过设置时长阈值，使得如果在时长阈值内，故障计算设备自行恢复，那么代理服务器无需启动故障恢复流程，这样能够避免分布式数据库系统的计算设备数量抖动。

如果某一计算设备的故障时长超过时长阈值，那么代理服务器新增一个计算设备来负责原本故障计算设备的事务，对于划分至新增的计算设备的事务，需要携带原本故障计算设备（即第一计算设备）的哈希值，这时，针对新增的计算设备，如果接收到的某一事务同时携带了第一计算设备的哈希值，说明需要从分布式存储集群中拉取本事务涉及的数据记录（由于第一计算设备已经故障，因此无法从第一计算设备中加载数据记录）。

由于计算设备与存储设备之间具有对应关系，即计算设备上的事务缓存区和存储设备上的提交日志组件具有对应关系，通过在发往新增的计算设备的事务中添加第一计算设备的哈希值，能够从第一计算设备的哈希值确定对应的存储设备，进而先从确定的存储设备的提交日志组件中查询本事务涉及的数据记录（提交日志里记录的是最新数据记录），如果命中则将提交日志中记录的数据记录返回到新增的计算设备，如果未命中则说明这段故障时间内提交日志中记录的变更已经完成了数据落盘，因此直接从存储设备的磁盘中读取提交日志中未查询到的数据记录即可保证是最新的数据记录，如果在磁盘中也没有找到对应的数据记录，说明这一数据记录不存在，可上报异常情况并回滚事务。

换言之，对于任一计算设备，如果代理服务器分配过来的目标事务没有携带第一计算设备的哈希值，执行上述各个实施例中从本地的事务缓存区或者底层存储设备中读取该目标事务所对应的该至少一条数据记录的操作。如果代理服务器分配过来目标事务携带了第一计算设备的哈希值，那么需要从第一计算设备对应的存储设备中拉取该目标事务所对应的该至少一条数据记录。其中，第一计算设备是指发生故障的计算设备。

也即是说，在该目标事务中携带第一计算设备的哈希值的情况下，基于该第一计算设备的哈希值，查询与该第一计算设备对应的提交日志；对该至少一条数据记录中的每条数据记录，在该提交日志中包含该数据记录的日志记录的情况下，从该提交日志中读取该数据记录；在该提交日志中不包含该数据记录的日志记录的情况下，从该数据记录所在的存储设备中读取该数据记录。

采用上述故障恢复方式，与事务Cache机制结合，能够实现故障计算设备中事务缓存区中的相关数据记录从提交日志中进行平滑迁移。

由于在上述三类场景下的数据迁移开始时，代理服务器都已经确保后续会有新的需要操作这部分数据记录的事务被路由到原来的计算设备（一致性哈希算法提供保障），因此只需要解决一个存量事务访问的问题。可选地，为解决存量事务问题，代理服务器下发热点切换任务之后，计算设备给当前活跃事务记录一个快照，这一快照作为同步点，当在快照中的事务处理时，读取数据记录发现已经被置为失效状态了，此时可以直接回滚快照中的事务，实现原理简单，但对于存量事务不友好，不过由于仅发生在热点切换过程中，因此用户通常能够接受这部分存量事务的损失，或者，还可以将快照中的事务变成2PC提交模式，并将这部分数据记录迁移至的新增计算设备作为事务参与者进行处理，从而能够提高对用户事务的友好度，但有可能会使得用户事务变慢，考虑到热点计算设备本身的负载较高，所以用户较为容易接受事务变慢的影响。在快照中的所有事务结束后，代理服务器标记热点迁移完成，可清理相应的数据结构，以节约存储空间。

图11是本申请实施例提供的一种事务执行装置的结构示意图，请参考图11，该装置位于分布式数据库系统中，该装置包括：

获取模块1101，用于响应于目标事务，获取该目标事务所对应的至少一条数据记录，该数据记录为主键记录或该主键记录关联的二级索引记录；

处理模块1102，用于基于该目标事务，处理该至少一条数据记录；

生成模块1103，用于在提交该目标事务时，生成该目标事务的提交日志，以使该分布式数据库系统中的存储设备对该至少一条数据记录进行相同的处理。

本申请实施例提供的装置，通过对划分至本计算设备的目标事务，获取该目标事务对应的至少一条数据记录，该至少一条数据记录包括目标事务所操作的所有主键记录和该主键记录对应的二级索引记录，使得能够分布式数据库系统中的单个计算设备中，完成对目标事务所操作的所有主键记录和该主键记录对应的二级索引记录的处理，从而以单机事务的方式来提交目标事务，而无需采用2PC算法与其他计算设备进行多轮通信，并由存储设备对目标事务的提交日志进行异步回放即可实现数据落盘，能够在保证数据一致性的前提下，大大提升分布式数据库系统的事务执行性能。

在一种可能实施方式中，基于图11的装置组成，该获取模块1101包括：

第一确定单元，用于确定该目标事务所对应的至少一个索引，该索引为主键索引或二级索引；

查询单元，用于基于该至少一个索引，从事务缓存区中查询得到该至少一条数据记录。

在一种可能实施方式中，该查询单元用于：

在该至少一条数据记录全部缓存在该事务缓存区中的情况下，基于该至少一个索引，从该事务缓存区中读取对应的该至少一条数据记录；

在该至少一条数据记录未全部缓存在该事务缓存区中的情况下，从该存储设备中将未缓存的数据记录读取到该事务缓存区中；基于该至少一个索引，从该事务缓存区中读取对应的该至少一条数据记录。

在一种可能实施方式中，基于图11的装置组成，该获取模块1101还包括：

获取单元，用于获取该事务缓存区的数据加载信息，该数据加载信息用于记录该事务缓存区中已缓存的数据记录；

第二确定单元，用于基于该数据加载信息，确定该至少一条数据记录是否全部缓存在该事务缓存区中。

在一种可能实施方式中，该获取模块1101用于：

在该目标事务中携带第一计算设备的哈希值的情况下，基于该第一计算设备的哈希值，查询与该第一计算设备对应的提交日志，该第一计算设备为发生故障的计算设备；

对该至少一条数据记录中的每条数据记录，在该提交日志中包含该数据记录的日志记录的情况下，从该提交日志中读取该数据记录；

在该提交日志中不包含该数据记录的日志记录的情况下，从该数据记录所在的存储设备中读取该数据记录。

在一种可能实施方式中，基于图11的装置组成，该装置还包括：

第一确定模块，用于确定该目标事务所对应的至少一条数据记录的分区列；

该处理模块1102，还用于在该至少一条数据记录的分区列与该计算设备具有映射关系的情况下，由该计算设备处理该目标事务；

发送模块，用于在该至少一条数据记录的分区列与该计算设备不具有映射关系的情况下，将该目标事务转发至第二计算设备，该第二计算设备与该至少一条数据记录的分区列具有映射关系。

在一种可能实施方式中，该分布式数据库系统中的多个计算设备与多个哈希值一一对应，基于图11的装置组成，该装置还包括：

第二确定模块，用于在该计算设备的哈希值大于该至少一条数据记录的分区列的哈希值，且与该至少一条数据记录的分区列的哈希值最接近的情况下，确定该至少一条数据记录的分区列与该计算设备具有映射关系。

在一种可能实施方式中，对该至少一条数据记录中的任一条数据记录，在该数据记录的键值对中的键值后增加该数据记录的分区列。

在一种可能实施方式中，基于图11的装置组成，该装置还包括：

接收模块，用于接收该分布式数据库系统中第三计算设备发送的数据加载请求，该数据加载请求用于加载该计算设备中已缓存的至少一条目标数据记录；

加锁标记模块，用于对该至少一条目标数据记录加锁，将该至少一条目标数据记录标记为失效状态；

发送释放模块，用于将该至少一条目标数据记录发送至该第三计算设备，释放该至少一条目标数据记录的锁资源。

在一种可能实施方式中，该分布式数据库系统在符合目标条件时新增计算设备；其中，该目标条件包括下述至少一项：接收到对计算设备的新增指令；或，该分布式数据库系统中任一计算设备的计算负载超过负载阈值；或，该分布式数据库系统中任一计算设备的故障时长超过时长阈值。

在一种可能实施方式中，在该目标条件包括该分布式数据库系统中任一计算设备的计算负载大于负载阈值的情况下，新增的计算设备的哈希值小于第一哈希值且大于第二哈希值，该第一哈希值为计算负载大于负载阈值的计算设备的哈希值，该第二哈希值为该分布式数据库系统中原本小于该第一哈希值且与该第一哈希值最接近的哈希值。

在一种可能实施方式中，新增的计算设备为虚拟计算设备，且该虚拟计算设备关联于该分布式数据库系统的目标计算设备。

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

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

图12是本申请实施例提供的一种计算设备的结构示意图。如图12所示，以计算设备为终端1200为例进行说明，该终端1200可以是分布式计算集群中的任一计算设备。可选地，该终端1200的设备类型包括：智能手机、平板电脑、MP3播放器（Moving PictureExperts Group Audio Layer III，动态影像专家压缩标准音频层面3）、MP4（MovingPicture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4）播放器、笔记本电脑或台式电脑。终端1200还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1200包括有：处理器1201和存储器1202。

可选地，处理器1201包括一个或多个处理核心，比如4核心处理器、8核心处理器等。可选地，处理器1201采用DSP（Digital Signal Processing，数字信号处理）、FPGA（Field－Programmable Gate Array，现场可编程门阵列）、PLA（Programmable LogicArray，可编程逻辑阵列）中的至少一种硬件形式来实现。在一些实施例中，处理器1201包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU（Central Processing Unit，中央处理器）；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1201集成有GPU（Graphics Processing Unit，图像处理器），GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1201还包括AI（Artificial Intelligence，人工智能）处理器，该AI处理器用于处理有关机器学习的计算操作。

在一些实施例中，存储器1202包括一个或多个计算机可读存储介质，可选地，该计算机可读存储介质是非暂态的。可选地，存储器1202还包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1202中的非暂态的计算机可读存储介质用于存储至少一个程序代码，该至少一个程序代码用于被处理器1201所执行以实现本申请中各个实施例提供的事务执行方法。

在一些实施例中，终端1200还可选包括有：外围设备接口1203和至少一个外围设备。处理器1201、存储器1202和外围设备接口1203之间能够通过总线或信号线相连。各个外围设备能够通过总线、信号线或电路板与外围设备接口1203相连。具体地，外围设备包括：射频电路1204、显示屏1205、摄像头组件1206、音频电路1207、定位组件1208和电源1209中的至少一种。

外围设备接口1203可被用于将I/O（Input /Output，输入/输出）相关的至少一个外围设备连接到处理器1201和存储器1202。在一些实施例中，处理器1201、存储器1202和外围设备接口1203被集成在同一芯片或电路板上；在一些其他实施例中，处理器1201、存储器1202和外围设备接口1203中的任意一个或两个在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1204用于接收和发射RF（Radio Frequency，射频）信号，也称电磁信号。射频电路1204通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1204将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1204包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。可选地，射频电路1204通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络（2G、3G、4G及5G）、无线局域网和/或WiFi（Wireless Fidelity，无线保真）网络。在一些实施例中，射频电路1204还包括NFC（Near Field Communication，近距离无线通信）有关的电路，本申请对此不加以限定。

显示屏1205用于显示UI（User Interface，用户界面）。可选地，该UI包括图形、文本、图标、视频及其它们的任意组合。当显示屏1205是触摸显示屏时，显示屏1205还具有采集在显示屏1205的表面或表面上方的触摸信号的能力。该触摸信号能够作为控制信号输入至处理器1201进行处理。可选地，显示屏1205还用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1205为一个，设置终端1200的前面板；在另一些实施例中，显示屏1205为至少两个，分别设置在终端1200的不同表面或呈折叠设计；在再一些实施例中，显示屏1205是柔性显示屏，设置在终端1200的弯曲表面上或折叠面上。甚至，可选地，显示屏1205设置成非矩形的不规则图形，也即异形屏。可选地，显示屏1205采用LCD（Liquid Crystal Display，液晶显示屏）、OLED（Organic Light-Emitting Diode，有机发光二极管）等材质制备。

摄像头组件1206用于采集图像或视频。可选地，摄像头组件1206包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR（Virtual Reality，虚拟现实）拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1206还包括闪光灯。可选地，闪光灯是单色温闪光灯，或者是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，用于不同色温下的光线补偿。

在一些实施例中，音频电路1207包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1201进行处理，或者输入至射频电路1204以实现语音通信。出于立体声采集或降噪的目的，麦克风为多个，分别设置在终端1200的不同部位。可选地，麦克风是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1201或射频电路1204的电信号转换为声波。可选地，扬声器是传统的薄膜扬声器，或者是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅能够将电信号转换为人类可听见的声波，也能够将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1207还包括耳机插孔。

定位组件1208用于定位终端1200的当前地理位置，以实现导航或LBS（LocationBased Service，基于位置的服务）。可选地，定位组件1208是基于美国的GPS（GlobalPositioning System，全球定位系统）、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1209用于为终端1200中的各个组件进行供电。可选地，电源1209是交流电、直流电、一次性电池或可充电电池。当电源1209包括可充电电池时，该可充电电池支持有线充电或无线充电。该可充电电池还用于支持快充技术。

在一些实施例中，终端1200还包括有一个或多个传感器1210。该一个或多个传感器1210包括但不限于：加速度传感器1211、陀螺仪传感器1212、压力传感器1213、指纹传感器1214、光学传感器1215以及接近传感器1216。

在一些实施例中，加速度传感器1211检测以终端1200建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1211用于检测重力加速度在三个坐标轴上的分量。可选地，处理器1201根据加速度传感器1211采集的重力加速度信号，控制显示屏1205以横向视图或纵向视图进行用户界面的显示。加速度传感器1211还用于游戏或者用户的运动数据的采集。

在一些实施例中，陀螺仪传感器1212检测终端1200的机体方向及转动角度，陀螺仪传感器1212与加速度传感器1211协同采集用户对终端1200的3D动作。处理器1201根据陀螺仪传感器1212采集的数据，实现如下功能：动作感应（比如根据用户的倾斜操作来改变UI）、拍摄时的图像稳定、游戏控制以及惯性导航。

可选地，压力传感器1213设置在终端1200的侧边框和/或显示屏1205的下层。当压力传感器1213设置在终端1200的侧边框时，能够检测用户对终端1200的握持信号，由处理器1201根据压力传感器1213采集的握持信号进行左右手识别或快捷操作。当压力传感器1213设置在显示屏1205的下层时，由处理器1201根据用户对显示屏1205的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1214用于采集用户的指纹，由处理器1201根据指纹传感器1214采集到的指纹识别用户的身份，或者，由指纹传感器1214根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1201授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。可选地，指纹传感器1214被设置终端1200的正面、背面或侧面。当终端1200上设置有物理按键或厂商Logo时，指纹传感器1214能够与物理按键或厂商Logo集成在一起。

光学传感器1215用于采集环境光强度。在一个实施例中，处理器1201根据光学传感器1215采集的环境光强度，控制显示屏1205的显示亮度。具体地，当环境光强度较高时，调高显示屏1205的显示亮度；当环境光强度较低时，调低显示屏1205的显示亮度。在另一个实施例中，处理器1201还根据光学传感器1215采集的环境光强度，动态调整摄像头组件1206的拍摄参数。

接近传感器1216，也称距离传感器，通常设置在终端1200的前面板。接近传感器1216用于采集用户与终端1200的正面之间的距离。在一个实施例中，当接近传感器1216检测到用户与终端1200的正面之间的距离逐渐变小时，由处理器1201控制显示屏1205从亮屏状态切换为息屏状态；当接近传感器1216检测到用户与终端1200的正面之间的距离逐渐变大时，由处理器1201控制显示屏1205从息屏状态切换为亮屏状态。

本领域技术人员能够理解，图12中示出的结构并不构成对终端1200的限定，能够包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

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

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

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

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

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

Claims (16)

1.一种事务执行方法，其特征在于，由分布式数据库系统中的计算设备执行，所述方法包括：

响应于目标事务，获取所述目标事务所对应的至少一条数据记录，所述数据记录为主键记录或所述主键记录关联的二级索引记录；

基于所述目标事务，处理所述至少一条数据记录；

在提交所述目标事务时，生成所述目标事务的提交日志，以使所述分布式数据库系统中的存储设备对所述至少一条数据记录进行相同的处理。

2.根据权利要求1所述的方法，其特征在于，所述获取所述目标事务所对应的至少一条数据记录包括：

确定所述目标事务所对应的至少一个索引，所述索引为主键索引或二级索引；

基于所述至少一个索引，从事务缓存区中查询得到所述至少一条数据记录。

3.根据权利要求2所述的方法，其特征在于，所述基于所述至少一个索引，从事务缓存区中查询得到所述至少一条数据记录包括：

在所述至少一条数据记录全部缓存在所述事务缓存区中的情况下，基于所述至少一个索引，从所述事务缓存区中读取对应的所述至少一条数据记录；

在所述至少一条数据记录未全部缓存在所述事务缓存区中的情况下，从所述存储设备中将未缓存的数据记录读取到所述事务缓存区中；基于所述至少一个索引，从所述事务缓存区中读取对应的所述至少一条数据记录。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

获取所述事务缓存区的数据加载信息，所述数据加载信息用于记录所述事务缓存区中已缓存的数据记录；

基于所述数据加载信息，确定所述至少一条数据记录是否全部缓存在所述事务缓存区中。

5.根据权利要求1所述的方法，其特征在于，所述获取所述目标事务所对应的至少一条数据记录包括：

在所述目标事务中携带第一计算设备的哈希值的情况下，基于所述第一计算设备的哈希值，查询与所述第一计算设备对应的提交日志，所述第一计算设备为发生故障的计算设备；

对所述至少一条数据记录中的每条数据记录，在所述提交日志中包含所述数据记录的日志记录的情况下，从所述提交日志中读取所述数据记录；

在所述提交日志中不包含所述数据记录的日志记录的情况下，从所述数据记录所在的存储设备中读取所述数据记录。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

确定所述目标事务所对应的至少一条数据记录的分区列；

在所述至少一条数据记录的分区列与所述计算设备具有映射关系的情况下，由所述计算设备处理所述目标事务；

在所述至少一条数据记录的分区列与所述计算设备不具有映射关系的情况下，将所述目标事务转发至第二计算设备，所述第二计算设备与所述至少一条数据记录的分区列具有映射关系。

7.根据权利要求6所述的方法，其特征在于，所述分布式数据库系统中的多个计算设备与多个哈希值一一对应，所述方法还包括：

在所述计算设备的哈希值大于所述至少一条数据记录的分区列的哈希值，且与所述至少一条数据记录的分区列的哈希值最接近的情况下，确定所述至少一条数据记录的分区列与所述计算设备具有映射关系。

8.根据权利要求6所述的方法，其特征在于，对所述至少一条数据记录中的任一条数据记录，在所述数据记录的键值对中的键值后增加所述数据记录的分区列。

9.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述分布式数据库系统中第三计算设备发送的数据加载请求，所述数据加载请求用于加载所述计算设备中已缓存的至少一条目标数据记录；

对所述至少一条目标数据记录加锁，将所述至少一条目标数据记录标记为失效状态；

将所述至少一条目标数据记录发送至所述第三计算设备，释放所述至少一条目标数据记录的锁资源。

10.根据权利要求1所述的方法，其特征在于，所述分布式数据库系统在符合目标条件时新增计算设备；其中，所述目标条件包括下述至少一项：接收到对计算设备的新增指令；或，所述分布式数据库系统中任一计算设备的计算负载超过负载阈值；或，所述分布式数据库系统中任一计算设备的故障时长超过时长阈值。

11.根据权利要求10所述的方法，其特征在于，在所述目标条件包括所述分布式数据库系统中任一计算设备的计算负载大于负载阈值的情况下，新增的计算设备的哈希值小于第一哈希值且大于第二哈希值，所述第一哈希值为计算负载大于负载阈值的计算设备的哈希值，所述第二哈希值为所述分布式数据库系统中原本小于所述第一哈希值且与所述第一哈希值最接近的哈希值。

12.根据权利要求10所述的方法，其特征在于，新增的计算设备为虚拟计算设备，且所述虚拟计算设备关联于所述分布式数据库系统的目标计算设备。

13.一种事务执行装置，其特征在于，所述装置位于分布式数据库系统中，所述装置包括：

获取模块，用于响应于目标事务，获取所述目标事务所对应的至少一条数据记录，所述数据记录为主键记录或所述主键记录关联的二级索引记录；

处理模块，用于基于所述目标事务，处理所述至少一条数据记录；

生成模块，用于在提交所述目标事务时，生成所述目标事务的提交日志，以使所述分布式数据库系统中的存储设备对所述至少一条数据记录进行相同的处理。

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

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

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

Images