CN110032428A

CN110032428A - 分布式事务的执行方法和装置

Info

Publication number: CN110032428A
Application number: CN201910130756.0A
Authority: CN
Inventors: 张森; 尹博学; 王光树
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-02-21
Filing date: 2019-02-21
Publication date: 2019-07-19
Anticipated expiration: 2039-02-21
Also published as: CN110032428B

Abstract

本说明书实施例提供一种分布式事务的执行方法和装置，方法包括：首先在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；然后在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作，从而能够校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

Description

分布式事务的执行方法和装置

技术领域

本说明书一个或多个实施例涉及计算机领域，尤其涉及分布式事务的执行方法和装置。

背景技术

如果一个事务操作的资源只有一个，那么这个事务就是本地事务；通常见到的单数据库上的事务属于本地事务；如果一个事务操作的资源有多个，并且这些资源分布在网络上的不同节点上，那么这个事务就是分布式事务。

一个事务将数据从状态A修改成另一个的状态B，在事务执行前、执行中、执行后，外界不会看到除A、B以为的其他状态，这种一致性称为强一致性；一个事务将数据从状态A修改成另一个的状态B，在事务执行过程中，外界会看到除A、B以为的其他状态C，但是在事务结束之后，外界只会看到状态A(事务回滚)或者状态B(事务提交)，这种一致性称为最终一致性(也称为弱一致性)。分布式事务通常是最终一致性的事务。在分布式事务的执行过程中，常常会出现脏写导致的数据不一致，例如，数据库访问中，两个事务都同时更新一行数据，一个事务T1对数据的更新把另一个事务T2对数据的更新覆盖了。也就是说，当多个不同的分布式事务，对同一行数据同时进行修改时，会发生脏写，造成业务数据的不一致。

目前通常使用"行锁"来阻止多个分布式事务并发修改同一条业务数据，这可以达到避免脏写的目的；但是“行锁”会阻止分布式事务的并行执行，使分布式事务必须串行执行，这就降低了分布式事务的并发性，影响了分布式事务的性能。

因此，希望能有改进的方案，能够在不影响分布式事务性能的情况下实现校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

发明内容

本说明书一个或多个实施例描述了一种分布式事务的执行方法和装置，能够在不影响分布式事务性能的情况下实现校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

第一方面，提供了一种分布式事务的执行方法，方法包括：

在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；

在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。

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

在所述第一分布式事务执行的第一阶段，将所述目标字段的标识与所述第一业务数据对应记录在回滚日志中。

进一步地，所述执行回滚操作包括：

根据所述回滚日志，将所述业务表中的目标字段的字段值由所述第二业务数据更新为所述第一业务数据。

在一种可能的实施方式中，所述将所述目标字段的标识与所述第二业务数据对应记录在重做日志中，包括：

将更新后的所述业务表的一部分备份在所述重做日志中，所述业务表的一部分包括所述目标字段的标识与所述第二业务数据。

在一种可能的实施方式中，所述第一分布式事务与第二分布式事务并行执行。

进一步地，所述方法还包括：

在所述第二分布式事务执行的第一阶段，将所述业务表中的所述目标字段的字段值由第一业务数据更新为第三业务数据；

在所述第二分布式事务执行的第二阶段，执行提交操作。

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

当判断结果为所述业务表与所述重做日志中所述目标字段的字段值不一致时，转人工处理。

第二方面，提供了一种分布式事务的执行装置，装置包括：

第一处理单元，用于在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；

第二处理单元，用于在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。

第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面的方法。

第四方面，提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面的方法。

通过本说明书实施例提供的方法和装置，首先在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；然后在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。根据该实施例，通过保存业务数据的最新快照为重做日志，在分布式事务回滚时，对比重做日志和数据库中当前最新的业务数据，来校验并发现脏写，从而能够在不影响分布式事务性能的情况下实现校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

附图说明

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

图1为本说明书披露的一个实施例的实施场景示意图；

图2示出根据一个实施例的分布式事务的执行方法流程图；

图3为本说明书实施例提供的分布式事务第一阶段执行过程示意图；

图4为本说明书实施例提供的分布式事务第二阶段执行过程示意图；

图5示出根据一个实施例的分布式事务的执行装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

图1为本说明书披露的一个实施例的实施场景示意图。该实施场景涉及分布式事务的执行，分布式事务通常基于两阶段提交。两个阶段是指：第一阶段：准备阶段(事务管理器通知资源管理器准备分支事务，资源管理器告之事务管理器准备结果)和第二阶段：提交阶段(事务管理器通知资源管理器提交分支事务，资源管理器告之事务管理器结果)。二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

参照图1，第一阶段为请求阶段(也可称为表决阶段)：

事务协调者通知每个参与者准备提交或取消事务，然后进入表决过程，参与者在本地执行事务，写本地的重做日志(redolog)和回滚日志(undolog)，但不提交。请求阶段，参与者将告知协调者自己的表决结果:同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)。

其中，回滚日志(undo log)用于还原业务数据；比如：某业务数据当前值是A，其被修改成B值之后，A值便是其undo log，可以用于回滚本次修改；重做日志(redo log)用于恢复业务数据操作；比如：某业务数据当前值是A，其被修改成B值之后，由于某种原因B修改丢了，此时B值便是redo log，可以重复执行redo log，将业务数据恢复成B，还原业务操作。

第二阶段为提交阶段(也可称为执行阶段):

在该阶段，事务协调者将基于第一阶段的表决结果进行决策:提交或取消。当且仅当所有的参与者同意提交事务，事务协调者才通知所有的参与者提交事务，否则事务协调者将通知所有的参与者取消事务，参与者在接收到协调者发来的消息后将执行相应的操作。

当多个不同的分布式事务，对同一行数据同时进行修改时，会发生脏写，造成业务数据的不一致。

本说明书实施例中，基于现有的两阶段提交，在分布式事务的提交阶段，如果事务协调者将通知所有的参与者取消事务时，此时参与者需要执行回滚操作。为避免脏写导致的业务数据的不一致，通过保存业务数据的最新快照为重做日志(redo log)，在分布式事务回滚时，对比重做日志(redo log)和数据库中当前最新的业务数据，来校验并发现脏写；相比通过“行锁”来阻止多个分布式事务并发修改同一条数据来避免脏写的做法，不会阻塞分布式事务的并行执行，能提供分布式事务的并发性，从而能够在不影响分布式事务性能的情况下实现校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

图2示出根据一个实施例的分布式事务的执行方法流程图。如图2所示，该实施例中分布式事务的执行方法包括以下步骤：步骤21，在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；步骤22，在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。下面描述以上各个步骤的具体执行方式。

首先在步骤21，在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中。可以理解的是，同时可能有多个分布式事务并发执行，第一分布式事务为多个分布式事务中的任意一个分布式事务。

在一个示例中，在所述第一分布式事务执行的第一阶段，还可以将所述目标字段的标识与所述第一业务数据对应记录在回滚日志中。

在一个示例中，将更新后的所述业务表的一部分备份在所述重做日志中，所述业务表的一部分包括所述目标字段的标识与所述第二业务数据。

然后在步骤22，在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。可以理解的是，通过判断所述业务表与所述重做日志中所述目标字段的字段值是否一致，可以来识别是否发生脏写，从而采取有针对性的措施来避免脏写引起的数据不一致。

在一个示例中，所述执行回滚操作包括：根据所述回滚日志，将所述业务表中的目标字段的字段值由所述第二业务数据更新为所述第一业务数据。

在一个示例中，所述第一分布式事务与第二分布式事务并行执行。

进一步地，在第二分布式事务执行的第一阶段，将所述业务表中的所述目标字段的字段值由第一业务数据更新为第三业务数据；在所述第二分布式事务执行的第二阶段，执行提交操作。

在一个示例中，所述方法还包括：

通过本说明书实施例提供的方法，首先在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；然后在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。根据该实施例，通过保存业务数据的最新快照为重做日志，在分布式事务回滚时，对比重做日志和数据库中当前最新的业务数据，来校验并发现脏写，从而能够在不影响分布式事务性能的情况下实现校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

下面结合分布式事务的两阶段提交，对脏写导致的数据不一致进行分析。

当多个不同的分布式事务，对同一行数据同时进行修改时，会发生脏写，造成业务数据的不一致。举例说明：

业务表结构如下：CREATE TABLE`business_table`(`id`long COMMENT'主键ID',`a`int NOT NULL COMMENT'业务字段a'PRIMARYKEY(`id`))；初始化时，业务表business_table数据如下：id a 110，即业务表中的数据如表一所示。

表一：业务表

id	a
		1	10

分布式事务T1：T1修改id＝1的业务数据的a字段值为15；T1业务结构化查询语言(structured query language，SQL)语句如下：SQL1：“update table business_table seta＝15where id＝1”；此时a字段的值被修改为15，修改后业务表business_table数据如下：id a 1 15，即业务表中的数据如表二所示。

表二：业务表

id	a
		1	15

分布式事务T2：在T1的SQL1执行结束之后，T1事务结束之前，T2修改id＝1的业务数据的a字段值为20；T2业务SQL如下：SQL2：“update table business_table set a＝20where id＝1”；此时a字段的值被修改为20，修改后业务表business_table数据如下：ida 1 20，即业务表中的数据如表三所示。

表三：业务表

id	a
		1	20

脏写问题说明：这种情况下，T1和T2重复修改了同一条数据，并且T2把T1修改的数据覆盖掉了，此时便出现数据的脏写；由于分布式事务T1和T2都还处于执行中，其最终状态是提交好是回滚还不确定，有以下可能的结果：a、T1提交，T2提交；T1提交：T1不会去回滚业务数据；T2提交：T2不会去回滚业务数据；这种情况下，业务数据不会出现问题；b、T1提交，T2回滚；T1提交：T1不会去回滚业务数据，T1什么都不做，T1认为业务数据已经由10被改成15；T2回滚：T2会将业务数据回滚到原来的值，即把业务数据还原成10；业务表business_table数据如下：ida 1 10即业务表中的数据如表一所示；这种情况下，T1提交之后将业务数据由10改成15，T2回滚时又把业务数据改成了10；T1的修改被T2回滚了，出现了业务数据的不一致；c、T1回滚，T2提交：与上述b类似，T2提交的数据会被T1回滚，业务数据会出现不一致；d、T1回滚，T2回滚：T1和T2都将业务数据还原成10，虽然是T1和T2脏写，但是业务数据无异常。

当多个分布式事务之间出现脏写时，如上述b、c场景下，一个分布式事务提交的数据会被另外一个分布式事务回滚掉，出现业务数据的不一致；本说明书实施例要解决的问题是，检测分布式事务的脏写，阻止一个分布式事务提交的数据被另外一个分布式事务回滚，保障业务数据的一致性。

根据前述分析，脏写只在分布式事务回滚时，才会出现问题，本说明书实施例中在分布式事务回滚时，通过“redo log”来检测脏写；通过“redolog”来校验业务数据有无修改，如果业务数据发生修改就是出现脏写，不允许回滚；未发生修改则无脏写，允许回滚。

以前述示例的业务表“business_table”为例，初始化时业务表“business_table”数据如表一所示(id＝1的行，a字段值为10)：id a 1 10。

图3为本说明书实施例提供的分布式事务第一阶段执行过程示意图。如图3所示，分布式事务第一阶段，“执行业务SQL”修改数据，“保存redo log”快照数据；例如，执行业务SQL1：“update table business_table set a＝15where id＝1”，将id＝1的行的a字段由10更新成15；在业务SQL1执行之后，将业务表“business_table”中id＝1的行的最新数据当成redo log，保存到业务数据库(database，DB)的“redo log”表中；这个时候，业务表“business_table”中id＝1的行的a字段最新值是15，这个最新值便是“redo log”。

图4为本说明书实施例提供的分布式事务第二阶段执行过程示意图。如图4所示，分布式事务第二阶段回滚时，首先用“redo log”表中的redo log快照数据，与业务表中的当前数据进行对比，如果“redo log”与业务表中数据完全一致，则业务数据未被其他分布式事务修改过，未出现脏写，可以正常回滚业务数据；如果“redo log”与业务表中数据出现不一致，则说明业务数据被其他分布式事务修改过，出现了脏写，不能回滚业务数据，需要转人工处理业务数据回滚。

本说明书实施例提供的方法，基于多个分布式事务修改同一业务数据，会出现脏写，可能导致业务数据的不一致(一个分布式事务提交的数据被另外一个分布式事务回滚了，造成写成功的数据不见了)的问题，在分布式事务第一阶段业务SQL执行之后，将业务表中最新的业务数据保存成“redo log”快照数据；在分布式事务第二阶段回滚时，校验“redolog”快照数据与业务表此时的当前数据是否相同；如果相同则未出现脏写，如果不相同则出现脏写；通过业务SQL执行之后，将最新的业务数据保成一份冗余的“redo log”快照数据，回滚时用此数据与业务表的数据进行对比，来发现是否有脏写，如果有脏写则不还原业务数据，能做到避免脏写导致的业务数据不一致。

根据另一方面的实施例，还提供一种分布式事务的执行装置，该装置用于执行本说明书实施例提供的分布式事务的执行方法。图5示出根据一个实施例的分布式事务的执行装置的示意性框图。如图5所示，该装置500包括：

第一处理单元51，用于在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；

第二处理单元52，用于在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。

可选地，作为一个实施例，所述第一处理单元51，还用于在所述第一分布式事务执行的第一阶段，将所述目标字段的标识与所述第一业务数据对应记录在回滚日志中。

进一步地，所述第二处理单元52用于执行回滚操作包括：

可选地，作为一个实施例，所述第一处理单元51用于将所述目标字段的标识与所述第二业务数据对应记录在重做日志中，包括：

可选地，作为一个实施例，所述第一分布式事务与第二分布式事务并行执行。

进一步地，所述第一处理单元51，还用于在所述第二分布式事务执行的第一阶段，将所述业务表中的所述目标字段的字段值由第一业务数据更新为第三业务数据；

所述第二处理单元52，还用于在所述第二分布式事务执行的第二阶段，执行提交操作。

可选地，作为一个实施例，所述第二处理单元52，还用于当判断结果为所述业务表与所述重做日志中所述目标字段的字段值不一致时，转人工处理。

通过本说明书实施例提供的装置，首先由第一处理单元51在第一分布式事务执行的第一阶段，将业务表中的目标字段的字段值由第一业务数据更新为第二业务数据；以及，将所述目标字段的标识与所述第二业务数据对应记录在重做日志中；然后由第二处理单元52在所述第一分布式事务执行的第二阶段，当确定需要回滚时，判断所述业务表与所述重做日志中所述目标字段的字段值是否一致；当判断结果为所述业务表与所述重做日志中所述目标字段的字段值一致时，执行回滚操作。根据该实施例，通过保存业务数据的最新快照为重做日志，在分布式事务回滚时，对比重做日志和数据库中当前最新的业务数据，来校验并发现脏写，从而能够在不影响分布式事务性能的情况下实现校验是否发生脏写，避免脏写造成的业务数据丢失和不一致。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图2至图4所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图2至图4所描述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims

1.一种分布式事务的执行方法，所述方法包括：

2.如权利要求1所述的方法，其中，所述方法还包括：

3.如权利要求2所述的方法，其中，所述执行回滚操作包括：

4.如权利要求1所述的方法，其中，所述将所述目标字段的标识与所述第二业务数据对应记录在重做日志中，包括：

5.如权利要求1所述的方法，其中，所述第一分布式事务与第二分布式事务并行执行。

6.如权利要求5所述的方法，其中，所述方法还包括：

在所述第二分布式事务执行的第二阶段，执行提交操作。

7.如权利要求1所述的方法，其中，所述方法还包括：

8.一种分布式事务的执行装置，所述装置包括：

9.如权利要求8所述的装置，其中，所述第一处理单元，还用于在所述第一分布式事务执行的第一阶段，将所述目标字段的标识与所述第一业务数据对应记录在回滚日志中。

10.如权利要求9所述的装置，其中，所述第二处理单元用于执行回滚操作包括：

11.如权利要求8所述的装置，其中，所述第一处理单元用于将所述目标字段的标识与所述第二业务数据对应记录在重做日志中，包括：

12.如权利要求8所述的装置，其中，所述第一分布式事务与第二分布式事务并行执行。

13.如权利要求12所述的装置，其中，所述第一处理单元，还用于在所述第二分布式事务执行的第一阶段，将所述业务表中的所述目标字段的字段值由第一业务数据更新为第三业务数据；

所述第二处理单元，还用于在所述第二分布式事务执行的第二阶段，执行提交操作。

14.如权利要求8所述的装置，其中，所述第二处理单元，还用于当判断结果为所述业务表与所述重做日志中所述目标字段的字段值不一致时，转人工处理。

15.一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-7中任一项的所述的方法。

16.一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-7中任一项的所述的方法。