事务处理方法、设备及计算机可读存储介质
技术领域
本申请实施例涉及数据库技术领域,特别涉及一种事务处理方法、设备及计算机可读存储介质。
背景技术
随着数据库技术的发展,为了能够适应大数据、云计算等业务场景,分布式数据库系统逐渐变得普及。在多种分布式数据库系统中,基于共享存储(share-disk)架构的分布式数据库系统是一种主流系统。
目前,在基于share-disk架构的分布式数据库系统中,根据数据项的分布情况对事务进行分配,将涉及某一数据项的事务分配给为该数据项服务的固定节点设备进行独立处理。基于此,很大程度上限制了事务的处理效率,事务处理的可靠性较差。
发明内容
本申请实施例提供了一种事务处理方法、设备及计算机可读存储介质,可用于提高事务的处理效率。
一方面,本申请实施例提供了一种事务处理方法,所述方法应用于事务分配设备上,所述事务分配设备处于分布式数据库系统中,所述分布式数据库系统中还包括共享同一个存储系统的至少两个节点设备,所述方法包括:
响应于目标事务的分配请求,确定所述至少两个节点设备分别对应的事务分配指标,任一节点设备对应的事务分配指标用于指示为所述任一节点设备分配新事务的匹配度;
基于所述至少两个节点设备分别对应的事务分配指标,在所述至少两个节点设备中确定所述目标事务的协调节点设备,由所述协调节点设备对所述目标事务进行协调处理。
还提供了一种事务处理方法,所述方法应用于协调节点设备上,所述协调节点设备为共享同一个存储系统的至少两个节点设备中用于对目标事务进行协调处理的节点设备,所述协调节点设备根据所述至少两个节点设备分别对应的事务分配指标确定,所述方法包括:
获取所述目标事务的事务信息;
基于所述目标事务的事务信息,向数据节点设备发送数据读取请求,所述数据节点设备为所述至少两个节点设备中用于参与处理所述目标事务的节点设备;
响应于所述数据节点设备返回的数据读取结果满足事务验证条件,向所述数据节点设备发送事务验证请求和本地写集;
基于所述数据节点设备返回的所述目标事务的验证结果,确定所述目标事务的处理指令,向所述数据节点设备发送所述处理指令,所述处理指令为提交指令或者回滚指令,所述数据节点设备用于执行所述处理指令。
还提供了一种事务处理方法,所述方法应用于数据节点设备上,所述数据节点设备为共享同一个存储系统的至少两个节点设备中用于参与处理目标事务的节点设备,所述方法包括:
基于协调节点设备发送的数据读取请求,获取数据读取结果,将所述数据读取结果返回所述协调节点设备,所述协调节点设备根据所述至少两个节点设备分别对应的事务分配指标确定;
基于所述协调节点设备发送的事务验证请求和本地写集,获取所述目标事务的验证结果,将所述目标事务的验证结果返回所述协调节点设备;
响应于接收到所述协调节点设备发送的所述目标事务的处理指令,执行所述处理指令,所述处理指令为提交指令或者回滚指令。
另一方面,提供了一种事务处理装置,所述装置包括:
第一确定单元,用于响应于目标事务的分配请求,确定所述至少两个节点设备分别对应的事务分配指标,任一节点设备对应的事务分配指标用于指示为所述任一节点设备分配新事务的匹配度;
第二确定单元,用于基于所述至少两个节点设备分别对应的事务分配指标,在所述至少两个节点设备中确定所述目标事务的协调节点设备,由所述协调节点设备对所述目标事务进行协调处理。
在一种可能实现方式中,所述第一确定单元,用于确定事务分配模式,所述事务分配模式包括基于事务繁忙程度进行分配、基于设备繁忙程度进行分配和基于混合繁忙程度进行分配中的任一种;根据所述事务分配模式指示的确定方式,确定所述至少两个节点设备分别对应的事务分配指标。
在一种可能实现方式中,所述事务分配模式包括基于混合繁忙程度进行分配,所述第一确定单元,还用于对于所述至少两个节点设备中的任一节点设备,基于所述任一节点设备的事务处理数量、所述任一节点设备的设备资源使用率、事务处理数量权重、设备资源使用率权重以及权重调节参数,确定所述任一节点设备对应的事务分配指标。
在一种可能实现方式中,所述装置还包括:
发送单元,用于将所述协调节点设备的设备标识信息发送给发起所述分配请求的终端,所述终端用于根据所述协调节点设备的设备标识信息,将所述目标事务的事务信息发送给所述协调节点设备,由所述协调节点设备基于所述事务信息对所述目标事务进行协调处理。
在一种可能实现方式中,所述分布式数据库系统支持键值式数据存储格式和段页式数据存储格式。
还提供了一种事务处理装置,所述装置包括:
获取单元,用于获取所述目标事务的事务信息;
第一发送单元,用于基于所述目标事务的事务信息,向数据节点设备发送数据读取请求,所述数据节点设备为所述至少两个节点设备中用于参与处理所述目标事务的节点设备;
第二发送单元,用于响应于所述数据节点设备返回的数据读取结果满足事务验证条件,向所述数据节点设备发送事务验证请求和本地写集;
确定单元,用于基于所述数据节点设备返回的所述目标事务的验证结果,确定所述目标事务的处理指令;
第三发送单元,用于向所述数据节点设备发送所述处理指令,所述处理指令为提交指令或者回滚指令,所述数据节点设备用于执行所述处理指令。
在一种可能实现方式中,所述数据读取结果携带第二逻辑生命周期和可见版本数据,所述第二逻辑生命周期由所述数据节点设备根据所述数据读取请求携带的所述目标事务的第一逻辑生命周期确定,所述第一逻辑生命周期由时间戳下界和时间戳上界构成;
所述第二发送单元,用于将所述第一逻辑生命周期的时间戳下界和所述第二逻辑生命周期的时间戳下界中的最大值作为所述目标事务的第三逻辑生命周期的时间戳下界;将所述第一逻辑生命周期的时间戳上界和所述第二逻辑生命周期的时间戳上界中的最小值作为所述目标事务的第三逻辑生命周期的时间戳上界;响应于所述第三逻辑生命周期有效,向所述数据节点设备发送携带所述第三逻辑生命周期的事务验证请求,所述第三逻辑生命周期有效用于指示所述第三逻辑生命周期的时间戳下界小于所述第三逻辑生命周期的时间戳上界。
在一种可能实现方式中,所述数据节点设备的数量为至少两个,所述确定单元,用于响应于所述至少两个数据节点设备返回的至少两个验证结果中存在用于指示验证不通过的验证结果,将所述回滚指令作为所述目标事务的处理指令;响应于所述至少两个数据节点设备返回的至少两个验证结果均指示验证通过,将所述至少两个验证结果携带的逻辑生命周期的交集作为目标逻辑生命周期;响应于所述目标逻辑生命周期有效,将所述提交指令作为所述目标事务的处理指令;响应于所述目标逻辑生命周期无效,将所述回滚指令作为所述目标事务的处理指令。
还提供了一种事务处理装置,所述装置包括:
第一获取单元,用于基于协调节点设备发送的数据读取请求,获取数据读取结果;
返回单元,用于将所述数据读取结果返回所述协调节点设备,所述协调节点设备根据所述至少两个节点设备分别对应的事务分配指标确定;
第二获取单元,用于基于所述协调节点设备发送的事务验证请求和本地写集,获取所述目标事务的验证结果;
所述返回单元,还用于将所述目标事务的验证结果返回所述协调节点设备;
执行单元,用于响应于接收到所述协调节点设备发送的所述目标事务的处理指令,执行所述处理指令,所述处理指令为提交指令或者回滚指令。
在一种可能实现方式中,所述数据读取请求携带所述目标事务的第一逻辑生命周期,所述第一逻辑生命周期由时间戳下界和时间戳上界构成;
所述第一获取单元,用于基于所述第一逻辑生命周期,确定所述数据读取请求指示的待读取数据项的可见版本数据;基于所述可见版本数据的创建时间戳和所述第一逻辑生命周期,确定所述目标事务的第二逻辑生命周期;将携带所述第二逻辑生命周期和所述可见版本数据的结果作为所述数据读取结果。
在一种可能实现方式中,所述事务验证请求携带所述目标事务的第三逻辑生命周期,所述第三逻辑生命周期为由所述协调节点设备基于所述第一逻辑生命周期和所述第二逻辑生命周期确定的有效逻辑生命周期;
所述第二获取单元,用于将所述第三逻辑生命周期的时间戳下界和所述第二逻辑生命周期的时间戳下界中的最大值作为所述目标事务的第四逻辑生命周期的时间戳下界;将所述第三逻辑生命周期的时间戳上界和所述第二逻辑生命周期的时间戳上界中的最小值作为所述目标事务的第四逻辑生命周期的时间戳上界;响应于所述第四逻辑生命周期有效,基于所述本地写集对应的各个待写入数据项的读事务相关信息和所述第四逻辑生命周期,确定所述目标事务的第五逻辑生命周期;响应于所述第五逻辑生命周期有效,将用于指示验证通过的验证结果作为所述目标事务的验证结果;响应于所述第五逻辑生命周期无效,将用于指示验证不通过的验证结果作为所述目标事务的验证结果。
在一种可能实现方式中,任一待写入数据项的读事务相关信息包括所述任一待写入数据项的最大读事务时间戳,所述任一待写入数据项的最大读事务时间戳用于指示读取过所述任一待写入数据项的各个读事务的逻辑提交时间戳中的最大值;
所述第二获取单元,还用于基于所述各个待写入数据项的最大读事务时间戳和所述第四逻辑生命周期,确定所述目标事务的第五逻辑生命周期,所述第五逻辑生命周期的时间戳下界大于所述各个待写入数据项的最大读事务时间戳中的最大值。
在一种可能实现方式中,任一待写入数据项的读事务相关信息包括所述任一待写入数据项的目标读事务的结束时间戳,所述目标读事务为本地验证通过或者处于提交阶段的读事务,所述目标读事务的结束时间戳为所述目标读事务的逻辑生命周期的时间戳上界;
所述第二获取单元,还用于基于所述各个待写入数据项的目标读事务的结束时间戳和所述第四逻辑生命周期,确定所述目标事务的第五逻辑生命周期,所述第五逻辑生命周期的时间戳下界大于所述各个待写入数据项的目标读事务的结束时间戳中的最大值。
另一方面,提供了一种计算机设备,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条计算机程序,所述至少一条计算机程序由所述处理器加载并执行,以实现上述任一所述的事务处理方法。
另一方面,还提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有至少一条计算机程序,所述至少一条计算机程序由处理器加载并执行,以实现上述任一所述的事务处理方法。
另一方面,还提供了一种计算机程序产品或计算机程序,所述计算机程序产品或计算机程序包括计算机指令,所述计算机指令存储在计算机可读存储介质中。计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令,处理器执行所述计算机指令,使得所述计算机设备执行上述任一所述的事务处理方法。
本申请实施例提供的技术方案至少带来如下有益效果:
在本申请实施例中,根据各个节点设备分别对应的事务分配指标确定用于协调处理目标事务的协调节点设备,事务的分配过程无需考虑事务涉及的数据项,也无需考虑数据项的分布情况。基于此种方式,每个节点设备均能够作为去中心化的设备协调处理事务,使得事务能够跨节点处理,有利于提高事务的处理效率,事务处理的可靠性较高,有利于提升数据库系统的系统性能。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种事务处理方法的实施环境的示意图;
图2是本申请实施例提供的一种事务处理方法的流程图;
图3是本申请实施例提供的一种事务日志的格式示意图;
图4是本申请实施例提供的一种事务日志的格式示意图;
图5是本申请实施例提供的一种事务处理装置的示意图;
图6是本申请实施例提供的一种事务处理装置的示意图;
图7是本申请实施例提供的一种事务处理装置的示意图;
图8是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
需要说明的是,本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在介绍本申请实施例之前,需要引入一些云技术领域内的基本概念。
云技术(Cloud Technology):是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术,云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台系统进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的系统后盾支撑,需要通过云计算来实现。
云存储(Cloud Storage):是在云计算概念上延伸和发展出来的一个新的概念,分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能,将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作,共同对外提供数据存储和业务访问功能的一个存储系统。
数据库(Database):简而言之可视为一种电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
在一些实施例中,本申请实施例还可以应用于一种基于区块链技术的数据库系统(以下简称为“区块链系统”),上述区块链系统在本质上属于一种去中心化式的分布式数据库系统,采用共识算法保持区块链上不同节点设备所记载的账本数据一致,通过密码算法保证不同节点设备之间账本数据的加密传送以及不可篡改,通过脚本系统来拓展账本功能,通过网络路由来进行不同节点设备之间的相互连接。
在区块链系统中可以包括一条或多条区块链,区块链是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。
区块链系统中节点设备之间可以组成点对点(Peer To Peer,P2P)网络,P2P协议是一个运行在传输控制协议(Transmission Control Protocol,TCP)协议之上的应用层协议。在区块链系统中,任一节点设备可以具备如下功能:1)路由,节点设备具有的基本功能,用于支持节点设备之间的通信;2)应用,用于部署在区块链中,根据实际业务需求而实现特定业务,记录实现功能相关的数据形成账本数据,在账本数据中携带数字签名以表示数据来源,将账本数据发送至区块链系统中的其他节点设备,供其他节点设备在验证账本数据来源以及完整性成功时,将账本数据添加至临时区块中,其中,应用实现的业务可以包括钱包、共享账本、智能合约等;3)区块链,包括一系列按照先后的时间顺序相互接续的区块,新区块一旦加入到区块链中就不会再被移除,区块中记录了区块链系统中节点设备提交的账本数据。
在一些实施例中,每个区块中可以包括本区块存储交易记录的哈希值(本区块的哈希值)以及前一区块的哈希值,各区块通过哈希值连接形成区块链。另外,区块中还可以包括有区块生成时的时间戳等信息,区块中还可以包括本申请实施例涉及的事务的状态信息。
在一些实施例中,本申请实施例所涉及的分布式数据库系统,是一种基于共享存储(share-disk)架构的分布式数据库系统,在基于共享存储的分布式数据库系统中包括至少两个节点设备,该至少两个节点设备具有自己本地的内存区域,通过网络通讯机制直接访问同一个存储系统,即至少两个节点设备共享同一个存储系统。例如,共享同一个HDFS(Hadoop Distributed File System,分布式文件系统)。至少两个节点设备共享的存储系统中可以存储有多个数据表,每个数据表可以用于存储一个或多个数据项。
从逻辑的角度出发,可以将分布式数据库系统中的节点设备划分为两种角色:协调节点设备和数据节点设备,其中,协调节点设备主要负责生产、分发处理计划,以及协调分布式事务,而数据节点设备则主要负责接收协调节点设备发来的处理计划,执行相应的事务并向协调节点设备返回事务涉及的相关数据。
在分布式数据库系统中,最小的操作执行单元为事务,依据事务是否需要对多个数据节点设备上的数据项进行操作,事务可以被划分为分布式事务和本地事务两种,针对这两种不同的事务,可以分别采取不同的执行流程,以尽量减少网络通信开销,提升事务处理效率。其中,分布式事务表示事务需要跨多个数据节点设备执行读写操作,也即事务需要对多个数据节点设备上的数据项进行操作,例如,事务T需要操作数据节点设备RM1、RM2、RM3上的数据项,那么该事务T为一个分布式事务;本地事务表示事务只需要对单个数据节点设备上的数据项进行操作,例如,事务T只需要操作RM1上的数据项,则该事务T为一个本地事务。
图1是本申请实施例提供的一种事务处理方法的实施环境的示意图。参见图1,本申请实施例可以应用于基于share-disk框架的分布式数据库系统中,该分布式数据库系统中可以包括网关服务器101、事务分配设备102、分布式存储集群103以及全局时间戳生成集群104。分布式存储集群103中包括m(m为不小于2的整数)个节点设备,该m个节点设备共享同一个存储系统。
网关服务器101用于接收外部的读写请求,并将读写请求对应的读写事务分发至事务分配设备102或者分布式存储集群103。比如,用户在登录终端上的应用客户端之后,触发应用客户端生成读写请求,调用分布式数据库系统提供的API(ApplicationProgramming Interface,应用程序编程接口)将该读写请求对应的读写事务发送至网关服务器101。
在一些实施例中,网关服务器101可以与分布式存储集群103中的任一个节点设备合并在同一个物理机上,也即是,让某个节点设备充当网关服务器101。
在一些实施例中,应用客户端所在的终端能够与分布式数据库系统中的事务分配设备102和分布式存储集群103直接建立通信连接,此种情况下,分布式数据库系统中可以不存在网关服务器101。
事务分配设备102用于为新事务分配合适的节点设备作为协调节点设备。在示例性实施例中,事务分配设备处于分布式协调系统(如ZooKeeper)中。分布式协调系统可以用于对网关服务器101、分布式存储集群103和全局时间戳生成集群104中的至少一项进行管理,可选地,技术人员可以通过终端上的调度器(scheduler)访问该分布式协调系统,从而基于前端的调度器来控制后端的分布式协调系统,实现对各个集群或服务器的管理。例如,技术人员可以通过调度器来控制ZooKeeper将某一个节点设备从分布式存储集群103中删除,也即是使得某一个节点设备失效。
分布式存储集群103可以包括数据节点设备和协调节点设备,每个协调节点设备可以对应于至少一个数据节点设备,数据节点设备与协调节点设备的划分是针对不同事务而言的,以某一分布式事务为例,分布式事务的发起节点可以称为协调节点设备,分布式事务所涉及的其他节点设备称为数据节点设备,数据节点设备或协调节点设备的数量可以是一个或多个,本申请实施例不对分布式存储集群103中数据节点设备或协调节点设备的数量进行具体限定。
由于本申请实施例所提供的分布式数据库系统中缺乏全局事务管理器,因此在该系统中可以采用XA(eXtended Architecture,X/Open组织分布式事务规范)/2PC(Two-Phase Commit,二阶段提交)技术来支持跨节点的事务(分布式事务),保证跨节点写操作时数据的原子性和一致性,此时,协调节点设备用于充当2PC算法中的协调者,而该协调节点设备所对应的各个数据节点设备用于充当2PC算法中的参与者。
每个数据节点设备或者协调节点设备可以是单机设备,也可以采用主备结构(也即是为一主多备集群),如图1所示,以节点设备(数据节点设备或协调节点设备)为一主两备集群为例进行示意,每个节点设备中包括一个主机和两个备机,可选地,每个主机或备机都对应配置有代理(agent)设备,代理设备可以与主机或备机是物理独立的,当然,代理设备还可以作为主机或备机上的一个代理模块,以节点设备1为例,节点设备1包括一个主数据库及代理设备(主database+agent,简称主DB+agent),此外还包括两备数据库及代理设备(备database+agent,简称备DB+agent)。
全局时间戳生成集群104用于生成分布式事务的全局提交时间戳(GlobalTimestamp,Gts),该分布式事务可以是指涉及到多个数据节点设备的事务,例如分布式读事务可以涉及到对多个数据节点设备上存储数据的读取,又例如,分布式写事务可以涉及到对多个数据节点设备上的数据写入。全局时间戳生成集群104在逻辑上可以视为一个单点,但在一些实施例中可以通过一主三从的架构来提供具有更高可用性的服务,采用集群的形式来实现该全局提交时间戳的生成,可以防止单点故障,也就规避了单点瓶颈问题。
可选地,全局提交时间戳是一个在分布式数据库系统中全局唯一且单调递增的时间戳标识,能够用于标志每个事务全局提交的顺序,以此来反映出事务之间在真实时间上的先后关系(事务的全序关系),全局提交时间戳可以采用物理时钟、逻辑时钟或者混合物理时钟中至少一项,本申请实施例不对全局提交时间戳的类型进行具体限定。
在一些实施例中,该全局时间戳生成集群104可以是物理独立的,也可以和分布式协调系统(例如ZooKeeper)合并到一起。
上述图1仅是提供了一种轻量级的事务处理的架构图,是一种基于share-disk架构的分布式数据库系统的示例性描述。在一些实施例中,上述网关服务器101、事务分配设备102、分布式存储集群103以及全局时间戳生成集群104所构成的分布式数据库系统,可以视为一种向用户终端提供数据服务的服务器,该服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(ContentDelivery Network,内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。可选地,上述用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等,但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本申请在此不做限制。
基于上述图1所示的实施环境,本申请实施例提供一种事务处理方法。如图2所示,本申请实施例提供的方法包括如下步骤201至步骤209。
在步骤201中,事务分配设备响应于目标事务的分配请求,确定至少两个节点设备分别对应的事务分配指标,任一节点设备对应的事务分配指标用于指示为任一节点设备分配新事务的匹配度。
事务分配设备和至少两个节点设备均处于分布式数据库系统中,且至少两个节点设备共享同一个存储系统。本申请实施例对分布式数据系统的具体结构不加以限定,只要包括事务分配设备和共享同一个存储系统的至少两个节点设备即可。
目标事务是指待处理的事务,目标事务可以是分布式事务,也可以是本地事务,本申请实施例对此不加以限定。目标事务的分配请求用于指示为目标事务分配合适的节点设备作为协调节点设备,以由分配的协调节点设备协调处理该目标事务。
目标事务的分配请求由终端发起,终端发起的目标事务的分配请求由终端直接发送给事务分配设备,或者由网关服务器转发给事务分配设备,本申请实施例对此不加以限定。终端可以是用户所对应的任一电子设备,包括但不限于:智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱或者智能手表中至少一项,本申请实施例不对终端的类型进行具体限定。可选地,在终端上安装有应用客户端,该应用客户端可以是能够提供数据服务的任一客户端,例如,该应用客户端可以是支付应用客户端、外卖应用客户端、打车应用客户端或者社交应用客户端中至少一项,本申请实施例不对应用客户端的类型进行具体限定。
至少两个节点设备是指分布式数据库系统中能够作为去中心化的节点设备协调处理事务的节点设备,每个节点设备均能够用于通过去中心化的算法协调处理分布式事务。
事务分配设备在接收到目标事务的分配请求后,需要为目标事务分配合适的节点设备作为协调节点设备,以保证事务处理的效率。在为目标事务分配合适的节点设备作为协调节点设备的过程中,事务分配设备先确定至少两个节点设备分别对应的事务分配指标。任一节点设备对应的事务分配指标用于指示为任一节点设备分配新事务的匹配度。为任一节点设备分配新事务的匹配度越高,说明越适合为该任一节点设备分配新事务。
事务分配指标是从事务的角度确定的用于衡量是否适合为某一节点设备分配新事务的指标。在一种可能实现方式中,确定至少两个节点设备分别对应的事务分配指标的过程包括以下步骤2011和步骤2012。
步骤2011:确定事务分配模式,事务分配模式包括基于事务繁忙程度进行分配、基于设备繁忙程度进行分配和基于混合繁忙程度进行分配中的任一种。
事务分配模式用于指示确定节点设备对应的事务分配指标的确定方式。在一些实施例中,事务分配模式由开发人员设置并上传至事务分配设备。需要说明的是,不同时期采用的事务分配模式可能不同。在此步骤2011中确定的是在接收到目标事务的分配请求时应该采用的事务分配模式。
事务分配模型包括基于事务繁忙程度进行分配、基于设备繁忙程度进行分配和基于混合繁忙程度进行分配中的任一种。其中,基于事务繁忙程度进行分配的模式是指从考虑节点设备的事务处理数量的角度确定事务分配指标,节点设备的事务处理数量能够反映出节点设备的事务繁忙程度。基于设备繁忙程度进行分配的模式是指从考虑节点设备的设备资源使用率的角度确定事务分配指标,调节点设备的设备资源使用率能够反映出节点设备的设备繁忙程度。基于混合繁忙程度进行分配的模式是指从综合考虑节点设备的事务处理数量以及节点设备的设备资源使用率的角度确定事务分配指标,节点设备的事务处理数量以及节点设备的设备资源使用率能够反映出节点设备的混合繁忙程度。
步骤2012:根据事务分配模式指示的确定方式,确定至少两个节点设备分别对应的事务分配指标。
不同的事务分配模式指示的确定方式不同,在确定事务分配模式后,根据事务分配模式指示的确定方式,确定至少两个节点设备分别对应的事务分配指标。接下来分别介绍不同的事务分配模式下,确定至少两个节点设备中的任一节点设备对应的事务分配指标的方式。
在一些实施例中,事务分配模式为基于事务繁忙程度进行分配。在此种情况下,根据事务分配模式指示的确定方式,确定任一节点设备对应的事务分配指标的方式为:基于该任一节点设备的事务处理数量,确定该任一节点设备对应的事务分配指标。
任一节点设备的事务处理数量是指任一节点设备在单位时间内需要处理的事务的数量,需要说明的是,此处的需要处理的事务是指已经分配给该任一节点设备进行处理的事务。任一节点设备在单位时间内需要处理的事务的数量越多,说明越不适合为该任一节点设备分配新事务。在示例性实施例中,任一节点设备的事务处理数量可以由该任一节点设备反馈给事务分配设备,也可以由事务分配设备根据事务分配情况自行确定,本申请实施例对此不加以限定。
本申请实施例对事务分配指标的表现形式不加以限定,示例性地,事务分配指标的表现形式为繁忙级别或数值。
示例性地,当事务分配指标的表现形式为繁忙级别时,基于该任一节点设备的事务处理数量确定该任一节点设备对应的事务分配指标的方式为:为不同的繁忙级别设置不同的事务处理数量范围,将该任一节点设备的事务处理数量所处的事务处理范围对应的繁忙级别作为该任一节点设备对应的繁忙级别。示例性地,繁忙级别包括“繁忙”、“部分繁忙”和“清闲”,“繁忙”对应的事务处理数量范围为[10,+∞),“部分繁忙”对应的事务处理数量范围为[3,10),“清闲”对应的事务处理数量范围为[0,3),若任一节点设备的事务处理数量为2,则将“清闲”作为该任一节点设备对应的事务分配指标。任一节点设备对应的事务分配指标越接近“清闲”,说明为该任一节点设备分配新事务的匹配度越高。
示例性地,当事务分配指标的表现形式为数值时,基于该任一节点设备的事务处理数量确定该任一节点设备对应的事务分配指标的方式为:对该任一节点设备的事务处理数量进行数值化处理,将数值化处理后得到的数值作为该任一节点设备对应的事务分配指标。对事务处理数量进行数值化处理的方式根据经验设置,或者根据应用场景灵活调整,本申请实施例对此不加以限定。示例性地,对事务处理数量进行数值化处理的方式为:计算事务处理数量和参考权重的乘积。在此种方式下,事务处理数量越多,数值化处理后得到的数值越大。任一节点设备对应的事务分配指标越小,说明为该任一节点设备分配新事务的匹配度越高。
在一些实施例中,事务分配模式为基于设备繁忙程度进行分配。在此种情况下,根据事务分配模式指示的确定方式,确定任一节点设备对应的事务分配指标的方式为:基于该任一节点设备的设备资源使用率确定该任一节点设备对应的事务分配指标。
任一节点设备的设备资源使用率是指任一节点设备已经使用的设备资源占用总设备资源的比率,示例性地,设备资源是指CPU(Central Processing Unit,中央处理器)资源。任一节点设备的设备资源使用率越高,说明越不适合为该任一节点设备分配新事务。需要说明的是,任一节点设备的设备资源使用率可以由该任一节点设备实时监控并反馈给事务分配设备,也可以由事务分配设备自行监控得到,本申请实施例对此不加以限定。
基于该任一节点设备的设备资源使用率确定该任一节点设备对应的事务分配指标的方式参见基于该任一节点设备的事务处理数量确定该任一节点设备对应的事务分配指标的方式,此处不再赘述。
在一些实施例中,事务分配模式为基于混合繁忙程度进行分配。在此种情况下,根据事务分配模式指示的确定方式,确定任一节点设备对应的事务分配指标的方式为:基于任一节点设备的事务处理数量、任一节点设备的设备资源使用率、事务处理数量权重、设备资源使用率权重以及权重调节参数,确定任一节点设备对应的事务分配指标。
在示例性实施例中,事务处理数量权重和设备资源使用率权重用于调节事务处理数量和设备资源使用率这两个参数的百分占比,可实测得到,示例性地,事务处理数量权重和设备资源使用率权重的默认值均为1;权重调节参数是指设备资源使用率和事务处理数量的相对占比因子,用以调节设备资源使用率和事务处理数量的权重分配,可实测得到,示例性地,权重调节参数的默认值为0.33。
示例性地,利用p1表示设备资源使用率权重,利用p2表示事务处理数量权重,利用w表示权重调节参数,则任一节点设备对应的事务分配指标Q可以表示为:Q=p1×设备资源使用率+p2×w×事务处理数量。
在一些实施例中,在基于混合繁忙程度进行分配的模式中,除了综合考虑事务处理数量和设备资源使用率外,还可以考虑其他方面的因素,如,需要处理的事务中长事务的数量等。在此种情况下,任一节点设备对应的事务分配指标Q可以表示为:Q=p1×设备资源使用率+p2×w×事务处理数量+p3×其他因素。其中,p3表示其他因素权重,p3可根据其他因素的类型实测得到,示例性地,p3的默认值为1。任一节点设备对应的事务分配指标Q越小,说明为该任一节点设备分配新事务的匹配度越高。
需要说明的是,以上所述仅从任一节点设备的角度介绍了确定任一节点设备对应的事务分配指标的过程,根据上述方式能够确定分布式数据库系统中的至少两个节点设备分别对应的事务分配指标,进而执行步骤202。
在步骤202中,事务分配设备基于至少两个节点设备分别对应的事务分配指标,在至少两个节点设备中确定目标事务的协调节点设备,由协调节点设备对目标事务进行协调处理。
目标事务的协调节点设备是指至少两个节点设备中适合分配新事务的节点设备。目标事务的协调节点设备用于对目标事务进行协调处理,也就是说,目标事务的协调节点设备是指目标事务的协调者。示例性地,对目标事务进行协调处理的过程是指在分布式数据库系统中发起目标事务,然后组织目标事务的数据节点设备共同处理该目标事务的过程。目标事务的数据节点设备是指至少两个节点设备中用于参与处理目标事务的节点设备,也就是说,目标事务的数据节点设备是指目标事务的参与者。
需要说明的是,本申请实施例中提到的协调节点设备和数据节点设备均是针对目标事务而言的,对不同的事务而言协调节点设备或者数据节点设备并非是固定不变的,也即是说,同一节点设备有可能对一些事务而言属于协调节点设备,对另一些事务而言属于数据节点设备。
基于至少两个节点设备分别对应的事务分配指标,在至少两个节点设备中确定目标事务的协调节点设备的方式根据事务分配指标的表现形式不同有所不同,本申请实施例对此不加以限定,只要能够保证协调节点设备为当前适合分配新事务的节点设备即可。
在一些实施例中,事务分配指标的表现形式为繁忙级别,繁忙级别分别为“繁忙”、“部分繁忙”和“清闲”。此种情况下,基于至少两个节点设备分别对应的事务分配指标,在至少两个节点设备中确定目标事务的协调节点设备的方式为:将至少两个节点设备中对应的事务分配指标为“清闲”的节点设备作为备选节点设备,在备选节点设备中任选一个节点设备作为目标事务的协调节点设备。
示例性地,若不存在对应的事务分配指标为“清闲”的节点设备,则将至少两个节点设备中对应的事务分配指标为“部分繁忙”的节点设备作为备选节点设备,进而在备选节点设备中任选一个节点设备作为目标事务的协调节点设备。示例性地,若至少两个节点设备对应的事务分配指标均为“繁忙”,则暂停确定目标事务的协调节点设备,等待参考时长后重新确定至少两个节点设备分别对应的事务分配指标,进而重新确定目标事务的协调节点设备。参考时长根据经验设置,例如,参考时长为实测的完成一个事务的平均时长。
在一些实施例中,事务分配指标的表现形式为数值,且任一节点设备对应的事务分配指标越小,说明为该任一节点设备分配新事务的匹配度越高。在此种情况下,基于至少两个节点设备分别对应的事务分配指标,在至少两个节点设备中确定目标事务的协调节点设备的方式为:将至少两个节点设备中对应前s(s为不小于1的整数)小事务分配指标的节点设备作为备选节点设备,在备选节点设备中任选一个节点设备作为目标事务的协调节点设备。s的取值根据经验设置,或者根据至少两个节点设备的总数量灵活调整,本申请实施例对此不加以限定,例如,s的取值为1,或者s的取值为3等。
需要说明的是,以上所述仅为基于至少两个节点设备分别对应的事务分配指标,在至少两个节点设备中确定目标事务的协调节点设备的方式的示例性描述,本申请实施例并不局限于此。示例性地,对于事务分配指标的表现形式为数值,且任一节点设备对应的事务分配指标越大,说明为该任一节点设备分配新事务的匹配度越高的情况,将至少两个节点设备中对应前t(t为不小于1的整数)大事务分配指标的节点设备作为备选节点设备,在备选节点设备中任选一个节点设备作为目标事务的协调节点设备。
基于事务分配指标确定出的目标事务的协调节点设备为至少两个节点设备中适合分配新事务的节点设备,进而将目标事务分配给该协调节点设备,由该协调节点设备对该目标事务进行协调处理,有利于保证目标事务的处理效率。
相关技术中,每个节点设备为一定数量的区域(region)服务,每个节点设备均维护该节点设备服务的区域中的数据项的分布信息,数据项的分布信息用于指示数据项的存储位置。此外,事务分配设备中维护有区域的元信息。在此种架构下,相关技术中,事务分配设备根据维护的区域的元信息,确定用于为目标事务涉及的数据项所在的区域服务的节点设备,进而由该节点设备独立处理目标事务。在此种方式下,极大程度上限制了事务的处理效率,无法支持真正的分布式事务,不具备良好的带有事务属性特征的全局一致性多读和一致性多写的能力。
本申请实施例中,节点设备不再为某些固定的区域服务,节点设备不再维护数据项的分布信息,事务分配设备也不再维护区域的元信息。示例性地,将区域的元信息分布在分布式数据库系统中的整个共享的存储系统中。基于此种改进,事务分配节点设备能够基于事务分配指标为目标事务分配合适的节点设备作为协调节点设备,无需考虑事务涉及的数据项,也无需考虑数据项的分布情况。节点设备能够根据事务中的SQL(StructuredQuery Language,结构化查询语言)语句的需求,自动从共享的存储系统中调入数据。在此种方式下,每个节点设备均能够作为去中心化的节点设备协调处理分布式事务,使得分布式数据库系统具有去中心化的分布式事务处理能力。
在一种可能实现方式中,在确定目标事务的协调节点设备之后,还包括:将协调节点设备的设备标识信息发送给发起该分配请求的终端,终端用于根据协调节点设备的设备标识信息,将目标事务的事务信息发送给协调节点设备,由协调节点设备基于事务信息对目标事务进行协调处理。
协调节点设备的设备标识信息用于唯一标识该协调节点设备,通过将协调节点设备的设备标识信息发送给发起分配请求的终端,能够使终端获知用于协调处理目标事务的协调节点设备。终端在根据设备标识信息获知用于协调处理目标事务的协调节点设备后,将目标事务的事务信息发送给协调节点设备。目标事务的事务信息用于指示目标事务的相关处理操作,示例性地,目标事务的事务信息是指SQL语句。
在一种可能实现方式中,终端直接将目标事务的事务信息发送给协调节点设备;或者,终端将目标事务的事务信息以及协调节点设备的设备标识信息发送给网关服务器,由网关服务器将目标事务的事务信息转发给协调节点设备。
协调节点设备在接收到目标事务的事务信息后,基于事务信息协调处理目标事务。协调节点设备能够解析事务信息,如,SQL语句,生成事务执行计划,然后通过与相关的数据节点设备进行通信完成目标事务的处理。
在示例性实施例中,由于目标事务的协调节点设备是根据事务分配指标确定的,不同的事务能够利用不同的节点设备进行协调处理,所以本申请实施例提供的方法能够实现去中心化的事务处理过程。在去中心化的事务处理过程中,多个分布式事务分别由多个节点设备进行协调处理。在目标事务的协调节点设备协调处理目标事务的过程中,若存在多个分布式事务,则协调节点设备与其他节点设备建立通讯,获取其他节点设备在协调处理其他分布式事务的过程中产生的数据信息,进而根据获取的数据信息做数据异常或可串行化的验证,以判断目标事务是否符合事务一致性,保证事务处理技术是正确的。在示例性实施例中,协调节点设备将其他节点设备传来的数据信息缓冲在临时数据缓冲区中,目标事务结束而被清理。
在一种可能实现方式中,对于发起目标事务的分配请求的终端而言,该终端在接入分布式数据库系统后,若产生了其他事务,每个其他事务均由协调节点设备进行协调处理;或者,每个其他事务均由事务分配设备根据节点设备的事务分配指标实时分配适合的节点设备作为协调节点设备,本申请实施例对此不加以限定。
在步骤203中,协调节点设备获取目标事务的事务信息。
目标事务的事务信息可以由目标事务的创建终端直接发送给协调节点设备,也可以由网关服务器转发给协调节点设备,本申请实施例对此不加以限定。示例性地,目标事务的事务信息是指用于实现目标事务的SQL语句。
在一种可能实现方式中,协调节点设备在获取目标事务的事务信息后,对目标事务进行初始化。对目标事务进行初始化的阶段可认为是建立事务的快照阶段。此阶段能够建立全局的一致性快照点,保障全局读一致性。
在一种可能实现方式中,在对目标事务进行初始化的过程中,协调节点设备可以执行下述两项初始化操作中的至少一项。
初始化操作一:协调节点设备为目标事务分配一个全局唯一的事务标识TID。
该事务标识TID用于唯一标识该目标事务。
初始化操作二:协调节点设备在第一事务状态列表中记录目标事务的初始状态信息。
本申请实施例将协调节点设备维护的事务状态列表称为第一事务状态列表,该第一事务状态列表为去中心框架下用于记录目标事务的全局状态的全局状态列表。
在示例性实施例中,第一事务状态列表中记录的目标事务的状态信息包括但不限于目标事务的事务标识、目标事务的全局事务状态和目标事务的逻辑生命周期。其中,逻辑生命周期由时间戳下界和时间戳上界构成。逻辑生命周期的时间戳下界称为目标事务的开始时间戳(Begintimestamp,Bts),逻辑生命周期的时间戳上界称为目标事务的结束时间戳(Endtimestamp,Ets),也就是说,逻辑生命周期由时间戳下界Bts和时间戳上界Ets构成。
在目标事务的初始状态信息中,目标事务的事务标识TID为初始化操作一中分配的,目标事务的全局事务状态Status为Grunning(全局正在运行),目标事务的逻辑生命周期为第一逻辑生命周期,该第一逻辑生命周期的时间戳下界Bts为全局的唯一递增时间戳值,第一逻辑生命周期的时间戳上界Ets为+∞。
在示例性实施例中,第一逻辑生命周期的时间戳下界Bts和时间戳上界Ets的获取方式为:对于可串行化级别之上的隔离级别,协调节点设备从全局时钟获取时间戳值;对于可串行化级别以及更弱的隔离级别而言,协调节点设备从本地的混合逻辑时钟(HybridLogical Clock,HLC)获取时间戳值。当然,在一些实施例中,对于可串行化级别以及更弱的隔离级别,协调节点设备也能够通过从全局时钟获取时间戳值的方式获取第一逻辑生命周期的时间戳下界Bts和时间戳上界Ets。在示例性实施例中,对于可串行化级别以及更弱的隔离级别而言,从本地的HLC获取时间戳值的效率较高。
全局时钟是指全局逻辑时钟生成器生成的时钟,具备单调递增的特性,形式上可以是walltime(墙上时间),也可以是自然数N等。示例性地,全局时钟由分布式数据库系统中的全局时间戳生成集群提供。示例性地,对于基于share-disk架构的分布式数据库系统而言,全局时钟由分布式数据库系统中的存储系统通过API的方式提供。示例性地,全局逻辑时钟生成器能够为事务的开始时间戳Bts、事务的结束时间戳Ets赋值,还能够为WAL(Write Ahead Logging,提前写日志)的全局LSN(Log Sequence Number日志序列号)赋值。
在一些实施例中,全局时钟是一个逻辑概念,为全系统提供统一的单调递增值;物理形态可以是一个全局的物理时钟,也可以是一个全局的逻辑时钟。全局时钟的实现形态,可以有多种方式。如,全局时钟是一个类似Google(谷歌)的“Truetime(一种时钟机制)”机制的分布式去中心化的时钟;或者,全局时钟是一个采取多个冗余节点(如,一致性协议(Paxos/Raft等)构造的集群)的主备系统统一提供的时钟;再或者,全局时钟是一个具有精准同步机制协同节点退出机制的一种算法机制提供的时钟。
在示例性实施例中,一个事务的Bts和Ets的构成均由8字节组成。8字节分为两个部分,第一部分为物理时间戳的取值(即Unix(一种操作系统)时间戳,精确到毫秒),用于标识全局时间(用gts表示);第二部分为在某一毫秒内的单调递增计数,用于标识在全局时间上的相对时间(即局部时间,用
lts表示)。示例性地,8字节中的前44位为第一部分,这样共可表示2
44个无符号整数,因此理论上一共可以表示约为557.8
年的物理时间戳;8字节中的后20位为第二部分,这样,每毫秒有2
20个(约100万个)计数。在示例性实施例中,也可以调整两个部分的位数,使得全局时间gts和局部时间
lts表示的范围发生变化。
需要说明的是,根据实际需要,一个事务的Bts和Ets的构成可由多于8字节的字节组成或者由少于8字节的字节组成。示例性地,将Bts和Ets的构成调整为由10字节组成,使得局部时间lts增大,以应对更大的并发事务数量。
示例性地,对于由全局时间gts和局部时间lts这两部分构成的两个时间戳Ti.bts和Tj.bts而言,如果Ti.bts.gts<Tj.bts.gts,或者Ti.bts.gts=Tj.bts.gts且Ti.bts.lts<Tj.bts.lts,则认为Ti.bts<Tj.bts。
在步骤204中,协调节点设备基于目标事务的事务信息,向数据节点设备发送数据读取请求,数据节点设备为至少两个节点设备中用于参与处理目标事务的节点设备。
协调节点设备对目标事务进行初始化后,开始目标事务的执行阶段,事务的执行阶段可认为事务语义实现操作阶段。
数据节点设备为至少两个节点设备中用于参与处理目标事务的节点设备,数据节点设备能够获取目标事务涉及的数据项,即本申请实施例中的数据节点设备为目标事务相关的数据节点设备。目标事务的事务信息中携带需要读取的数据的相关信息,协调节点设备能够根据目标事务的事务信息,生成数据读取请求,然后向数据节点设备发送数据读取请求。
在一种可能实现方式中,数据读取请求表示为ReadRequestMessage(读请求消息),简称rrqm。
在一种可能实现方式中,数据读取请求携带目标事务的第一逻辑生命周期、目标事务的事务标识和读取计划。第一逻辑生命周期利用时间戳下界Bts和时间戳上界Ets表示。读取计划是指目标事务对应的数据读取计划,用于指示需要读取的数据项。在示例性实施例中,事务标识、时间戳下界Bts、时间戳上界Ets和读取计划分别记录在rrqm的四个字段中。
需要说明的是,数据节点设备的数量可以为一个或多个,本申请实施例中不对数据节点设备的数量进行具体限定。对于数据节点设备的数量为多个的情况,向不同的数据节点设备发送的数据读取请求中携带的读取计划不同,以指示需要在不同的数据节点设备中读取不同的数据项。
在步骤205中,数据节点设备基于协调节点设备发送的数据读取请求,获取数据读取结果,将数据读取结果返回协调节点设备。
数据节点设备在获取数据读取请求后,基于数据读取请求,获取数据读取结果。在一种可能实现方式中,对于数据读取请求携带目标事务的第一逻辑生命周期的情况,数据节点设备基于数据读取请求,获取数据读取结果的过程包括以下步骤2051至步骤2053。
步骤2051:基于第一逻辑生命周期,确定数据读取请求指示的待读取数据项的可见版本数据。
数据节点设备能够基于数据读取请求携带的读取计划,确定目标事务需要读取的数据项,将目标事务需要读取的数据项作为待读取数据项。待读取数据项的可见版本数据是指待读取数据项对应的各版本数据中相对于目标事务可见的某一版本数据。示例性地,数据节点设备中设置有数据缓冲区,若数据缓冲区中存在待读取数据项的各版本数据,则数据节点设备直接从数据缓冲区中获取待读取数据项的各版本数据;若数据缓冲区中不存在待读取数据项的各版本数据,则数据节点设备从共享的存储系统中获取待读取数据项的各版本数据。
在示例性实施例中,数据节点设备在接收到数据读取请求后,先检查本地事务状态列表(Local TS)中是否包含目标事务的状态信息。本地事务状态列表为数据节点设备维护的事务状态列表,本地事务状态列表中记录有该数据节点设备参与的各未提交事务的状态信息。在示例性实施例中,数据节点设备在接收到数据读取请求后,根据数据读取请求携带的目标事务的事务标识,检查本地事务状态列表中是否包含目标事务的状态信息,检查结果包括以下两种。
检查结果1、本地事务状态列表中不包含目标事务的状态信息。
在此种情况下,可以在本地事务状态列表中初始化该目标事务的状态信息,即在Local TS中插入一条与目标事务相关的记录,该记录中的值分别为数据读取请求携带的目标事务的事务标识rrqm.TID、数据读取请求携带的目标事务的第一逻辑生命周期的时间戳下界rrqm.Bts、数据读取请求携带的目标事务的第一逻辑生命周期的时间戳上界rrqm.Ets以及数据读取请求指示的目标事务当前的事务状态rrqm.Running。
在此种情况下,基于第一逻辑生命周期,确定数据读取请求指示的待读取数据项的可见版本数据的方式为:确定待读取数据项相对于第一逻辑生命周期的可见版本数据。
检查结果2、本地事务状态列表中包含目标事务的状态信息。
在此种情况下,说明在接收到数据读取请求之前,目标事务已访问过该数据节点设备,此时,可以更新该数据节点设备上的目标事务的状态信息,更新方法为:将目标事务的逻辑生命周期的时间戳下界T.Bts更新为查询到的时间戳下界T.Bts与数据读取请求中携带的时间戳下界rrqm.Bts(即第一逻辑生命周期的时间戳下界)中的最大值,也即是说,令T.Bts=max(T.Bts,rrqm.Bts);此外,还将目标事务的逻辑生命周期的时间戳上界T.Ets更新为查询到的时间戳上界T.Ets与数据读取请求中携带的时间戳上界rrqm.Ets(即第一逻辑生命周期的时间戳上界)中的最小值,也即是说,令T.Ets= min(T.Ets,rrqm.Ets)。将更新后的时间戳下界和更新后的时间戳上界构成的逻辑生命周期作为更新后的逻辑生命周期。
在此种情况下,基于第一逻辑生命周期,确定数据读取请求指示的待读取数据项的可见版本数据的方式为:基于第一逻辑生命周期,确定更新后的逻辑生命周期;确定待读取数据项相对于更新后的逻辑生命周期的可见版本数据。
需要说明的是,确定待读取数据项相对于第一逻辑生命周期的可见版本数据实现方式与确定待读取数据项相对于更新后的逻辑生命周期的可见版本数据的实现方式类似,在本申请实施例中,以确定待读取数据项相对于第一逻辑生命周期的可见版本数据为例进行说明。
在一种可能实现方式中,在确定待读取数据项相对于第一逻辑生命周期的可见版本数据之前先对第一逻辑生命周期进行合法性检验,来判断第一逻辑生命周期是否有效。示例性地,对第一逻辑生命周期进行合法性检验的方式为:检验第一逻辑生命周期的时间戳下界是否小于第一逻辑生命周期的时间戳上界。当第一逻辑生命周期的时间戳下界不小于第一逻辑生命周期的时间戳上界,说明第一逻辑生命周期无效,此时,将本地事务状态列表中目标事务的事务状态由Running更新为Aborted(回滚)。此外,数据节点设备向协调节点设备返回携带Abort(回滚)消息的数据读取结果。数据读取结果表示为ReadReplyMessage(读取反馈消息),简称rrpm。对于数据读取结果携带Abort消息的情况,rrpm消息中的IsAbort字段等于1,即rrpm.IsAbort=1。
当第一逻辑生命周期的时间戳下界小于第一逻辑生命周期的时间戳上界时,说明第一逻辑生命周期有效,此时,执行确定待读取数据项相对于第一逻辑生命周期的可见版本数据的操作。
在一种可能实现方式中,确定待读取数据项相对于第一逻辑生命周期的可见版本数据的过程为:响应于待读取数据项的最新版本数据的创建时间戳小于第一逻辑生命周期的时间戳上界,将该最新版本数据作为可见版本数据;响应于待读取数据项的最新版本数据的创建时间戳不小于第一逻辑生命周期的时间戳上界,继续将待读取数据项的前一版本数据与第一逻辑生命周期的时间戳上界进行比对,直至确定出第一个创建时间戳小于第一逻辑生命周期的时间戳上界的某一版本数据,将该版本数据作为可见版本数据。
也就是说,数据节点设备在确定待读取数据项x相对于某一逻辑生命周期的可见版本数据的过程中,首先从待读取数据项x的最新版本数据开始检查,如果该逻辑生命周期的时间戳上界T.Ets大于最新版本数据的创建时间戳Wts,该最新版本数据即为相对于该逻辑生命周期的可见版本数据。否则,该最新版本数据不是相对于该逻辑生命周期的可见版本数据,需要查找前一版本数据,直到找到第一个满足T.Ets>Wts的某一版本数据x.v为止,将该版本数据x.v作为相对于该逻辑生命周期的可见版本数据。
在一种可能实现方式中,在确定出可见版本数据后,将该可见版本数据x.v存储到该目标事务的读集中。可选地,这里的读集可以是本地读集,也可以是全局读集,在本申请实施例中以该读集为本地读集为例进行说明,能够避免因同步全局读集而带来的通信开销。
在示例性实施例中,任一个事务的读集中记录了该事务需要读取的数据项的可见版本数据。需要说明的是,对一个分布式读事务而言,其读集可以划分为本地读集和全局读集,本地读集存在于数据节点设备上,而全局读集存在于协调节点设备上,当然,协调节点设备可以定期将全局读集同步至各个数据节点设备上,使得数据节点设备上也能够维护事务的全局读集。
步骤2052:基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期。
在确定可见版本数据后,数据节点设备基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期。
在一些实施例中,当可见版本数据是指相对于第一逻辑生命周期的可见版本数据时,该步骤2052的实现方式为:直接基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期。当可见版本数据是指相对于根据第一逻辑生命周期确定的更新后的生命周期的可见版本数据时,该步骤2052的实现方式为:基于可见版本数据的创建时间戳和根据第一逻辑生命周期确定的更新后的逻辑生命周期,确定目标事务的第二逻辑生命周期。本申请实施例以直接基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期为例进行说明。
在一种可能实现方式中,直接基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期的方式为:调整第一逻辑生命周期的时间戳下界,使其大于可见版本数据x.v的创建时间戳,即,使得T.Bts>x.v.Wts,以消除写读异常;将调整后得到的逻辑生命周期作为第二逻辑生命周期。
在另一种可能实现方式中,对于可见版本数据为待读取数据项的最新版本数据的情况,直接基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期的方式为:调整第一逻辑生命周期的时间戳下界,使其大于可见版本数据x.v的创建时间戳,即,使得T.Bts>x.v.Wts,以消除写读异常;响应于可见版本数据对应的待写事务不为空,调整第一逻辑生命周期的时间戳上界,使其小于可见版本数据对应的待写事务的逻辑生命周期的时间戳下界,即使得T.Ets<T0.Bts(T0表示可见版本数据对应的待写事务),以消除读写冲突;将调整后得到的逻辑生命周期作为第二逻辑生命周期。
可见版本数据对应的待写事务WT为正在修改可见版本数据所对应的数据项,且通过验证的事务。示例性地,通过记录待写事务的事务标识来记录待写事务。在一些实施例中,对于可见版本数据为最新版本数据的情况,将目标事务的事务标识添加到可见版本数据的活跃事务集合中;将可见版本数据添加到目标事务的本地读集中。
活跃事务集合(RTlist)用于记录访问过该最新版本数据的活跃事务,也可以称为读事务列表,该活跃事务集合可以是数组的形式,也可以是列表、队列、堆栈等形式,本申请实施例不对活跃事务集合的形式进行具体限定,RTlist中每个元素可以是读取过上述最新版本数据的事务的事务标识(TID)。
步骤2053:将携带第二逻辑生命周期和可见版本数据的结果作为数据读取结果。
在确定第二逻辑生命周期和可见版本数据后,数据节点设备将携带第二逻辑生命周期和可见版本数据的结果作为数据读取结果,然后将携带第二逻辑生命周期和可见版本数据的数据读取结果返回协调节点设备,以使协调节点设备获取第二逻辑生命周期和可见版本数据。示例性地,数据读取结果表示为ReadReplyMessage(读取反馈消息),简称rrpm。示例性地,携带第二逻辑生命周期和可见版本数据的rrpm中包括Bts、Ets和Value字段,其中,Bts字段和Ets字段分别记录了第二逻辑生命周期的时间戳下界和第二逻辑生命周期的时间戳上界,Value字段记录了可见版本数据的值。
在步骤206中,协调节点设备响应于数据节点设备返回的数据读取结果满足事务验证条件,向数据节点设备发送事务验证请求和本地写集。
在数据节点设备将数据读取结果返回协调节点设备后,协调节点设备判断数据读取结果是否满足事务验证条件,然后在确定数据读取结果满足事务验证条件时,向数据节点设备发送事务验证请求和本地写集,以使数据节点设备对目标事务进行验证。
示例性地,在协调节点设备判断数据读取结果是否满足事务验证条件的过程中,先判断数据读取结果是否携带Abort(回滚)消息,即检查rrpm中的IsAbort字段是否等于1。若数据读取结果携带Abort消息,即rrpm.IsAbort=1,则认为数据读取结果不满足事务验证条件,此时,进入到全局回滚阶段。
若数据读取结果不携带Abort消息,对第一事务状态列表中目标事务的逻辑生命周期进行更新,更新方式为:将第一逻辑生命周期的时间戳下界和第二逻辑生命周期的时间戳下界中的最大值作为目标事务的第三逻辑生命周期的时间戳下界,将第一逻辑生命周期的时间戳上界和第二逻辑生命周期的时间戳上界中的最小值作为目标事务的第三逻辑生命周期的时间戳上界。即,使T.Bts=max(T.Bts,rrpm.Bts)、T.Ets=min(T.Ets,rrpm.Ets);其中,括号内的T.Bts和T.Ets分别为更新前的逻辑生命周期(即第一逻辑生命周期)的时间戳下界和时间戳上界,rrpm.Bts和rrpm.Ets分别为数据读取结果携带的第二逻辑生命周期的时间戳下界和时间戳上界。
在对第一事务状态列表中目标事务的逻辑生命周期进行更新后,检查第一事务状态列表中的T.Bts是否小于T.Ets,即检查第三逻辑生命周期的时间戳下界是否小于第三逻辑生命周期的时间戳上界,以判断第三逻辑生命周期是否有效。当第三逻辑生命周期的时间戳下界不小于第三逻辑生命周期的时间戳上界时,第三逻辑生命周期无效,此种情况下,认为数据读取结果不满足事务验证条件,进入到全局回滚阶段;当第三逻辑生命周期的时间戳下界小于第三逻辑生命周期的时间戳上界时,第三逻辑生命周期有效,此种情况下,认为数据读取结果满足事务验证条件,向数据节点设备发送携带第三逻辑生命周期的事务验证请求。
在示例性实施例中,如果协调节点设备决定回滚目标事务,需要将第一事务状态列表中目标事务的全局事务状态修改为Gaborting(全局正在回滚),通知相关子节点(即数据节点设备)进行局部回滚。
在示例性实施例中,在发送事务验证请求之前,协调节点设备将第一事务状态列表中目标事务的全局事务状态修改为Gvalidating(全局正在验证)。示例性地,事务验证请求表示为ValidateRequestMessage(验证请求消息),简称vrm。示例性地,vrm中包括Bts和Ets字段。其中,Bts字段和Ets字段分别记录了目标事务在第一事务状态列表中最新的逻辑生命周期的时间戳下界和时间戳上界,即第三逻辑生命周期的时间戳下界和时间戳上界。
在一些实施例中,数据节点设备的数量为多个,在此种情况下,每个数据节点设备均返回一个数据读取结果,数据读取结果满足事务验证条件是指各个数据节点设备返回的各个数据读取结果均满足事务验证条件。此种情况下,第三逻辑生命周期为通过综合考虑各个数据读取结果确定的逻辑生命周期。
在一些实施例中,在读取完全部所需数据且将更新写到本地内存中后,认为满足事务验证条件。也就是说,协调节点设备响应于第三逻辑生命周期有效,且目标事务的全局写集存储到本地内存中,向数据节点设备发送事务验证请求。目标事务的全局写集由终端生成并传输到协调节点设备,或者由协调节点设备自行生成,本申请实施例对此不加以限定。
任一个事务的写集中记录了该事务需要更新的数据项,与读集结构类似,同样可以使用内存链表结构来维护事务的写集。需要说明的是,对一个分布式写事务而言,其写集可以划分为本地写集和全局写集,本地写集存在于数据节点设备上,而全局写集存在于协调节点设备上,当然,协调节点设备可以定期将全局写集同步至各个数据节点设备上,使得数据节点设备上也能够维护事务的全局写集。
在将目标事务的全局写集写到协调节点设备的本地内存后,协调节点设备能够基于全局写集确定数据节点设备的本地写集,以将事务验证请求和本地写集一同发送给数据节点设备。数据节点设备的本地写集是指目标事务的全局写集中需要由数据节点设备负责写入的写集。
在目标事务的读取阶段,通信主要在协调节点设备和相关的数据节点设备之间发生,每成功读取一次数据需要两次通信:协调节点设备发送数据读取请求到相关的数据节点设备上、相关的数据节点设备返回数据读取结果给协调节点设备。因此,在数据读取阶段,假设n(n为大于1的整数)为远程读取的次数,那么最多需要进行2n次通信,最大通信量可以表示为n×(数据读取请求消息大小+数据读取结果消息大小)。在示例性实时中,当目标事务需要读取某相关的数据节点设备的多个数据项的数据时,将多个数据项的数据的数据读取请求打包发送,以批量读取这些数据,节省通信次数,提高数据读取效率。
在步骤207中,数据节点设备基于协调节点设备发送的事务验证请求和本地写集,获取目标事务的验证结果,将目标事务的验证结果返回协调节点设备。
数据节点设备接收到协调节点设备发送的事务验证请求和本地写集后,验证目标事务的合法性,以获取目标事务的验证结果。此阶段为事务提交前的事务合法性验证阶段。
数据节点设备的验证过程为本地验证过程,数据节点设备基于事务验证请求和本地写集,获取目标事务的验证结果的过程为协调节点设备执行本地验证操作的过程。在一种可能实现方式中,事务验证请求携带第三逻辑生命周期,第三逻辑生命周期为协调节点设备发送事务验证请求之前维护的目标事务的最新逻辑生命周期。
在一种可能实现方式中,在数据节点设备基于事务验证请求和本地写集,获取目标事务的验证结果的过程中,数据节点设备先更新本地事务状态列表中目标事务T的状态信息,更新方式为:T.Bts=max(T.Bts,vrm.Bts)、T.Ets=min(T.Ets,vrm.Ets),其中,括号中的vrm.Bts和vrm.Ets分别为事务验证请求携带的第三逻辑生命周期的时间戳下界和时间戳上界。在本申请实施例中,在接收事务验证请求之前,数据节点设备的本地事务状态列表中维护的目标事务的逻辑生命周期为第二逻辑生命周期,为便于区分,将在接收事务验证请求之后且对目标事务的状态信息进行更新后,本地事务状态列表维护的目标事务的逻辑生命周期称为第四逻辑生命周期。
也就是说,数据节点设备将第三逻辑生命周期的时间戳下界和第二逻辑生命周期的时间戳下界中的最大值作为目标事务的第四逻辑生命周期的下界;将第三逻辑生命周期的时间戳上界和第二逻辑生命周期的时间戳上界中的最小值作为目标事务的第四逻辑生命周期的时间戳上界。由此,得到第四逻辑生命周期。需要说明的是,此处更新的是数据节点设备的本地事务状态列表中维护的目标事务的逻辑生命周期,此种更新能够用于事务并发访问控制,即用于保证事务一致性。
在示例性实施例中,对于可串行化隔离级别,在确定第四逻辑生命周期后,通过检查第四逻辑生命周期的时间戳下界是否小于第四逻辑生命周期的时间戳上界,来验证第四逻辑生命周期是否有效。
响应于第四逻辑生命周期的时间戳下界不小于第四逻辑生命周期的时间戳上界,说明第四逻辑生命周期无效,此时,目标事务的本地验证不通过,数据节点设备向协调节点设备返回携带Abort消息的验证结果。该Abort消息用于引发全局回滚。向协调节点设备返回目标事务的验证结果的过程可看作向协调节点设备发送本地验证反馈消息lvm的过程,对于目标事务的验证结果为携带Abort消息的验证结果的情况,本地验证反馈消息lvm中的IsAbort字段等于1,即lvm.IsAbort=1。
响应于第四逻辑生命周期的时间戳下界小于第四逻辑生命周期的时间戳上界,说明第四逻辑生命周期有效,此种情况下,基于本地写集对应的各个待写入数据项的读事务相关信息和第四逻辑生命周期,确定目标事务的第五逻辑生命周期。第五逻辑生命周期是指在对本地写集中的各个待写入数据项进行读写冲突验证的过程中更新得到的逻辑生命周期。
在一种可能实现方式中,任一待写入数据项的读事务相关信息包括任一待写入数据项的最大读事务时间戳和任一待写入数据项的目标读事务的结束时间戳中的至少一项。其中,任一待写入数据项的最大读事务时间戳(记为Rts)用于指示读取过该任一待写入数据项的各个读事务的逻辑提交时间戳中的最大值,任一待写入数据项的目标读事务为任一待写入数据项对应的本地验证通过或者处于提交阶段的读事务,目标读事务的结束时间戳为目标读事务的逻辑生命周期的时间戳上界。
在示例性实施例中,任一待写入数据项的目标读事务为任一待写入数据项对应的活跃事务集合中本地验证通过或者处于提交阶段的读事务。通过检测任一待写入数据项对应的活跃事务集合中各读事务的事务状态,即可确定该任一待写入数据项的目标读事务。
在一种可能实现方式中,在任一待写入数据项的读事务相关信息的三种不同情况下,基于本地写集对应的各个待写入数据项的读事务相关信息和第四逻辑生命周期,确定目标事务的第五逻辑生命周期的过程也有所不同。
情况1、任一待写入数据项的读事务相关信息包括该任一待写入数据项的最大读事务时间戳。
在此种情况1下,基于本地写集对应的各个待写入数据项的读事务相关信息和第四逻辑生命周期,确定目标事务的第五逻辑生命周期的过程为:基于各个待写入数据项的最大读事务时间戳和第四逻辑生命周期,确定目标事务的第五逻辑生命周期,其中,第五逻辑生命周期的时间戳下界大于各个待写入数据项的最大读事务时间戳中的最大值。
第四逻辑生命周期为在确定第五逻辑生命周期之前,数据节点设备的本地事务状态列表中维护的目标事务的最新逻辑生命周期。在一种可能实现方式中,基于各个待写入数据项的最大读事务时间戳和第四逻辑生命周期,确定目标事务的第五逻辑生命周期的方式为:基于各个待写入数据项的最大读事务时间戳对第四逻辑生命周期的时间戳下界进行调整,将调整后得到的生命周期作为第五逻辑生命周期。
示例性地,基于各个待写入数据项的最大读事务时间戳对第四逻辑生命周期的时间戳下界进行调整的方式为:使调整后的时间戳下界T.Bts=max(T.Bts,y.Rts+1),其中,括号内的T.Bts表示第四逻辑生命周期的时间戳下界,y.Rts表示各个待写入数据项的最大读事务时间戳中的最大值,数值1用于保证得到的第五逻辑生命周期的时间戳下界大于各个待写入数据项的最大读事务时间戳中的最大值。
在一些实施例中,数据节点设备在接收到本地写集后,先检测本地写集对应的各个待写入数据项的待写事务WT是否为空,若某一该待写入数据项的待写事务WT不为空,说明有其他事务正在修改该待写入数据项,且该事务已经进入了验证阶段,此时,需要回滚目标事务以消除写写冲突,即向协调节点设备返回携带Abort消息的验证结果。若各个待写入数据项的待写事务WT均为空,则将目标事务的事务标识赋值给各个待写入数据项的待写事务WT,以表示进入验证阶段的目标事务需要修改各个待写入数据项。在实现上,使用无锁的CAS(Compare and Swap,比较与交换)技术为待写入数据项y的待写事务WT进行赋值,以提高性能;或者,先对待写入数据项y的待写事务WT加锁,防止其他并发事务并发修改y,然后对加锁后的待写事务WT赋值。示例性地,在待写入数据项y上施加建议性锁,该建议性锁用于指示互斥对待写入数据项y的待写事务WT的修改操作。
情况2、任一待写入数据项的读事务相关信息包括该任一待写入数据项的目标读事务的结束时间戳。
在此种情况2下,基于本地写集对应的各个待写入数据项的读事务相关信息和第四逻辑生命周期,确定目标事务的第五逻辑生命周期的过程为:基于各个待写入数据项的目标读事务的结束时间戳和第四逻辑生命周期,确定目标事务的第五逻辑生命周期,其中,第五逻辑生命周期的时间戳下界大于各个待写入数据项的目标读事务的结束时间戳中的最大值。
在一种可能实现方式中,基于各个待写入数据项的目标读事务的结束时间戳和第四逻辑生命周期,确定目标事务的第五逻辑生命周期的方式为:基于各个待写入数据项的目标读事务的结束时间戳对第四逻辑生命周期的时间戳下界进行调整,将调整后得到的生命周期作为第五逻辑生命周期。示例性地,基于各个待写入数据项的目标读事务的结束时间戳对第四逻辑生命周期的时间戳下界进行调整的方式为:使调整后的时间戳下界T.Bts=max(T.Bts,T1.Ets+1),其中,括号内的T.Bts表示第四逻辑生命周期的时间戳下界,T1.Ets表示各个待写入数据项的目标读事务的结束时间戳中的最大值,数值1用于保证得到的第五逻辑生命周期的时间戳下界大于各个待写入数据项的目标读事务的结束时间戳中的最大值。
需要说明的是,任一待写入数据项的目标读事务的数量可能为一个或多个,对于任一待写入数据项的目标读事务的数量为多个的情况,上述T1.Ets是指全部待写入数据项的全部目标读事务的结束时间戳中的最大值。
基于此种方式能够使目标事务的写操作的发生推迟到目标读事务的读操作之后,以避免读写冲突。
情况3、任一待写入数据项的读事务相关信息包括该任一待写入数据项的最大读事务时间戳和该任一待写入数据项的目标读事务的结束时间戳。
在此种情况3下,基于本地写集对应的各个待写入数据项的读事务相关信息和第四逻辑生命周期,确定目标事务的第五逻辑生命周期的过程为:基于各个待写入数据项的最大读事务时间戳以及各个待写入数据项的目标读事务的结束时间戳对第四逻辑生命周期进行连续的两次调整,将两次调整后得到的生命周期作为目标事务的第五逻辑生命周期。本申请实施例对两次调整的先后顺序不加以限定,示例性地,先基于各个待写入数据项的最大读事务时间戳对第四逻辑生命周期进行调整,然后基于各个待写入数据项的目标读事务的结束时间戳对一次调整后得到的逻辑生命周期进行调整。
示例性地,对于将两次调整后得到的逻辑生命周期作为第五逻辑生命周期的情况,在一次调整后得到逻辑生命周期后,若为可串行化隔离级别,先验证得到的逻辑生命周期的时间戳下界是否小于时间戳上界,若是,则继续进行下一次调整;若否,则直接认为本地验证失败,向协调节点设备返回携带Abort消息的验证结果。
在得到第五逻辑生命周期后,通过验证第五逻辑生命周期的时间戳下界是否小于第五逻辑生命周期的时间戳上界,来判断第五逻辑生命周期是否有效。响应于第五逻辑生命周期有效,将用于指示验证通过的验证结果作为目标事务的验证结果;响应于第五逻辑生命周期无效,将用于指示验证不通过的验证结果作为目标事务的验证结果。对于将用于指示验证通过的验证结果作为目标事务的验证结果的情况,数据节点设备的本地验证反馈消息lvm中记录目标事务在数据节点设备上得到的最新的逻辑生命周期(即第五逻辑生命周期)的时间戳下界Bts和时间戳上界Ets。示例性地,用于指示验证不通过的验证结果即为携带Abort消息的验证结果。
在示例性实施例中,当确定第五逻辑生命周期有效时,认为目标事务的本地验证通过,数据节点设备更新本地事务状态列表中目标事务的状态信息,将目标事务的事务状态更新为Validated(验证通过),即,使T.Status=Validated。在示例性实施例中,在确定目标事务的本地验证通过后,数据节点设备根据待写入数据项的更新值,创建待写入数据项的新版本数据。在示例性实施例中,为创建的新版本数据设置用于指示该新版本数据并未全局提交的第一标记。具有第一标记的新版本数据对外不可见。
需要说明的是,如果目标事务在数据节点设备中的本地验证不通过,则需要更新数据节点设备的本地事务状态列表中目标事务的事务状态为Aborted(回滚),即,使T.Status=Aborted。
在一种可能实现方式中,任一待写入数据项的活跃事务集合中,除了包括目标读事务外,还包括正在运行的读事务,需要根据目标事务的第五逻辑生命周期调整正在运行的读事务的逻辑生命周期,以使得正在运行的读事务读不到目标事务新写入的数据,从而避免读写冲突现象,保证事务正确执行。示例性地,正在运行的读事务是指活跃事务集合中的事务状态为Running(正在运行)的事务。调整正在运行的读事务的逻辑生命周期方式为:使正在运行的读事务的逻辑生命周期的时间戳上界小于目标事务的第五逻辑生命周期的时间戳下界。假设正在运行的读事务为T2,则更新方式为T2.Ets=min(T2.Ets,T.Bts-1)。若某一正在运行的读事务更新后的逻辑生命周期的时间戳下界不小于时间戳上界,则通知该正在运行的读事务应该回滚。
从上述事务验证阶段可以看出,在目标事务的验证过程中,通信主要在协调节点设备和相关的数据节点设备之间发生,通信主要包含以下两步:协调节点设备向每个相关的数据节点设备发送事务验证请求及本地写集、相关的数据节点设备反馈验证结果给协调节点设备。因此,在目标事务的验证阶段,假设m(m为不小于1的整数)为与目标事务T相关的数据节点设备的数量,那么最多需要进行2m次通信,最大通信量可以表示为m×(事务验证请求消息大小+验证结果消息大小)+全局写集大小。
在步骤208中,协调节点设备基于数据节点设备返回的目标事务的验证结果,确定目标事务的处理指令,向数据节点设备发送处理指令,处理指令为提交指令或者回滚指令。
协调节点设备在接收到数据节点设备返回的验证结果后,根据接收到的验证结果来判断目标事务能否通过全局验证,进而确定目标事务的处理指令,向数据节点设备发送处理指令。其中,处理指令为提交指令或回滚指令。
在一种可能实现方式中,数据节点设备的数量为一个或多个,当数据节点设备的数量为多个时,每个数据节点设备均返回一个验证结果。
对于数据节点设备的数量为至少两个的情况,基于数据节点设备返回的目标事务的验证结果,确定目标事务的处理指令的过程为:响应于至少两个数据节点设备返回的至少两个验证结果中存在用于指示验证不通过的验证结果,将回滚指令作为目标事务的处理指令。响应于至少两个数据节点设备返回的至少两个验证结果均指示验证通过,将至少两个验证结果携带的逻辑生命周期的交集作为目标逻辑生命周期;响应于目标逻辑生命周期有效,将提交指令作为目标事务的处理指令;响应于目标逻辑生命周期无效,将回滚指令作为目标事务的处理指令。
在示例性实施例中,用于指示验证不通过的验证结果为携带Abort消息的验证结果,若某一验证结果不携带Abort消息,而是携带逻辑生命周期(即步骤207中确定的第五逻辑生命周期),则该验证结果指示验证通过。也就是说,在协调节点设备根据接收到的验证结果来判断目标事务能否通过全局验证的过程中,若接收到的验证结果中存在至少一个携带Abort消息的验证结果,即IsAbort字段等于1的lvm,表明目标事务没有通过全部的本地验证,目标事务的全局验证不通过,目标事务需要进行全局回滚。此种情况下,将回滚指令作为目标事务的处理指令。协调节点设备将第一事务状态列表中目标事务的全局事务状态更新为Gaborting(全局正在回滚)。协调节点设备向数据节点设备发送回滚指令,以通知数据节点设备进行本地回滚。示例性地,处理指令通过写入提交/回滚消息coarm发送,当处理指令为回滚指令时,coarm中的IsAbort字段等于1,即coarm.IsAbort=1。
若接收到的验证结果中不存在携带Abort消息的验证结果,或者接收到的验证结果均携带逻辑生命周期,则说明目标事务通过全部的本地验证。此种情况下,协调节点设备计算接收到的各个验证结果携带的逻辑生命周期的交集,得到目标逻辑生命周期。若目标逻辑生命周期的时间戳下界不小于目标逻辑生命周期的时间戳上界,则说明目标逻辑生命周期无效,确定目标事务的全局验证不通过,目标事务需要进行全局回滚,协调节点设备将回滚指令作为目标事务的处理指令。此外,协调节点设备还将第一事务状态列表中目标事务的全局事务状态更新为Gaborting(全局正在回滚),协调节点设备向数据节点设备发送回滚指令,以通知数据节点设备进行本地回滚。
若目标逻辑生命周期的时间戳下界小于目标逻辑生命周期,则说明目标逻辑生命周期有效,确定目标事务的全局验证通过,协调节点设备从目标逻辑生命周期中随机选择一个时间戳为目标事务的逻辑提交时间戳Cts赋值,例如,选择目标逻辑生命周期的时间戳下界作为目标事务的逻辑提交时间戳。
在确定逻辑提交时间戳后,协调节点设备将第一事务状态列表中目标事务T的逻辑生命周期下界以及逻辑生命周期上界均更新为逻辑提交时间戳,即,使T.Bts=T.Ets=T.Cts。此外,将第一事务状态列表中目标事务的全局事务状态更新为Gcommitted(全局验证通过),请求全局时间戳生成集群为目标事务分配全局提交时间戳,记录到第一事务状态列表中目标事务的全局提交时间戳Gts字段中。此外,协调节点设备将提交指令作为目标事务的处理指令,向数据节点设备发送提交指令,以通知数据节点设备对目标事务进行提交。示例性地,对于处理指令通过写入提交/回滚消息coarm发送的情况,当处理指令为提交指令时,coarm中的IsAbort字段等于0,即coarm.IsAbort=0,coarm中的Cts和Gts字段中分别记录了目标事务的逻辑提交时间戳和目标事务的全局提交时间戳。
在步骤209中,数据节点设备响应于接收到协调节点设备发送的目标事务的处理指令,执行处理指令,处理指令为提交指令或者回滚指令。
数据节点设备接收到处理指令后,执行处理指令。数据节点设备执行处理指令的阶段为事务提交或回滚操作收尾阶段。
当处理指令为提交指令时,说明目标事务的全局验证通过,进入提交阶段,即将目标事务对数据的更新持久化到数据库中,并做一些后续清理工作。在示例性实施例中,数据节点设备接收到协调节点设备发送的提交指令之后,可以执行下述操作A至操作E。
操作A:对于目标事务的本地读集对应的每个数据项x,修改数据项x的最大读事务时间戳Rts,使使其大于或等于目标事务的逻辑提交时间戳Cts,即,使x.Rts=max(x.Rts,T.Cts);从该数据项x的活跃事务列表RTlist中将目标事务的事务标识TID删除。
操作B:对于目标事务的本地写集对应的每个数据项y,执行以下操作:a)将数据项y原本的创建时间戳Wts修改为目标事务的逻辑提交时间戳T.Cts;b)将数据项y的最大读事务时间戳更新为原本的最大读事务时间戳和目标事务的逻辑提交时间戳中的最大值,即,使y.Rts=max(y.Rts,T.Cts);c)将数据项y持久化到数据库中,且将数据项y的标记由第一标记修改为第二标记,第二标记用于指示对外可见;d)将数据项y的活跃事务列表RTlist内容清空;e)将数据项y的待写事务T内容清空。
操作C:清空目标事务的本地读集和本地写集。
操作D:将本地事务状态列表中目标事务的逻辑生命周期的时间戳下界和时间戳上界均更新为目标事务的逻辑提交时间戳,即,使T.Bts=T.Ets=T.Cts;将本地事务状态列表中目标事务的事务状态更新为Committed(提交完成)。需要说明的是,此时的本地事务状态列表,用于保证事务一致性,无需涉及全局事务状态的同步。
操作E:向协调节点设备返回提交成功的ACK(Acknowledge Character,确认字符)。
协调节点设备在接收到全部的数据节点设备返回的提交成功的ACK后,将第一事务状态列表中目标事务的全局事务状态修改为Gcommitted(全局提交完成),然后协调节点设备向数据节点设备发送状态信息清理指令,以使数据节点设备从本地事务状态列表中删除目标事务的状态信息。
当处理指令为回滚指令时,说明目标事务的全局验证不通过,需要进入全局回滚阶段,即将目标事务回滚,并做相应的清理工作。示例性地,清理工作内容包括:从目标事务的本地读集对应的每个数据项x的活跃事务列表RTlist中将目标事务的事务标识TID删除;清理目标事务的本地写集对应的每个数据项y对应的新创建数据,且将数据项y的待写事务WT的内容清空;清空目标事务的本地读集和本地写集;将本地事务状态列表中目标事务的事务状态更新为Aborted(回滚完成);向协调节点设备返回回滚完成的ACK。
协调节点设备在接收到全部的数据节点设备返回的回滚完成的ACK后,将第一事务状态列表中目标事务的全局事务状态修改为Gaborted(全局回滚完成),然后协调节点设备向数据节点设备发送状态信息清理指令,以使数据节点设备从本地事务状态列表中删除目标事务的状态信息。在一种可能实现方式中,协调节点设备批量向数据节点设备发送状态信息清理指令,以减少通信次数。
根据上述内容可知,在目标事务的提交/回滚阶段,通信主要在协调节点设备和相关的数据节点设备之间发生,通信主要以下两步:协调节点设备向每个相关的数据节点设备发送提交/回滚指令、每个相关的数据节点设备向协调节点设备发送相应的提交/回滚完成消息(ACK)。因此,提交/回滚阶段最多进行2m次通信,通信量的大小为m×(提交/回滚指令消息大小+提交/回滚完成消息大小),其中m(m为不小于1的整数)为目标事务T相关的数据节点设备的数量。
需要说明的是,本申请实施例以目标事务涉及读写操作为例进行了介绍,本申请实施例并不局限于此,对于目标事务仅涉及读操作或者仅涉及写操作的情况,依然能够根据本申请实施例提供的事务处理方法实现对事务的处理,本申请实施例不再一一赘述。
基于上述步骤201至步骤209处理事务的过程实现了事务的去中心化处理,能够解决并发事务之间的冲突操作带来的数据异常问题。从实现原理上看,本申请实施例提供的事务处理方法主要应用了OCC(Optimistic Concurrency Control,乐观并发控制)的算法框架,结合DTA(Dynamic Timestamp Allocation,动态分配时间戳)算法,减少网络传输的事务数据信息,提高分布式事务的验证效率,提升分布式事务的并发处理能力。此外,还结合MVCC(Mutil-Version Concurrency Control,多版本并发控制)实现无锁的数据读写,从而提升局部节点设备的并发处理能力。其中,DTA算法属于TO(Timestamp Ordering,时间戳排序)算法,事务的逻辑生命周期的时间戳下界和时间戳上界,可以动态调整。
本申请实施例提供的方法不受数据存储格式的影响,本申请实施例中的分布式数据库系统既支持键值式数据存储格式(KV数据存储格式)(如,HBase数据库系统中的数据存储格式),又支持段页式数据存储格式(如,PostgreSQL和MsSQL/InnoDB数据库系统中的数据存储格式)。
在示例性实施例中,对于段页式数据存储格式,在节点设备内建立数据缓冲区,以缓冲从共享的存储系统传输来的数据,从而加快下次获取数据的速度,缓冲的格式同下层的数据存储格式保持一致。从共享的存储系统中传输来的数据,缓冲在本地的数据缓冲区,事务结束但不被清理,直至本地数据缓冲区满或者有脏数据需要刷回共享的存储系统,或者缓冲失效(如,在其他节点设备上同样的数据被修改)。
事务提交前,每个节点设备向共享的存储系统算出事务日志(如,WAL日志),事务日志向共享的存储系统索要LSN值,该值是全局唯一且递增的一个值。在不同的数据存储格式下,事务处理过程中产生的事务日志具有不同的格式。示例性地,当数据存储格式为KV数据存储格式时,事务日志的格式如图3所示。
数据库系统维护的大表划分的各个区域(Region)共享一个日志文件,单个区域在日志中是按照时间顺序存储的,但是多个区域可能并不是完全按照时间顺序。每个日志最小单元由日志键(HLogKey)和日志编辑(WALEdit)两部分组成。其中,HLogKey由序列号(sequenceid)、时间戳(timestamp)、簇号(cluster ids)、区域名称(regionname)以及表名称(tablename)等组成,WALEdit由一系列的键值对(KeyValue)组成,对一行上所有列(即所有KeyValue)的更新操作,都包含在同一个WALEdit对象中,这主要是为了实现写入一行多个列时的原子性。sequenceid,是一个存储级别的自增序列号,区域的数据恢复和日志过期清除都要依赖它,示例性地,sequenceid是指事务日志的LSN值。
示例性地,当数据存储格式为段页式数据存储格式时,事务日志的格式如图4所示。每个Region共享一个日志文件,单个Region在HLOG中是按照时间顺序存储,且多个Region可能并不是完全按照时间顺序。每个日志最小单元不再由HLOGkey和WALEdit两部分组成,而是由一个日志记录(XLog Record)组成。
XLog Record由两部分构成,第一部分是头部信息,大小固定(如,24 Bytes(字节)),对应的结构体是XLogRecord;第二部分是日志记录数据(XLog Record data)。
XLog Record按存储的数据内容来划分,主要分为以下三类。
第1类:Record for backup block(备份块记录):存储full-write-page(全写页面)的block(块),这种类型的记录是为了解决页面部分写的问题。在checkpoint(检测点)完成后第一次修改数据页面,在记录此变更写入事务日志文件时整页写入(需设置相应的初始化参数,默认为打开)。
第2类:Record for tuple data block(元组数据块记录):用于存储页面中的元组变更。
第3类:Record for Checkpoint(检查点记录):在checkpoint发生时,在事务日志文件中记录checkpoint信息(其中包括Redo point(重做点))。
XLog Record data是存储实际数据的地方,由以下四个部分组成。
第1部分:0..N个XLogRecordBlockHeader(日志记录块头),每一个XLogRecordBlockHeader对应一个block data(块数据)。如果设置了BKPBLOCK_HAS_IMAGE标记,则在XLogRecordBlockHeader结构体后跟XLogRecordBlockImageHeader结构体;如果设置了BKPBLOCK_HAS_HOLE&BKPIMAGE_IS_COMPRESSED标记,则在XLogRecordBlockHeader结构体后跟XLogRecordBlockCompressHeader结构体;如果未设置BKPBLOCK_SAME_REL标记,则在XLogRecordBlockHeader结构体后跟RelFileNode。示例性地,在XLogRecordBlockHeader结构体后还可以跟BlockNumber(块编号)。
第2部分:XLogRecordDataHeader[Short|Long](日志记录数据头[短|长]),如数据大小<256 Bytes,则使用Short格式,否则使用Long格式。
第3部分:block data(块数据):full-write-page data(全写页面数据)和tupledata(元组数据)。对于full-write-page data,如启用了压缩,则数据压缩存储,压缩后该page相关的元数据存储在XLogRecordBlockCompressHeader(日志记录块压缩头)
第4部分:main data(主要数据):记录checkpoint等日志数据。
示例性地,XLog Record的定义如下:
头部信息(固定大小的XLogRecord结构体)
XLogRecordBlockHeader 结构体
XLogRecordBlockHeader 结构体
XLogRecordDataHeader[Short|Long] 结构体
block data
block data
main data
在一种可能实现方式中,对于数据格式为段页式数据存储格式的情况,当并发事务在不同节点设备(ES)上处理,且修改同一个页面上的不同数据项时,会发生页面级冲突导致数据覆盖问题。如,事务Ta在节点设备ES-1上修改X=2的数据项,事务Tb在节点设备ES-2上修改X=3的数据项,而X=2和X=3的数据项在同一个页面(page)上,此时,事务处理机制,是运行并发、并行事务执行的,在事务级不存在数据异常。但是,在页面级,却存在究竟应该是选取ES-1还是ES-2刷出的事务日志的选择,这导致对同一个物理页面的修改不能并存的问题出现。
在支持段页式数据存储格式的事务日志中,增加一个段页式列表(list),标出本段日志中的页面的地址(如,文件号、表空间号、在文件中的相对偏移等)和每个页面上正在执行写操作的事务标识。当事务日志刷出到底层共享的存储系统时,验证设备检查所有并发事务提交到共享的存储系统的事务中的list中的页面是否有重合,如果有,表明并发事务写过相同的页面(如果写的是相同数据项,则在事务验证阶段,检测存在事务冲突并通过回滚已经把冲突解决掉),写的是相同页上的不同的数据项,此时有页面级冲突存在,发生数据覆盖事件,需要回滚其中一个节点设备ES对应的事务,使其事务日志不再刷出,避免问题发生。
在示例性实施例中,执行上述页面级冲突验证的主体为分布式数据库系统中的验证设备。该验证设备可以与任一节点设备处于同一物理机上,也可以是独立设备,本申请实施例对此不加以限定。
基于本申请实施例提供的事务处理方法,能够使分布式数据库系统既支持分布式事务、又能达到全局一致性的多读,能够通过去中心化事务处理技术兼顾性能。具备良好的带有事务属性特征的全局一致性多读和一致性多写的能力。基于本申请实施例提供的事务处理方法,能够为基于share-disk架构的分布式数据库系统,如知名的NoSQL(Non-relational SQL,泛指非关系型数据库)下的HBase数据库系统,提供去中心化的分布式事务处理方案,使得类似HBase的数据库系统具备了跨区、跨节点的高效的事务处理能力。
在本申请实施例中,根据各个节点设备分别对应的事务分配指标确定用于协调处理目标事务的协调节点设备,事务的分配过程无需考虑事务涉及的数据项,也无需考虑数据项的分布情况。基于此种方式,每个节点设备均能够作为去中心化的设备协调处理事务,使得事务能够跨节点处理,有利于提高事务的处理效率,事务处理的可靠性较高,有利于提升数据库系统的系统性能。
参见图5,本申请实施例提供了一种事务处理装置,该装置包括:
第一确定单元501,用于响应于目标事务的分配请求,确定至少两个节点设备分别对应的事务分配指标,任一节点设备对应的事务分配指标用于指示为任一节点设备分配新事务的匹配度;
第二确定单元502,用于基于至少两个节点设备分别对应的事务分配指标,在至少两个节点设备中确定目标事务的协调节点设备,由协调节点设备对目标事务进行协调处理。
在一种可能实现方式中,第一确定单元501,用于确定事务分配模式,事务分配模式包括基于事务繁忙程度进行分配、基于设备繁忙程度进行分配和基于混合繁忙程度进行分配中的任一种;根据事务分配模式指示的确定方式,确定至少两个节点设备分别对应的事务分配指标。
在一种可能实现方式中,事务分配模式包括基于混合繁忙程度进行分配,第一确定单元501,还用于对于至少两个节点设备中的任一节点设备,基于任一节点设备的事务处理数量、任一节点设备的设备资源使用率、事务处理数量权重、设备资源使用率权重以及权重调节参数,确定任一节点设备对应的事务分配指标。
在一种可能实现方式中,该装置还包括:
发送单元,用于将协调节点设备的设备标识信息发送给发起分配请求的终端,终端用于根据协调节点设备的设备标识信息,将目标事务的事务信息发送给协调节点设备,由协调节点设备基于事务信息对目标事务进行协调处理。
在一种可能实现方式中,分布式数据库系统支持键值式数据存储格式和段页式数据存储格式。
在本申请实施例中,根据各个节点设备分别对应的事务分配指标确定用于协调处理目标事务的协调节点设备,事务的分配过程无需考虑事务涉及的数据项,也无需考虑数据项的分布情况。基于此种方式,每个节点设备均能够作为去中心化的设备协调处理事务,使得事务能够跨节点处理,有利于提高事务的处理效率,事务处理的可靠性较高,有利于提升数据库系统的系统性能。
参见图6,本申请实施例提供了一种事务处理装置,该装置包括:
获取单元601,用于获取目标事务的事务信息;
第一发送单元602,用于基于目标事务的事务信息,向数据节点设备发送数据读取请求,数据节点设备为至少两个节点设备中用于参与处理目标事务的节点设备;
第二发送单元603,用于响应于数据节点设备返回的数据读取结果满足事务验证条件,向数据节点设备发送事务验证请求和本地写集;
确定单元604,用于基于数据节点设备返回的目标事务的验证结果,确定目标事务的处理指令;
第三发送单元605,用于向数据节点设备发送处理指令,处理指令为提交指令或者回滚指令,数据节点设备用于执行处理指令。
在一种可能实现方式中,数据读取结果携带第二逻辑生命周期和可见版本数据,第二逻辑生命周期由数据节点设备根据数据读取请求携带的目标事务的第一逻辑生命周期确定,第一逻辑生命周期由时间戳下界和时间戳上界构成;
第二发送单元603,用于将第一逻辑生命周期的时间戳下界和第二逻辑生命周期的时间戳下界中的最大值作为目标事务的第三逻辑生命周期的时间戳下界;将第一逻辑生命周期的时间戳上界和第二逻辑生命周期的时间戳上界中的最小值作为目标事务的第三逻辑生命周期的时间戳上界;响应于第三逻辑生命周期有效,向数据节点设备发送携带第三逻辑生命周期的事务验证请求,第三逻辑生命周期有效用于指示第三逻辑生命周期的时间戳下界小于第三逻辑生命周期的时间戳上界。
在一种可能实现方式中,数据节点设备的数量为至少两个,确定单元604,用于响应于至少两个数据节点设备返回的至少两个验证结果中存在用于指示验证不通过的验证结果,将回滚指令作为目标事务的处理指令;响应于至少两个数据节点设备返回的至少两个验证结果均指示验证通过,将至少两个验证结果携带的逻辑生命周期的交集作为目标逻辑生命周期;响应于目标逻辑生命周期有效,将提交指令作为目标事务的处理指令;响应于目标逻辑生命周期无效,将回滚指令作为目标事务的处理指令。
在本申请实施例中,根据各个节点设备分别对应的事务分配指标确定用于协调处理目标事务的协调节点设备,事务的分配过程无需考虑事务涉及的数据项,也无需考虑数据项的分布情况。基于此种方式,每个节点设备均能够作为去中心化的设备协调处理事务,使得事务能够跨节点处理,有利于提高事务的处理效率,事务处理的可靠性较高,有利于提升数据库系统的系统性能。
参见图7,本申请实施例提供了一种事务处理装置,该装置包括:
第一获取单元701,用于基于协调节点设备发送的数据读取请求,获取数据读取结果;
返回单元702,用于将数据读取结果返回协调节点设备,协调节点设备根据至少两个节点设备分别对应的事务分配指标确定;
第二获取单元703,用于基于协调节点设备发送的事务验证请求和本地写集,获取目标事务的验证结果;
返回单元702,还用于将目标事务的验证结果返回协调节点设备;
执行单元704,用于响应于接收到协调节点设备发送的目标事务的处理指令,执行处理指令,处理指令为提交指令或者回滚指令。
在一种可能实现方式中,数据读取请求携带目标事务的第一逻辑生命周期,第一逻辑生命周期由时间戳下界和时间戳上界构成;
第一获取单元701,用于基于第一逻辑生命周期,确定数据读取请求指示的待读取数据项的可见版本数据;基于可见版本数据的创建时间戳和第一逻辑生命周期,确定目标事务的第二逻辑生命周期;将携带第二逻辑生命周期和可见版本数据的结果作为数据读取结果。
在一种可能实现方式中,事务验证请求携带目标事务的第三逻辑生命周期,第三逻辑生命周期为由协调节点设备基于第一逻辑生命周期和第二逻辑生命周期确定的有效逻辑生命周期;
第二获取单元703,用于将第三逻辑生命周期的时间戳下界和第二逻辑生命周期的时间戳下界中的最大值作为目标事务的第四逻辑生命周期的时间戳下界;将第三逻辑生命周期的时间戳上界和第二逻辑生命周期的时间戳上界中的最小值作为目标事务的第四逻辑生命周期的时间戳上界;响应于第四逻辑生命周期有效,基于本地写集对应的各个待写入数据项的读事务相关信息和第四逻辑生命周期,确定目标事务的第五逻辑生命周期;响应于第五逻辑生命周期有效,将用于指示验证通过的验证结果作为目标事务的验证结果;响应于第五逻辑生命周期无效,将用于指示验证不通过的验证结果作为目标事务的验证结果。
在一种可能实现方式中,任一待写入数据项的读事务相关信息包括任一待写入数据项的最大读事务时间戳,任一待写入数据项的最大读事务时间戳用于指示读取过任一待写入数据项的各个读事务的逻辑提交时间戳中的最大值;
第二获取单元703,还用于基于各个待写入数据项的最大读事务时间戳和第四逻辑生命周期,确定目标事务的第五逻辑生命周期,第五逻辑生命周期的时间戳下界大于各个待写入数据项的最大读事务时间戳中的最大值。
在一种可能实现方式中,任一待写入数据项的读事务相关信息包括任一待写入数据项的目标读事务的结束时间戳,目标读事务为本地验证通过或者处于提交阶段的读事务,目标读事务的结束时间戳为目标读事务的逻辑生命周期的时间戳上界;
第二获取单元703,还用于基于各个待写入数据项的目标读事务的结束时间戳和第四逻辑生命周期,确定目标事务的第五逻辑生命周期,第五逻辑生命周期的时间戳下界大于各个待写入数据项的目标读事务的结束时间戳中的最大值。
在本申请实施例中,根据各个节点设备分别对应的事务分配指标确定用于协调处理目标事务的协调节点设备,事务的分配过程无需考虑事务涉及的数据项,也无需考虑数据项的分布情况。基于此种方式,每个节点设备均能够作为去中心化的设备协调处理事务,使得事务能够跨节点处理,有利于提高事务的处理效率,事务处理的可靠性较高,有利于提升数据库系统的系统性能。
需要说明的是,上述实施例提供的装置在实现其功能时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的装置与方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图8是本申请实施例提供的一种计算机设备的结构示意图,该计算机设备可因配置或性能不同而产生比较大的差异,可以包括一个或多个处理器(Central ProcessingUnits,CPU)801和一个或多个存储器802,其中,该一个或多个存储器802中存储有至少一条计算机程序,该至少一条计算机程序由该一个或多个处理器801加载并执行,以实现上述各个方法实施例提供的事务处理方法。当然,该计算机设备还可以具有有线或无线网络接口、键盘以及输入输出接口等部件,以便进行输入输出,该计算机设备还可以包括其他用于实现设备功能的部件,在此不做赘述。
在示例性实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有至少一条计算机程序,该至少一条计算机程序由计算机设备的处理器加载并执行,以实现上述任一种事务处理方法。
在一种可能实现方式中,上述计算机可读存储介质可以是只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、只读光盘(Compact DiscRead-Only Memory,CD-ROM)、磁带、软盘和光数据存储设备等。
在示例性实施例中,还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述任一种事务处理方法。
应当理解的是,本申请中术语“至少一个”是指一个或多个,“多个”或“至少两个”的含义均是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
以上所述仅为本申请的示例性实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。