CN114328613B - Sql数据库中分布式事务的处理方法、装置及系统 - Google Patents
Sql数据库中分布式事务的处理方法、装置及系统 Download PDFInfo
- Publication number
- CN114328613B CN114328613B CN202210200793.6A CN202210200793A CN114328613B CN 114328613 B CN114328613 B CN 114328613B CN 202210200793 A CN202210200793 A CN 202210200793A CN 114328613 B CN114328613 B CN 114328613B
- Authority
- CN
- China
- Prior art keywords
- transaction
- distributed
- global
- state
- target
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 71
- 238000012545 processing Methods 0.000 title claims abstract description 45
- 230000002085 persistent effect Effects 0.000 claims abstract description 22
- 230000000977 initiatory effect Effects 0.000 claims abstract description 13
- 238000004590 computer program Methods 0.000 claims description 17
- 230000008569 process Effects 0.000 claims description 15
- 238000004140 cleaning Methods 0.000 claims description 12
- 238000003860 storage Methods 0.000 claims description 10
- 230000000903 blocking effect Effects 0.000 claims description 7
- 230000002688 persistence Effects 0.000 claims description 7
- 238000005457 optimization Methods 0.000 abstract description 3
- 238000010926 purge Methods 0.000 description 23
- 230000004048 modification Effects 0.000 description 17
- 238000012986 modification Methods 0.000 description 17
- 230000007246 mechanism Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 13
- 101100356020 Haemophilus influenzae (strain ATCC 51907 / DSM 11121 / KW20 / Rd) recA gene Proteins 0.000 description 12
- 101100042680 Mus musculus Slc7a1 gene Proteins 0.000 description 12
- 230000006870 function Effects 0.000 description 5
- 230000009471 action Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 206010000210 abortion Diseases 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明实施例提供了SQL数据库中分布式事务的处理方法、装置及系统，SQL数据库包括多个数据库节点，所述方法包括：在至少两个数据库节点发起分布式事务；针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的；响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果。通过本发明实施例，实现了对SQL数据库中分布式一致性查询的优化，能够根据分布式事务的提交顺序来进行可见性判断。
Description
技术领域
本发明涉及数据库技术领域，特别是涉及SQL数据库中分布式事务的处理方法、装置及系统。
背景技术
面对日益增长的海量数据，传统的集中式数据库的弊端日益显现，分布式数据库相比于传统的集中式数据库主要有如下优点：
1、更强的扩展性。分布式数据库可以通过增添存储节点来实现存储容量的线性扩展，而集中式数据库的可扩展性十分有限。
2、更高的并发访问能力。分布式数据库由于采用多台主机组成存储集群，所以相对集中式数据库，它可以提供更高的用户并发访问量。
3、更高的可靠性和更好的可用性。由于数据分布在多个场地并有许多副本数据，在个别场地或个别通信链路发生故障时，不致于导致整个系统的崩溃，而且系统的局部故障不会引起全局失控。
对于SQL数据库，如MySQL数据库，可以通过XA（eXtended Architecture，由X/Open组织提出的分布式交易处理的规范）协议发起XA事务来实现分布式事务，进而可以允许多个MySQL实例共同参与到一个全局事务中，通过XA事务使得MySQL有能力成为分布式数据库。
但在事实上，MySQL仍然是一个单机数据库管理系统，所有基于MySQL的分布式数据库，在产品力上相比于业界上原生的分布式数据库来说，有所欠缺，特别是，现有的MySQL要在内核层面实现高效的分布式一致性查询，几乎是没有手段的。
发明内容
鉴于上述问题，提出了以便提供克服上述问题或者至少部分地解决上述问题的SQL数据库中分布式事务的处理方法、装置及系统，包括：
一种SQL数据库中分布式事务的处理方法，SQL数据库包括多个数据库节点，所述方法包括：
在至少两个数据库节点发起分布式事务；
针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的；
响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果。
可选地，当前构建的一致性视图对应有一第一全局事务提交号，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果，包括：
在目标分布式事务的全局事务提交号小于或等于第一全局事务提交号的情况下，判定数据记录为可见状态；
在目标分布式事务的全局事务提交号大于第一全局事务提交号的情况下，判定数据记录为不可见状态。
可选地，分布式事务的全局事务提交号为单调递增的时序值。
可选地，还包括：
在分布式事务提交过程中，持久化分布式事务的事务状态；
在根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果之前，还包括：
查询扫描的数据记录对应的目标分布式事务的事务状态；
在目标分布式事务的事务状态为提交成功状态时，查询目标分布式事务的全局事务提交号；
在目标分布式事务的事务状态为未提交成功状态时，控制一致性查询进入等待状态，直至目标分布式事务的事务状态更新为提交成功状态时，查询目标分布式事务的全局事务提交号。
可选地，分布式事务为基于两阶段提交协议进行提交，事务状态与分布式事务在两阶段提交协议中所处的阶段相对应。
可选地，数据记录存储有用于指向目标分布式事务对应的事务槽的事务槽地址，还包括：
在分布式事务启动时，在预置的事务表中分配分布式事务对应的事务槽，事务槽用于持久化分布式事务的全局事务提交号和分布式事务的事务状态。
可选地，还包括：
当对目标事务槽进行复用时，判断目标事务槽对应的分布式事务是否已结束，并在目标事务槽对应的分布式事务结束的情况下，允许对目标事务槽进行复用。
可选地，还包括：
在存在至少两个分布式事务修改同一个数据记录时，通过事务锁阻塞除在先进行修改的分布式事务外的其他分布式事务，直至在先进行修改的分布式事务获得全局事务提交号并提交。
可选地，还包括：
在对数据记录的历史版本进行清理时，确定第二全局事务提交号；
在当前历史版本对应的分布式事务的全局事务提交号小于或等于第二全局事务提交号的情况下，对当前历史版本进行清理；
在当前历史版本对应的分布式事务的全局事务提交号大于第二全局事务提交号的情况下，对第二全局事务提交号进行增大。
一种SQL数据库中分布式事务的处理装置，SQL数据库包括多个数据库节点，所述装置包括：
分布式事务发起模块，用于在至少两个数据库节点发起分布式事务；
全局事务提交号持久化模块，用于针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的；
一致性查询模块，用于响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果。
一种SQL数据库中分布式事务的处理系统，SQL数据库包括多个数据库节点，处理系统包括服务组件和处理模块；
服务组件，用于在SQL数据库中分布式事务提交成功时，生成分布式事务的全局事务提交号；
处理模块，用于在SQL数据库中至少两个数据库节点发起分布式事务的情况下，针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号；响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果；其中，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的。
一种电子设备，包括处理器、存储器及存储在存储器上并能够在处理器上运行的计算机程序，计算机程序被处理器执行时实现如上所述的SQL数据库中分布式事务的处理方法。
一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如上所述的SQL数据库中分布式事务的处理方法。
本发明实施例具有以下优点：
在本发明实施例中，通过在至少两个数据库节点发起分布式事务，然后针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，响应于针对所述SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果，实现了对SQL数据库中分布式一致性查询的优化，能够根据分布式事务的提交顺序来进行可见性判断，保证了一致性查询的准确性、高效性。
附图说明
为了更清楚地说明本发明的技术方案，下面将对本发明的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明一实施例提供的一种SQL数据库中分布式事务的处理方法的步骤流程图；
图2是本发明一实施例提供的另一种SQL数据库中分布式事务的处理方法的步骤流程图；
图3是本发明一实施例提供的一种系统结构的示意图；
图4是本发明一实施例提供的一种SQL数据库中分布式事务的处理装置的结构框图；
图5是本发明一实施例提供的一种SQL数据库中分布式事务的处理系统的结构框图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
对于SQL数据库，如MySQL数据库，其可以通过XA协议发起XA事务来实现分布式事务，进而可以允许多个MySQL实例共同参与到一个全局事务中。在MySQL数据库中，通过XA事务实现分布式事务具体如下：
XA START xid（XID是用于唯一标识全局的XA事务）: 开启一个事务，并将事务置于ACTIVE状态，此后执行的SQL语句都将置于该是事务中。
XA END xid: 将事务置于IDLE状态，表示事务内的SQL操作完成。
XA PREPARE xid: 实现事务提交的准备工作，事务状态置于PREPARED状态。事务如果无法完成提交前的准备操作，该语句会执行失败。
XA COMMIT xid: 事务最终提交，完成持久化。
XA ROLLBACK xid: 事务回滚终止。
XA RECOVER: 查看MySQL中存在的PREPARED状态的XA事务。
对于执行分布式事务的数据库，需要进行分布式的一致性查询，一致性查询最核心的问题在于：如何在多个分布式节点之间采用同一个视图，即看到一致性的结果。而从上文可见，在多个MySQL分布式节点之间，同一个全局分布式事务的标识号是XID，会存在以下问题：
1、分布式事务并发执行时，分布式事务因为网络、负载、调度等原因，在多个分布式MySQL节点的执行顺序不同。
例如，有两个分布式事务DT_A、DT_B，分布式事务DT_A在两个分布式节点（Node1，Node2）上执行的本地事务是LT_A1、LT_A2，分布式事务DT_B在两个分布式节点（Node1，Node2）上执行的本地事务是LT_B1，LT_B2，它们的执行顺序可能是：
Node1：LT_A1，LT_B1
Node2：LT_B2，LT_A2
可见，在任何时候看到的数据库全局状态，都不应该是：LT_A1，LT_B1，LT_B2，而由于执行顺序的不同，确实会出现这样的情况，因为此时看到的DT_A事务缺失了在Node2的修改LT_A2，看到了一个不一致的数据库状态。
2、XID只是一个XA事务的唯一标识，在XA事务启动的时候指定，然而事务的可见性仅仅取决于事务的提交顺序，而多个分布式事务在不同的分布式MySQL节点上的提交顺序也不同。
具体而言，事务的可见性由事务的提交顺序决定，而XID是XA事务启动时分配的唯一标识。和提交顺序没有关系（即XID不能表示事务的提交顺序），而MySQL只有XID做不到全局一致性读。
3、XID虽然持久化在Undo表空间中，但在XA事务结束后（提交或回滚），就会被Purge系统（不会再有查询需要看的历史版本没有存在的必要，Purge系统会定期按需清理掉这些历史版本数据）清理掉。
4、对于多个分布式MySQL节点，通过维护XID信息来构建视图是困难的，而这样的视图在多个分布式节点以及Client节点之间共享也是困难的。
具体而言，由于可见性是由事务的提交顺序决定的，XID不能代表事务的提交顺序，只能表示事务的起始标识，如果只有XID，却要用XID来表示事务可见性工程实现比较复杂且性能不好，在分布式场景下会放大问题，几乎处于不可用状态，具体的可见性工程实现如下：
A、需要维护当前的活跃事务的XID链表，有多少个活跃事务，就有多少个元素。XID链表的读取和修改，都需要在全局锁保护下。
B、读事务启动的时候需要拿到当前的活跃事务的XID链表。
C、分布式事务的协调者需用统筹各个分布式节点的活跃XID链表信息。需要知道每个XID代表的分布式事务在各个节点上的执行状态：未启动，执行中，提交，回滚等。
基于此，本发明通过系统化、结构化的改造，让如MySQL这种传统的单机数据库具有更强大、更内聚的分布式能力，相比于MySQL原生的事务系统，主要区别如下：
1、引入Transaction Table（事务表），用于持久化事务状态。在事务启动的时候，会在Transaction Table分配一个Transaction Slot（事务槽），在事务提交的时候，会将事务状态信息回填到Transaction Slot上。
作为一示例，事务状态信息可以包括XID、Trx ID（本地事务的唯一标识，在事务开始的时候分配的全局唯一递增号）、State（事务的状态，如：启动、提交、回滚、清理等）、TCN（Transaction Commit Number，本地事务提交号）、GCN（Global Commit Number，全局事务提交号）等。
2、引入本地事务提交号TCN、全局事务提交号GCN，来表示本地、全局事务的提交顺序。
3、数据记录在格式上除了Trx ID以及Rollptr（回滚段指针，存在于每一个InnoDB数据行上，通过回滚段指针，能够回溯该数据行的最近的一个历史版本）两个系统字段外，还额外引入系统字段：GCN、TCN以及TSA（Transaction Slot Address，事务槽地址），TSA字段上记录了修改本记录的事务所对应的Transaction Slot的地址。
其中，数据记录可以为记录（record）、数据行、行记录等，都可以看做是同一个概念，即表示一行数据在物理上的实际存储内容，当用户插入一行数据，就会在数据库上持久化一条数据记录。
4、丢弃掉Read View上用Trx ID来做可见性判断的机制，而采用TCN、GCN做可见性判断的机制。
对于可见性判断，可以通过如下例子理解：
有两个事务先后发生了：Trx_A以及Trx_B
时间线为：读事务R1-->写事务Trx_A提交-->读事务R2-->写事务Trx_B提交-->读事务R3。
显然：读事务R1不能看到Trx_A和Trx_B的修改，原因在于这个时候Trx_A和Trx_B都还没有提交，R2可以看到Trx_A的修改，但不能看到Trx_B的修改，R3可以看到Trx_A和Trx_B的修改。
所以，一个视图能否看到某个事务的修改：关键在于视图建立时，该事务是否已经提交。
对于用Trx ID来做可见性判断的机制，可以通过如下例子理解：
在T1时刻，有两个活跃事务TrxA，TrxB。它们的Trx ID分别是50，100。同时，事务系统中还维护两个边界：30和110。所有Trx ID < 30的事务都已经提交，而Trx ID > 110的事务都未提交。
在T2时刻，读事务R1启动，构建了它的视图ReadView。该视图实际上代表本时刻数据库的状态。即“Trx ID为50，100的事务处于活跃状态，而Trx ID < 30的事务都已经提交，而Trx ID > 110的事务都未提交”。
当读事务R1扫描到行记录rec_1，发现修改rec_1的事务的Trx ID的是15，则该行记录对于R1是可见的。当读事务发现修改rec_1的事务的Trx ID是120，则该行记录不可见。当读事务发现修改rec_1的事务的Trx ID是75，通过查询R1视图的活跃事务链表信息，发现Trx ID为75的事务不在活跃事务范围内。则判断该行记录可见。当读事务发现修改rec_1的事务的Trx ID是50，通过查询R1视图的活跃事务链表信息，发现Trx ID为50的事务在活跃事务范围内。则判断该行记录不可见。
对于用Trx ID来做可见性判断的机制存在以下问题：
A、写事务和写事务、读事务和读事务，以及读事务和写事务之间都因为一把全局的事务系统大锁，而造成了相互干扰。特别是读写混合场景，写事务较多会导致Active TrxSet比较大，在构造Read View的时候需要持有锁更长的时间，来拷贝Active Trx Set，从而造成了更严重的锁争抢问题。而MySQL MVCC机制设计的初衷是：读操作只读取历史版本，不会与写操作相互阻塞。但是因为这把全局大锁的原因，读写干扰难以避免。
B、由于真实业务场景中，大部分写事务都是小事务，先进入Active Trx Set的一般也会先出来。但是Active Trx Set的数据结构是数组，移走前面的元素，需要把后面的元素全部往前挪，整个过程都需持有全局事务系统大锁，进一步加剧了问题的严重程度。
C复杂的数据结构以及复杂的工程实现，使得MySQL无法充分利用单机的多核能力。而在分布式场景下，分布式一致性查询，需要共享一个全局的Read View。如果ReadView本身的设计就很复杂，那么各个分布式节点之间需要保持一致性就会变得更加复杂和困难。
而对于采用TCN、GCN做可见性判断的机制，可以通过如下例子理解：
在T1时刻，事务系统维护了全局事务提交号200。
在T2时刻，读事务R1启动，构建了它的视图Vision。认为所有事务提交号小于或等于200的事务都已经提交，而大于200的事务仍未提交。
当读事务R1扫描到行记录rec_1，发现修改rec_1的事务的TCN是150。通过和Vision上记录的视图信息（200）比较，发现R1启动时，修改rec_1的事务已经提交，则可判断该行记录可见。当读事务R1扫描到行记录rec_1，发现修改rec_1的事务的TCN是250。通过和Vision上记录的视图信息（200）比较，发现R1启动时，修改rec_1的事务仍未提交，则可判断该行记录不可见。
5、原生支持Native Flashback Query（数据库领域中一种特殊的查询，它可以指定过往的某个时间点，查找该时间点时的数据库数据），用户可以通过SELECT * FROM ASOF [TIMESTAMP | SCN] 任意查询过往的历史版本。
6. 引入Undo（数据库数据的历史版本保存在Undo当中，通过undo，用户可以查询到数据过往的版本，也可以让数据回滚到某个历史版本） Reservation机制。允许MySQL能够从时间和空间两个维度上，控制Purge系统推进的程度，让数据的历史版本得以保留。
以下进行详细说明：
参照图1，示出了本发明一实施例提供的一种SQL数据库中分布式事务的处理的步骤流程图，SQL数据库可以为MySQL数据库，SQL数据库可以包括多个数据库节点，如多个MySQL实例。
具体的，可以包括如下步骤：
步骤101，在至少两个数据库节点发起分布式事务。
在XA事务的基础上，可以在多个数据库中至少两个数据库节点中发起分布式事务，即同一个事务在该至少两个数据库节点中执行。
步骤102，针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的。
如前文所述，事务的可见性取决于事务提交成功的顺序，而XID是XA事务启动时分配的唯一标识，其和提交顺序没有关系，则本发明实施例可以在当前的分布式事务提交成功时，按照当前的分布式事务在所有分布式事务中提交成功的顺序，确定当前的分布式事务的全局事务提交号GCN，并可以将该全局事务提交号进行持久化存储。
具体而言，可以通过以下两种方法在提交成功的时候指定外部的全局事务提交号GCN：
1、SET SESSION innodb_commit_seq = [GCN];
XA COMMIT XID
2、XA COMMIT XID $GCN
在本发明一实施例中，分布式事务的全局事务提交号可以为单调递增的时序值，可以通过服务组件TSO（Timestamp Oracle）方案来保证分布式事务的时序。即存在一个服务组件TSO，TSO 授时服务可以保证按照递增的方式分配时间戳，任何一次申请得到的时间戳都不会重复，在分布式系统中用于给事件定序，最常见和重要的作用即保证事务版本号的单调递增，确保分布式事务的时序，不断产生递增的单调时序值，该值将会作为全局的分布式事务提交GCN持久化到各个MySQL节点中。
步骤103，响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果。
其中，一致性视图可以为数据库的状态（包括数据、数据与数据之间的关系），数据库的状态会随着用户的操作而发生改变，在读事务发生时，需要拿到一个视图，来表示读事务观察到的当时的数据库的状态，一致性视图是通过一个全局事务提交号来表示（即：视图起来的时候，从全局事务提交号中拿当时的事务提交号构成自己）。
由于全局事务提交号可以表征分布式事务提交成功的顺序，且在事务提交成功时进行了持久化，则在进行全局一致性查询时，在扫描到某个数据记录时，可以查询该数据记录对应的目标分布式事务的全局事务提交号，进而可以根据目标分布式事务的全局事务提交号，判断该数据记录是否可见，得到在当前构建的一致性视图下的可见性判断结果。
在本发明一实施例中，当前构建的一致性视图可以对应有一第一全局事务提交号，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果，可以包括：
在目标分布式事务的全局事务提交号小于或等于第一全局事务提交号的情况下，判定数据记录为可见状态；在目标分布式事务的全局事务提交号大于第一全局事务提交号的情况下，判定数据记录为不可见状态。
在具体实现中，可以在MySQL节点上都采用Flashback Query的方式，即：用户可以任意指定GCN，查询所有全局事务提交号小于或等于该GCN的分布式事务带来的修改（需要说明的是，在数据记录存在多个历史版本的情况下，如undo链中存在GCN分别为200、100、80的分布式事务对应的历史版本，则当输入的全局事务提交号为GCN=120，则只会看到GCN为100的分布式事务对应的历史版本，而不是GCN为80的分布式事务对应的历史版本，即在数据记录存在多个历史版本的情况下，查询全局事务提交号小于或等于指定的GCN对应的最近一个历史版本），其提供了两种使用方式：
1、SET SESSION innodb_snapshot_seq = [GCN ]
2、SELECT ... FROM tablename AS OF GCN
其中，方式1可以通过改变innodb_snapshot_seq 这个会话级的变量，来指定分布式一致性查询所需要的GCN，方式2可以通过扩展的SQL（社区MySQL版本没有这样的语法）来指定分布式一致性查询所需要的GCN。
基于此，一致性查询可以对应有一第一全局事务提交号，即指定的GCN，在判断数据记录是否可见时，可以判断数据记录对应的分布式事务的全局事务提交号是否小于或等于第一全局事务提交号的情况下，可以判定该数据记录为可见状态，在目标分布式事务的全局事务提交号大于第一全局事务提交号的情况下，可以判定该数据记录为不可见状态。
在本发明实施例中，通过在至少两个数据库节点发起分布式事务，然后针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果，实现了对SQL数据库中分布式一致性查询的优化，能够根据分布式事务的提交顺序来进行可见性判断，保证了一致性查询的准确性、高效性。
参照图2，示出了本发明一实施例提供的另一种SQL数据库中分布式事务的处理的步骤流程图，具体可以包括如下步骤：
步骤201，在至少两个数据库节点发起分布式事务。
步骤202，针对至少两个数据库节点中每个数据库节点，在分布式事务提交过程中，持久化分布式事务的事务状态，并在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的。
其中，分布式事务可以为基于两阶段提交（2PC，Two-phase Commit）协议进行提交，事务状态可以与分布式事务在两阶段提交协议中所处的阶段相对应，其可以包括未提交成功状态和提交成功状态，未提交成功状态即可以为2PC的第一阶段中的PREPARED状态。需要说明的是，未提交成功的事务状态有多种，如Active状态表示事务处于活跃状态。这样的事务带来的修改，只有本事务才可见。也就是说，自己的修改，自己必须能看见。否则，其它视图对于这样的都是不可见的。另外还有一阶段的状态，也就是说所谓的prepare状态，只有遇到这样的状态，才需要等待这个事务提交掉。
具体的，MySQL在XA事务中采用2PC来保证事务的一致性，具体的，分布式系统中存在两种角色，一种是协调者，一种是参与者。
事务提交的时候有两个阶段：
第一阶段（也被称为Prepare阶段）：
1、协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
2、参与者节点执行完所有的操作后，将修改持久化掉。
3、参与者节点根据具体情况，响应协调者是"同意"还是"中止"。
第二阶段：
1、协调者根据各个节点反馈，决定分布式事务是提交还是回滚。然后将这个决议下发给所有的节点。
2、各个节点根据协调者的指令，对本事务进行提交或回滚操作。完成后向协调者反馈。
3.、协调者收到所有节点的反馈后，最终该事务进入完结状态（提交或回滚）。
在本发明实施例中，一个XA事务在数据库节点上执行的过程如下：
1、XA START $XID: 开启一个事务，并将事务置于ACTIVE状态，同时分配一个Transaction Slot。
2、XA END $XID: 将事务置于IDLE状态，表示事务内的SQL操作完成。
3、XA PREPARE $XID: 2PC的第一个阶段，事务状态置于PREPARED状态，PREPARED状态表示事务已经完成2PC的第一个阶段。
4、XA COMMIT $XID: 2PC的第二个阶段，从TSO获取GCN并持久化，事务最终提交。
从上述过程可知，如果分布式一致性查询发现当前查询的行记录，所对应的事务处于PREPARED状态，该事务虽然处于提交的过程中，但事实上在这个节点上并没有完成提交，无法查询其对应的全局事务提交号（在2PC的第二阶段提交成功才确定GCN），则读视图无法判断出该记录是否可见。
具体而言，如果认为该事务仍处于活跃状态，则判断为不可见，但这个分布式事务可能在别分布式节点上已经提交，并被查询出结果。这样会导致同一个查询在一个节点上能查询到结果，而在另外的节点上查询不到结果。如果认为该事务处于完结状态，而事实上该事务需要在2PC的第二个阶段才能获知本事务的外部提交号GCN。
基于上述分析，可以得出结论：处于PREPARED状态的事务是无法进行可见性判断，需要进行进一步操作，不能直接进行可见性判断，则可以在分布式事务采用2PC进行提交过程中，根据其在两阶段提交协议中所处的阶段确定事务状态，进而可以对事务状态进行持久化。
步骤203，响应于针对SQL数据库的一致性查询，查询扫描的数据记录对应的目标分布式事务的事务状态；
在进行全局的一致性查询时，由于对事务状态进行了持久化，则可以查询扫描的数据记录对应的目标分布式事务的事务状态。
步骤204，在目标分布式事务的事务状态为提交成功状态时，查询目标分布式事务的全局事务提交号；
在目标分布式事务的事务状态为提交成功状态时，即其已完成2PC中的第二阶段，则可以直接查询目标分布式事务的全局事务提交号。
步骤205，在目标分布式事务的事务状态为未提交成功状态时，控制一致性查询进入等待状态，直至目标分布式事务的事务状态更新为提交成功状态时，查询目标分布式事务的全局事务提交号；
在目标分布式事务的事务状态为未提交成功状态时，即处于2PC中的第一阶段，即处于PREPARED状态，则可以应用GP（Global Query） Wait机制，在事务锁的基础上，构建出GP Lock来表示阻塞关系，使得一致性查询进入等待状态，直到该PREPARE状态的事务完成2PC的第二阶段，即分布式事务提交成功，事务状态更新为提交成功状态，则可以查询目标分布式事务的全局事务提交号。
步骤206，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果。
以下结合2PC来说明数据记录的可见性判断：
假设。现在有两个分布式事务DT_A（包括DT_A1、DT_A2）、DT_B（包括DT_B1、DT_B2），它们的提交号分别是50和100。在某个时刻T1，TSO上的GCN生成器已经推高到110，而上面两个分布式事务在两个分布式节点上的状态分别是：
Node1：
DT_A1（已提交，GCN=50），DT_B1（已提交，GCN=100）
Node2：
DT_B2（已提交，GCN=100），DT_A2（PREPARED）。
这个时候一个全局的一致性查询Q1发起，拿到的全局视图R1的第一全局事务提交号GCN=110。
在Node1上，根据以GCN为核心的可见性判断机制。DT_A1与DT_B1的修改都被判断为可见。
而在Node2上，对于DT_B2的修改，R1可以判断为可见（110 > 100）。但是对于DT_A2带来的修改，假设这些修改作用于行记录rec_1上，则：
1、R1是没有办法知道这个修改是由DT_A这个分布式事务带来的，并且这个事务在全局视图下认为已经被提交了。
2、在R1看来，这个事务处于PREPARED状态，即不是活跃状态（可以直接判定为不可见），也不是事务的终态（即提交）。所以这个时候必须要陷入GP Wait状态，等待这个事务最终提交。当DT_A2完成提交过程后，R1才能够知道DT_A2的全局事务提交号GCN（GCN=50）。此时，才能够判断为该事务带来的修改，对于R1来说是可见的。
在本发明一实施例中，数据记录可以存储有用于指向目标分布式事务对应的事务槽的事务槽地址（TSA），还可以包括：
在分布式事务启动时，在预置的事务表中分配分布式事务对应的事务槽，事务槽用于持久化分布式事务的全局事务提交号和分布式事务的事务状态。
在具体实现，可以通过XA START $XID开启一个事务，并将事务置于ACTIVE状态，同时分配一个Transaction Slot，后续的分布式事务的全局事务提交号和分布式事务的事务状态都将存储在该Transaction Slot中。
在一示例中，本地事务提交号（TCN）也可以持久化至该Transaction Slot中，本地事务提交号可以由数据库节点中的TCN生成器在本地事务提交时生成，并持久化。
需要说明的是，分布式事务是由多个本地事务协同完成的，事务槽是属于本地的，如分布式事务需要在两个数据节点上完成，两个数据节点都需要完成各自本地事务，然后都成功提交掉后，这个分布式事务才算提交成功。事务槽是存在每个数据节点上的。
在本发明一实施例中，还可以包括：
当对目标事务槽进行复用时，判断目标事务槽对应的分布式事务是否已结束，并在目标事务槽对应的分布式事务结束的情况下，允许对目标事务槽进行复用。
在具体实现中，可以将分布式事务的包括TCN、GCN等信息持久化到TransactionTable上。由于Transaction Table不能无限膨胀，所以Transaction Table引入了复用机制。然而，如果某个事务的Transaction Slot被复用掉，这个事务的事务状态信息将会丢失掉。
为了让查询（包括全局一致性查询和本地查询）能够尽可能地找到行记录对应事务的真实的事务状态信息，可以将被复用的事务状态信息放到一个深度链表上。这意味着，GCN在这个深度链表也有一个时序。如果GCN在深度链表上是乱序的，则被查询的行记录，会获取到一个错误的事务状态信息，从而导致查询得到错误的结果集。
针对这种情况，本方案通过控制Transaction Slot的复用机制来保证GCN在这个深度链表的有序性。Transaction Slot在事务启动的时候被分配，在事务完结后才允许被复用。Transaction Slot至少要在事务完结之后才允许被复用，所以能够保证GCN在深度链表上的有序性。
在本发明一实施例中，还可以包括：
在存在至少两个分布式事务修改同一个数据记录时，通过事务锁阻塞除在先进行修改的分布式事务外的其他分布式事务，直至在先进行修改的分布式事务获得全局事务提交号并提交。
在具体实现中，MySQL的历史版本数据都会存在Undo表空间中。对于每一条行记录，它的所有历史版本都会按照先后顺序被组织成一个链表。行记录的最新版本在链表的头部，而行记录的最老记录在链表的末尾。从链表头部沿着链表走到链表的尾部，Trx ID、TCN是降序的。如果GCN在这个Undo链上是乱序的，则可能会导致分布式一致性查询查到错误的结果，因为分布式查询在每个MySQL节点上都采用Flashback Query的方式，而该方式需要不断遍历Undo链表，直到找到第一个历史版本数据（最近一个历史版本数据），它的持久化GCN号比Flashback Query指定的GCN号要小。
基于此，本方案通过MySQL事务锁机制，能够保证GCN在Undo链上有正确的先后顺序。假设事务A以及事务B都修改了同一个行记录，如果事务A先进行修改，则事务A能够持有该行记录的行锁，并且该行锁会一直持有直到事务A从TSO上拿到GCN并完结掉该事务。整个过程事务B都会被阻塞，所以事务B最后获取的GCN一定比事务A的大。
在本发明一实施例中，还可以包括：
在对数据记录的历史版本进行清理时，确定第二全局事务提交号；在当前历史版本对应的分布式事务的全局事务提交号小于第二全局事务提交号的情况下，对当前历史版本进行清理；在当前历史版本对应的分布式事务的全局事务提交号大于第二全局事务提交号的情况下，对第二全局事务提交号进行增大。
在具体实现中，为了防止Undo表空间无限制膨胀，MySQL的Purge系统会按照一定的策略清理掉Undo表空间中历史版本数据。Purge系统会从最老的历史版本开始清理，为了保证Purge系统总是清理当前Undo表空间中最老的历史版本，MySQL引入了History List来组织所有历史事务的Undo段。History List上的每一个结点都是一个Undo段。每一个Undo段都存储了一个事务产生的所有历史版本数据。History List上的Undo段是按照事务提交的本地顺序来排序的。
在分布式场景中，由于网络、负载、调度等原因，多个不冲突的分布式事务在各个分布式节点上提交的顺序可能是不同的。具体地说，对于某一个分布式节点，假设有两个分布式事务：Trx_A和Trx_B。在本地提交顺序上，Trx_A先于Trx_B提交，即TCN_A < TCN_B。然而在全局视角上，TSO认为事务B是先提交的，即会先给事务B分配GCN_B，所以GCN_A > GCN_B。也就是说，沿着History List，TCN是递增的，而GCN是乱序的。
如果Flashback Query查询已经被Purge系统清理掉的历史版本，则会返回错误告知用户该历史版本已经被清理掉。对于基于TCN的Flashback Query，由于Purge系统是严格按照TCN递增的顺序清理历史版本，所以基于TCN的Flashback Query总是能够正确判断行记录的历史版本是否已经被Purge系统清理掉。
然而，由于GCN在History List上是乱序的，同样的保证，对于基于GCN的Flashback Query，是无法得到满足的。为了解决该问题，本方案引入了Purged_GCN，即第二全局事务提交号，Purge系统每次沿着History List清理老事务产生的历史版本时，会回溯该事务的GCN信息，如果小于或等于当前Purged_GCN，则被Purge系统清理掉，如果比当前Purged_GCN要大，则推高Purged_GCN（即如果历史版本已经被清理，那么Purged_GCN就会被推高到至少比这个历史版本的全局提交号大），并将该Purged_GCN持久化掉。
这样，所有小于Purged_GCN的事务，都可能已经被Purge系统清理掉。显然，这种策略可能会导致有些事务仍在Undo当中未被实际清理，却被提前定性为Purged状态。但是，这样的方案能够彻底保障正确性。
需要说明的是，历史版本的清理不一定是按照GCN的顺序清理的。例如，可能是按照GCN为5、4、 6的顺序清理，当5的被清理后，Purged_GCN就会被推高到5，当6被清理，就会被推高。
总体而言，本发明实施例可以实现以下：
1、通过引入全局事务提交号GCN，将GCN持久化到Transaction Slot。
2、在Native Flashback Query的基础上，打造了基于GCN的Flashback Query方案。在分布式一致性查询中，所有在分布式节点上的分布式查询都是基于GCN的FlashbackQuery。
3、保证了GCN在核心结构上的正确性以及有效性，具体如下：
A、借助事务锁机制保证Undo链上的GCN的有序性。
B、控制Transaction Slot的复用机制来保证GCN在深度链表的有序性。
C、引入了Purged_GCN机制，解决了GCN在History List上乱序的问题，保证查询不会错误查找到已经被清理的历史版本。
4、引入了GP Lock机制，解决了处于PREPARE状态的事务的可见性问题，保证查询能够拿到正确事务状态信息。
5、生成持久化的全局单调递增号，并用于TSO生成全局事务提交号GCN。
以下结合图3和表1进行示例性说明：
如图3所示，存在两个数据库节点Node1和Node2，每个数据库节点存在Trx ID生成器和TCN生成器，Trx ID生成器在事务开始（Begin）时生成TRX ID，TCN生成器在事务提交时在事务表（Transaction Table）持久化TRX ID、TCN，数据记录的格式（Record Format）可以包括PK（Primary Key，MySQL InnoDB数据表的主键字段，表上的每一个数据行都有唯一的PK）、TCN、TSA、Trx ID、Rollptr、User Cols。
在外部可以设置以TSO组件，其携带有GCN生成器，可以在生成GCN并在事务提交时将GCN持久化至事务表。
如表1所示为一分布式事务的执行过程：
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
参照图4，示出了本发明一实施例提供的一种SQL数据库中分布式事务的处理装置的结构示意图，SQL数据库可以包括多个数据库节点。
具体的，可以包括如下模块：
分布式事务发起模块401，用于在至少两个数据库节点发起分布式事务。
全局事务提交号持久化模块402，用于针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的。
一致性查询模块403，用于响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果。
在本发明一实施例中，当前构建的一致性视图对应有一第一全局事务提交号，一致性查询模块403，可以包括：
可见状态判定子模块，用于在目标分布式事务的全局事务提交号小于或等于第一全局事务提交号的情况下，判定数据记录为可见状态。
不可见状态判定子模块，用于在目标分布式事务的全局事务提交号大于第一全局事务提交号的情况下，判定数据记录为不可见状态。
在本发明一实施例中，分布式事务的全局事务提交号为单调递增的时序值。
在本发明一实施例中，还可以包括：
事务状态持久化模块，用于在分布式事务提交过程中，持久化分布式事务的事务状态。
在本发明一实施例中，还可以包括：
事务状态查询模块，用于查询扫描的数据记录对应的目标分布式事务的事务状态。
第一全局事务提交查询模块，用于在目标分布式事务的事务状态为提交成功状态时，查询目标分布式事务的全局事务提交号。
第二全局事务提交查询模块，用于在目标分布式事务的事务状态为未提交成功状态时，控制一致性查询进入等待状态，直至目标分布式事务的事务状态更新为提交成功状态时，查询目标分布式事务的全局事务提交号。
在本发明一实施例中，分布式事务为基于两阶段提交协议进行提交，事务状态与分布式事务在两阶段提交协议中所处的阶段相对应。
在本发明一实施例中，数据记录存储有用于指向目标分布式事务对应的事务槽的事务槽地址，还可以包括：
分配事务槽模块，用于在分布式事务启动时，在预置的事务表中分配分布式事务对应的事务槽，事务槽用于持久化分布式事务的全局事务提交号和分布式事务的事务状态。
在本发明一实施例中，还可以包括：
事务槽复用模块，用于当对目标事务槽进行复用时，判断目标事务槽对应的分布式事务是否已结束，并在目标事务槽对应的分布式事务结束的情况下，允许对目标事务槽进行复用。
在本发明一实施例中，还可以包括：
事务锁阻塞模块，用于在存在至少两个分布式事务修改同一个数据记录时，通过事务锁阻塞除在先进行修改的分布式事务外的其他分布式事务，直至在先进行修改的分布式事务获得全局事务提交号并提交。
在本发明一实施例中，还可以包括：
第二全局事务提交号确定模块，用于在对数据记录的历史版本进行清理时，确定第二全局事务提交号。
当前历史版本清理模块，用于在当前历史版本对应的分布式事务的全局事务提交号小于第二全局事务提交号的情况下，对当前历史版本进行清理。
第二全局事务提交号增大模块，用于在当前历史版本对应的分布式事务的全局事务提交号大于第二全局事务提交号的情况下，对第二全局事务提交号进行增大。
参照图5，示出了本发明一实施例提供的一种SQL数据库中分布式事务的处理系统的结构示意图，SQL数据库可以包括多个数据库节点，处理系统可以包括服务组件501和处理模块502。
服务组件501，用于在SQL数据库中分布式事务提交成功时，生成分布式事务的全局事务提交号。
处理模块502，用于在SQL数据库中至少两个数据库节点发起分布式事务的情况下，针对至少两个数据库节点中每个数据库节点，在分布式事务提交成功时，确定并持久化分布式事务的全局事务提交号；响应于针对SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果；其中，分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的。
在本发明一实施例中，当前构建的一致性视图对应有一第一全局事务提交号，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定数据记录的可见性判断结果，可以包括：
在目标分布式事务的全局事务提交号小于或等于第一全局事务提交号的情况下，判定数据记录为可见状态。
在目标分布式事务的全局事务提交号大于第一全局事务提交号的情况下，判定数据记录为不可见状态。
在本发明一实施例中，分布式事务的全局事务提交号为单调递增的时序值。
在本发明一实施例中，处理模块502还可以用于：
在分布式事务提交过程中，持久化分布式事务的事务状态。
在本发明一实施例中，处理模块502还可以用于：
查询扫描的数据记录对应的目标分布式事务的事务状态。
在目标分布式事务的事务状态为提交成功状态时，查询目标分布式事务的全局事务提交号。
在目标分布式事务的事务状态为未提交成功状态时，控制一致性查询进入等待状态，直至目标分布式事务的事务状态更新为提交成功状态时，查询目标分布式事务的全局事务提交号。
在本发明一实施例中，分布式事务为基于两阶段提交协议进行提交，事务状态与分布式事务在两阶段提交协议中所处的阶段相对应。
在本发明一实施例中，数据记录存储有用于指向目标分布式事务对应的事务槽的事务槽地址，处理模块502还可以用于：
在分布式事务启动时，在预置的事务表中分配分布式事务对应的事务槽，事务槽用于持久化分布式事务的全局事务提交号和分布式事务的事务状态。
在本发明一实施例中，处理模块502还可以用于：
当对目标事务槽进行复用时，判断目标事务槽对应的分布式事务是否已结束，并在目标事务槽对应的分布式事务结束的情况下，允许对目标事务槽进行复用。
在本发明一实施例中，处理模块502还可以用于：
在存在至少两个分布式事务修改同一个数据记录时，通过事务锁阻塞除在先进行修改的分布式事务外的其他分布式事务，直至在先进行修改的分布式事务获得全局事务提交号并提交。
在本发明一实施例中，处理模块502还可以用于：
在对数据记录的历史版本进行清理时，确定第二全局事务提交号。
在当前历史版本对应的分布式事务的全局事务提交号小于或等于第二全局事务提交号的情况下，对当前历史版本进行清理。
在当前历史版本对应的分布式事务的全局事务提交号大于第二全局事务提交号的情况下，对第二全局事务提交号进行增大。
本发明一实施例还提供了一种电子设备，可以包括处理器、存储器及存储在存储器上并能够在处理器上运行的计算机程序，计算机程序被处理器执行时实现如上SQL数据库中分布式事务的处理方法。
本发明一实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如上SQL数据库中分布式事务的处理方法。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本发明实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对所提供的SQL数据库中分布式事务的处理方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
Claims (13)
1.一种SQL数据库中分布式事务的处理方法，其特征在于，所述SQL数据库包括多个数据库节点，所述方法包括：
在至少两个数据库节点发起分布式事务；
针对所述至少两个数据库节点中每个数据库节点，在所述分布式事务提交成功时，确定并持久化所述分布式事务的全局事务提交号，所述分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的；
响应于针对所述SQL数据库的一致性查询，在当前构建的一致性视图的基础上，查询扫描的数据记录对应的目标分布式事务的事务状态，在所述目标分布式事务的事务状态为未提交成功状态时，控制所述一致性查询进入等待状态，直至所述目标分布式事务的事务状态更新为提交成功状态时，查询所述目标分布式事务的全局事务提交号；
根据所述扫描的数据记录对应的目标分布式事务的全局事务提交号，确定所述数据记录的可见性判断结果；
所述数据记录存储有用于指向所述目标分布式事务对应的事务槽的事务槽地址，所述事务槽用于持久化所述分布式事务的全局事务提交号和所述分布式事务的事务状态。
2.根据权利要求1所述的方法，其特征在于，所述当前构建的一致性视图对应有一第一全局事务提交号，所述根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定所述数据记录的可见性判断结果，包括：
在所述目标分布式事务的全局事务提交号小于或等于所述第一全局事务提交号的情况下，判定所述数据记录为可见状态；
在所述目标分布式事务的全局事务提交号大于所述第一全局事务提交号的情况下，判定所述数据记录为不可见状态。
3.根据权利要求1所述的方法，其特征在于，所述分布式事务的全局事务提交号为单调递增的时序值。
4.根据权利要求1-3任一项所述的方法，其特征在于，还包括：
在所述分布式事务提交过程中，持久化所述分布式事务的事务状态；
在所述根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定所述数据记录的可见性判断结果之前，还包括：在所述目标分布式事务的事务状态为提交成功状态时，查询所述目标分布式事务的全局事务提交号。
5.根据权利要求1所述的方法，其特征在于，所述分布式事务为基于两阶段提交协议进行提交，所述事务状态与所述分布式事务在两阶段提交协议中所处的阶段相对应。
6.根据权利要求1所述的方法，其特征在于，还包括：
在所述分布式事务启动时，在预置的事务表中分配所述分布式事务对应的事务槽。
7.根据权利要求6所述的方法，其特征在于，还包括：
当对目标事务槽进行复用时，判断所述目标事务槽对应的分布式事务是否已结束，并在所述目标事务槽对应的分布式事务结束的情况下，允许对所述目标事务槽进行复用。
8.根据权利要求1所述的方法，其特征在于，还包括：
在存在至少两个分布式事务修改同一个数据记录时，通过事务锁阻塞除在先进行修改的分布式事务外的其他分布式事务，直至所述在先进行修改的分布式事务获得全局事务提交号并提交。
9.根据权利要求1所述的方法，其特征在于，还包括：
在对数据记录的历史版本进行清理时，确定第二全局事务提交号；
在当前历史版本对应的分布式事务的全局事务提交号小于或等于所述第二全局事务提交号的情况下，对所述当前历史版本进行清理；
在当前历史版本对应的分布式事务的全局事务提交号大于所述第二全局事务提交号的情况下，对所述第二全局事务提交号进行增大。
10.一种SQL数据库中分布式事务的处理装置，其特征在于，所述SQL数据库包括多个数据库节点，所述装置包括：
分布式事务发起模块，用于在至少两个数据库节点发起分布式事务；
全局事务提交号持久化模块，用于针对所述至少两个数据库节点中每个数据库节点，在所述分布式事务提交成功时，确定并持久化所述分布式事务的全局事务提交号，所述分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的；
一致性查询模块，用于响应于针对所述SQL数据库的一致性查询，在当前构建的一致性视图的基础上，根据扫描的数据记录对应的目标分布式事务的全局事务提交号，确定所述数据记录的可见性判断结果；
其中，所述装置还包括：
事务状态查询模块，用于查询所述扫描的数据记录对应的目标分布式事务的事务状态；
第二全局事务提交查询模块，用于在所述目标分布式事务的事务状态为未提交成功状态时，控制所述一致性查询进入等待状态，直至所述目标分布式事务的事务状态更新为提交成功状态时，查询目标分布式事务的全局事务提交号；
所述数据记录存储有用于指向所述目标分布式事务对应的事务槽的事务槽地址，所述事务槽用于持久化所述分布式事务的全局事务提交号和所述分布式事务的事务状态。
11.一种SQL数据库中分布式事务的处理系统，其特征在于，所述SQL数据库包括多个数据库节点，所述处理系统包括服务组件和处理模块；
所述服务组件，用于在所述SQL数据库中分布式事务提交成功时，生成所述分布式事务的全局事务提交号；
所述处理模块，用于在所述SQL数据库中至少两个数据库节点发起分布式事务的情况下，针对所述至少两个数据库节点中每个数据库节点，在所述分布式事务提交成功时，确定并持久化所述分布式事务的全局事务提交号；响应于针对所述SQL数据库的一致性查询，在当前构建的一致性视图的基础上，查询扫描的数据记录对应的目标分布式事务的事务状态，在所述目标分布式事务的事务状态为未提交成功状态时，控制所述一致性查询进入等待状态，直至所述目标分布式事务的事务状态更新为提交成功状态时，查询所述目标分布式事务的全局事务提交号；根据所述扫描的数据记录对应的目标分布式事务的全局事务提交号，确定所述数据记录的可见性判断结果；其中，所述分布式事务的全局事务提交号为按照在所有分布式事务中提交成功的顺序确定的；
所述数据记录存储有用于指向所述目标分布式事务对应的事务槽的事务槽地址，所述事务槽用于持久化所述分布式事务的全局事务提交号和所述分布式事务的事务状态。
12.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至9中任一项所述的SQL数据库中分布式事务的处理方法。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如权利要求1至9中任一项所述的SQL数据库中分布式事务的处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210200793.6A CN114328613B (zh) | 2022-03-03 | 2022-03-03 | Sql数据库中分布式事务的处理方法、装置及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210200793.6A CN114328613B (zh) | 2022-03-03 | 2022-03-03 | Sql数据库中分布式事务的处理方法、装置及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114328613A CN114328613A (zh) | 2022-04-12 |
| CN114328613B true CN114328613B (zh) | 2022-07-05 |
Family
ID=81030096
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210200793.6A Active CN114328613B (zh) | 2022-03-03 | 2022-03-03 | Sql数据库中分布式事务的处理方法、装置及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114328613B (zh) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016078423A1 (zh) * | 2014-11-17 | 2016-05-26 | 中兴通讯股份有限公司 | 分布式数据库系统的事务处理方法及装置 |
| CN106445644A (zh) * | 2016-08-30 | 2017-02-22 | 中国民生银行股份有限公司 | 基于改进的一阶段提交的分布式事务的处理方法和装置 |
| CN109933412A (zh) * | 2019-01-28 | 2019-06-25 | 武汉慧联无限科技有限公司 | 基于分布式消息中间件的分布式事务处理方法 |
| CN110716793A (zh) * | 2019-10-10 | 2020-01-21 | 腾讯科技（深圳）有限公司 | 一种分布式事务的执行方法、装置、设备及存储介质 |
| CN111259083A (zh) * | 2020-02-13 | 2020-06-09 | 神州数码融信软件有限公司 | 分布式事务处理方法及装置 |
| WO2021107988A1 (en) * | 2020-05-30 | 2021-06-03 | Xfuturewei Technologies, Inc. | Distributed processing of transactions in a network using timestamps |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170255668A1 (en) * | 2016-03-07 | 2017-09-07 | Change Healthcare Llc | Methods and apparatuses for improving processing efficiency in a distributed system |
| CN110196760B (zh) * | 2018-07-12 | 2023-04-18 | 腾讯科技（深圳）有限公司 | 分布式事务一致性实现方法及装置 |
| CN109739935B (zh) * | 2019-01-09 | 2022-12-30 | 腾讯科技（深圳）有限公司 | 数据读取方法、装置、电子设备以及存储介质 |
| CN109977171B (zh) * | 2019-02-02 | 2023-04-28 | 中国人民大学 | 一种保证事务一致性和线性一致性的分布式系统和方法 |
| CN113495872A (zh) * | 2020-04-08 | 2021-10-12 | 北京万里开源软件有限公司 | 分布式数据库中的事务处理方法及系统 |
| CN113590273A (zh) * | 2021-06-25 | 2021-11-02 | 阿里巴巴新加坡控股有限公司 | 事务处理方法、系统、设备及存储介质 |
-
2022
- 2022-03-03 CN CN202210200793.6A patent/CN114328613B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016078423A1 (zh) * | 2014-11-17 | 2016-05-26 | 中兴通讯股份有限公司 | 分布式数据库系统的事务处理方法及装置 |
| CN106445644A (zh) * | 2016-08-30 | 2017-02-22 | 中国民生银行股份有限公司 | 基于改进的一阶段提交的分布式事务的处理方法和装置 |
| CN109933412A (zh) * | 2019-01-28 | 2019-06-25 | 武汉慧联无限科技有限公司 | 基于分布式消息中间件的分布式事务处理方法 |
| CN110716793A (zh) * | 2019-10-10 | 2020-01-21 | 腾讯科技（深圳）有限公司 | 一种分布式事务的执行方法、装置、设备及存储介质 |
| CN111259083A (zh) * | 2020-02-13 | 2020-06-09 | 神州数码融信软件有限公司 | 分布式事务处理方法及装置 |
| WO2021107988A1 (en) * | 2020-05-30 | 2021-06-03 | Xfuturewei Technologies, Inc. | Distributed processing of transactions in a network using timestamps |
Non-Patent Citations (2)
| Title |
|---|
| A queue-oriented transaction processing paradigm;Thamir M. Qadah;《ACM》;20191209;第26-30页 * |
| 分布式系统设计中NewSQL数据库技术的应用;奚军庆 等;《长江信息通信》;20120531;第64-67页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114328613A (zh) | 2022-04-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Taft et al. | Cockroachdb: The resilient geo-distributed sql database | |
| US11372890B2 (en) | Distributed database transaction protocol | |
| US11681684B2 (en) | Client-driven commit of distributed write transactions in a database environment | |
| EP3185143B1 (en) | Decentralized transaction commit protocol | |
| CN111143389B (zh) | 事务执行方法、装置、计算机设备及存储介质 | |
| US6785696B2 (en) | System and method for replication of distributed databases that span multiple primary nodes | |
| US6662196B2 (en) | Collision avoidance in bidirectional database replication | |
| US8756196B2 (en) | Propagating tables while preserving cyclic foreign key relationships | |
| EP1326184A2 (en) | Conflict resolution for collaborative work system | |
| CN111190935B (zh) | 数据读取方法、装置、计算机设备及存储介质 | |
| EP4276651A1 (en) | Log execution method and apparatus, and computer device and storage medium | |
| CN107533474B (zh) | 一种事务处理方法及装置 | |
| Cetintemel et al. | Support for speculative update propagation and mobility in deno | |
| CN114328613B (zh) | Sql数据库中分布式事务的处理方法、装置及系统 | |
| Alkhatib et al. | Transaction management in distributed database systems: the case of oracle’s two-phase commit | |
| Pankowski | Consistency and availability of Data in replicated NoSQL databases | |
| CN115617571A (zh) | 一种数据备份方法、装置、系统、设备及存储介质 | |
| JP4314126B2 (ja) | 同時実行制御方法及び装置 | |
| US7542983B1 (en) | Delaying automated data page merging in a B+tree until after committing the transaction | |
| CN114691307A (zh) | 事务处理方法及计算机系统 | |
| CN111984665B (zh) | 一种分布式事务处理方法、装置及系统 | |
| CN114328591A (zh) | 事务执行方法、装置、设备和存储介质 | |
| Arora et al. | Dynamic Timestamp Allocation for Reducing Transaction Aborts | |
| Bhargava et al. | Adaptable recovery using dynamic quorum assignments | |
| CN114661719B (zh) | 一种在OpenGauss数据库分区表上在线创建全局索引的方法 |
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 |