CN111444027A - 事务处理方法、装置、计算机设备及存储介质 - Google Patents
事务处理方法、装置、计算机设备及存储介质 Download PDFInfo
- Publication number
- CN111444027A CN111444027A CN202010214259.1A CN202010214259A CN111444027A CN 111444027 A CN111444027 A CN 111444027A CN 202010214259 A CN202010214259 A CN 202010214259A CN 111444027 A CN111444027 A CN 111444027A
- Authority
- CN
- China
- Prior art keywords
- transaction
- variable
- read
- version
- write
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/526—Mutual exclusion algorithms
- G06F9/528—Mutual exclusion algorithms by using speculative mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种事务处理方法、装置、计算机设备及存储介质,属于数据库技术领域。本申请通过对目标事务的读写集合进行一致性检测,能够在事务提交阶段精准识别出单事务构成的数据异常,当一致性检测通过时,获取待合并事务集,并对目标事务与历史事务进行合并,在事务合并后不存在数据异常的条件下,提交目标事务,通过事务合并方式能够检测出多事务共同构成的数据异常,从而能够全面的识别出数据库系统内各种各样的数据异常,保证数据状态的一致性,上述事务处理机制既不依赖于封锁技术也不依赖于依赖图技术,避免了限制数据库系统的并发度,也无需遍历并发事务去识别依赖图中环的存在,提升了数据库系统的事务处理效率。
Description
技术领域
本申请涉及数据库技术领域,特别涉及一种事务处理方法、装置、计算机设备及存储介质。
背景技术
随着数据库技术的发展,在数据库系统中如何识别并规避数据异常成为了一个关键问题。目前有两种识别数据异常的方法,其一是利用封锁技术,依赖锁的互斥机制来避免数据异常,其二是利用依赖图技术,通过在并发事务构成的依赖图中确认是否存在环,如果存在环则需要打破环的存在从而消除潜在的数据异常。然而,封锁技术严重限制了数据库系统的并发度,导致事务处理效率低下,而依赖图技术又需要遍历每个并发事务以识别出环的存在,导致事务处理效率仍然不高。因此,亟需一种能够提升事务处理效率的事务处理方法。
发明内容
本申请实施例提供了一种事务处理方法、装置、计算机设备及存储介质,能够提升数据库系统的事务处理效率。该技术方案如下:
一方面,提供了一种事务处理方法,该方法包括:
响应于目标事务的提交请求,对所述目标事务的读写集合进行一致性检测;
响应于对所述读写集合的一致性检测通过,基于所述读写集合,获取所述目标事务的待合并事务集,所述待合并事务集用于提供待与所述目标事务进行合并的历史事务;
对所述目标事务以及所述待合并事务集中的历史事务进行合并,响应于事务合并后不存在数据异常,提交所述目标事务。
在一种可能实施方式中,所述对所述目标事务的读写集合进行一致性检测包括:
对所述目标事务的读集中变量版本进行一致性检测;
响应于对所述目标事务的读集中变量版本的一致性检测通过,对所述目标事务的写集中变量进行一致性检测;否则,回滚所述目标事务;
响应于对所述目标事务的写集中变量的一致性检测通过,为所述写集中变量分配版本号,确定对所述读写集合的一致性检测通过;否则,回滚所述目标事务。
在一种可能实施方式中,所述对所述目标事务的读集中变量版本进行一致性检测包括:
对于所述目标事务的读集中任一变量版本,将所述目标事务添加至所述变量版本的版本读取集合中,所述版本读取集合用于表示当前读取所述变量版本的事务集合;
响应于存在任一已提交事务写入版本号大于所述变量版本的目标版本,且所述目标事务读取的另一变量版本的版本号大于所述已提交事务所读取的对应变量版本的版本号,确定对所述变量版本一致性检测不通过,回滚所述目标事务;否则,确定对所述变量版本的一致性检测通过。
在一种可能实施方式中,所述对所述目标事务的写集中变量进行一致性检测包括:
对于所述写集中任一变量,获取所述变量当前已提交的最大版本号;
响应于所述读集中存在所述变量的版本号与所述最大版本号不相等,确定对所述变量一致性检测不通过,回滚所述目标事务;否则,确定对所述变量的一致性检测通过。
在一种可能实施方式中,所述基于所述读写集合,获取所述目标事务的待合并事务集包括:
对于所述目标事务的读集中任一变量版本,响应于所述变量版本的下一版本位于所述目标事务的写集中,将所述变量版本的版本读取集合中的事务添加至所述待合并事务集;将写入所述变量版本的事务添加至所述待合并事务集。
在一种可能实施方式中,所述对所述目标事务以及所述待合并事务集中的历史事务进行合并包括:
对于所述待合并事务集中任一历史事务,响应于所述目标事务的读集中的变量均包含在所述历史事务的读集中,跳过所述历史事务;否则,将所述目标事务的读集合并至所述历史事务的读集,对读集合并后的历史事务递归执行合并操作,直到遍历所述待合并事务集。
在一种可能实施方式中,所述将所述目标事务的读集合并至所述历史事务的读集包括:
对所述目标事务的读集中任一变量版本,响应于所述历史事务的读集中不包含与所述变量版本对应的任一版本,将所述变量版本添加至所述历史事务的读集中。
在一种可能实施方式中,所述对所述目标事务以及所述待合并事务集中的历史事务进行合并包括:
对于所述待合并事务集中任一历史事务,响应于所述目标事务与所述历史事务之间不存在动边交叉,将所述目标事务与所述历史事务在逻辑上进行融合,得到一个逻辑事务。
在一种可能实施方式中,所述将所述目标事务与所述历史事务在逻辑上进行融合包括:
将所述目标事务的读集与所述历史事务的读集进行合并,得到所述逻辑事务的读集;将所述目标事务的写集与所述历史事务的写集进行合并,得到所述逻辑事务的写集。
在一种可能实施方式中,所述方法还包括:
响应于所述目标事务的读集和所述历史事务的读集中包括同一变量的不同变量版本,或者所述目标事务的写集和所述历史事务的写集中包括同一变量的不同变量版本,将所述同一变量的不同变量版本合并为所述同一变量的逻辑版本。
在一种可能实施方式中,所述方法还包括:
响应于所述逻辑事务的读集中包括至少两种变量的变量版本,且所述逻辑事务的写集中包括所述至少两种变量的其他变量版本,将所述至少两种变量合并为逻辑变量。
在一种可能实施方式中,所述对所述目标事务的读写集合进行一致性检测之前,所述方法还包括:
在开始执行所述目标事务时,将所述目标事务的读集和写集初始化为空集;
响应于所述目标事务对任一变量进行更新,将所述变量添加至所述目标事务的写集中,不为所述变量分配版本号;
响应于所述目标事务读取任一变量,若所述变量位于所述目标事务的写集中,读取所述目标事务针对所述变量写入的值;若所述变量位于所述目标事务的读集中,读取所述目标事务的读集中已存储的所述变量的值;否则,读取所述变量当前已提交的最大版本,将所述最大版本添加至所述目标事务的读集中。
一方面,提供了一种事务处理装置,该装置包括:
检测模块,用于响应于目标事务的提交请求,对所述目标事务的读写集合进行一致性检测;
获取模块,用于响应于对所述读写集合的一致性检测通过,基于所述读写集合,获取所述目标事务的待合并事务集,所述待合并事务集用于提供待与所述目标事务进行合并的历史事务;
合并提交模块,用于对所述目标事务以及所述待合并事务集中的历史事务进行合并,响应于事务合并后不存在数据异常,提交所述目标事务。
在一种可能实施方式中,所述检测模块包括:
第一检测单元,用于对所述目标事务的读集中变量版本进行一致性检测;
第二检测单元,用于响应于对所述目标事务的读集中变量版本的一致性检测通过,对所述目标事务的写集中变量进行一致性检测;否则,回滚所述目标事务;
确定单元,用于响应于对所述目标事务的写集中变量的一致性检测通过,为所述写集中变量分配版本号,确定对所述读写集合的一致性检测通过;否则,回滚所述目标事务。
在一种可能实施方式中,所述第一检测单元用于:
对于所述目标事务的读集中任一变量版本,将所述目标事务添加至所述变量版本的版本读取集合中,所述版本读取集合用于表示当前读取所述变量版本的事务集合;
响应于存在任一已提交事务写入版本号大于所述变量版本的目标版本,且所述目标事务读取的另一变量版本的版本号大于所述已提交事务所读取的对应变量版本的版本号,确定对所述变量版本一致性检测不通过,回滚所述目标事务;否则,确定对所述变量版本的一致性检测通过。
在一种可能实施方式中,所述第二检测单元用于:
对于所述写集中任一变量,获取所述变量当前已提交的最大版本号;
响应于所述读集中存在所述变量的版本号与所述最大版本号不相等,确定对所述变量一致性检测不通过,回滚所述目标事务;否则,确定对所述变量的一致性检测通过。
在一种可能实施方式中,所述获取模块用于:
对于所述目标事务的读集中任一变量版本,响应于所述变量版本的下一版本位于所述目标事务的写集中,将所述变量版本的版本读取集合中的事务添加至所述待合并事务集;将写入所述变量版本的事务添加至所述待合并事务集。
在一种可能实施方式中,所述合并提交模块包括:
递归合并单元,用于对于所述待合并事务集中任一历史事务,响应于所述目标事务的读集中的变量均包含在所述历史事务的读集中,跳过所述历史事务;否则,将所述目标事务的读集合并至所述历史事务的读集,对读集合并后的历史事务递归执行合并操作,直到遍历所述待合并事务集。
在一种可能实施方式中,所述递归合并单元用于:
对所述目标事务的读集中任一变量版本,响应于所述历史事务的读集中不包含与所述变量版本对应的任一版本,将所述变量版本添加至所述历史事务的读集中。
在一种可能实施方式中,所述合并提交模块包括:
融合单元,用于对于所述待合并事务集中任一历史事务,响应于所述目标事务与所述历史事务之间不存在动边交叉,将所述目标事务与所述历史事务在逻辑上进行融合,得到一个逻辑事务。
在一种可能实施方式中,所述融合单元用于:
将所述目标事务的读集与所述历史事务的读集进行合并,得到所述逻辑事务的读集;将所述目标事务的写集与所述历史事务的写集进行合并,得到所述逻辑事务的写集。
在一种可能实施方式中,所述融合单元还用于:
响应于所述目标事务的读集和所述历史事务的读集中包括同一变量的不同变量版本,或者所述目标事务的写集和所述历史事务的写集中包括同一变量的不同变量版本,将所述同一变量的不同变量版本合并为所述同一变量的逻辑版本。
在一种可能实施方式中,所述融合单元还用于:
响应于所述逻辑事务的读集中包括至少两种变量的变量版本,且所述逻辑事务的写集中包括所述至少两种变量的其他变量版本,将所述至少两种变量合并为逻辑变量。
在一种可能实施方式中,所述装置还包括:
初始化模块,用于在开始执行所述目标事务时,将所述目标事务的读集和写集初始化为空集;
添加模块,用于响应于所述目标事务对任一变量进行更新,将所述变量添加至所述目标事务的写集中,不为所述变量分配版本号;
所述添加模块,还用于响应于所述目标事务读取任一变量,若所述变量位于所述目标事务的写集中,读取所述目标事务针对所述变量写入的值;若所述变量位于所述目标事务的读集中,读取所述目标事务的读集中已存储的所述变量的值;否则,读取所述变量当前已提交的最大版本,将所述最大版本添加至所述目标事务的读集中。
一方面,提供了一种计算机设备,该计算机设备包括一个或多个处理器和一个或多个存储器,该一个或多个存储器中存储有至少一条程序代码,该至少一条程序代码由该一个或多个处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法所执行的操作。
一方面,提供了一种存储介质,该存储介质中存储有至少一条程序代码,该至少一条程序代码由处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法所执行的操作。
本申请实施例提供的技术方案带来的有益效果至少包括:
通过对目标事务的读写集合进行一致性检测,能够在事务提交阶段精准识别出单事务构成的数据异常,当一致性检测通过时,获取待合并事务集,并对目标事务与历史事务进行合并,在事务合并后不存在数据异常的条件下,提交该目标事务,通过事务合并方式能够检测出多事务共同构成的数据异常,从而能够在事务处理过程中全面的识别出数据库系统内各种各样的数据异常,保证数据状态的一致性,在保证数据一致性的基础上,上述事务处理机制既不依赖于封锁技术也不依赖于依赖图技术,避免了限制数据库系统的并发度,也无需遍历并发事务去识别依赖图中环的存在,从而能够提升数据库系统的事务处理效率。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种事务处理方法的实施环境示意图;
图2是本申请实施例提供的一种垂边的示意图;
图3是本申请实施例提供的一种天边的示意图;
图4是本申请实施例提供的一种读写斜边的示意图;
图5是本申请实施例提供的一种只读斜边的示意图;
图6是本申请实施例提供的一种静边的示意图;
图7是本申请实施例提供的一种事务处理方法的流程图;
图8是本申请实施例提供的一种融合事务合并方式的原理图;
图9是本申请实施例提供的一种融合事务合并方式的原理图;
图10是本申请实施例提供的一种融合事务合并方式的原理图;
图11是本申请实施例提供的一种融合事务合并方式的原理图;
图12是本申请实施例提供的一种融合事务合并方式的原理图;
图13是本申请实施例提供的一种融合事务合并方式的原理图;
图14是本申请实施例提供的一种单向事务合并方式的原理图;
图15是本申请实施例提供的一种单向事务合并方式的原理图;
图16是本申请实施例提供的一种单向事务合并方式的原理图;
图17是本申请实施例提供的一种单向事务合并方式的原理图;
图18是本申请实施例提供的一种单变量数据异常的原理图;
图19是本申请实施例提供的一种单变量数据异常的原理图;
图20是本申请实施例提供的一种单变量数据异常的原理图;
图21是本申请实施例提供的一种单变量数据异常的原理图;
图22是本申请实施例提供的一种单变量数据异常的原理图;
图23是本申请实施例提供的一种单变量数据异常的原理图;
图24是本申请实施例提供的一种两个变量数据异常的原理图;
图25是本申请实施例提供的一种两个变量数据异常的原理图;
图26是本申请实施例提供的一种两个变量数据异常的原理图;
图27是本申请实施例提供的一种两个变量数据异常的原理图;
图28是本申请实施例提供的一种两个变量数据异常的原理图;
图29是本申请实施例提供的一种三个变量构成伪斜边交叉的原理图;
图30是本申请实施例提供的一种锯齿波异常的原理图;
图31是本申请实施例提供的一种锯齿波异常的原理图;
图32是本申请实施例提供的一种锯齿波异常的原理图;
图33是本申请实施例提供的一种锯齿波异常的冲突环示意图;
图34是本申请实施例提供的一种幻读异常的原理图;
图35是本申请实施例提供的一种幻读异常的原理图;
图36是本申请实施例提供的一种单变量扩展为两变量的拆分结果示意图;
图37是本申请实施例提供的一种对单变量拓展为两变量进行单向事务合并的原理图;
图38是本申请实施例提供的一种由两变量写异常拓展得到的三变量写异常的原理图;
图39是本申请实施例提供的一种基于不可重复读的变量拆分结果示意图;
图40是本申请实施例提供的一种状态分型方式的原理性示意图;
图41是本申请实施例提供的一种状态分型方式的原理性示意图;
图42是本申请实施例提供的一种不合法的事务分型方式的结果图;
图43是本申请实施例提供的一种混合分型方式的原理性示意图;
图44是本申请实施例提供的一种事务处理装置的结构示意图;
图45是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分,应理解,“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系,也不对数量和执行顺序进行限定。
本申请中术语“至少一个”是指一个或多个,“多个”的含义是指两个或两个以上,例如,多个第一位置是指两个或两个以上的第一位置。
在介绍本申请实施例之前,需要引入一些云技术领域内的基本概念:
云技术(Cloud Technology):是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术,也即是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台系统进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的系统后盾支撑,均能通过云计算来实现。
云存储(Cloud Storage):是在云计算概念上延伸和发展出来的一个新的概念,分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能,将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作,共同对外提供数据存储和业务访问功能的一个存储系统。
数据库(Database):简而言之可视为一种电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
本申请实施例所涉及的数据库系统,可以是单机数据库系统、单机以事务为主的数据库系统、单机以分析型为主但需要事务处理能力的数据库系统,可以是NoSQL(Non-relational SQL,泛指非关系型数据库)体系,还可以是分布式数据库系统、分布式大数据处理系统,对于分布式数据库系统而言,当不同变量分布存储在不同的物理节点上时,对应于数据状态一致性模型中存在两个及两个以上变量的情况,数据状态一致性模型以及相应的事务处理流程均将在后文的各个实施例中进行详细说明,这里不做赘述。
在数据库系统中可以包括至少一个节点设备,每个节点设备的数据库中可以存储有多个数据表,每个数据表可以用于存储一个或多个数据项(也称为变量版本)。其中,节点设备的数据库可以为任一类型的分布式数据库,可以包括关系型数据库或者非关系型数据库中至少一项,例如SQL(Structured Query Language,结构化查询语言)数据库、NoSQL、NewSQL(泛指各种新式的可拓展/高性能数据库)等,在本申请实施例中对数据库的类型不作具体限定。
在一些实施例中,本申请实施例还可以应用于一种基于区块链技术的数据库系统(以下简称为“区块链系统”),上述区块链系统在本质上属于一种去中心化式的分布式数据库系统,采用共识算法保持区块链上不同节点设备所记载的账本数据一致,通过密码算法保证不同节点设备之间账本数据的加密传送以及不可篡改,通过脚本系统来拓展账本功能,通过网络路由来进行不同节点设备之间的相互连接。
在区块链系统中可以包括一条或多条区块链,区块链是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。
区块链系统中节点设备之间可以组成点对点(Peer To Peer,P2P)网络,P2P协议是一个运行在传输控制协议(Transmission Control Protocol,TCP)协议之上的应用层协议。在区块链系统中,任一节点设备可以具备如下功能:1)路由,节点设备具有的基本功能,用于支持节点设备之间的通信;2)应用,用于部署在区块链中,根据实际业务需求而实现特定业务,记录实现功能相关的数据形成账本数据,在账本数据中携带数字签名以表示数据来源,将账本数据发送至区块链系统中的其他节点设备,供其他节点设备在验证账本数据来源以及完整性成功时,将账本数据添加至临时区块中,其中,应用实现的业务可以包括钱包、共享账本、智能合约等;3)区块链,包括一系列按照先后的时间顺序相互接续的区块,新区块一旦加入到区块链中就不会再被移除,区块中记录了区块链系统中节点设备提交的账本数据。
在一些实施例中,每个区块中可以包括本区块存储交易记录的哈希值(本区块的哈希值)以及前一区块的哈希值,各区块通过哈希值连接形成区块链,另,区块中还可以包括有区块生成时的时间戳等信息。
在介绍本申请实施例之前,由于数据库系统中事务并发控制的正确程度可以通过一致性和隔离性来描述,下面对一致性和隔离性进行解释说明:
一、隔离性
事务隔离级别通过能否规避某种数据异常而进行定义,可能涉及到的数据异常包括:1)脏读,指一个事务读取到了另一事务尚未提交的数据项;2)不可重复读,指一个事务对同一数据项重复读取两次却得到了不同的结果;3)幻读,指事务在操作过程中进行两次范围查询,第二次查询的结果包含了第一次查询的结果中未出现的数据项或者缺少了第一次查询的结果中出现的数据项。
基于能够解决上述三种数据异常,标准SQL中定义了四种隔离级别,分别包括:1)读未提交:允许如上三种数据异常发生;2)读已提交:不允许脏读发生;3)可重复读:不允许脏读、不可重复读发生;4)可串行化:如上三种数据异常均不能发生。
另外,还需要注意的一种数据异常称为丢失更新异常,是指两个并发事务同时进行更新,而后一个事务的更新覆盖了前一个事务的更新的情况,丢失更新异常是由于数据没有保证一致性而导致的。比如,存在数据项r1,r1中记录了属性值x=100,t时刻下事务w1和w2同时对数据项r1进行更新,事务w1首先将x=100修改为x=120之后提交,随后事务w2又将x=100修改为x=130之后提交,导致在查询事务w1时,会发现刚才修改的内容没有被修改掉,就好像是“丢失了更新”,因此这种数据异常称为丢失更新异常,丢失更新异常在可重复读和可串行化的一致性级别下均不允许发生。
二、一致性
数据库的一致性定义为:在事务的操作下,数据库的数据状态从一个一致的状态变迁为另一个一致的状态。上述“一致的状态”是指满足数据库系统预先定义的一些规则的数据状态,比如,这些规则可以包括约束、级联、触发器以及三者之间任意的组合(属于数据的逻辑语义),写偏序异常违反的就是特定数据之间的约束,这里的约束属于用户语义所限定的数据的一致性。
对于整个数据库系统而言,一致性还包括一层系统级的含义,是指要想保证数据在数据库系统中保持一致,还要求数据库系统符合两个特性,一个是可串行性(serializability),另一个是可恢复性(recoverability)。可串行性也即是说上述在隔离性中所定义到的可串行化隔离级别,可串行性保证了数据不会被并发操作改坏,而可恢复性是指已经提交的事务未曾读过被回滚的事务写过的数据(指不会发生脏读异常),可恢复性保证了事务被回滚后数据回到之前的一致的状态,被回滚的事务不会对数据的一致性造成影响,数据库系统的一致性状态是可恢复的。
基于上述概念可知一致性和隔离性与数据异常是息息相关的,目前,在数据库系统中如何识别并规避数据异常是一个犹为关键的问题。涉及到的数据库异常可以包括:脏读数据异常、脏写数据异常、不可重复读数据异常、幻读数据异常、丢失更新数据异常、读偏序数据异常、写偏序数据异常、串行并发现象(Serial-Concurrent-Phenomenon)数据异常、交叉现象(Cross-Phenomenon)数据异常等。
在识别数据异常时主要依赖于可串行化原理,通常可以采用两种识别数据异常的策略。其一是利用封锁技术,依赖锁的互斥机制来避免数据异常的发生,比如DB2、Informix、MySQL等数据库系统的可串行化隔离级别都是使用封锁技术;其二是利用依赖图技术,通过在并发事务所构成的依赖图中确认是否存在环,如果存在环则需要打破环的存在从而消除潜在的数据异常。
针对上述两种策略分别进行分析,封锁技术严重限制了数据库系统的并发度,导致事务处理效率低下,而依赖图技术则需要在并发事务之间遍历每个事务以识别出环的存在,这样的事务处理效率也不高,而为了识别出环是否存在,不仅需要借助各种衍生出的算法,而且需要复杂的数据结构来表示并发事务与被操作的数据项(也即是变量版本)之间的关联关系,大大提高了数据库系统的复杂性。
此外,还提供了一种基于依赖图和冲突可串行化技术(该技术基于可串行化原理)的简化实现方式,比如PostgreSQL的SSI(Snapshot Isolation,快照隔离)技术,SSI技术中能够提前识别出可能会造成依赖图中存在环的必要不充分条件:一个事务存在一条读写冲突入边和读写冲突出边;如果任一事务满足上述条件,则认为存在数据异常。
另外,更重要的是,上述识别数据异常的方法还存在如下问题:
第一,认知割裂不统一:不管是封锁技术、依赖图技术还是SSI技术,均割裂了每一种数据异常的识别方式,使得在识别数据异常时只能逐个去认知是否符合每一种数据异常,也即是说,不能用统一的角度去识别、认知这些不同种类的数据异常,导致针对数据异常的认知思路复杂且不清晰统一,运用到的各种算法也都形形色色难以理解。
第二,认知有限不全面:不管是封锁技术、依赖图技术还是SSI技术,均不能穷尽是否还有未知的新的数据异常。而一旦新的数据异常存在,那么将会为整个数据库系统带来不可估量的损失和代价,比如,当数据库系统处于非可串行化隔离级别下,如有新的数据异常,那么会导致系统中出现数据不一致错误。
第三,识别原理不精准:可串行化是数据存在异常的充分条件,但并非是数据存在异常的充要条件,在系统实现中虽然可避免出现新的数据异常,但是也有可能会把一些不存在数据异常的情况也当作了数据异常,相当于对于数据异常进行了误判,比如事务1写入了变量版本X1且读取了变量版本Y1,事务2读取了变量版本X1且写入了变量版本Y1,上述一系列的数据库操作可以记为“W1(X1)R2(X1)W2(Y1)R1(Y1)C2 C1”,这一系列的操作是不可串行化的,但并不存在数据异常。
有鉴于此,本申请实施例提供一种事务处理方法,给出了在事务处理过程中识别数据异常的算法,能够统一不同种类的数据库异常的定义,并且首次揭露了数据异常出现的本质原因,且基于不同的数据异常识别方法分别进行了效率评估,最终验证了本申请实施例的事务处理方法能够提升数据库系统的事务处理效率,下面将进行详述。
图1是本申请实施例提供的一种事务处理方法的实施环境示意图。参见图1,本实施例可以应用于分布式数据库系统,该系统中可以包括网关服务器101、全局时间戳生成集群102、分布式存储集群103以及分布式协调系统104(例如ZooKeeper),在分布式存储集群103中可以包括数据节点设备和协调节点设备。
其中,网关服务器101用于接收外部的读写请求,并将读写请求对应的读写事务分发至分布式存储集群103,比如,用户在登录终端上的应用客户端之后,触发应用客户端生成读写请求,调用分布式数据库系统提供的API(Application Programming Interface,应用程序编程接口)将该读写请求发送至网关服务器101,比如,该API可以是MySQL API(一种关系型数据库系统提供的API)。
在一些实施例中,该网关服务器101可以与分布式存储集群103中的任一个数据节点设备或任一协调节点设备合并在同一个物理机上,也即是,让某个数据节点设备或协调节点设备充当网关服务器101。
全局时间戳生成集群102用于生成全局事务的全局提交时间戳(GlobalTimestamp,Gts),该全局事务可以是指涉及到多个数据节点设备的事务,例如全局读事务可以涉及到对多个数据节点设备上存储数据的读取,又例如,全局写事务可以涉及到对多个数据节点设备上的数据写入。全局时间戳生成集群102在逻辑上可以视为一个单点,但在一些实施例中可以通过一主三从的架构来提供具有更高可用性的服务,采用集群的形式来实现该全局提交时间戳的生成,可以防止单点故障,也就规避了单点瓶颈问题。
可选地,全局提交时间戳是一个在分布式数据库系统中全局唯一且单调递增的时间戳标识,能够用于标志每个事务全局提交的顺序,以此来反映出事务之间在真实时间上的先后关系(事务的全序关系),全局提交时间戳可以采用物理时钟、逻辑时钟或者混合物理时钟中至少一项,本申请实施例不对全局提交时间戳的类型进行具体限定。
在一个示例性场景中,全局提交时间戳可以采用混合物理时钟的方式生成,全局提交时间戳可以由八字节组成,其中,前44位可以为物理时间戳的取值(也即Unix时间戳,精确到毫秒),这样共计可以表示244个无符号整数,因此理论上一共可以表示约为年的物理时间戳,其中,后20位可以为在某一毫秒内的单调递增计数,这样每毫秒有220个(约100万个)计数,基于上述数据结构,如果单机(任一数据节点设备)的事务吞吐量为10w/s,理论上可以支持包含1万个节点设备的分布式存储集群103,同时,全局提交时间戳的数量代表了系统理论上所能支持的总事务数,基于上述数据结构,理论上系统可以支持(244-1)*220个事务。这里仅仅是对一种全局提交时间戳的定义方法的示例性说明,根据业务需求的不同,可以对全局提交时间戳的位数进行扩展,以满足对更多的节点数、事务处理数的支持,本申请实施例不对全局提交时间戳的定义方法进行具体限定。
在一些实施例中,该全局时间戳生成集群102可以是物理独立的,也可以和分布式协调系统104(例如ZooKeeper)合并到一起。
其中,分布式存储集群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)。
在一个示例性场景中,每个节点设备所对应的主机或备机的数据库实例集合称为一个SET(集合),例如,假设某一节点设备为单机设备,那么该节点设备的SET仅为该单机设备的数据库实例,假设某一节点设备为一主两备集群,那么该节点设备的SET为主机数据库实例以及两个备机数据库实例的集合,此时可以基于云数据库的强同步技术来保证主机的数据与备机的副本数据之间的一致性,可选地,每个SET可以进行线性扩容,以应付大数据场景下的业务处理需求,在一些金融业务场景下,全局事务通常是指跨SET的转账。
分布式协调系统104可以用于对网关服务器101、全局时间戳生成集群102或者分布式存储集群103中至少一项进行管理,可选地,技术人员可以通过终端上的调度器(scheduler)访问该分布式协调系统104,从而基于前端的调度器来控制后端的分布式协调系统104,实现对各个集群或服务器的管理。例如,技术人员可以通过调度器来控制ZooKeeper将某一个节点设备从分布式存储集群103中删除,也即是使得某一个节点设备失效。
上述图1仅是提供了一种轻量级的全局事务处理的架构图,是一种类分布式数据库系统。整个分布式数据库系统可以看作是共同维护一个逻辑上的大表,这个大表中存储的数据通过主键被打散到分布式存储集群103中的各个节点设备中,每个节点设备上存储的数据是独立于其他节点设备的,从而实现了节点设备对逻辑大表的水平切分。由于在上述系统中能够将各个数据库中各个数据表水平切分后进行分布式地存储,因此,这种系统也可以形象地称为具有“分库分表”的架构。
在上述分布式数据库系统中,已经基于XA/2PC算法实现了写操作时数据的原子性和一致性,而读操作的数据一致性问题,需要通过构造一个轻量的、去中心化的分布式事务处理机制来改善,从技术的角度来看,分布分表架构缺乏一个全局事务管理器,也就缺乏分布式事务处理能力,通过构造上述轻量的、去中心化的分布式事务处理机制,能够为分布式数据库系统提供水平扩展等能力,并且保证分布式数据库系统简单易推广、事务处理效率更高,必将对传统并发控制方式所设计的分布式数据库架构产生极大冲击,具体的分布式事务处理机制将在下个实施例中进行详述。
在一些实施例中,上述网关服务器101、全局时间戳生成集群102、分布式存储集群103以及分布式协调系统104所构成的分布式数据库系统,可以视为一种向用户终端提供数据服务的服务器,该服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network,内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。可选地,上述用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等,但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本申请在此不做限制。
在介绍本申请实施例之前,首先将对数据库系统中所涉及到的一些基本术语以及符号表示进行介绍:
事务:事务是数据库管理系统在执行操作的过程中的一个逻辑单位,由一个有限的数据库操作序列构成,是数据库系统操作的最小执行单位。
变量:事务是数据库关系系统中的一个数据单位,变量是数据库操作的作用者(或者说操作对象),一个变量可以包含若干变量版本(在后文中也简称为“版本”),每当事务对变量进行更新时,则会添加新的变量版本,变量的各个变量版本可以以自然数作为版本号标识,版本号越大,则表示变量版本越新。
操作:一个数据库操作由操作类型、事务、变量版本三部分构成,其中,操作类型可以包括读(R)和写(W)两种。例如,事务T对变量x进行更新,生成了变量x的新版本i,上述读操作则可以记为WT(xi);又比如,事务T读取变量x的版本i的值,上述写操作可以记为RT(xi)。
事务数据集合:数据集合是由若干个变量版本所构成的集合,且集合中每个变量至多仅包含一个版本,可以记为数据集合DS(T)={xi,yj,zk,...|x,y,z为变量,i,j,k为版本号}。
数据库系统中的每个事务拥有两个事务数据集合,分别为事务的写集和事务的读集,其含义为:写集DSW(T)用于存储事务T所写入的新的数据版本,读集DSR(T)用于存储事务T所读取的数据版本。
版本读取集合:版本读取集合是由若干个事务所构成的集合,表示读取某一变量版本的全部事务,可以记为版本读取集合TS(xi)={Ti,Tj,Tk,...|i,j,k为事务ID},版本读取集合中既可以包括已提交事务,也可以包括未提交事务。
本申请实施例所提供的事务处理方法,是在数据状态一致性模型的基础上运行的,而本申请所提供的数据状态一致性模型是数据库事务处理技术范围内第一次、全面、系统地提出一个数据模型,该模型揭示了各种数据异常的本质,而且统一了各种数据异常的描述和表达,解释了数据异常和并发事务之间的关联关系,并且,还能够发现出更多新的、未知的数据异常,能够更好地保证数据库系统的一致性。
在上述数据状态一致性模型中,可以将事务与事务操作的变量版本之间的关系绘制成图形表示,下面,将对数据状态一致性模型所涉及的几个图形概念进行定义:
1、结点:每个变量版本为一个结点,由于一个变量可以包括若干版本,在图形表示中同一变量的若干版本按照由旧至新的顺序呈纵向排列,也即是说,在图形表示中,同一变量的若干版本呈一纵列,并且位于顶端的版本最旧,位于底端的版本最新。
2、垂边:同一个变量的两个相邻版本之间所存在的垂直边,称为“垂边”。垂边表示同一变量中版本的变迁,更新操作(比如DML的UPDATE语句)可以造成数据状态的改变,从而生成一条垂边。图2是本申请实施例提供的一种垂边的示意图,如图2所示,t0时刻存在变量版本x0,在t1时刻事务T1将变量版本x0更新为变量版本x1,记为W(x1),在变量版本x0与变量版本x1之间的垂线段200即为一条“垂边”。
需要注意的是,垂边包含“从变量的某一版本更新至另一版本”的含义,因此对于任一个事务而言,其垂边上端连接的变量版本,应加入到当前事务的读集中(无论是否实际对该变量版本执行过读操作)。另外,版本更新只能由单个事务进行,不能由并发事务进行,这样可以禁止写写并发,从而避免发生脏写数据异常。
3、斜边:两个不同变量的版本之间存在的边,称为“斜边”。斜边表示两个变量之间的一致性状态,斜边可以划分为写写斜边(又称为“WW斜边”或“天边”)、读写斜边(又称为“RW斜边”)、读读斜边(“RR斜边”或“只读斜边”),其含义分别为:
1)天边:同一个事务修改了两个或两个以上不同的变量,则这些变量在两两之间可以构成一条天边。换言之,在事务的写集中,任意两变量之间一定存在一条天边,天边的两端分别与两结点的上端相连。图3是本申请实施例提供的一种天边的示意图,如图3所示,t0时刻存在变量版本x0和变量版本y0,在t1时刻事务T1将变量版本x0更新为变量版本x1,将变量版本y0修改为变量版本y1,记为W(x1)和W(y1),在变量版本x1与变量版本y1的上顶点之间的连线300即为一条“天边”。
需要说明的是,在一些实施例中,如果一个事务仅修改了一个变量,那么该事务的垂边的终端点可以称为天点,天点是天边的一种特殊形式,相当于天边的两端点重合,以图2为例,由于事务T1仅修改了一个变量版本x0,其垂边的终端点为变量版本x1,因此图2中的变量版本x1就是一个天点。
2)读写斜边:某个事务在任何两个不同的变量间,先后存在读、写操作,则该事务所读的变量版本和所写的变量版本之间可以构成一条读写斜边。读写斜边的读端与结点下端相连,写端与结点上端相连。图4是本申请实施例提供的一种读写斜边的示意图,如图4所示,t0时刻存在变量版本x0和变量版本y0,在t1时刻事务T1将变量版本x0更新为变量版本x1,并读取变量版本y0,记为W(x1)和R(y0),在变量版本y0的下顶点与变量版本x1的上顶点之间的连线400即为一条“读写斜边”。
3)只读斜边:同一个事务读取两个或两个以上不同的变量,则这些变量在两两之间可以构成一条只读斜边。换言之,在事务的读集中,任意两变量之间一定存在一条只读斜边。只读斜边的两端分别与两结点的下端相连,也即是说只有当变量版本已经处于提交状态时才可以被事务读取到,此时执行读已提交规则。图5是本申请实施例提供的一种只读斜边的示意图,如图5所示,t0时刻存在变量版本x0和变量版本y0,随后某一事务将变量版本x0更新为变量版本x1,在t1时刻事务T1分别读取变量版本x1和变量版本y0,记为R(x1)和R(y0),在变量版本y0的下顶点与变量版本x1的下顶点之间的虚线500即为一条“只读斜边”。
4、一致性状态边:
一致性状态边由一个或多个斜边或垂边首尾相连构成,用于描述多个变量之间的一致性状态。例如,图3中变量版本x0与变量版本x1之间构成的垂边、变量版本x1与变量版本y1之间构成的天边、变量版本y0与变量版本y1之间构成的垂边,这三条边共同构成一个一致性状态边;又比如,图4中变量版本x0与变量版本x1之间构成的垂边、变量版本y0与变量版本x1之间构成的读写斜边,这两条边共同构成一个一致性状态边;又比如,图5中变量版本y0与变量版本x1之间构成的只读斜边,该只读斜边可以独自构成一个一致性状态边。
一致性状态边可能涉及多个事务的垂边或天边,也即是说,处于一致性状态边上的结点之间保持数据一致性,但这些结点并不一定是单个事务操作的,有可能涉及到多个并发事务。例如,图5中变量版本x0与变量版本x1之间构成的垂边以及变量版本y0与变量版本x1之间构成的只读斜边可以共同构成一致性状态边,但垂边是由某一事务执行更新操作而生成的,而只读斜边是由另一事务执行读取操作而生成的,虽然两者对应于不同的事务,但可以共同构成一个一致性状态边。
按照事务提交与否,一致性状态边可以划分为两种,下面分别进行介绍:
1)静边:指静态一致性状态边,静边由已经提交的事务生成。静边反映了历史时刻上数据状态发生变化后,各个变量版本之间的一致性关系。
图6是本申请实施例提供的一种静边的示意图,如图6所示,3个变量的初始状态分别为r11,r21,r31,随着时间的推移(图6中从上至下代表时间增长),不同事务修改了变量状态,变量状态发生变化,比如T1事务将r11修改为r12,此时r12、r21和r31之间的虚线构成一条静边601,T2事务将r21和r31分别修改为r22和r32,则此时r22、r32和r12之间的连线构成一条静边602,T3事务将r12和r32分别修改为r13和r33,则此时r13、r33和r22之间的虚线构成一条静边603。如果在介于t1和t2时刻中间的任一个时间点读取保持一致性的变量版本,由于r22、r32的修改尚未提交,因此此时保持一致性的只能是r12、r21和r31间的虚线静边601,因此读取到的变量版本为r12、r21和r31。
2)动边:指动态一致性状态边,动边是并发事务集合中的一部分事务共同读写变量而构成的边,在并发事务集合中至少有一个事务没有提交。动边至少由一个事务构成,也可由多个事务构成,多个并发事务合并后可构成一条动边(并发事务合并条件在将后文进行介绍,这里不做赘述)。动边反映出了并发事务对数据状态的影响。
上述过程中,并发事务是指并发执行的两个或两个以上的事务,以两事务为例进行说明,若两事务对相同的变量在同一段时间内进行了读写操作,则认为两事务并发执行,假设存在事务T1和事务T2,若两事务满足ts(T1)<tc(T2)且ts(T2)<tc(T1),并对相同的变量执行过读写操作,也即是说T1的事务开始时刻ts小于T2的事务提交时刻tc,且T2的事务开始时刻ts小于T1的事务提交时刻tc,且两者对相同的变量执行过读写操作,此时可以认为T1和T2互为并发事务。
在一些实施例中,上述事务开始时刻有2种不同的含义:一种是事务启动时刻,另一种是事务的第一个读操作或写操作开始的时刻,两种含义均可以作为判定并发事务的条件,本申请实施例不对事务开始时刻的具体含义进行限定。
在同一时间段内一系列并发事务可以构成一个并发事务集合,并发事务集合={T1,T2,…,Tn},其中n≥2,n个事务中每个事务在该并发事务集合中均至少存在一个与其并发的事务,也即是说每个事务至少在该并发事务集合中存在“两事务并发执行”的情况,并发事务集合也可以简称并发事务,一个并发事务集合中至少存在一条“动态一致性状态边”。
在并发事务集合中,如果存在至少两条动边在两个相同的变量上构成RW-RW、RR-RR、RW-RR、RW-WR或者RR-WR关系中至少一项,则表示并发事务构成动边交叉。在动边交叉中,至少有一条动边包含了一个未提交事务,此外,上述两个相同的变量,不仅可以指两个相同的物理变量,比如x和y,或者x1和x2,还可以指两个相同的逻辑变量,逻辑变量是基于一个或多个物理变量组合而构成,比如{x}和{y1,z0}。
下面分别讨论动边交叉的几种情况:
A)2个变量上构成RW-RW关系:倘若存在两事务执行如R1(X0)R2(Y0)W1(Y1)W2(X1)的数据库操作,则两事务在变量X和Y上构成RW-RW关系,其中,上述示例以事务1读取X0写入Y1、事务2读取Y0写入X1为例进行说明,可选地,两事务的读操作与读操作可互换位置,两事务的写操作与写操作可互换位置,使得互换位置后两事务仍然在变量X和Y上构成RW-RW关系。
B)2个变量上构成RR-RR关系:倘若存在两事务执行如R1(X0)R2(Y0)R1(Y1)R2(X1)的数据库操作,则两事务在变量X和Y上构成RR-RR关系,其中,上述示例以事务1读取X0和Y1、事务2读取Y0和X1为例进行说明,可选地,前2个读操作与读操作可互换位置,后2个读操作与读操作可互换位置,使得互换位置后两事务仍然在变量X和Y上构成RR-RR关系。
C)2个变量上构成RW-RR关系:倘若存在两事务执行如R1(X0)R2(Y0)W1(Y1)R2(X1)的数据库操作,则两事务在变量X和Y上构成RW-RR关系,其中,上述示例以事务1读取X0写入Y1、事务2读取Y0和X1为例进行说明,可选地,前2个读操作与读操作可互换位置,后2个写操作与读操作可互换位置,使得互换位置后两事务仍然在变量X和Y上构成RW-RR关系。
D)2个变量上构成RW-WR关系:倘若存在两事务执行如R1(X0)W2(X1)W2(Y1)R1(Y1)的数据库操作,则两事务在变量X和Y上构成RW-WR关系。
E)2个变量上构成RR-WR关系:倘若存在两事务执行如R1(X0)R2(X1)W2(Y1)R1(Y1)的数据库操作,则两事务在变量X和Y上构成RR-WR关系,其中,前2个读操作与读操作可互换位置,使得互换位置后两事务仍然在变量X和Y上构成RR-WR关系。
上述A)~E)五种情况代表了五种可能的动边交叉场景,动边交叉则代表并发事务之间构成了数据异常,这是因为两条动边各自跨了一个一致性状态边,分别操作(或读或写)了处于不同一致性状态的变量,因此会导致数据异常。在数据库系统中,为保持数据状态的一致性,当检测到出现动边交叉时,至少一条动边中的未提交事务需要回滚,从而能够解决掉产生数据异常的原因。
在上述过程中,静边和动边协同反映了时态数据库中的全态数据的获取方式和技术,这里的全态数据包括历史态数据和当前态数据,可选地,在一些数据库中还可以包括过渡态数据,其中,静边反映了历史态数据的一致性状态,使得数据库的处理能够可以扩展到历史态数据中,动边反映了当前态数据(以及过渡态数据)的一致性状态,使得数据库可以不依赖于可串行化技术以及各种隔离级别的基础上,仍然能够精准识别与避免各类数据异常。
其中,全态数据中的各个不同状态属性,可以用于标识数据在其生命周期轨迹中所处的状态:当前态是指最新版本的变量,是处于当前阶段的变量版本;历史态是指变量在历史上的一个状态,其值是旧值,不是当前值,多个历史态版本可以对应于同一变量,反映了该变量的数据状态变迁过程,处于历史态的变量版本只能被读取而不能被修改或删除;过渡态既不是当前态也不是历史态,处于从当前态向历史态转变的过程中,这种处于过渡态的数据也称为半衰数据。
在本申请实施例的数据库系统中,每个已经完成的事务之间是按照逻辑时钟有序的,也即是说,各个已提交事务的提交时间戳全局有序,可以由全局时间戳生成集群来保证全局有序,比如图6中t0~t5这几个时刻均可以采用逻辑时钟进行定序,在一些实施例中,也可以采用物理时钟、混合时钟进行定序,本申请实施例不对采用的时钟类型进行具体限定。
在介绍了数据状态一致性模型的基本概念之后,在本申请实施例中将结合事务处理流程,对如何基于该数据状态一致性模型识别数据异常的过程进行说明。图7是本申请实施例提供的一种事务处理方法的流程图,参见图7,该实施例可以应用于数据库系统中任一节点设备,比如上述分布式存储集群103中的协调节点设备或者数据节点设备,该实施例包括:
700、节点设备在开始执行目标事务时,将该目标事务的读集和写集初始化为空集。
其中,该目标事务可以是全局事务,也可以是局部事务,其中,该全局事务是指涉及到跨节点操作的事务,而局部事务则是指仅涉及单个节点操作的事务,本申请实施例不对目标事务的类型进行具体限定。
在上述过程中,目标事务可以由终端发起,此时终端与节点设备建立用于处理目标事务的会话,终端向节点设备发送目标事务的执行请求,节点设备响应于目标事务的执行请求,开始执行该目标事务,可选地,如果终端与节点设备已经建立过一个会话,那么无需在两者之间建立新的会话,只需要复用当前已建立的会话即可。
在上述步骤700中,节点设备可以在数据库系统启动时,向操作系统申请一块内存空间,该内存空间用于维护至少一个事务的读写集合(包括读集和写集),当目标事务开始执行时,节点设备从该内存空间中申请一块内存,该内存用于管理该目标事务的读写集合(包括读集和写集),从而在节点设备上完成了目标事务的读写集合的创建,并且,将创建出的读集和写集均初始化为空集。
在一些实施例中,由于目标事务可以涉及到针对变量的两种操作类型,一种是读取操作,一种是更新操作,因此,当目标事务涉及到对变量进行更新操作时,执行下述步骤701,当目标事务涉及到对变量进行读取操作时,执行下述步骤702。
701、响应于该目标事务对任一变量进行更新,节点设备将该变量添加至该目标事务的写集中,不为该变量分配版本号。
在上述过程中,节点设备根据目标事务的执行语句,确定该目标事务是否涉及对变量进行更新操作,若目标事务涉及到对任一变量进行更新操作,可以将该变量添加至写集中,但不为该变量分配版本号,以变量x为例,当目标事务对变量x进行更新时,将变量x添加至写集中,且不为变量x分配版本号。需要说明的是,若该变量已经被添加到了写集中,那么无需向写集中重复添加相同的变量。
在上述过程中,如果目标事务涉及到对多个变量执行更新操作,那么节点设备可以对多个变量中的每个变量均执行上述步骤701,从而能够将该多个变量均添加至目标事务的写集中,实现对目标事务的写集的维护。
702、响应于该目标事务读取任一变量,若该变量位于该目标事务的写集中,节点设备读取该目标事务针对该变量写入的值;若该变量位于该目标事务的读集中,节点设备读取该目标事务的读集中已存储的该变量的值;否则,节点设备读取该变量当前已提交的最大版本,将该最大版本添加至该目标事务的读集中。
在上述过程中,节点设备根据目标事务的执行语句,确定该目标事务是否涉及对变量进行读取操作,若目标事务涉及到对任一变量进行读取操作,节点设备可以判断该变量是否已经存在于读写集合中:以变量x为例,如果变量x已经存在与写集中,说明目标事务此前已经对变量x的值进行过更新操作,此时节点设备应当读取目标事务写过的值,且不向读集中添加新的变量版本;如果变量x的第i个版本xi(i≥0)已经存在于读集中,为了确保可重复读(也即是为避免出现不可重复读数据异常),此时节点设备应当读取读集中已存储的变量版本xi的值;否则,如果变量x不存在于目标事务的读写集合中,那么节点设备可以读取变量x当前已提交的最大版本xj(j≥0),并将最大版本xj加入到读集中,这里的最大版本xj是指变量x当前已提交的各个变量版本中版本号最大的变量版本,从时序上来讲最大版本xj的时间戳是最新的,因此最大版本也可以俗称为“最新版本”。
上述步骤700-702中,提供了节点设备在数据读写阶段中针对目标事务的读写集合的扩充算法,该扩充算法可以采用如下伪代码进行表示:
在上述过程中,如果目标事务涉及到对多个变量执行读取操作,那么节点设备可以对多个变量中的每个变量均执行上述步骤702,从而能够实现对目标事务的读集的维护。
在上述步骤700-702中,通过对目标事务的读写集合进行初始化,并在事务执行过程中维护目标事务的读写集合,能够保证后续针对读写集合进行一致性检测过程的准确性,从而有利于更好地识别出数据异常,提升数据库系统的事务处理效率。
703、响应于目标事务的提交请求,节点设备对该目标事务的读集中变量版本进行一致性检测。
在上述过程中,若节点设备为数据节点设备,那么目标事务的提交请求可以由协调节点设备向数据节点设备进行发送,若节点设备为协调节点设备,那么目标事务的提交请求由协调节点设备自身生成,本申请实施例不对提交请求的来源进行具体限定。
在上述步骤703中,节点设备在对读集中的变量版本进行一致性检测的过程中,假设用T表示目标事务,用DSR(T)表示目标事务的读集,用DSW(T)表示目标事务的写集,节点设备可以遍历目标事务T的读集DSR(T),对于该目标事务的读集DSR(T)中任一变量版本xi(i≥0),节点设备可以执行下述操作:
1)节点设备将该目标事务T添加至该变量版本xi的版本读取集合中,该版本读取集合用于表示当前读取该变量版本xi的事务集合。
在数据库系统中,每个变量版本都可以维护一个由若干个事务所构成的版本读取集合,该版本读取集合用于表示当前读取该变量版本的全部事务(既包括未提交事务,也包括已提交事务),在本申请实施例中,节点设备将事务T添加到变量版本xi的版本读取集合中,在一些实施例中,该版本读取集合可以存储于变量版本的页眉(header)结构中。
2)响应于存在任一已提交事务Ta写入版本号大于该变量版本xi的目标版本x(i+1),且该目标事务T读取的另一变量版本yj的版本号j大于该已提交事务Ta所读取的对应变量版本yk的版本号k(也即是j<k),节点设备确定对该变量版本xi一致性检测不通过,回滚该目标事务;否则,节点设备确定对该变量版本xi的一致性检测通过。
在上述过程中,节点设备在将目标事务T添加到变量版本xi的版本读取集合之后,可以检测是否存在已提交事务Ta写入了变量x的较新版本x(i+1),若存在已提交事务Ta写入了较新的x(i+1)版本,则比较目标事务T和已提交事务Ta的读写集合:对于已提交事务Ta的读集DSR(Ta)中的每个变量版本yj,若目标事务的写集DSW(T)中存在相同的变量y,或者目标事务的读集DSR(T)中存在相同变量的另一版本yk,且满足j<k,说明目标事务T读取的版本比已提交事务Ta读取的版本更新,此时目标事务T和已提交事务Ta在变量x和y上出现了斜边交叉,存在数据不一致的异常问题,节点设备需要将目标事务T回滚,否则,不满足上述回滚目标事务T的相关条件,则可以按照事务合并算法将已提交事务Ta(也称为历史事务)合并至目标事务T,具体的事务合并算法将在下述步骤706-707中进行详述,这里不做赘述。
704、响应于对该目标事务的读集中变量版本的一致性检测通过,节点设备对该目标事务的写集中变量进行一致性检测;否则,节点设备回滚该目标事务。
在上述过程中,节点设备需要对目标事务的读集中的每个变量版本均进行一致性检测,只要存在任一变量版本未通过一致性检测,那么节点设备就需要回滚目标事务,反之,如果读集中所有变量版本均通过一致性检测,那么节点设备对目标事务的写集中变量进行一致性检测。
在上述步骤704中,节点设备在对写集中的变量进行一致性检测的过程中,假设用T表示目标事务,用DSR(T)表示目标事务的读集,用DSW(T)表示目标事务的写集,节点设备可以遍历目标事务T的写集DSW(T),对于该目标事务的写集DSW(T)中任一变量x(这里称作变量而不是变量版本,是因为写集中的变量均未分配版本号),节点设备可以执行下述操作:
1)节点设备对该变量x加锁。
在上述过程中,通过对写集中的各个变量进行加锁,能够防止并发写冲突(或者称为写写冲突,指同一时间段两个并发事务对同一变量执行写操作),此时节点设备可以按照一定的顺序对变量加锁,以避免产生死锁,避免影响数据库系统的性能。
2)节点设备获取该变量x当前已提交的最大版本号。
在上述过程中,节点设备可以获取变量x当前已提交的最新版本xi,将最新版本xi的版本号i确定为上述最大版本号,其中i≥0。
3)响应于该读集中存在该变量x的版本号与该最大版本号不相等,节点设备确定对该变量x一致性检测不通过,回滚该目标事务T;否则,节点设备确定对该变量x的一致性检测通过。
在上述过程中,如果目标事务T的读集DSR(T)中存在变量版本xj,且i≠j,说明此时数据库系统中产生了写写冲突,因此节点设备需要将目标事务T回滚;反之,如果目标事务T的读集DSR(T)中不存在变量x的任何变量版本,那么节点设备确定对变量x的一致性检测通过,节点设备对目标事务T的写集DSW(T)中每一个变量均进行一致性检测,如果写集中所有变量均通过一致性检测,节点设备执行下述步骤705,否则,如果写集中存在任一个变量未通过一致性检测,节点设备回滚目标事务T。
需要说明的是,针对目标事务的回滚操作中包括一些清理逻辑,比如释放锁、从各版本的版本读取集合中将本事务T移除,后面各个步骤所涉及到回滚操作时均执行上述清理逻辑,在后文中将不做赘述。
705、响应于对该目标事务的写集中变量的一致性检测通过,节点设备为该写集中变量分配版本号,确定对该目标事务的读写集合的一致性检测通过;否则,节点设备回滚该目标事务。
在上述过程中,当目标事务的写集中所有变量均通过一致性检测之后,对于写集中任一变量,节点设备可以将该变量当前已提交的最新版本添加至目标事务的读集中,将目标事务添加到上述最新版本的版本读取集合中,在写集中为该变量的对应版本分配目标版本号,该目标版本号为该变量当前已提交的最大版本号加一所得的数值,也即是说,该目标版本号为上述最新版本的版本号加一所得的数值。
以变量x为例进行说明,节点设备可以在上述步骤704中对变量x进行一致性检测时,已经获取到了变量x当前已提交的最新版本xi,若写集中所有变量均通过一致性检测,节点设备将变量x的最新版本xi加入到目标事务T的读集DSR(T)中,将目标事务T加入到最新版本xi的版本读取集合中,并为目标事务T的写集DSW(T)中变量x的对应版本赋予版本号为i+1。
在上述步骤703-705中,响应于目标事务的提交请求,节点设备对该目标事务的读写集合进行一致性检测,在对读写集合进行一致性检测的过程中,节点设备先对读集进行一致性检测,当读集中所有变量版本均通过一致性检测之后,再对写集进行一致性检测,当写集中所有变量也均通过一致性检测时,确定目标事务的整个读写集合通过一致性检测。
在一些实施例中,节点设备还可以先对写集进行一致性检测,当写集中所有变量均通过一致性检测之后,再对读集进行一致性检测,当读集中所有变量版本也均通过一致性检测时,确定目标事务的整个读写集合通过一致性检测,可选地,节点设备还可以同时对目标事务的读集和写集分别进行一致性检测,本申请实施例不对读集和写集分别进行一致性检测的时序进行具体限定。
在上述步骤703-705中,提供了基于数据状态一致性模型在事务提交阶段的一致性检验算法,该算法可以采用如下伪代码进行表示:
在上述步骤703-705中,通过对目标事务的读写集合进行一致性检测,能够从本质上检测出识别出数据异常,在本申请实施例中,通过检测并发事务之间是否存在斜边交叉,即可确定并发事务之间是否存在数据异常,这样能够对数据异常进行一个统一的认知,而无需去针对各种类型的数据异常进行一一比对,而且即使面对一些未知的数据异常,依然能够通过斜边交叉的一致性检测逻辑识别出来,能够保证在事务处理过程中准确高效地识别出数据异常,从而提升了数据库系统的事务处理效率。
706、响应于对该读写集合的一致性检测通过,节点设备基于该读写集合,获取该目标事务的待合并事务集,该待合并事务集用于提供待与该目标事务进行合并的历史事务。
在上述过程中,节点设备可以将待合并事务集初始化为空集,进一步地,遍历目标事务的读集中的每个变量版本,对于该目标事务的读集中任一变量版本,响应于该变量版本的下一版本位于该目标事务的写集中,节点设备可以将该变量版本的版本读取集合中的事务添加至该待合并事务集;将写入该变量版本的事务添加至该待合并事务集。
以目标事务T的读集DSR(T)中的某一变量版本xi为例进行说明,如果变量版本xi的下一版本x(i+1)位于目标事务T的写集DSW(T)中,则节点设备可以将变量版本xi的版本读取集合中所有事务T’添加至待合并事务集中,其中,变量版本xi的版本读取集合中所有事务T’均满足RT′(xi)条件;进一步地,节点设备将写入变量版本xi的事务T”添加至待合并事务集中,其中,写入变量版本xi的事务T”均满足WT″(xi)条件;进一步地,对于目标事务T的读集DSR(T)中的下一变量版本循环执行上述操作,直到遍历了目标事务T的读集DSR(T)中的每个变量版本,此时可以得到最终的待合并事务集,执行下述步骤707。
707、节点设备对该目标事务以及该待合并事务集中的历史事务进行合并。
在一些实施例中,在进行事务合并时,本申请实施例提供一种单向事务合并方式:对于该待合并事务集中任一历史事务,响应于该目标事务的读集中的变量均包含在该历史事务的读集中,节点设备跳过该历史事务;否则,节点设备将该目标事务的读集合并至该历史事务的读集,对读集合并后的历史事务递归执行合并操作,直到遍历该待合并事务集。
以待合并事务集中的某一历史事务Tm为例进行说明,如果目标事务T的读集DSR(T)中的所有变量均包含在了历史事务Tm的读集DSR(Tm)中,换言之,在不考虑相同变量的不同版本的前提下,如果满足了DSR(T)为DSR(Tm)的子集这一条件,相当于对于所有的RT(xi),均存在那么在事务合并时跳过该历史事务Tm,否则,将目标事务T的读集合并至历史事务Tm的读集,对合并了目标事务T之后的历史事务Tm递归执行上述合并操作,也即是说,继续判断合并后的历史事务Tm是否需要与待合并事务集中另外的历史事务继续进行合并,循环执行合并操作,最终遍历完整个待合并事务集。
上述步骤706-707中提供了基于数据状态一致性模型的历史事务递归合并算法,该历史事务递归合并算法可以采用如下伪代码进行表示:
在一些实施例中,节点设备在将目标事务的读集合并至历史事务的读集的过程中,对该目标事务的读集中任一变量版本,响应于该历史事务的读集中不包含与该变量版本对应的任一版本,节点设备可以将该变量版本添加至该历史事务的读集中。
在上述过程中,介绍了如何将目标事务与历史事务进行合并(本质上是读集合并),由于对于合并后的历史事务仍然要进行历史事务递归合并算法,因此上述事务合并方法可以类推到任意两个事务的合并过程,假设将事务T1合并到历史事务T2,这里的事务T1可以是目标事务,也可以是经过了多次合并之后的历史事务,此时节点设备可以遍历事务T1的读集DSR(T1),对于事务T1的读集DSR(T1)中的每个变量版本xi而言,如果历史事务T2的读集DSR(T2)中未包含变量x的任一版本,那么节点设备直接将变量版本xi添加至历史事务T2的读集DSR(T2)中,否则,如果历史事务T2的读集DSR(T2)中包含了变量x的变量版本xj,此时一直会有j<i,也即是说,历史事务T2所读取到的变量版本一定比事务T1更旧。
上述针对任意两个事务进行合并的过程,可以看作是一种历史事务合并算法,该算法可以采用如下伪代码进行表示:
在上述过程中,由于将事务T1合并到历史事务T2的过程中,本质上是将事务T1的读集合并到历史事务T2的读集中,在合并完成之后,历史事务T2的读集得到了扩充,而事务T1的读集不发生改变,这种合并方式可以形象地称为“单向事务合并方式”,是指单向的将事务T1合并到历史事务T2中。
在一些实施例中,节点设备还可以通过融合事务合并方式来进行事务合并:对于该待合并事务集中任一历史事务,响应于该目标事务与该历史事务之间不存在动边交叉,节点设备将该目标事务与该历史事务在逻辑上进行融合,得到一个逻辑事务。这里的融合事务合并方式是指将两个不同的事务在逻辑上融合成为一个逻辑事务,该逻辑事务的读集为两事务各自读集的并集,而该逻辑事务的写集为两事务各自写集的并集。
可选地,节点设备在对目标事务与历史事务进行事务融合时,可以将该目标事务的读集与该历史事务的读集进行合并,得到该逻辑事务的读集;将该目标事务的写集与该历史事务的写集进行合并,得到该逻辑事务的写集。通过分别对两事务的读集和写集进行合并,能够得到虚构出来的、逻辑上存在的逻辑事务自身的读集和写集。
融合事务合并方式与单向事务合并方式的区别也在于此,在单向事务合并方式中,并不会虚构一个逻辑事务,而是直接将目标事务的读集合并到历史事务的读集中,目标事务的读集不发生变化,而历史事务的读集会进行扩充,而在融合事务合并方式中,会生成一个逻辑上存在的逻辑事务,逻辑事务的读集和写集分别是两个被合并事务各自读集和写集之间的并集。
在一些实施例中,在融合事务合并方式中,节点设备还可以对变量进行版本纵向合并:响应于该目标事务的读集和该历史事务的读集中包括同一变量的不同变量版本,或者该目标事务的写集和该历史事务的写集中包括同一变量的不同变量版本,节点设备将该同一变量的不同变量版本合并为该同一变量的逻辑版本。通过将同一变量的不同变量版本进行合并,能够达到变量的版本纵向合并,可以提高事务合并的程度,从而能够降低并发事务的数量,提升数据库系统的事务处理效率。
在一些实施例中,在融合事务合并方式中,节点设备还可以对不同的变量进行逻辑合并:响应于该逻辑事务的读集中包括至少两种变量的变量版本,且该逻辑事务的写集中包括该至少两种变量的其他变量版本,将该至少两种变量合并为逻辑变量。通过对不同的变量进行逻辑合并,能够达到不同变量的横向合并,同样可以提高事务合并的程度,从而能够降低并发事务的数量,提升数据库系统的事务处理效率。
708、响应于事务合并后不存在数据异常,节点设备提交该目标事务。
在上述过程中,不管采用单向事务合并方式还是融合事务合并方式,均能够对目标事务以及待合并事务集中的历史事务完成事务合并操作,对于事务合并后的读写集合再次执行一致性检测,响应于事务合并后的读写集合通过了一致性检测,即可确定事务合并后不存在数据异常,从而提交该目标事务,对该目标事务进行数据落盘,在目标事务提交完成之后,可以对目标事务的写集中的所有变量解锁。
需要说明的是,这种事务合并的方式能够检测出多事务共同构成的数据异常,基于本申请实施例提供的数据状态一致性模型,无需去逐个判断并发事务符合哪种类型的数据异常的判定条件,而是直接判断合并后各个事务的一致性状态边上是否存在动边交叉即可,能够从本质上揭示数据异常的产生原因,并且能够提升事务处理过程中识别数据异常的精准度。在下个实施例中,将结合数据状态的一致性模型分别对上述两种不同的事务合并方式进行详细介绍,这里不做赘述。
上述所有可选技术方案,可以采用任意结合形成本公开的可选实施例,在此不再一一赘述。
本申请实施例提供的方法,通过对目标事务的读写集合进行一致性检测,能够在事务提交阶段精准识别出单事务构成的数据异常,当一致性检测通过时,获取待合并事务集,并对目标事务与历史事务进行合并,在事务合并后不存在数据异常的条件下,提交该目标事务,通过事务合并方式能够检测出多事务共同构成的数据异常,从而能够在事务处理过程中全面的识别出数据库系统内各种各样的数据异常,保证数据状态的一致性,在保证数据一致性的基础上,上述事务处理机制既不依赖于封锁技术也不依赖于依赖图技术,避免了限制数据库系统的并发度,也无需遍历并发事务去识别依赖图中环的存在,从而能够提升数据库系统的事务处理效率。
在本申请实施例中,提出两种不同的事务合并方式,分别称为融合事务合并方式和单向事务合并方式,两种事务合并方式均可以用于检测多事务共同构成的数据异常(比如3变量构成的读、写偏序异常等),但是合并的方式有所不同,下面分别进行说明:
一、融合事务合并方式
融合事务合并方式的含义为:在并发事务集合中,若事务T1(表示为{T1})和事务T2(表示为{T2})之间可以构成一条动边,则事务T1和事务T2可以合并为一个逻辑事务(表示为{T1,T2}),两事务合并意味着两事务的读集和写集分别合并,也即是说,T1读集和T2读集合并,T1写集和T2写集合并。
两事务之间能够合并的一个重要条件是:合并在一起的事务,不存在动边交叉。在本申请实施例中,通过在事务提交阶段针对读写集合的一致性检测算法,能够识别出存在动边交叉的各种情况并进行回滚操作,从而保证最终进行事务合并时满足上述条件。
在一些实施例中,在合并事务读写集合的过程中,还涉及到变量合并的概念:若事务的读集中包含变量版本xi和yj,写集中包含变量版本x(i+1)和y(j+1),此时可以将变量x和y合并为一个逻辑变量{x,y},即执行变量合并后,事务的读集中包含变量版本{x,y}(i,j),写集中包含变量版本{x,y}(i+1,j+1)。
图8是本申请实施例提供的一种融合事务合并方式的原理图,请参考图8,事务T1和事务T2并发执行,事务T1读取变量版本x0和y0并写入变量版本y1,事务T2读取变量版本y0和z0并写入变量版本z1,此时事务T1所执行的操作可以表示为“R(x0)R(y0)W(y1)”,事务T2所执行的操作可以表示为“R(y0)R(z0)W(z1)”,事务T1和事务T2的一致性状态边如801所示,可以分析出,事务T1的读集为DSR(T1)={x0,y0},事务T1的写集为DSW(T1)={y1},事务T2的读集为DSR(T2)={y0,z0},事务T2的写集为DSW(T2)={z1}。
接下来,由于事务T1和事务T2之间不存在动边交叉情况,因此事务T1和事务T2满足事务合并条件,此时可以将事务T1和事务T2合并为一个逻辑事务{T1,T2},逻辑事务{T1,T2}的读写集合是事务T1和事务T2的读写集合的并集,也即是说,逻辑事务{T1,T2}的读集为DSR({T1,T2})={x0,y0,z0},是T1读集与T2读集的并集,逻辑事务{T1,T2}的写集为DSW({T1,T2})={y1,z1},是T1写集与T2写集的并集,此时逻辑事务{T1,T2}所执行的操作可以表示为“R(x0)R(y0)R(z0)W(y1)W(z1)”,逻辑事务{T1,T2}的一致性状态边如802所示,也即是说,可以看作逻辑事务{T1,T2}读取变量版本x0、y0和z0,并且写入变量版本y1和z1。
接下来,由于逻辑事务{T1,T2}的读集和写集中均包含变量y和z,因此在事务合并的基础上,还可以针对逻辑事务{T1,T2}的读写集合进行变量合并,此时将变量y和z合并为逻辑变量{y,z},在变量合并之后,逻辑事务{T1,T2}的读集可以表示为DSR({T1,T2})={x0,{y,z}(0,)},逻辑事务{T1,T2}的写集可以表示为DSW({T1,T2})={{y,z}(1,1)},此时逻辑事务{T1,T2}所执行的操作可以表示为“R(x0)R({y,z}(0,0))W({y,z}(1,1))”,变量合并后的逻辑事务{T1,T2}的一致性状态边如803所示,也即是说,可以看作逻辑事务{T1,T2}读取了变量版本x0以及逻辑变量{y,z}(0,0),并且写入逻辑变量{y,z}(1,1)。
在一些实施例中,在合并事务读写集合的过程中,变量合并是指不同变量之间的横向合并,而对于同一变量的不同版本而言,还涉及到版本纵向合并的概念:对于待合并的事务T1、T2而言,如果事务T1的读集DSR(T1)和事务T2的读集DSR(T2)中包含同一变量的不同版本,或者事务T1的写集DSW(T1)和事务T2的写集DSW(T2)中包含同一变量的不同版本,则需要对两变量版本进行纵向合并。在进行版本纵向合并的过程中,可以遵循如下规则:
1)若事务T1的写集DSW(T1)和事务T2的读集DSR(T2)中皆包含变量版本xi,则将变量版本xi从逻辑事务{T1,T2}的读集DSR({T1,T2})中删除。
需要说明的是,由于变量版本xi出现在事务T1的写集中,而事务T1的写集又是逻辑事务{T1,T2}的写集的子集,因此变量版本xi必定存在于逻辑事务{T1,T2}的写集中,这里仅将变量版本xi从逻辑事务{T1,T2}的读集中删除,但变量版本xi仍然在逻辑事务{T1,T2}的写集中进行保留。
2)若事务T1的写集DSW(T1)中包含变量版本xi,事务T2的写集DSW(T2)中包含变量版本x(i+1),则可以将变量版本xi和变量版本x(i+1)纵向合并为变量版本x{i,(i+1)}。
3)若通过上述1)和2)两种合并规则进行版本纵向合并后,逻辑事务{T1,T2}的读集或写集中,依然存在同一变量的不同版本,则确定事务合并失败。
图9是本申请实施例提供的一种融合事务合并方式的原理图,请参考图9,事务T1和事务T2并发执行,事务T1读取变量版本x0并写入变量版本y1和z1,事务T2读取变量版本x0和y1并写入变量版本z2,此时事务T1所执行的操作可以表示为“R(x0)W(y1)W(z1)”,事务T2所执行的操作可以表示为“R(x0)R(y1)W(z2)”,事务T1和事务T2的一致性状态边如901所示,可以分析出,事务T1的读集为DSR(T1)={x0,y0,z0},事务T1的写集为DSW(T1)={y1,z2},事务T2的读集为DSR(T2)={x0,y1,z1},事务T2的写集为DSW(T2)={z2}。
接下来,由于事务T1和事务T2之间不存在动边交叉情况,因此事务T1和事务T2满足事务合并条件,事务T1和事务T2共同读取变量版本x0,此时可以将事务T1和事务T2融合为一个逻辑事务{T1,T2},逻辑事务{T1,T2}的读写集合是事务T1和事务T2的读写集合的并集,也即是说,逻辑事务{T1,T2}的读集为T1读集与T2读集的并集,可以表示为DSR({T1,T2})={x0,y0,y1,z0,z1},同理,该逻辑事务{T1,T2}的写集为T1写集与T2写集的并集,具体可以表示为DSW({T1,T2})={y1,z1,z2}。
接下来,由于事务T1的写集DSW(T1)和事务T2的读集DSR(T2)中皆包含变量版本y1和z1,按照规则1),将变量版本y1和z1从逻辑事务{T1,T2}的读集DSR({T1,T2})中删除,得到DSR({T1,T2})={x0,y0,z0},进一步地,由于事务T1的写集DSW(T1)中包含变量版本z1,事务T2的写集DSW(T2)中包含变量版本z2,按照规则2),在逻辑事务{T1,T2}的写集中将变量版本z1和变量版本z2纵向合并为变量版本z{1,2},得到DSW({T1,T2})={y1,z{1,2}},此时逻辑事务{T1,T2}所执行的操作可以表示为“R(x0)W(y1)W(z{1,2})”,逻辑事务{T1,T2}的一致性状态边如902所示,也即是说,可以看作逻辑事务{T1,T2}读取变量版本x0,并且写入变量版本y1和z{1,2}。
进一步地,在经过版本纵向合并之后,由于逻辑事务{T1,T2}的读集中包含变量版本y0和z0,逻辑事务{T1,T2}的写集中包含变量版本y1和z{1,2},此时可以将变量y和z合并为一个逻辑变量{y,z},在变量合并之后,逻辑事务{T1,T2}的读集可以表示为DSR({T1,T2})={x0{y,z}(0,0)},逻辑事务{T1,T2}的写集可以表示为DSW({T1,T2})={{y,z}(1,{1,2})},按照规则3),此时逻辑事务{T1,T2}的读集DSR({T1,T2})和写集DSW({T1,T2})中对于每个变量只包含一个版本(不存在同一变量的不同版本),因此事务T1和事务T2合并成功,此时逻辑事务{T1,T2}所执行的操作可以表示为“R(x0)W({y,z}(1,{1,2}))”,变量合并后的逻辑事务{T1,T2}的一致性状态边如903所示,也即是说,可以看作逻辑事务{T1,T2}读取了变量版本x0,并且写入逻辑变量{y,z}(1,{1,2})。
图10是本申请实施例提供的一种融合事务合并方式的原理图,请参考图10,示出了两事务之间融合合并失败的情况。存在事务T1读取变量版本x0和y0,事务T1表示为“R(x0)R(y0)”,事务T2写入变量版本y1,事务T2表示为“R(y1)”,事务T3读取变量版本x0和y1,事务T3表示为“R(x0)R(y1)”,事务T1、T2和T2的一致性状态边如1000所示,由于事务T1的读集为DSR(T1)={x0,y0},事务T3的读集为DSR(T3)={x0,y1},可以对事务T1和事务T3进行合并,合并后的逻辑事务{T1,T3}的读集可以表示为DSR({T1,T3})={x0,y0,y1},此时逻辑事务{T1,T3}的读集中包含同一变量y的两个版本y0和y1,并且无法通过规则1)和规则2)在逻辑上进行版本消除,因此,根据规则3)可以确定事务合并失败。
在这种情况下,还可以考虑先将事务T1与别的事务(比如T2)进行合并,在合并完成后再与事务T3进行合并。图11是本申请实施例提供的一种融合事务合并方式的原理图,请参考图11,示出了在图10所给示例基础上先将T1与T2合并之后再与T3合并的情况,事务T1的读集为DSR(T1)={x0,y0},事务T2的读集为DSR(T2)={y0},事务T2的写集为DSW(T2)={y1},事务T3的读集为DSR(T3)={x0,y1}。首先,对事务T1和事务T2进行合并,得到逻辑事务{T1,T2},针对事务T1和事务T2的读集和写集分别进行合并,得到逻辑事务{T1,T2}的读集DSR({T1,T2})={x0,y0}和写集DSW({T1,T2})={y1},其次,对逻辑事务{T1,T2}和事务T3进行再次合并,得到逻辑事务{T1,T2,T3},针对逻辑事务{T1,T2}和事务T3的读集和写集分别进行合并,得到逻辑事务{T1,T2,T3}的读集DSR({T1,T2,T3})={x0,y0,y1}和写集DSW({T1,T2,T3})={y1},由于逻辑事务{T1,T2}的写集DSW({T1,T2})以及事务T3的读集DSR(T3)中均包含变量版本y1,按照规则1),将变量版本y1从逻辑事务{T1,T2,T3}的读集中删除,得到逻辑事务{T1,T2,T3}最终的读集为DSR({T1,T2,T3})={x0,y0},此时由于逻辑事务{T1,T2,T3}的读集和写集中同一变量只包含一个版本,因此按照规则3)可以确定事务合并成功,逻辑事务{T1,T2,T3}的一致性状态边如1100所示,逻辑事务{T1,T2,T3}读取了变量版本x0和y0并写入了变量版本y1,因此逻辑事务{T1,T2,T3}所执行的操作可以表示为“R(x0)R(y0)W(y1)”。
在一些实施例中,融合事务合并方式有可能会遮盖掉一些数据异常,图12是本申请实施例提供的一种融合事务合并方式的原理图,请参考图12,示出了融合事务合并方式对动边交叉的掩盖情况。事务T1读取变量版本x0写入变量版本y1,事务T1所执行的操作可以表示为“R(x0)W(y1)”,事务T2读取变量版本x0写入变量版本y2,事务T2所执行的操作可以表示为“R(x0)W(y2)”,事务T3读取变量版本y1写入变量版本z1,事务T3所执行的操作可以表示为“R(y1)W(z1)”,事务T3读取变量版本z0和y2,事务T4所执行的操作可以表示为“R(z0)R(y2)”,T1~T4这四个事务之间的一致性状态边如1201所示,可以看出,事务T3和事务T4构成了动边交叉,说明存在数据不一致的异常情况。
然而,若对事务T1和事务T2进行合并,得到逻辑事务{T1,T2},逻辑事务{T1,T2}读取变量版本x0写入逻辑变量y{1,2},逻辑事务{T1,T2}所执行的操作可以表示为“R(x0)W(y{1,2})”,也即是说,变量版本y1和y2被合并为了逻辑变量y{1,2},此时事务T3可以视为读取逻辑变量y{1,2}写入变量版本z1,事务T3所执行的操作可以表示为“R(y{1,2})W(z1)”,事务T4可以视为读取变量版本z0和逻辑变量y{1,2},事务T4所执行的操作可以表示为“R(z0)R(y{1,2})”,逻辑事务{T1,T2}以及T3、T4这三个事务之间的一致性状态边如1202所示,可以看出,在事务T1和T2合并之后,动边交叉消失了,会得出不存在数据异常的错误结论。这是因为在对T1和T2进行版本纵向合并之前,没有检测被合并的版本之间是否存在动边交叉,只有在不存在动边交叉的情况下才能进行事务合并,这样可以防止数据异常被遗漏。
在一些实施例中,融合事务合并方式还有可能会造成对数据异常的误判。请参考图13,图13是本申请实施例提供的一种融合事务合并方式的原理图,示出了融合事务合并形成新的天边导致对异常的误判情况。事务T1读取变量版本x0和z0,事务T1所执行的操作可以表示为“R(x0)R(z0)”,事务T2读取变量版本x0写入变量版本y1,事务T2所执行的操作可以表示为“R(x0)W(y1)”,事务T3读取变量版本y0写入变量版本z1,事务T3所执行的操作可以表示为“R(y0)W(z1)”,T1~T3三个事务之间的一致性状态边如1301所示,可以看出此时三事务之间未出现动边交叉,因此不存在数据异常。
然而,若对事务T1和事务T2进行合并,得到逻辑事务{T1,T2},逻辑事务{T1,T2}读取变量版本x0和z0,并且写入变量版本y1,逻辑事务{T1,T2}所执行的操作可以表示为“R(x0)R(z0)W(y1)”,逻辑事务{T1,T2}与事务T3之间的一致性状态边如1302所示,可以看出,在事务T1与T2合并之后,在变量版本y1和z0之间构造了一条新的动边(RW斜边),这条新的动边和事务T3的动边交叉,构成了数据异常,这种属于对数据异常的误判情况,会导致将原本不存在异常的事务进行回滚,因此事务合并虽然能够提升识别数据异常的准确性,但会对事务的回滚率造成一定的提升。
二、单向事务合并方式
单向事务合并方式的含义为:在并发事务集合中,若事务T2读取了事务T1所写的数据,或者事务T2更新了事务T1读过的数据,则需要将事务T2的读集DSR(T2)合并至事务T1的读集DSR(T1),在合并之后事务T2的读集DSR(T2)不发生改变。
图14是本申请实施例提供的一种单向事务合并方式的原理图,请参考图14,事务T1读取变量版本x0,事务T1所执行的操作可以表示为“R(x0)”,事务T2写入变量版本x1,事务T2所执行的操作可以表示为“W(x1)”,事务T3读取变量版本x1,事务T3所执行的操作可以表示为“R(x1)”,T1~T3三个事务之间的一致性状态边如1400所示,此时,由于事务T3读取了事务T3所写的变量版本x1,因此需要将事务T3合并至事务T2,由于事务T2更新了事务T1读过的变量版本x0,因此需要将事务T2合并至事务T1,在经历过单向事务合并之后,最终满足如下条件:DSR(T3)变量集合变量集合变量集合。
在单向事务合并方式中,对于将事务T2合并至事务T1的情况,假设存在变量版本xi∈DSR(T2),则需要对事务T1的读集DSR(T1)执行如下判断规则:
1)若事务T1的读集DSR(T1)中不包含变量x的任何版本,此时将变量版本xi添加至事务T1的读集DSR(T1)中,同时事务T1形成新的动边。
2)若有变量版本xj∈DSR(T1),且i<j,即事务T1读到的变量版本xj新于事务T2读到的变量版本xi,则事务T1和T2之间构成动边交叉,出现数据异常。
3)若有变量版本xj∈DSW(T1),且i<j,即事务T1写了一个更新的版本xj,则事务T1和T2之间构成动边交叉,出现数据异常。
4)否则,跳过该变量版本xi。
图15是本申请实施例提供的一种单向事务合并方式的原理图,请参考图15,事务T1和事务T2并发执行,事务T1读取变量版本x0和y0并写入变量版本y1,事务T2读取变量版本y0和z0并写入变量版本z1,此时事务T1所执行的操作可以表示为“R(x0)R(y0)W(y1)”,事务T2所执行的操作可以表示为“R(y0)R(z0)W(z1)”,事务T1和事务T2的一致性状态边如1501所示,可以分析出,事务T1的读集为DSR(T1)={x0,y0},事务T2的读集为DSR(T2)={y0,z0},由于事务T1更新了事务T2读过的变量版本y0,满足单向事务合并方式中的事务合并条件,因此需要将事务T1合并至事务T2,在合并后的事务T2的读集中添加变量版本x0,也即是说,执行单向事务合并之后,事务T1的读集不变,而事务T2的读集变为DSR(T2)={x0,y0,z0},事务T1与合并后的事务T2之间的一致性状态边如1502所示,可以看出,在一致性状态图中,增加了三条由事务T1构成的新动边,分别包括由变量版本x0和变量版本y0构成的RR斜边、由变量版本x0和变量版本z0构成的RR斜边,以及由变量版本x0和变量版本z1构成的RW斜边。
在一些实施例中,单向事务合并方式是可以进行连续传导合并的(也即是递归合并),图16是本申请实施例提供的一种单向事务合并方式的原理图,请参考图16,图16是在图13所给出示例的基础上采用单向事务合并方式进行事务合并所得的结果,示出了单向事务合并方式中的连续传导合并情况。事务T1读取变量版本x0和z0,事务T1所执行的操作可以表示为“R(x0)R(z0)”,事务T2读取变量版本x0写入变量版本y1,事务T2所执行的操作可以表示为“R(x0)W(y1)”,事务T3读取变量版本y0写入变量版本z1,事务T3所执行的操作可以表示为“R(y0)W(z1)”,T1~T3三个事务之间的一致性状态边如1601所示,事务T1的读集为DSR(T1)={x0,z0},事务T2的读集为DSR(T2)={x0,y0},事务T3的读集为DSR(T3)={y0,z0}。
由于事务T2更新了事务T3读过的变量版本y0,故需要将事务T2的读集合并至事务T3的读集,合并后事务T3的读集变为DSR(T3)={x0,y0,z0},而事务T3又更新了事务T1读过的变量版本z0,故需要将合并后事务T3的读集再次合并至事务T1的读集,合并后事务T1的读集变为DSR(T1)={x0,y0,z0},所以,最终的事务合并顺序为T2→T3→T1,合并后的事务T1~T3这三者之间的一致性状态边如1602所示,可以看出,针对同一示例,图16采用的单向事务合并方式与图13中采用的融合事务合并方式相比,单向事务合并方式并未导致对数据异常的误判情况,但是也并未降低并发事务的个数(仍然是三个事务并发)。
图17是本申请实施例提供的一种单向事务合并方式的原理图,请参考图17,示出了单向事务合并方式中可能检测到的四种动边交叉情况1701~1704。在情况1701和1702中,事务T2将事务T1读过的变量版本y0更新为变量版本y1;情况1703和1704中,事务T2读了事务T1所写的变量版本y1。根据事务合并条件,此时应该将事务T2合并至事务T1,然而,针对情况1701和1703来说,事务T1读到的变量版本x1新于事务T2读到的变量版本x0,根据上述规则2),可以确定此时出现动边交叉,构成了数据异常;针对情况1702和1704来说,事务T2读了变量版本x0,事务T1将变量版本x0更新为了变量版本x1,根据上述规则3),可以确定此时出现动边交叉,构成了数据异常。
在本申请实施例中,融合事务合并方式可以将多个事务融合成为一个逻辑事务,从而能够降低并发事务的数量,简化数据库系统的操作复杂度,但由于随着被合并事务的数量增加,逻辑事务会变得越来越庞大,因此还需要一些额外的机制来避免针对数据异常的遗漏或者误判;而单向事务合并方式能够将某一事务T1的读集合并到另一事务T2的读集中,在此过程中事务T1的读集不发生改变,因此能够解决逻辑事务变庞大的问题,但无法降低并发事务的数量,而且还需要对同一事务多次进行单向合并,会带来一部分事务合并的开销。
在上个实施例中,分别介绍了两种不同的事务合并方式,融合事务合并方式能够降低并发事务的数量,而单向事务合并方式能够避免对数据异常的遗漏或误判。在本申请实施例中,将基于数据状态一致性模型来描述传统的单变量的所有数据异常,单变量异常可以划分为三种类型:动边交叉导致的异常、脏写异常以及读写未提交异常,下面分别进行讨论。
一、单变量中动边交叉导致的异常
单变量中动边交叉导致的异常包括:丢失更新异常、不可重复读异常以及幻读异常。
图18是本申请实施例提供的一种单变量数据异常的原理图,请参考图18,示出了单变量丢失更新异常,事务T1写入变量版本x1,事务T1所执行的操作可以表示为“W(x1)”,事务T2读取变量版本x0并写入变量版本x2,事务T2所执行的操作可以表示为“R(x0)W(x2)”,在图18中存在两条一致性状态边,一致性状态边1801是变量版本x0到变量版本x1之间的垂边,在变量版本x1的上端构成了一个天点,且事务T1已经提交,而一致性状态边1802是变量版本x0到变量版本x2之间的垂边,与变量版本x1上端的天点构成了交叉,也即是说,事务T2的一致性状态边1802穿过了其他事务T1写过的天点(变量版本x1),一致性状态边1802跨了一致性状态边1801以及天点所构成的动边,形成了两条动边交叉,事务T1与事务T2是并发事务,满足一致性模型定义,因此事务T1和事务T2之间存在丢失更新数据异常。
图19是本申请实施例提供的一种单变量数据异常的原理图,请参考图19,示出了单变量不可重复读异常,事务T1写入变量版本x1,事务T1所执行的操作可以表示为“W(x1)”,事务T2读取变量版本x0和x1,事务T2所执行的操作可以表示为“R(x0)R(x1)”,在图19中存在两条一致性状态边,一致性状态边1901是变量版本x0到变量版本x1之间的垂边,在变量版本x1的上端构成了一个天点,且事务T1已经提交,而一致性状态边1902是变量版本x0到变量版本x1下端之间的虚线,与变量版本x1上端的天点构成了交叉,也即是说,事务T2的一致性状态边1902穿过了其他事务T1写过的天点(变量版本x1),一致性状态边1902跨了一致性状态边1901以及天点所构成的动边,形成了两条动边交叉,事务T1与事务T2是并发事务,满足一致性模型定义,因此事务T1和事务T2之间存在不可重复读异常。
图20是本申请实施例提供的一种单变量数据异常的原理图,请参考图20,示出了幻读异常。图20是在图19的基础上扩展得到的,在图19中,事务T2对变量x执行单点读操作,构成了不可重复读异常,而在图20中,事务T1写入变量版本y0,事务T1所执行的操作可以表示为“W(y0)”,事务T2对变量x和y先后两次执行谓词读操作(也称为范围读操作),第一次谓词读操作读取到了变量版本x0,记为“R(Range1={x0})”,第二次谓词读操作读取到了变量版本x0和y0,记为“R(Range1={x0,y0})”,事务T1和T2的一致性状态边如2000所示,也即是说,第二次谓词读操作读到了T1事务写入的变量版本y0(插入或更新操作),导致两次谓词读操作出现不一样的读取结果,此时即构成幻读异常。关于幻读异常的产生原因将在下个实施例中进行详述,这里不做赘述。
二、脏写异常
数据状态一致性模型要求并发事务之间禁止同时写同一个变量(也即禁止写写冲突),图21是本申请实施例提供的一种单变量数据异常的原理图,请参考图21,示出了单变量脏写异常,事务T1写入变量版本x1,记为“W(x1)”,事务T2写入变量版本x2,记为“W(x2)”,事务T1与事务T2并发执行且同时写了变量x,事务T1和T2的一致性状态边如2100所示,此时即构成脏写异常,在脏写异常发生时,可以采取先提交者获胜原则或者先写者获胜原则,获胜的事务进行提交阶段,而未获胜的事务进入回滚阶段。
三、读写未提交异常
数据状态一致性模型要求事务满足读写已提交原则,如果并发事务破坏了读写已提交原则,那么将会导致脏写异常、脏读异常以及中间读异常。
图22是本申请实施例提供的一种单变量数据异常的原理图,请参考图22,示出了单变量脏读异常,事务T1写入变量版本x1,记为“W(x1)”,事务T2读取变量版本x1,记为“R(x1)”,事务T1与事务T2并发执行,事务T1和T2的一致性状态边如2200所示,此时即构成脏读异常。
图23是本申请实施例提供的一种单变量数据异常的原理图,请参考图23,示出了单变量中间读异常,事务T1写入变量版本x1和x2,记为“W(x1)W(x2)”,事务T2读取变量版本x1,记为“R(x1)”,事务T1与事务T2并发执行,事务T1和T2的一致性状态边如2300所示,此时即构成中间读异常。
在本申请实施例中,基于数据状态一致性模型,对传统单变量的所有数据异常均进行了分析和描述,单变量异常可以划分为三种类型:动边交叉导致的异常、脏写异常以及读写未提交异常,结合一致性状态图,分别对三种类型的单变量异常的产生原因和产生场景进行了分析和描述,因此,在该数据状态一致性模型中,能够检测出传统单变量的所有数据异常。
在上述实施例中,基于数据状态一致性模型对传统单变量的数据异常进行了说明,而在本申请实施例中,将基于数据状态一致性模型对两个变量的数据异常进行分析和描述,两个变量的数据异常可以划分为写相关的数据异常以及读相关的数据异常,下面分别进行讨论:
一、写相关的数据异常
两个或两个以上的并发事务之间可以构成写偏序数据异常。
图24是本申请实施例提供的一种两个变量数据异常的原理图,请参考图24,示出了两个事务构成的写偏序数据异常。事务T1读取变量版本y0写入变量版本x1,记为“R(y0)W(x1)”,事务T2读取变量版本x0写入变量版本y1,记为“R(x0)W(y1)”,事务T1和T2的一致性状态边如2400所示,变量版本x0到x1到y0之间的连线构成一条一致性状态边(对应于事务T1),而变量版本y0到y1到x0之间的连线构成另一条一致性状态边(对应于事务T2),这两条一致性状态边之间构成动边交叉,事务T1和事务T2是并发事务,各自构成一条动边,满足一致性模型定义中的动边交叉,因此存在写偏序数据异常。
图25是本申请实施例提供的一种两个变量数据异常的原理图,请参考图25,示出了三个事务构成的写偏序数据异常。事务T1写入变量版本x1,记为“W(x1)”,事务T2读取变量版本y0和x1,记为“R(y0)R(x1)”,事务T3读取变量版本x0写入变量版本y1,记为“R(x0)W(y1)”,事务T1~T3的一致性状态边如2500所示,变量版本x0到x1之间的连线构成一条一致性状态边(对应于事务T1),而变量版本y0到x1之间的连线构成一条一致性状态边(对应于事务T2),变量版本y0到y1到x0之间的连线构成一条一致性状态边(对应于事务T3),事务T1和T2合并构成一条动边,事务T3独自构成了一条动边,两条动边之间存在动边交叉,因此存在写偏序数据异常。
二、读相关的数据异常
两个或两个以上的并发事务之间可以构成读偏序数据异常。
图26是本申请实施例提供的一种两个变量数据异常的原理图,请参考图26,示出了两个事务构成的读偏序数据异常。事务T1写入变量版本x1和y1,记为“W(x1)W(y1)”,事务T2读取变量版本x0和y1,记为“R(x0)R(y1)”,事务T1和T2的一致性状态边如2600所示,变量版本x0到x1到y1到y0之间的连线构成一条一致性状态边(对应于事务T1),而变量版本x0到y1之间的连线构成另一条一致性状态边(对应于事务T2),这两条一致性状态边之间构成动边交叉,事务T1和事务T2是并发事务,各自构成一条动边,满足一致性模型定义中的动边交叉,事务T2执行R(y1)操作时,想要读取到变量版本y1,根据读已提交原则,则事务T1写的y1的值必须已经提交,因此存在读偏序数据异常。
图27是本申请实施例提供的一种两个变量数据异常的原理图,请参考图27,示出了三个事务构成的读偏序数据异常。事务T1写入变量版本x1,记为“W(x1)”,事务T2读取变量版本x1写入变量版本y1,记为“R(x1)W(y1)”,事务T3读取变量版本x0和y1,记为“R(x0)R(y1)”,事务T1~T3的一致性状态边如2700所示,变量版本x0到x1之间的连线构成一条一致性状态边(对应于事务T1),变量版本y0到y1到x1之间的连线构成一条一致性状态边(对应于事务T2),变量版本x0到y1之间的连线构成一条一致性状态边(对应于事务T3),事务T1和T2合并构成一条动边,事务T3独自构成了一条动边,两条动边之间存在动边交叉,存在读偏序数据异常。
图28是本申请实施例提供的一种两个变量数据异常的原理图,请参考图28,示出了四个事务构成的读偏序数据异常。事务T1写入变量版本x1,记为“W(x1)”,事务T2写入变量版本y1,记为“W(y1)”,事务T3读取变量版本y0和x1,记为“R(y0)R(x1)”,事务T4读取变量版本x0和y1,记为“R(x0)R(y1)”,事务T1~T4的一致性状态边如2800所示,变量版本x0到x1之间的连线构成一条一致性状态边(对应于事务T1),变量版本y0到y1之间的连线构成一条一致性状态边(对应于事务T2),变量版本y0到x1之间的连线构成一条一致性状态边(对应于事务T3),变量版本x0到y1之间的连线构成一条一致性状态边(对应于事务T4),事务T1和T4合并构成一条动边,事务T2和T3合并构成一条动边,两条动边之间存在动边交叉,存在读偏序数据异常。
在上述过程中,图27所示的三个事务构成的读偏序数据异常以及图28所示的四个事务构成的读偏序数据异常,均是目前主流数据库系统中并未发现的数据异常,因此在本申请实施例中能够检测出更加全面的数据异常情况。
在本申请实施例中,基于数据状态一致性模型,对两个变量的数据异常进行分析和描述,两个变量的数据异常可以划分为写相关的数据异常以及读相关的数据异常,结合一致性状态图,分别对写偏序异常和读偏序异常的产生原因和产生场景进行了分析和描述,因此,在该数据状态一致性模型中,能够检测出两个变量的数据异常。
在上述实施例中,基于数据状态一致性模型,对传统单变量的数据异常以及两个变量的数据异常采用一致性状态图的方式进行分析,除了中间读异常指纹,其余所有传统的数据异常均存在动边交叉,两变量之间的异常可以通过一致性状态边交叉(动边交叉)在图像中清晰地判别出来,而多变量的数据异常的检测方式则更为复杂,在本申请实施例中,将基于数据状态一致性模型对多变量的数据异常进行讨论。
一、伪斜边交叉
在本申请实施例中,动边交叉是指“存在至少2条动边,在2个不同变量上构成RW-RW、RR-RR、RW-RR、RW-WR、RR-WR关系”,因此动边交叉将变量数限制在2,如果变量数不是2,那么则不构成动边交叉。
图29是本申请实施例提供的一种三个变量构成伪斜边交叉的原理图,请参考图29,事务T1读取变量版本z0并写入变量版本x1,记为“R(z0)W(x1)”,事务T2读取变量版本y0写入变量版本z1,记为“R(y0)W(z1)”,如2901所示的一致性状态边中,事务T1所构成的z0到x1的动边(RW斜边)与事务T2所构成的y0到z1的动边(RW斜边)看似发生了动边交叉,但是实际上这两条动边之间的交叉涉及到了3个不同的变量,这与动边交叉的定义是不符的。在这种情况下,如2902所示的一致性状态边中可以看出,只要交换变量y和变量z的位置,就能够在一致性状态图中消除动边之间的交叉点,因此事务T1和事务T2在本质上并不存在并发冲突,这种情况下不构成多变量之间的动边交叉,也即是不构成数据异常。
二、锯齿波异常
在一些实施例中,本申请实施例中通过动边交叉来识别数据异常,但是动边交叉是数据异常的充分条件,而非必要条件,也即是说,即使任意两动边之间不构成交叉,也有可能会出现数据异常。
图30是本申请实施例提供的一种锯齿波异常的原理图,请参考图30,示出了由事务操作序列构成三变量的写偏序异常的情况。事务T1读取变量版本z0并写入变量版本x1,记为“R(z0)W(x1)”,事务T2读取变量版本y0写入变量版本z1,记为“R(y0)W(z1)”,事务T3读取变量版本x0写入变量版本y1,记为“R(x0)W(y1)”,事务T1~T3的一致性状态边如3000所示,根据动边交叉的定义,由于事务T1、T2、T3所构建的动边,彼此之间符合上述示例中“伪动边交叉”的情况,看似并未构成动边交叉。但是,为了检测出这种情况下的写偏序异常,可以运用事务合并方式构建新的动边,从而检测新动边与原有动边之间是否存在动边交叉,从而判断是否存在数据异常。
图31是本申请实施例提供的一种锯齿波异常的原理图,请参考图31,在图30的基础上针对事务T2和T3进行融合事务合并,根据事务T1、T2、T3所涉及的数据库操作,可知事务T1的读集为DSR(T1)={x0,z0},事务T1的写集为DSW(T1)={x1},事务T2的读集为DSR(T2)={y0,z0},事务T2的写集为DSW(T2)={z1},事务T3的读集为DSR(T3)={x0,y0},事务T3的写集为DSW(T3)={y1},事务T1~T3的一致性状态边如3000所示,接下来由于事务T2和事务T3之间不存在动边交叉,因此满足融合事务合并条件,可以将事务T2和事务T3合并为一个逻辑事务{T2,T3},将事务T2和T3的读集合并,得到逻辑事务{T2,T3}的读集DSR({T2,T3)}={x0,y0,z0},将事务T2和T3的写集合并,得到逻辑事务{T2,T3}的写集DSW({T2,T3)}={y1,z1},另外事务T1的读集和写集不变。合并后的逻辑事务{T2,T3}可以记为“T{2,3}”,逻辑事务T{2,3}所执行的操作可以表示为“R(x0)R(y0)W(y1)W(z1)”,也即是说,逻辑事务T{2,3}读取了变量版本x0和y0并写入了变量版本y1和z1。事务T1与逻辑事务T{2,3}的一致性状态边如3100所示,由于对事务T2和T3进行了融合合并,构造了一条由变量版本x0到z1的新动边(RW斜边),该逻辑事务T{2,3}的新动边与事务T1的动边发生动边交叉,从而能够通过融合事务合并方式检测出这种原本难以检测出的数据异常,这种数据异常被称为“锯齿波异常”。
图32是本申请实施例提供的一种锯齿波异常的原理图,请参考图32,在图30的基础上针对事务T2和T3进行单向事务合并,根据事务T1、T2、T3所涉及的数据库操作,可知事务T1的读集为DSR(T1)={x0,z0},事务T1的写集为DSW(T1)={x1},事务T2的读集为DSR(T2)={y0,z0},事务T2的写集为DSW(T2)={z1},事务T3的读集为DSR(T3)={x0,y0},事务T3的写集为DSW(T3)={y1},事务T1~T3的一致性状态边如3000所示,由于事务T3更新了事务T2读过的变量版本y0,因此满足单向事务合并条件,可以将事务T3的读集合并至事务T2的读集,合并之后事务T2的读集为DSR(T2)={x0,y0,z0},事务T2的写集保持不变,另外事务T1和T3的读集和写集均保持不变。经过单向事务合并之后事务T1~T3的一致性状态边如3200所示,由于将事务T3单向合并至事务T2,因此合并后事务T2构造了一条由变量版本x0到z1的新动边(RW斜边),该合并后事务T2的新动边与事务T1的动边发生动边交叉,从而能够通过单向事务合并方式检测出这种原本难以检测出的数据异常(也即锯齿波异常)。
在事务合并算法的角度进行分析,由于事务T2对事务T1读过的变量版本z0进行了更新,因此将事务T2的读集继续合并至事务T1的读集,此时事务T2的读集中存在变量版本x0,事务T1的写集中存在变量版本x1,根据单向事务合并方式的规则3),事务T1写了一个更新的版本x1,因此存在动边交叉,构成数据异常,能够从事务合并算法的角度检测出这种原本难以检测出的数据异常。
图33是本申请实施例提供的一种锯齿波异常的冲突环示意图,请参考图33,从串行化的角度进行验证,事务T1对事务T3读到的变量版本x0执行更新操作,故构成T3→T1的读写冲突(rw冲突);事务T2对事务T1读到的变量版本z0执行更新操作,故构成T1→T2的读写冲突(rw冲突);事务T3对事务T2读到的变量版本y0执行更新操作,故构成T2→T3的读写冲突(rw冲突)。因此,T1、T2、T3三个事务之间存在冲突环3300,故为冲突不可串行化,因此,从冲突环的角度验证出了锯齿波异常是不可串行化的。
三、幻读异常
幻读异常可以描述为事务T1对满足一定条件的变量先后两次进行批量读取,同时事务T2并发对某个变量执行写操作(包括插入或者更新),导致事务T1两次批量读取到的结果不一致,根据事务T2的写类型进行区分,幻读异常可以分为“由更新造成的幻读异常”和“由插入造成的幻觉异常”。
1)由更新造成的幻读异常:本质为不可重复读异常。
图34是本申请实施例提供的一种幻读异常的原理图,请参考图34,事务T1对满足条件的变量[a0]~[an]进行批量读取,事务T2并发对某变量[ak]进行更新,使得更新后的新值符合了事务T1的谓词范围,也即是说,更新后的变量[ak]的新值满足了事务T1的批量读取条件,当事务T1再次进行批量读取时,[ak]能被事务T1读取到,造成事务T1先后两次谓词读操作所读到的数据不一致。从局部来看,事务T1第一次读取的变量版本[a0]0~[an]0和第二次读取的变量版本[a0]0~[an]0-[ak]0构成一条动边,事务T2更新数据[ak]0构成一条动边(天点[ak]0),事务T1和T2的一致性状态边如3400所示,两条动边在天点上交叉(也即是一条动边和一个天点交叉,动边穿过了天点),从而构成动边交叉,满足单变量的不可重复读异常的定义,因此,可知由更新造成的幻读异常其本质为不可重复读异常。
2)由插入造成的幻觉异常:本质仍为不可重复读异常。
图35是本申请实施例提供的一种幻读异常的原理图,请参考图35,事务T1对满足条件的变量[a0]~[an]进行批量读取,事务T2并发插入了新变量[ak],而新变量[ak]同样满足事务T1的批量读取条件,当事务T1再次进行批量读取时,将会读到事务T2并发写入的新变量[ak],造成事务T1先后两次谓词读操作所读到的数据不一致。从局部来看,事务T1第一次读取的变量版本[a0]0~[an]0和第二次读取的变量版本[a0]0~[an]0-[ak]0构成一条动边,事务T2插入数据[ak]0构成一条动边(天点[ak]0),事务T1和T2的一致性状态边如3500所示,两条动边在天点上交叉(也即是一条动边和一个天点交叉,动边穿过了天点),从而构成动边交叉,满足单变量的不可重复读异常的定义,因此,可知由更新造成的幻读异常其本质仍然为不可重复读异常。也即是说,由插入操作和更新操作造成的幻读异常,在本质上是相同的,均属于不可重复读异常。
四、新数据异常的构造
在传统的数据库系统中,通常仅对单变量以及两个变量造成的数据异常进行检测,以保证数据状态的一致性,然而,随着并发事务的增长,三个以及三个以上的变量仍然会构成新的数据异常,这些数据异常是切实存在的,但却在传统的数据库系统中被忽略掉了,并不会针对性地检测三个以及三个以上的变量构成的数据异常,导致数据库系统存在漏判数据异常的情况。
在本申请实施例中,基于数据状态一致性模型可以构造出新的数据异常,从而能够探索出目前未被发现的一些可能存在的异常情况,在构造新的数据异常时,可以采用一种方式,其一是变量分型,其二是状态分型,其三是事务分型,其四是前三种方式混合在一起的技术,下面将分别针对这四种构造方式进行说明。
1)变量分型
变量分型是指通过将单变量拆分成以动边相连的两个变量,从而可以将“由n(n≥1)个变量构成的异常”扩展为“由n+1个变量构成的异常”,对变量的拆分需要满足一定条件,以将变量a拆分为变量a’和变量a”为例,则变量a’和变量a”满足下述拆分条件时才可以进行变量分型:
(ⅰ)对于变量a的某个变量版本ai(i≥0),能够映射到a’的某个变量版本a’j或者a”的某个变量版本a”k。也即是说,在进行变量拆分之前,存在某动边与变量版本ai相连,则拆分后,仍然需要保证该动边与a’j或者a”k相连。
(ⅱ)若在进行变量拆分前,变量a与其余n-1个变量共同构成“n个变量的异常”,则拆分后,变量a’、变量a”与其余n-1个变量共同构成“n+1个变量的异常”,也即是说,变量a’和变量a”二者中任一项单独与其余n-1个变量不构成数据异常。
上述条件(ⅰ)保证了变量拆分前后与动边之间的连接关系不发生改变,上述条件(ⅱ)保证了变量拆分前后能够实现对数据异常的扩展,因此,当满足条件(ⅰ)和(ⅱ)时,可以通过对变量进行拆分,以构造出新的数据异常。
在一些实施例中,针对变量拆分结果而言,存在四种可能的情况,图36是本申请实施例提供的一种单变量扩展为两变量的拆分结果示意图,请参考图36,示出了由单变量扩展为两变量时四种可能的拆分结果,单变量的数据状态一致性图如3600所示,可以看出,在拆分前,事务T1将变量版本x0更新为x1,同时事务Ta读取旧版本x0,事务Tb读取新版本x1,这里以事务Ta、Tb和T1在变量版本x1上构造了动边为例进行说明,可选地,事务Ta、Tb和T1在变量版本x1上构造的动边并不是必须存在的。接下来,对变量x进行扩展,新增了变量y,按照拆分方式的不同,可以得到3601~3604所示的四种不同的拆分结果。
在拆分结果3601中,新增了事务T2,事务T2读取变量版本x0写入变量版本y1,构成了从变量版本x0到y1的RW斜边;在拆分结果3602中,新增了事务T2和T3,事务T2写入变量版本y1,事务T3读取变量版本x0并写入变量版本y1,构成了从变量版本y1到x0之间的RR斜边;在拆分结果3603中,新增了事务T2,事务T2写入变量版本y1,随后事务T1读取变量版本y1并写入变量版本x1,构成了从变量版本y1到x1之间的RW斜边;在拆分结果3604中,事务T1先后写入变量版本x1和y1,构成了从变量版本x1到y1之间的天边。
图37是本申请实施例提供的一种对单变量拓展为两变量进行单向事务合并的原理图,请参考图37,分别在图36所给出四种拆分结果的基础上进行单向事务合并,由于单向事务合并之后数据异常的存在性是不发生改变的,因此通过观察合并后事务是否存在数据异常,可以论证出在经过变量拆分之后,数据异常依然存在,也即是说,n(n≥1)个变量构成数据异常,在对某一变量进行拆分得到n+1个变量之后,n+1个变量之间仍然构成数据异常。
对于拆分结果3601而言,由于事务T2对事务Ta读到的变量版本y0进行了更新,因此根据单向事务合并规则,需要将事务T2的读集合并至事务Ta的读集,得到合并结果3701;
对于拆分结果3602而言,由于事务T3读到了事务T2所写入的变量版本y1,事务T2对事务Ta读到的变量版本y0进行了更新,因此根据单向事务合并规则,需要将事务T3的读集合并到事务T2的读集,将事务T2的读集合并到事务Ta的读集,得到合并结果3702;
对于拆分结果3603而言,由于事务T1读到了事务T2所写入的变量版本y1,事务T2对事务Ta读到的变量版本y0进行了更新,因此根据单向事务合并规则,需要将事务T1的读集合并到事务T2的读集,将事务T2的读集合并到事务Ta的读集,得到合并结果3703;
对于拆分结果3604而言,由于事务T1对事务Ta读到的变量版本y0进行了更新,因此根据单向事务合并规则,需要将事务T1的读集合并到事务Ta的读集,得到合并结果3704。
可以观察出,在针对拆分结果3601~3604分别进行单向事务合并之后,得到合并结果3701~3704,在每个合并结果中事务Ta的读集中均包含变量版本x0,也即是说,能够在变量版本x0与y0之间构建一条事务Ta的动边(RR斜边),由于可见,对于变量版本x0而言,在变量拆分前的一致性状态,与变量拆分后又经事务合并的一致性状态是保持一致的,也即是说,仍然满足事务Ta读取变量版本x0,事务Tb读取变量版本x1,因此,若拆分前变量版本x0与其余变量共同构成数据异常,那么将x0进行变量拆分之后,数据异常仍然存在。
图38是本申请实施例提供的一种由两变量写异常拓展得到的三变量写异常的原理图,请参考图38,在图24所示的两变量构成的写偏序数据异常的基础上,对两变量构成的写偏序数据异常进行拓展,得到三变量构成的写偏序数据异常。事务T1读取变量版本y0写入变量版本x1,事务T2读取变量版本x0写入变量版本y1,事务T1和T2的一致性状态边如2400所示,在此基础上对变量y0进行拆分扩展,可以得到如3801~3804所示的4种三变量写异常情况,其中,3801即为图30所描述的三变量写偏序异常,这里不做赘述。
下面以3803所示的三变量写异常情况为例,结合串行化原理进行验证,事务T1对事务T2读过的变量版本x0进行更新,因此存在事务T2与事务T1之间的读写冲突(T2→T1);事务T3对事务T1读过的变量版本z0进行更新,因此存在事务T1与事务T3之间的读写冲突(T1→T3);事务T2读取了事务T3所写入的变量版本z1,因此存在事务T3与事务T2之间的写读冲突(T3→T2)。由此看来,事务T1、T2、T3之间存在冲突环,因此属于冲突不可串行化,三变量之后构成写偏序数据异常。
在本申请实施例中,仅以针对两变量异常进行扩展,得到三变量异常为例进行说明,在一些实施例中,还可以继续对三变量异常进行扩展,得到四变量、五变量以及更多变量所构成的数据异常,得到更加复杂的异常情况下的一致性状态图。
正是由于变量拆分可以构造出新的数据异常,那么基于这样的原理可以推理出,传统的两变量读偏序数据异常正是由单变量的不可重复读异常经变量拆分之后扩展而来的。
图39是本申请实施例提供的一种基于不可重复读的变量拆分结果示意图,请参考图39,在3900所示的一致性状态中,假设事务Ta和事务Tb为同一数据,那么变量拆分前的一致性状态3900即代表了不可重复读异常,根据变量拆分规则,将单变量拆分为两变量,可以从单变量的不可重复读异常,扩展为3901~3904所示的四种两变量异常情况,3901~3904的一致性状态分别对应于图25~图28所示的两变量的数据异常情况。
2)状态分型
状态分型是指对某个变量版本xi进行纵向版本拆分,扩展出新的变量版本xi’。从一致性状态图上来看,变量版本xi与变量版本xi’通过垂边相连,变量版本xi’与变量版本x(i+1)通过垂边相连。
图40是本申请实施例提供的一种状态分型方式的原理性示意图,请参考图40,事务T1将变量版本x0更新为x1,事务T2将变量版本x1更新为x2,事务T1~T2之间的一致性状态边如4001所示,通过对变量版本x1进行纵向版本拆分,构成新的变量版本x1’,变量版本x0、x1、x1’以及x2之间依次通过垂边相连,相当于构造了一个新的事务T3,事务T3将变量版本x1更新为x1’,事务T1~T3之间的一致性状态边如4002所示。
图41是本申请实施例提供的一种状态分型方式的原理性示意图,请参考图41,示出了针对两事务的写偏序异常进行状态分型之间所构造的新数据异常,以图24所示的两事务的写偏序异常2400为例,在此基础上将变量版本y0进行垂直变量拆分(也即是状态分型),得到新的变量版本y0’,变量版本y0、y0’以及y1之间依次通过垂边相连,相当于构造了一个新的事务T3,事务T3将变量版本y0更新为y0’,事务T1~T3之间的一致性状态边如4100所示,可以看出在状态分型前后,事务T1和事务T2之间仍然构成动边交叉,因此状态分型不会掩盖掉已有的数据异常。需要说明的是,拆分得到的新事务T3在事务T2开始之前已经完成提交,因此事务T3和事务T2之间不构成针对同一个变量的写写并发冲突。
3)事务分型
事务分型是指对于由同一事务构成的一个或若干动边,可以将其拆分,构成新的事务。需要说明的是,在对动边的拆分过程中,需要保证不破坏原有的动边交叉关系。
以图24所示的两事务写偏序异常为例,在两事务写偏序异常的基础上进行事务分型,可以得到三事务写偏序异常以及四事务写偏序异常。在事务分型之前,如图24所示,事务T1与事务T2的动边(两条RW斜边)构成动边交叉,也即是构成RW-RW关系,基于事务分型规则,可以将事务T1的RW斜边与垂边进行拆分,得到如图25所示的三事务写偏序异常,此时事务T3的RW斜边与事务T2的RR斜边构成RW-RR关系,因此动边交叉仍然存在,在三事务写偏序异常的基础上,继续对图25中的事务T3执行类似事务T1的事务分型操作,可以构成如图28所示的四事务读偏序异常,此时事务T3和事务T4的两条RR斜边构成RR-RR关系,因此动边交叉仍然存在。
在一些实施例中,如果在动边拆分时破坏了原有的动边交叉关系,那么将会得到不合法的事务分型结果。图42是本申请实施例提供的一种不合法的事务分型方式的结果图,请参考图42,在图27所示的三事务读偏序异常的基础上进行事务分型,当对事务T2的RW斜边进行拆分后,得到新事务T4,T4在变量版本x1和y1上构成了RR斜边,但是事务T3与新事务T4之间不构成动边交叉关系,因此如4200所示的一致性状态边属于不合法的事务分型结果,因为在事务分型之后掩盖了原本的数据异常。
4)混合三种分型方式的异常构造规则
在上述1)~3)中,提供了三种异常扩展方式,分别通过对变量、版本以及动边进行拆分,能够在已有一致性状态图的基础上构建出新的事务或者新的动边,以达到扩展出更多数据异常的目标,而将变量分型、状态分型以及事务分型三者相结合,可以通过混合分型的方式构造出更多的数据异常。
图43是本申请实施例提供的一种混合分型方式的原理性示意图,请参考图43,在两事务读偏序异常4301的基础上,先后通过状态分型和变量分型可以构造出新的异常——台阶异常4302。具体地,首先在两事务读偏序异常4301的基础上,对变量版本x0进行状态分型操作,可以产生新的变量版本x0’;随后对变量版本x0、x0’进行变量分型操作,可以扩展出新的变量z(包括z0和z0’两个版本)。在台阶异常4302中,涉及到T1~T3三个事务,事务T1读取变量版本z0和变量版本y1,记为“R(z0)R(y1)”,事务T2写入变量版本x1和y1,记为“W(y1)W(y1)”,事务T3是一个已提交的事务,在事务T3中写入变量版本x0’和z0’,记为“W(x0’)W(z0’)”。结合串行化原理进行验证,事务T3对事务T1读过的变量版本z0进行了更新,故存在T1→T3的读写冲突;事务T2对事务T3所写的变量版本x0’进行了更新,故存在T3→T2的写写冲突;事务T1读取了事务T2所写的变量版本y1,故存在T2→T1的写读冲突。由此看来,T1、T2、T3之间存在冲突环,故为冲突不可串行化,从而通过串行化原理验证出了台阶异常的存在。
在本申请实施例中,基于数据状态的一致性模型,分别将传统的、一致的单变量异常、两变量异常纳入到一致性模型中进行描述和分析,揭示了两变量异常可以由单变量异常扩展得到,进一步地,通过对两变量异常再次进行扩展,可以发现新的更多变量构成的数据异常,并且,还将幻读异常也纳入到一致性模型中进行描述和分析,最终,还给出了数据异常的四种扩展方法(变量分型、状态分型、事务分型、混合分型),能够基于任一种数据异常扩展出新的数据异常,大大提升了数据库系统进行异常检测时的覆盖面,有利于识别出更多新的、未知的数据异常,提升了数据库系统数据存储的正确性。
上述数据状态一致性模型是数据库事务处理技术范围内第一次、全面、系统地提出一个数据模型,通过该一致性模型能够描述各种数据异常的本质(即构成动边交叉),统一了各种数据异常的描述和表达,揭示了数据异常和并发事务之间的关联关系,并且还可以基于该一致性模型构造出更多的新的数据异常。
在上述实施例中,首先介绍了数据库系统的事务处理流程,其次介绍了数据状态一致性模型针对各种数据异常的描述,在本申请实施例中,将对数据状态一致性模型的算法效率进行评估。
在数据库系统中,影响事务异常检测效率的因素通常包括三种:
1)变量个数m:指某一时刻数据库系统中可被读写的变量个数,代表了数据库系统中存储数据的规模。
2)活跃事务个数n:指某一时刻数据库系统中的并发事务数量,代表了数据库系统的并发程度。活跃事务个数n等于“并发事务集合”所包含的元素个数。
3)活跃事务操作数总和s:指某一时刻所有未提交事务所执行操作数量的总和,代表了数据库的负载情况。
传统的数据库事务异常检测算法,可以包括事务可串行化检测算法、异常操作序列匹配算法、冲突环检测算法(也即是冲突可串行化验证算法)以及可串行化快照隔离算法,下面分别进行介绍。
1、事务可串行化检测算法
(ⅰ)节点设备在不对事务进行调度、不改变事务各操作先后顺序的前提下,得到执行结果。
(ⅱ)节点设备对当前待提交的活跃事务执行的先后顺序进行全排列,依次得到事务调度后的执行结果,判断(ⅱ)中调度后的执行结果是否和(ⅰ)中调度前的执行结果一致。
(ⅲ)若存在结果一致的调度,说明存在串行调度事务的序列,此时无数据异常,当前活跃事务可以在节点设备上并发提交;否则,确定有数据异常,节点设备需要对某些事务执行回滚操作。
上述事务可串行化检测算法,可以保证较高的事务并发度,降低事务回滚率,但是算法复杂度较高,在检测过程中需要对所有活跃事务的顺序进行全排列,且只能判断出是否存在数据异常,而在确定出现异常时无法精准确定出应该回滚哪个事务,该算法的时间复杂度为O(sn!)。
2、异常操作序列匹配算法
(ⅰ)节点设备事先将已定义的所有异常,以操作序列的方式枚举在文本里。
(ⅱ)节点设备在事务提交阶段进行异常检测分析时,将当前数据库系统中活跃事务的操作序列,和文本中已定义的异常操作序列一一进行匹配。
(ⅲ)如果某异常操作序列匹配成功,则说明存在某种数据异常,节点设备需要对该异常操作序列涉及到的某些事务执行回滚操作;若所有异常操作序列皆匹配失败,则说明无数据异常,当前活跃事务可以在节点设备上并发提交。
上述异常操作序列匹配算法,需要在文本中人为定义所有已知的数据异常,由于数据异常繁多复杂、难以穷尽,因此这一算法的扩展性和可靠性差,同时,在异常操作序列的匹配过程中,可能会多次涉及回溯,因此对于长事务而言,匹配异常文本的开销会很大,该算法的时间复杂度为O((2mn)s)。
3、冲突环检测算法(冲突可串行化验证)
(ⅰ)节点设备将事务抽象为冲突图上的结点,将事务之间的冲突关系抽象为结点之间的有向边。
(ⅱ)节点设备初始化时冲突图上不存在有向边。
(ⅲ)节点设备遍历当前活跃事务的操作序列,若发现两事务在某变量上存在冲突关系(读写冲突、写读冲突或写写冲突),则在冲突图上添加相应的有向边。
(ⅳ)节点设备检测冲突图上是否存在环,如果存在,则需要对环中的各事务执行回滚操作。
上述冲突环检测算法,其算法复杂度较低,但是由于冲突可串行化是可串行化的充分条件,也即是说冲突可串行化的条件比可串行化更加严苛,因此会降低事务的并发度,导致更多的事务被回滚。其中,构造冲突环的时间复杂度是O(s2),环检测的时间复杂度是O(n2),因此该算法的总时间复杂度是O(s2+n2)。
4、可串行化快照隔离算法
(ⅰ)每个事务存在一个出边和一个入边,本质上是两个bool(布尔)型变量,事务开始时出边和入边均初始化为false。
(ⅱ)当事务T读取变量时,节点设备在当前版本上加SIREAD锁(谓词锁),需要说明的是,写锁和SIREAD锁不相互阻塞,且多个SIREAD锁可并存。节点设备沿版本链从当前版本向更新的版本进行遍历,对于每个版本加写锁的事务Tw:若事务Tw未提交,将事务Tw的入边和事务T的出边置为true;若事务Tw已提交,仅将事务T的出边置为true,若事务Tw的出边为true,则回滚事务T。
(ⅲ)当事务T更新变量时,节点设备在当前版本上加写锁,对于每个在当前版本加SIREAD锁的事务Tr:若事务Tr未提交,将事务Tr的出边和事务T的入边置为true;若事务Tr已提交,且提交时间在事务T的事务开始时刻之前,仅将事务T的入边置为true。
(ⅳ)当事务T提交时,若出入边都为true,则节点设备回滚事务T。
上述可串行化快照隔离算法,是四种传统算法中时间复杂度最低的算法,但是连续读写冲突链是冲突可串行化的充分条件,也即是说快照隔离机制比冲突可串行化还要严苛一些,因此快照隔离算法也是四种传统算法中事务并发度最低的算法,该算法的时间复杂度为O(sn)。
5、本申请实施例所提供的数据状态一致性模型的异常检测算法
(ⅰ)算法中出现的集合(比如读写集合、版本读取集合、待合并事务集等)均基于哈希表实现,插入、查看、删除的复杂度均为O(log(N))。其中最坏的情况是读写集合中包含全部变量,可以认为插入、查看、删除读写集合元素的复杂度为O(log(m));在最坏的情况中,待合并事务集中包含全部事务,可以认为插入、查看、删除待合并事务集元素的复杂度为O(log(n))。
(ⅱ)在构造读写集合时需要遍历全部操作序列,该步骤的复杂度为O(slog(m))。
(ⅲ)算法中不存在嵌套遍历读写集合的操作,最多存在遍历某个读写集过程中,判断当前变量版本是否包含在另外事务的读写集合内,因此遍历读写集的最大复杂度为O(mlog(m))。
(ⅳ)在事务提交前进行异常检测时,最坏的情况需要遍历所有的事务,同时涉及对待合并读写集的写入操作,因此复杂度为O(nlog(n))。
综上所述,本申请实施例所提供的异常检测算法最终的时间复杂度可以确定为O(slog(m)+mnlog(m)log(n))。
从算法时间复杂度角度来看,本申请实施例提出的基于数据状态一致性模型的异常检测算法,相比于传统的事务可串行化检测算法和异常操作序列匹配算法具有更低的时间开销,且与冲突环检测算法的时间复杂度较为接近,但是时间复杂度高于可串行化快照隔离算法。
从事务并发度角度来看,可串行化是数据存在异常的充分条件非充要条件,本申请实施例提出的基于数据状态一致性模型的异常检测算法,从数据一致性这一根本判断方式入手,能够实现对异常的精准检测,避免以更加严苛的条件来进行异常检测,从而相比于可串行化快照隔离算法,能够保证较高的事务并发度。
图44是本申请实施例提供的一种事务处理装置的结构示意图,请参考图44,该装置包括:
检测模块4401,用于响应于目标事务的提交请求,对该目标事务的读写集合进行一致性检测;
获取模块4402,用于响应于对该读写集合的一致性检测通过,基于该读写集合,获取该目标事务的待合并事务集,该待合并事务集用于提供待与该目标事务进行合并的历史事务;
合并提交模块4403,用于对该目标事务以及该待合并事务集中的历史事务进行合并,响应于事务合并后不存在数据异常,提交该目标事务。
本申请实施例提供的装置,通过对目标事务的读写集合进行一致性检测,能够在事务提交阶段精准识别出单事务构成的数据异常,当一致性检测通过时,获取待合并事务集,并对目标事务与历史事务进行合并,在事务合并后不存在数据异常的条件下,提交该目标事务,通过事务合并方式能够检测出多事务共同构成的数据异常,从而能够在事务处理过程中全面的识别出数据库系统内各种各样的数据异常,保证数据状态的一致性,在保证数据一致性的基础上,上述事务处理机制既不依赖于封锁技术也不依赖于依赖图技术,避免了限制数据库系统的并发度,也无需遍历并发事务去识别依赖图中环的存在,从而能够提升数据库系统的事务处理效率。
在一种可能实施方式中,基于图44的装置组成,该检测模块4401包括:
第一检测单元,用于对该目标事务的读集中变量版本进行一致性检测;
第二检测单元,用于响应于对该目标事务的读集中变量版本的一致性检测通过,对该目标事务的写集中变量进行一致性检测;否则,回滚该目标事务;
确定单元,用于响应于对该目标事务的写集中变量的一致性检测通过,为该写集中变量分配版本号,确定对该读写集合的一致性检测通过;否则,回滚该目标事务。
在一种可能实施方式中,该第一检测单元用于:
对于该目标事务的读集中任一变量版本,将该目标事务添加至该变量版本的版本读取集合中,该版本读取集合用于表示当前读取该变量版本的事务集合;
响应于存在任一已提交事务写入版本号大于该变量版本的目标版本,且该目标事务读取的另一变量版本的版本号大于该已提交事务所读取的对应变量版本的版本号,确定对该变量版本一致性检测不通过,回滚该目标事务;否则,确定对该变量版本的一致性检测通过。
在一种可能实施方式中,该第二检测单元用于:
对于该写集中任一变量,获取该变量当前已提交的最大版本号;
响应于该读集中存在该变量的版本号与该最大版本号不相等,确定对该变量一致性检测不通过,回滚该目标事务;否则,确定对该变量的一致性检测通过。
在一种可能实施方式中,该获取模块4402用于:
对于该目标事务的读集中任一变量版本,响应于该变量版本的下一版本位于该目标事务的写集中,将该变量版本的版本读取集合中的事务添加至该待合并事务集;将写入该变量版本的事务添加至该待合并事务集。
在一种可能实施方式中,基于图44的装置组成,该合并提交模块4403包括:
递归合并单元,用于对于该待合并事务集中任一历史事务,响应于该目标事务的读集中的变量均包含在该历史事务的读集中,跳过该历史事务;否则,将该目标事务的读集合并至该历史事务的读集,对读集合并后的历史事务递归执行合并操作,直到遍历该待合并事务集。
在一种可能实施方式中,该递归合并单元用于:
对该目标事务的读集中任一变量版本,响应于该历史事务的读集中不包含与该变量版本对应的任一版本,将该变量版本添加至该历史事务的读集中。
在一种可能实施方式中,基于图44的装置组成,该合并提交模块4403包括:
融合单元,用于对于该待合并事务集中任一历史事务,响应于该目标事务与该历史事务之间不存在动边交叉,将该目标事务与该历史事务在逻辑上进行融合,得到一个逻辑事务。
在一种可能实施方式中,该融合单元用于:
将该目标事务的读集与该历史事务的读集进行合并,得到该逻辑事务的读集;将该目标事务的写集与该历史事务的写集进行合并,得到该逻辑事务的写集。
在一种可能实施方式中,该融合单元还用于:
响应于该目标事务的读集和该历史事务的读集中包括同一变量的不同变量版本,或者该目标事务的写集和该历史事务的写集中包括同一变量的不同变量版本,将该同一变量的不同变量版本合并为所述同一变量的逻辑版本。
在一种可能实施方式中,该融合单元还用于:
响应于该逻辑事务的读集中包括至少两种变量的变量版本,且该逻辑事务的写集中包括该至少两种变量的其他变量版本,将该至少两种变量合并为逻辑变量。
在一种可能实施方式中,基于图44的装置组成,该装置还包括:
初始化模块,用于在开始执行该目标事务时,将该目标事务的读集和写集初始化为空集;
添加模块,用于响应于该目标事务对任一变量进行更新,将该变量添加至该目标事务的写集中,不为该变量分配版本号;
该添加模块,还用于响应于该目标事务读取任一变量,若该变量位于该目标事务的写集中,读取该目标事务针对该变量写入的值;若该变量位于该目标事务的读集中,读取该目标事务的读集中已存储的该变量的值;否则,读取该变量当前已提交的最大版本,将该最大版本添加至该目标事务的读集中。
上述所有可选技术方案,可以采用任意结合形成本公开的可选实施例,在此不再一一赘述。
需要说明的是:上述实施例提供的事务处理装置在处理事务时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将计算机设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的事务处理装置与事务处理方法实施例属于同一构思,其具体实现过程详见事务处理方法实施例,这里不再赘述。
图45是本申请实施例提供的一种计算机设备的结构示意图,该计算机设备4500可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上处理器(CentralProcessing Units,CPU)4501和一个或一个以上的存储器4502,其中,该存储器4502中存储有至少一条程序代码,该至少一条程序代码由该处理器4501加载并执行以实现上述各个实施例提供的事务处理方法。当然,该计算机设备4500还可以具有有线或无线网络接口、键盘以及输入输出接口等部件,以便进行输入输出,该计算机设备4500还可以包括其他用于实现设备功能的部件,在此不做赘述。
在示例性实施例中,还提供了一种计算机可读存储介质,例如包括至少一条程序代码的存储器,上述至少一条程序代码可由终端中的处理器执行以完成上述实施例中事务处理方法。例如,该计算机可读存储介质可以是ROM(Read-Only Memory,只读存储器)、RAM(Random-Access Memory,随机存取存储器)、CD-ROM(Compact Disc Read-Only Memory,只读光盘)、磁带、软盘和光数据存储设备等。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,该程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本申请的可选实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (15)
1.一种事务处理方法,其特征在于,所述方法包括:
响应于目标事务的提交请求,对所述目标事务的读写集合进行一致性检测;
响应于对所述读写集合的一致性检测通过,基于所述读写集合,获取所述目标事务的待合并事务集,所述待合并事务集用于提供待与所述目标事务进行合并的历史事务;
对所述目标事务以及所述待合并事务集中的历史事务进行合并,响应于事务合并后不存在数据异常,提交所述目标事务。
2.根据权利要求1所述的方法,其特征在于,所述对所述目标事务的读写集合进行一致性检测包括:
对所述目标事务的读集中变量版本进行一致性检测;
响应于对所述目标事务的读集中变量版本的一致性检测通过,对所述目标事务的写集中变量进行一致性检测;否则,回滚所述目标事务;
响应于对所述目标事务的写集中变量的一致性检测通过,为所述写集中变量分配版本号,确定对所述读写集合的一致性检测通过;否则,回滚所述目标事务。
3.根据权利要求2所述的方法,其特征在于,所述对所述目标事务的读集中变量版本进行一致性检测包括:
对于所述目标事务的读集中任一变量版本,将所述目标事务添加至所述变量版本的版本读取集合中,所述版本读取集合用于表示当前读取所述变量版本的事务集合;
响应于存在任一已提交事务写入版本号大于所述变量版本的目标版本,且所述目标事务读取的另一变量版本的版本号大于所述已提交事务所读取的对应变量版本的版本号,确定对所述变量版本一致性检测不通过,回滚所述目标事务;否则,确定对所述变量版本的一致性检测通过。
4.根据权利要求2所述的方法,其特征在于,所述对所述目标事务的写集中变量进行一致性检测包括:
对于所述写集中任一变量,获取所述变量当前已提交的最大版本号;
响应于所述读集中存在所述变量的版本号与所述最大版本号不相等,确定对所述变量一致性检测不通过,回滚所述目标事务;否则,确定对所述变量的一致性检测通过。
5.根据权利要求1所述的方法,其特征在于,所述基于所述读写集合,获取所述目标事务的待合并事务集包括:
对于所述目标事务的读集中任一变量版本,响应于所述变量版本的下一版本位于所述目标事务的写集中,将所述变量版本的版本读取集合中的事务添加至所述待合并事务集;将写入所述变量版本的事务添加至所述待合并事务集。
6.根据权利要求1所述的方法,其特征在于,所述对所述目标事务以及所述待合并事务集中的历史事务进行合并包括:
对于所述待合并事务集中任一历史事务,响应于所述目标事务的读集中的变量均包含在所述历史事务的读集中,跳过所述历史事务;否则,将所述目标事务的读集合并至所述历史事务的读集,对读集合并后的历史事务递归执行合并操作,直到遍历所述待合并事务集。
7.根据权利要求6所述的方法,其特征在于,所述将所述目标事务的读集合并至所述历史事务的读集包括:
对所述目标事务的读集中任一变量版本,响应于所述历史事务的读集中不包含与所述变量版本对应的任一版本,将所述变量版本添加至所述历史事务的读集中。
8.根据权利要求1所述的方法,其特征在于,所述对所述目标事务以及所述待合并事务集中的历史事务进行合并包括:
对于所述待合并事务集中任一历史事务,响应于所述目标事务与所述历史事务之间不存在动边交叉,将所述目标事务与所述历史事务在逻辑上进行融合,得到一个逻辑事务。
9.根据权利要求8所述的方法,其特征在于,所述将所述目标事务与所述历史事务在逻辑上进行融合包括:
将所述目标事务的读集与所述历史事务的读集进行合并,得到所述逻辑事务的读集;将所述目标事务的写集与所述历史事务的写集进行合并,得到所述逻辑事务的写集。
10.根据权利要求9所述的方法,其特征在于,所述方法还包括:
响应于所述目标事务的读集和所述历史事务的读集中包括同一变量的不同变量版本,或者所述目标事务的写集和所述历史事务的写集中包括同一变量的不同变量版本,将所述同一变量的不同变量版本合并为所述同一变量的逻辑版本。
11.根据权利要求9所述的方法,其特征在于,所述方法还包括:
响应于所述逻辑事务的读集中包括至少两种变量的变量版本,且所述逻辑事务的写集中包括所述至少两种变量的其他变量版本,将所述至少两种变量合并为逻辑变量。
12.根据权利要求1所述的方法,其特征在于,所述对所述目标事务的读写集合进行一致性检测之前,所述方法还包括:
在开始执行所述目标事务时,将所述目标事务的读集和写集初始化为空集;
响应于所述目标事务对任一变量进行更新,将所述变量添加至所述目标事务的写集中,不为所述变量分配版本号;
响应于所述目标事务读取任一变量,若所述变量位于所述目标事务的写集中,读取所述目标事务针对所述变量写入的值;若所述变量位于所述目标事务的读集中,读取所述目标事务的读集中已存储的所述变量的值;否则,读取所述变量当前已提交的最大版本,将所述最大版本添加至所述目标事务的读集中。
13.一种事务处理装置,其特征在于,所述装置包括:
检测模块,用于响应于目标事务的提交请求,对所述目标事务的读写集合进行一致性检测;
获取模块,用于响应于对所述读写集合的一致性检测通过,基于所述读写集合,获取所述目标事务的待合并事务集,所述待合并事务集用于提供待与所述目标事务进行合并的历史事务;
合并提交模块,用于对所述目标事务以及所述待合并事务集中的历史事务进行合并,响应于事务合并后不存在数据异常,提交所述目标事务。
14.一种计算机设备,其特征在于,所述计算机设备包括一个或多个处理器和一个或多个存储器,所述一个或多个存储器中存储有至少一条程序代码,所述至少一条程序代码由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求12任一项所述的事务处理方法所执行的操作。
15.一种存储介质,其特征在于,所述存储介质中存储有至少一条程序代码,所述至少一条程序代码由处理器加载并执行以实现如权利要求1至权利要求12任一项所述的事务处理方法所执行的操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010214259.1A CN111444027B (zh) | 2020-03-24 | 2020-03-24 | 事务处理方法、装置、计算机设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010214259.1A CN111444027B (zh) | 2020-03-24 | 2020-03-24 | 事务处理方法、装置、计算机设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111444027A true CN111444027A (zh) | 2020-07-24 |
CN111444027B CN111444027B (zh) | 2022-11-18 |
Family
ID=71629531
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010214259.1A Active CN111444027B (zh) | 2020-03-24 | 2020-03-24 | 事务处理方法、装置、计算机设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111444027B (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112035222A (zh) * | 2020-07-30 | 2020-12-04 | 武汉达梦数据库有限公司 | 一种基于日志解析同步的事务操作合并执行方法及装置 |
CN112069196A (zh) * | 2020-11-12 | 2020-12-11 | 腾讯科技(深圳)有限公司 | 基于数据库的数据处理方法、装置、设备及可读存储介质 |
CN114022148A (zh) * | 2021-12-24 | 2022-02-08 | 杭州趣链科技有限公司 | 基于区块链的交易冲突检测方法、装置、设备和存储介质 |
CN115098228A (zh) * | 2021-05-19 | 2022-09-23 | 腾讯科技(深圳)有限公司 | 事务处理方法、装置、计算机设备及存储介质 |
CN115113989A (zh) * | 2021-11-05 | 2022-09-27 | 腾讯科技(深圳)有限公司 | 事务执行方法、装置、计算设备及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102354289A (zh) * | 2011-09-21 | 2012-02-15 | 苏州大学 | 一种并发事务的调度方法和相关装置 |
US9158573B2 (en) * | 2013-12-12 | 2015-10-13 | International Business Machines Corporation | Dynamic predictor for coalescing memory transactions |
CN105389161A (zh) * | 2014-09-09 | 2016-03-09 | 龙芯中科技术有限公司 | 事务内存的冲突检测方法、事务内存系统及微处理器 |
CN105955801A (zh) * | 2015-12-21 | 2016-09-21 | 上海交通大学 | 一种基于rdma和htm的分布式乐观并发控制方法 |
-
2020
- 2020-03-24 CN CN202010214259.1A patent/CN111444027B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102354289A (zh) * | 2011-09-21 | 2012-02-15 | 苏州大学 | 一种并发事务的调度方法和相关装置 |
US9158573B2 (en) * | 2013-12-12 | 2015-10-13 | International Business Machines Corporation | Dynamic predictor for coalescing memory transactions |
CN105389161A (zh) * | 2014-09-09 | 2016-03-09 | 龙芯中科技术有限公司 | 事务内存的冲突检测方法、事务内存系统及微处理器 |
CN105955801A (zh) * | 2015-12-21 | 2016-09-21 | 上海交通大学 | 一种基于rdma和htm的分布式乐观并发控制方法 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112035222A (zh) * | 2020-07-30 | 2020-12-04 | 武汉达梦数据库有限公司 | 一种基于日志解析同步的事务操作合并执行方法及装置 |
CN112035222B (zh) * | 2020-07-30 | 2022-04-19 | 武汉达梦数据库股份有限公司 | 一种基于日志解析同步的事务操作合并执行方法及装置 |
CN112069196A (zh) * | 2020-11-12 | 2020-12-11 | 腾讯科技(深圳)有限公司 | 基于数据库的数据处理方法、装置、设备及可读存储介质 |
CN112069196B (zh) * | 2020-11-12 | 2021-03-23 | 腾讯科技(深圳)有限公司 | 基于数据库的数据处理方法、装置、设备及可读存储介质 |
CN115098228A (zh) * | 2021-05-19 | 2022-09-23 | 腾讯科技(深圳)有限公司 | 事务处理方法、装置、计算机设备及存储介质 |
CN115098228B (zh) * | 2021-05-19 | 2023-04-14 | 腾讯科技(深圳)有限公司 | 事务处理方法、装置、计算机设备及存储介质 |
CN115113989A (zh) * | 2021-11-05 | 2022-09-27 | 腾讯科技(深圳)有限公司 | 事务执行方法、装置、计算设备及存储介质 |
CN115113989B (zh) * | 2021-11-05 | 2023-05-26 | 腾讯科技(深圳)有限公司 | 事务执行方法、装置、计算设备及存储介质 |
CN114022148A (zh) * | 2021-12-24 | 2022-02-08 | 杭州趣链科技有限公司 | 基于区块链的交易冲突检测方法、装置、设备和存储介质 |
CN114022148B (zh) * | 2021-12-24 | 2022-04-22 | 杭州趣链科技有限公司 | 基于区块链的交易冲突检测方法、装置、设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111444027B (zh) | 2022-11-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111338766B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
CN111444027B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
CN111143389B (zh) | 事务执行方法、装置、计算机设备及存储介质 | |
EP4254183A1 (en) | Transaction processing method and apparatus, computer device, and storage medium | |
CN111736964B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
CN111597015B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
CN112231071B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
CN111159252B (zh) | 事务执行方法、装置、计算机设备及存储介质 | |
US20150172412A1 (en) | Managing dependencies between operations in a distributed system | |
Moniz et al. | Blotter: Low latency transactions for geo-replicated storage | |
US10275400B1 (en) | Systems and methods for forming a fault-tolerant federated distributed database | |
Maiyya et al. | Unifying consensus and atomic commitment for effective cloud data management | |
Nawab et al. | Message Futures: Fast Commitment of Transactions in Multi-datacenter Environments. | |
Amiri et al. | Permissioned blockchains: Properties, techniques and applications | |
Krechowicz et al. | Highly scalable distributed architecture for NoSQL datastore supporting strong consistency | |
Bloch et al. | A weighted voting algorithm for replicated directories | |
Mao et al. | Reversible conflict-free replicated data types | |
Downing et al. | Issues in distributed database security. | |
Monteiro et al. | A mechanism for replicated data consistency in mobile computing environments | |
CN115098228B (zh) | 事务处理方法、装置、计算机设备及存储介质 | |
Peluso et al. | On Breaching the Wall of Impossibility Results on Disjoint-Access Parallel STM | |
Koutanov | Strict Serializable Multidatabase Certification with Out-of-Order Updates | |
Barreto | Optimistic replication in weakly connected resource-constrained environments | |
Jolson | A Method for Selective Update Propagation in Replicated Databases | |
Shaposhnikov | Algorithms for efficient transaction management and consistent queries in client-server semantic object-oriented parallel databases |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |