CN108596768A - 一种分布式事务处理方法、装置及系统 - Google Patents

一种分布式事务处理方法、装置及系统 Download PDF

Info

Publication number
CN108596768A
CN108596768A CN201810438825.XA CN201810438825A CN108596768A CN 108596768 A CN108596768 A CN 108596768A CN 201810438825 A CN201810438825 A CN 201810438825A CN 108596768 A CN108596768 A CN 108596768A
Authority
CN
China
Prior art keywords
stages
cancel
confirm
transaction
affairs
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.)
Withdrawn
Application number
CN201810438825.XA
Other languages
English (en)
Inventor
薛春雨
尹伟才
范凯杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SHENZHOU DIGITAL RONGXIN SOFTWARE Co Ltd
Original Assignee
SHENZHOU DIGITAL RONGXIN SOFTWARE Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by SHENZHOU DIGITAL RONGXIN SOFTWARE Co Ltd filed Critical SHENZHOU DIGITAL RONGXIN SOFTWARE Co Ltd
Priority to CN201810438825.XA priority Critical patent/CN108596768A/zh
Publication of CN108596768A publication Critical patent/CN108596768A/zh
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明提供了一种分布式事务处理方法，包括Prepare和Confirm/Cancel两个阶段，如果Prepare阶段的所有操作都成功，则进入Confirm阶段，否则进入Cancel阶段；如果Confirm或Cancel阶段的操作发生失败，等异常恢复后执行完相应阶段的操作。本发明还提供了一种内置上述处理方法的分布式事务处理装置及含有该装置的分布式事务处理系统。本发明的方法不用把所有逆向的异常情况组合搞清楚，而只需要关注正向情况即可，当异常恢复后促使其成功，其操作简单，同时可实现分布式事务领域的高隔离性、高保证度，且能降低风险。

Description

一种分布式事务处理方法、装置及系统
技术领域
本发明涉及互联网技术领域，特别是涉及一种分布式事务处理方法、装置及系统。
背景技术
随着分布式技术逐渐被应用到银行的交易系统中，经常会出现一个事务需要跨多个数据库或者跨多个微服务，由于这些数据库或者微服务都是独立运行的，也就是物理上是分开的，这就对事务一致性提出了非常大的挑战。其中，事务是指一个业务逻辑中，对所有相关资源的变更要么全部成功，要么全部失败，这些所有的变更组合在一起就是一个事务。同进同退的特性体现的就是事务一致性。微服务主要强调从业务维度将原来集中的一个系统拆分为多个功能高内聚、低耦合的子系统，其各自拥有自己独立的数据库，并且系统独立部署和运行。在这种情况下，原来的有些业务就有可能跨多个微服务的调用，但又要求保证事务的一致性。
针对分布式事务，目前行业内一个比较典型的处理方式就是冲正模式，其核心思想就是当后面的执行失败后，就调用前面的反交易(冲正交易)，也就相当于把之前执行成功的全部退回去。
举个简单的例子：A给B和C分别转200元和300元的一个业务，按照这种机制其内部实现大致如下：
a)A取500元(200+300)；
b)B存200元；
c)C存300元；
上述的每个步骤都是一次微服务调用，但必须保证全部成功或者全部失败，但如果执行到最后一步c)失败，那该机制就会调用步骤a)的冲正交易，也就是A存500元；再调用b)的冲正交易，也就是B取200元。相当于把之前的操作全部退回去。
谈事务处理机制(方法)的时候，需要从几个维度来看：
(1)隔离性：事务的隔离性主要强调的是多个事务同时运行时，对同一资源的使用必须保证不会发生错乱，否则就会产生错误数据。
(2)保证度：也就是事务一致性的保证程度，其实不存在绝对100％的一致性，尤其是在分布式的情况下，所以不同机制的差别主要就体现在是几个9，好的机制比如99.999％，弱一点比如99％。
(3)风险：处理机制自身是不是存在一定的风险，其风险对系统整体也是一个非常大的风险。
(4)代价：在上述指标保证的前提下，到底要付出多大的代价，例如：性能损失80％，当然这个代价就太大了。
(5)复杂度：指业务系统使用这套机制会带来多大的影响，是不是会变的特别复杂，不能接受。
下面就从上述几个维度对冲正模式进行分析：
(1)隔离性：上面的A、B、C的服务调用都是相互独立的，各自之间没有任何牵制，当出现冲正失败的时候，其相关资源还会被其他业务使用，后续即使人工干预的时候，也会因为资源被使用(例如上述的B的200元已经被取走，余额变为0)，而无论如何都达不成一致。也就是说冲正模式是不能保证隔离性的。
(2)保证度：对保证度而言，如果在调用前面两个步骤的冲正交易时，也执行不成功，那就肯定会造成数据不一致的情况，也就是说这种机制的保证度也比较低。
(3)风险：如果系统都处在比较大的交易量时候，最后一个步骤出现问题，就会有很多的冲正交易被调起，相关系统在自身交易量已经快接近饱和的情况下，又将面临比较集中的冲正交易的调用，系统的压力将会突然大幅度增加，就有可能将一些系统压死。
(4)代价：该机制对性能等方面倒是没有太多的影响。但是如果调用链路比较长，比如要对前面5个步骤进行冲正，当然在执行冲正的过程中也有可能出现失败，5个步骤失败的组合情况将是非常复杂，甚至业务人员都不知道该如何应对，造成对业务比较大的影响。
(5)复杂度：这种模式，必须要求每一个步骤都有一个反交易(冲正交易)，这对业务系统而言也是一个比较大的工作量。
由此可见，上述现有的冲正模式的分布式事务处理机制(方法)，在上述几个重要的维度都存在一定的不足。如何能创设一种操作简单且可实现分布式事务领域的高隔离性、高保证度，且能降低风险的分布式事务处理方法、装置和系统,成为当前业界极需改进的目标。
发明内容
本发明要解决的技术问题是提供一种操作简单且可实现分布式事务领域的高隔离性、高保证度，且能降低风险的分布式事务处理方法、装置和系统。
为解决上述技术问题，本发明采用如下技术方案：
一方面，本发明提供了一种分布式事务处理方法，包括：
(1)Prepare阶段：
主事务调用子服务；
对分支事务中待操作数据进行资源锁定，并记录Prepare日志；
记录数据操作的Submit日志；
(2)Confirm/Cancel阶段：
如果Prepare阶段的所有操作都成功，则进入(a)Confirm阶段，否则进入(b)Cancel阶段，其中：
(a)Confirm阶段包括：
根据Submit日志，真正提交数据；
根据Prepare日志，释放锁定的资源；
(b)Cancel阶段包括：
判断是否有锁定的资源，如有则释放锁定的资源；
如果所述Confirm或Cancel阶段的操作发生失败，等异常恢复后执行完相应阶段的操作。
作为本发明进一步地改进,在Prepare阶段，主事务开启后，持久化主事务信息，分支事务开启后，持久化分支事务信息。
进一步地,如在Prepare阶段发生失败则进入Cancel阶段或直接回滚；如在Confirm阶段发生失败，则对执行失败的业务定时重试直至完成Confirm阶段操作；如在Cancel阶段发生失败，则对执行失败的业务定时重试直至完成Cancel阶段操作，当定时重试多次失败或超出某一时间，等待人工干预。
进一步地，对于主事务服务节点或分支事务服务节点的网络或硬件故障导致的异常，在事务恢复时，直接尝试调用其他节点完成事务。
进一步地,所述Prepare阶段中记录数据操作的Submit日志满足幂等性、Confirm阶段的操作满足幂等性、Cancel阶段的操作满足幂等性。
进一步地,所述Prepare阶段具体包括如下步骤：
S101开启主事务；
S102持久化主事务信息；
S103执行本地逻辑；
S104调用分支事务；
S105开启分支事务；
S106持久化分支事务；
S107对待操作数据进行资源锁定；
S108记录Prepare日志；
S109执行本地逻辑；
S110记录Submit日志；
S111判断调用是否完成，否，则退回至S107，是，则返回成功；
如S106、S107、S109、S110中出现失败或异常则返回失败；
S112判断是否收到调用结果；
S113收到调用结果后判断调用是否成功；
S114调用成功后执行本地逻辑；
S115判断调用是否完成，调用完成后进入Confirm阶段，调用未完成则返回S103；
当S102、S103、S112、S113、S114过程中出现失败或异常或否定结果，则直接进入Cancel阶段。
进一步地,所述Confirm阶段具体包括如下步骤：
S201开始确认主事务；
S202更新主事务状态为Confirm；如更新成功，则跳至S203，如更新失败，则跳至S208；
S203获取分支事务列表；
S204判断是否有未确认事务；如有未确认事务，则跳至S205，如没有未确认事务则跳至S206；
S205获取Submit日志列表；判断是否有未执行的Submit日志，如果有则执行Submit日志，更新Submit日志状态为已执行；如果没有未执行的Submit日志则更新分支事务状态为确认然后跳至S204；
S206获取Prepare日志列表；
S207判断是否有锁定资源，如有，则解锁，如没有则更新主事务状态为confirm_complete；
S208结束。
进一步地,所述Cancel阶段具体包括如下步骤：
S301开始取消主事务；
S302更新主事务状态为Cancel，如成功则跳至S303，如失败则跳至S305；
S303获取Prepare日志列表；
S304判断是否有锁定资源，如有则解锁资源，如无则更新主事务状态为cancel_complete；
S305结束。
另一方面，本发明提供了一种分布式事务处理装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。
再一方面，本发明提供了一种分布式事务处理系统，包括上述的分布式事务处理装置及与其通讯连接的用于处理各分支事务的各微服务器。
通过采用上述技术方案，本发明至少具有以下优点：
(1)隔离性：本发明的方法中，在服务的第一个阶段(Prepare阶段)针对每个分支事务可以锁定相关的资源，具体的锁定内容跟业务有关，但锁定和解锁的过程由机制来触发。由于对参与业务的必要资源进行预留，所以，即使在第二个阶段(Confirm或Cancel阶段)执行失败，其他业务也不会占用该资源，也就是从机制上保证了隔离性。当故障解除后，异常恢复机制就会继续处理之前出现异常的工作，并消费前面预留的资源。
(2)保证度：首先由于有两个阶段的划分，如果在第一阶段出现异常，是不会影响到事务的；对于第二阶段由于在中间过程进行必要的留痕，以及异常恢复机制的保证，即使在运行过程中出现极端的物理异常，只要异常解除，系统都会第一时间将之前该做的事情做完，保证了事务的一致性。在该机制的保证下，除非是非常特殊的情况，否则一般都可以达成一致，使系统可以达到一个非常高的一致性保证度。
(3)风险：整个方法中虽然有主事务管理者、分支事务管理者等逻辑概念，但并不是一个集中点，而是谁发起谁就是主事务管理者，谁参与谁就是分支事务管理者。也就是上述功能是体现在具体的业务调用过程中，是一个去中心化的思路，所以风险很小。
(4)代价：该方法由于中间过程需要进行留痕，相关信息的持久化都是需要时间消耗的，所以该机制对性能是有一定影响的。
(5)复杂度：本方法对业务开发的侵入比较小，只要按照一定的开发规范，在分支事务的相关方法上增加相应的注解就可以启用该机制。所以，整体使用的复杂度还是比较小的。
整体而言，本发明提供的方法，重点考虑了分布式事务领域的隔离性、一致性保证度，降低了机制的风险，但对性能有一定的影响。相对而言现有的机制，在隔离性、一致性保证度、风险方面都相对比较弱。但在事务一致性领域，上述几个维度的关注点又是依次递减的，也就是本发明的机制保证了该领域的一些重点关注点，而现有机制在这些方面都有明显的短板。
附图说明
上述仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，以下结合附图与具体实施方式对本发明作进一步的详细说明。
图1是本发明实施例1中的分布式事务处理方法中的两阶段流程图；
图2是本发明实施例1中的分布式事务处理方法流程图(重点为第一阶段Prepare阶段)；
图3是本发明实施例1中的Confirm阶段流程图；
图4是本发明实施例1中的Cancel阶段流程图；
图5是本发明实施例1中的异常恢复流程图；
图6是本发明实施例2中的分布式事务处理装置结构框图；
图7是本发明实施例3中的分布式事务处理系统结构框图。
具体实施方式
一般在处理事务的时候，传统的思路都是想着出了问题就回退(冲正)，但是在分布式的大背景下，如果参与的资源比较多的话，回退过程中又发生异常，各种异常组合在一起就非常复杂，就这一点真正在分布式系统中使用就存在比较大的风险。而本发明的分布式事务处理方法的整体设计理念，不用把所有逆向的异常情况组合搞清楚(其实也很难搞清楚)，而只需要关注正向情况即可。也就是出现异常情况，我们不回退，而是等异常解除(恢复)后通过机制促使其成功(执行完对应阶段的操作)，当然通过分阶段处理及资源锁定，在异常期间隔离性也是可以保证的。促使成功的理念跟跟行业内的BASE理论不谋而合，都是强调分布式系统的高可用，同时也兼顾了事务的一致性。
实施例1分布式事务处理方法
本实施例提供了一种分布式事务处理方法，其主体方法是采用基于服务的两阶段实现的，具体如下：
一个完整的全局事务由一个主事务和若干个分支事务组成，主事务所在的服务发起并完成整个业务活动。主事务可以与分支事务处于相同服务，也可能为不同服务。
下面以转账为例进行说明：A给B和C分别转200元和300元的一个业务(相当于一个主事务)，其实现大致如下：
a)A取500元(200+300)；
b)B存200元；
c)C存300元；
a)、b)、c)的三个步骤相当于三个分支事务。
整个全局事务分为Prepare和Confirm/Cancel两个阶段进行，其中Confirm和Cancel在运行期间是根据第一阶段的结果二选一：
配合图1、图2所示，本实施例的分布式事务处理方法，包括：
(1)Prepare阶段：
主事务调用子服务；
对分支事务中待操作数据进行资源锁定，并记录Prepare日志；
记录数据操作的Submit日志；
(2)Confirm/Cancel阶段：
如果Prepare阶段的所有操作都成功，则进入(a)Confirm阶段，否则进入(b)Cancel阶段，其中：
配合图3所示，(a)Confirm阶段包括：
根据Submit日志，真正提交数据(执行Submit日志)；
根据Prepare日志，释放锁定的资源(解锁资源)；
配合图4所示，(b)Cancel阶段包括：
判断是否有锁定的资源，如有则释放锁定的资源(解锁资源)；
配合图5所示，如在Prepare阶段发生失败则进入Cancel阶段或直接回滚；如果所述Confirm或Cancel阶段的操作发生失败，等异常恢复后执行完相应阶段的操作；Prepare阶段的操作不成功则执行Cancel阶段的操作。
在上述处理方法中，由于在服务的第一个阶段(Prepare阶段)针对每个分支事务可以锁定相关的资源，具体的锁定内容跟业务有关，但锁定和解锁的过程由机制来触发。由于对参与业务的必要资源进行预留，所以，即使在第二个阶段执行失败，其他业务也不会占用该资源，也就是从机制上保证了隔离性。当故障解除后，异常恢复机制就会继续处理之前出现异常的工作，并消费前面预留的资源，因此有效地保证了隔离性。
另外，由于有两个阶段的划分，如果在第一阶段出现异常，是不会影响到事务的；对于第二阶段由于异常恢复机制的保证，即使在运行过程中出现极端的物理异常，只要异常解除，系统都会第一时间将之前该做的事情做完，保证了事务的一致性。在该机制的保证下，除非是非常特殊的情况，否则一般都可以达成一致，使系统可以达到一个非常高的一致性保证度。
下面分别结合各附图进行详细展开描述。
配合图2所示，Prepare阶段处理流程为：
S101开启主事务；
S102持久化主事务信息；
S103执行本地逻辑,此处的本地逻辑主要是指主事务发起方内部执行的业务逻辑，根据具体的业务有关；
S104调用子服务；
S105开启分支事务；
S106持久化分支事务；
S107对待操作数据进行资源锁定；
S108记录Prepare日志；
S109执行本地逻辑，此处的本地逻辑是指子服务内部的业务逻辑，一般涵盖相关的检查、校验以及一部分计算等逻辑；
S110记录Submit日志；
S111判断调用是否完成，否，则退回至S107，是，则返回成功；
如S106、S107、S109、S110中出现失败或异常则返回失败；
S112判断是否收到调用结果；
S113收到调用结果后判断调用是否成功；
S114调用成功后执行本地逻辑，此处的本地逻辑主要是指主事务发起方内部执行的业务逻辑，根据具体的业务有关；
S115判断调用是否完成，调用完成后进入Confirm阶段，调用未完成则返回S103；
当S102、S103、S112、S113、S114过程中出现失败或异常或否定结果，则直接进入Cancel阶段。
即，首先可由主事务开启全局事务，进入Prepare阶段(第一阶段)：大体为主事务依次执行业务逻辑，分别调用所有子服务，开启相应的分支事务，完成其中所有分支事务的检查与计算，并对待操作数据进行加锁。当遇到数据库更新操作，则将当前操作记录为Submit日志，并不提交。若要对多个库进行操作时，应该记录多条Submit日志。在当所有业务逻辑都执行成功或者某个操作失败，进入Confirm、Cancel阶段。所有业务异常应在此阶段抛出。
配合图3所示，对于Confirm阶段的处理流程为：
S201开始确认主事务；
S202更新主事务状态为Confirm；如更新成功，则跳至S203，如更新失败，则跳至S208；
S203获取分支事务列表；
S204判断是否有未确认事务；如有未确认事务，则跳至S205，如没有未确认事务则跳至S206；
S205获取Submit日志列表；判断是否有未执行的Submit日志，如果有则执行Submit日志，更新Submit日志状态为已执行；如果没有未执行的Submit日志则更新分支事务状态为确认然后跳至S204；
S206获取Prepare日志列表；
S207判断是否有锁定资源，如有，则解锁，如没有则更新主事务状态为Confirm-complete；
S208结束。
即，在Confirm阶段，可以根据Prepare阶段提交的Submit日志，依次执行，提交数据库。在此阶段，不做任何检查及计算，在此阶段，只可能由于网络或硬件故障造成异常。若未发生异常，则事务执行成功，然后根据Prepare日志，释放锁定的资源后，事务完成。若在执行过程中发生异常，启动异常恢复机制。此时数据处于不一致情况，对于需要保证强一致性的数据，由Prepare阶段加锁来保证隔离性，使其他事务不能访问这些数据。
配合图4所示，对于Cancel阶段的处理流程为：
S301开始取消主事务；
S302更新主事务状态为Cancel，如成功则跳至S303，如失败则跳至S305；
S303获取Prepare日志列表；
S304判断是否有锁定资源，如有则解锁资源，如无则更新主事务状态为cancel_complete；
S305结束。
即，在Cancel阶段，最主要的工作在于判断是否有锁定资源，如有则释放锁定的资源。
配合图5所示，对于上述执行过程中出现的异常状况，其处理流程为：
S401开始；
S402获取超时未完成的事务；
S403查看主事务状态，如主事务状态为Confirm，则执行Confirm逻辑，如主事务状态为Prepare或Cancel，则执行Cancel逻辑；
S404结束。
对上述执行过程中出现的异常情况，可通过异常恢复机制进行处理。对于不同阶段的事务，处理策略如下：
1)Prepare阶段：由于Prepare阶段，并没有对数据库进行实际的操作，可以直接回滚或直接进入Cancel阶段。
2)Cancel阶段：处于Cancel阶段的事务，只可能由于网络或硬件故障造成异常。定时重试执行Cancel操作，直到网络或硬件恢复，执行成功为止。
3)Confirm阶段：处于Confirm阶段的事务，只可能由于网络或硬件故障造成异常。对执行失败的业务进行定时重试。由于Submit日志，只记录数据库操作，定时重试对于服务器压力较小。
4)对于某个服务节点(包括主服务以及次服务节点)的网络或硬件故障导致的异常，在事务恢复时，可以直接尝试调用其他节点完成事务，不必等待。
5)定时重试多次失败或超出某一时间，等待人工干预。
当出现异常时会对事务造成一定影响，但如何保证在异常解除后促使其成功，这块也是本发明中的的另一个关键点。简单而言，可通过如上所述的对事务处理过程中留痕(持久化)、异常恢复等保证机制，进一步地，可通过幂等性保证机制。其中幂等性保证机制，主要体现在以下几个方面，如在所述Prepare阶段中记录数据操作的Submit日志(submit日志记录的内容要到方法级别，例如：某个服务的某个方法，以及方法的输入参数，满足幂等性)、Confirm阶段的操作满足幂等性、Cancel阶段的操作满足幂等性。
整体而言，本发明提供的方法，重点考虑了分布式事务领域的隔离性、一致性保证度，降低了机制的风险，但对性能有一定的影响。相对而言现有的机制，在隔离性、一致性保证度、风险方面都相对比较弱。但在事务一致性领域，上述几个维度的关注点又是依次递减的，也就是本发明的方法保证了该领域的一些重点关注点，而现有机制在这些方面都有明显的短板。
实施例2分布式事务处理装置
如图6所示，本实施例提供了一种分布式事务处理装置500，包括存储器501、处理器502及存储在所述存储器501上并可在所述处理器502上运行的计算机程序，所述处理器502执行所述计算机程序时实现上述实施例1中的分布式事务处理方法的步骤。
实施例3分布式事务处理系统
如图7所示，本实施例提供了一种分布式事务处理系统，包括实施例2的分布式事务处理装置500及与其通讯连接的用于处理各分支事务的各微服务器600。
以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，本领域技术人员利用上述揭示的技术内容做出些许简单修改、等同变化或修饰，均落在本发明的保护范围内。

Claims (10)

1.一种分布式事务处理方法，其特征在于,包括：
(1)Prepare阶段：
主事务调用子服务；
对分支事务中待操作数据进行资源锁定，并记录Prepare日志；
记录数据操作的Submit日志；
(2)Confirm/Cancel阶段：
如果Prepare阶段的所有操作都成功，则进入(a)Confirm阶段，否则进入(b)Cancel阶段，其中：
(a)Confirm阶段包括：
根据Submit日志，真正提交数据；
根据Prepare日志，释放锁定的资源；
(b)Cancel阶段包括：
判断是否有锁定的资源，如有则释放锁定的资源；
如果所述Confirm或Cancel阶段的操作发生失败，等异常恢复后执行完相应阶段的操作。
2.根据权利要求1所述的分布式事务处理方法，其特征在于,在Prepare阶段，主事务开启后，持久化主事务信息，分支事务开启后，持久化分支事务信息。
3.根据权利要求1所述的分布式事务处理方法，其特征在于,如在Prepare阶段发生失败则进入Cancel阶段或直接回滚；
如在Confirm阶段发生失败，则对执行失败的业务定时重试直至完成Confirm阶段操作；
如在Cancel阶段发生失败，则对执行失败的业务定时重试直至完成Cancel阶段操作；
当定时重试多次失败或超出某一时间，等待人工干预。
4.根据权利要求1所述的分布式事务处理方法，其特征在于，对于主事务服务节点或分支事务服务节点的网络或硬件故障导致的异常，在事务恢复时，直接尝试调用其他节点完成事务。
5.根据权利要求1-4任一项所述的分布式事务处理方法，其特征在于,所述Prepare阶段中记录数据操作的Submit日志满足幂等性、Confirm阶段的操作满足幂等性、Cancel阶段的操作满足幂等性。
6.根据权利要求1所述的分布式事务处理方法，其特征在于,所述Prepare阶段具体包括如下步骤：
S101开启主事务；
S102持久化主事务信息；
S103执行本地逻辑；
S104调用分支事务；
S105开启分支事务；
S106持久化分支事务；
S107对待操作数据进行资源锁定；
S108记录Prepare日志；
S109执行本地逻辑；
S110记录Submit日志；
S111判断调用是否完成，否，则退回至S107，是，则返回成功；
如S106、S107、S109、S110中出现失败或异常则返回失败；
S112判断是否收到调用结果；
S113收到调用结果后判断调用是否成功；
S114调用成功后执行本地逻辑；
S115判断调用是否完成，调用完成后进入Confirm阶段，调用未完成则返回S103；
当S102、S103、S112、S113、S114过程中出现失败或异常或否定结果，则直接进入Cancel阶段。
7.根据权利要求1所述的分布式事务处理方法，其特征在于,所述Confirm阶段具体包括如下步骤：
S201开始确认主事务；
S202更新主事务状态为Confirm；如更新成功，则跳至S203，如更新失败，则跳至S208；
S203获取分支事务列表；
S204判断是否有未确认事务；如有未确认事务，则跳至S205，如没有未确认事务则跳至S206；
S205获取Submit日志列表；判断是否有未执行的Submit日志，如果有则执行Submit日志，更新Submit日志状态为已执行；如果没有未执行的Submit日志则更新分支事务状态为确认然后跳至S204；
S206获取Prepare日志列表；
S207判断是否有锁定资源，如有，则解锁，如没有则更新主事务状态为confirm_complete；
S208结束。
8.根据权利要求1所述的分布式事务处理方法，其特征在于,所述Cancel阶段具体包括如下步骤：
S301开始取消主事务；
S302更新主事务状态为Cancel，如成功则跳至S303，如失败则跳至S305；
S303获取Prepare日志列表；
S304判断是否有锁定资源，如有则解锁资源，如无则更新主事务状态为cancel_complete；
S305结束。
9.一种分布式事务处理装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1至8任一项所述的方法的步骤。
10.一种分布式事务处理系统，包括权利要求9所述的分布式事务处理装置及与其通讯连接的用于处理各分支事务的各微服务器。
CN201810438825.XA 2018-05-09 2018-05-09 一种分布式事务处理方法、装置及系统 Withdrawn CN108596768A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810438825.XA CN108596768A (zh) 2018-05-09 2018-05-09 一种分布式事务处理方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810438825.XA CN108596768A (zh) 2018-05-09 2018-05-09 一种分布式事务处理方法、装置及系统

Publications (1)

Publication Number Publication Date
CN108596768A true CN108596768A (zh) 2018-09-28

Family

ID=63636062

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810438825.XA Withdrawn CN108596768A (zh) 2018-05-09 2018-05-09 一种分布式事务处理方法、装置及系统

Country Status (1)

Country Link
CN (1) CN108596768A (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110599330A (zh) * 2019-09-12 2019-12-20 中国工商银行股份有限公司 银行通用的反交易装置、方法及系统
CN110597923A (zh) * 2019-09-29 2019-12-20 腾讯云计算（北京）有限责任公司 区块链资源管理方法、装置及存储介质
CN110992188A (zh) * 2020-03-03 2020-04-10 支付宝(杭州)信息技术有限公司 交易处理方法、装置及设备
CN111415146A (zh) * 2020-06-08 2020-07-14 浙江口碑网络技术有限公司 资源数据的处理方法、装置及设备
CN111414266A (zh) * 2020-03-23 2020-07-14 山东浪潮通软信息科技有限公司 一种分布式事务的同步异步通信方法和装置
CN111626858A (zh) * 2020-05-28 2020-09-04 北京金山云网络技术有限公司 冲正交易的处理方法、装置、电子设备和计算机可读介质
CN112035269A (zh) * 2020-09-10 2020-12-04 蔡国凤 一种分布式系统多节点锁定方法
CN112395104A (zh) * 2020-11-16 2021-02-23 中国工商银行股份有限公司 一种分布式事务上下文在路由层传递的实现方法与装置
CN112598520A (zh) * 2020-12-28 2021-04-02 中国农业银行股份有限公司 交易管理的方法、装置、电子设备以及存储介质
CN114764405A (zh) * 2020-12-31 2022-07-19 正链科技(深圳)有限公司 一种分布式应用程序的事务数据一致性存储方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102073540A (zh) * 2010-12-15 2011-05-25 北京新媒传信科技有限公司 分布式事务提交方法和装置
US20120166407A1 (en) * 2010-12-28 2012-06-28 Juchang Lee Distributed Transaction Management Using Two-Phase Commit Optimization
CN105988862A (zh) * 2015-02-04 2016-10-05 阿里巴巴集团控股有限公司 分布式事务处理方法及装置
CN106502769A (zh) * 2016-09-30 2017-03-15 华为技术有限公司 分布式事务处理方法、装置及系统
CN107622119A (zh) * 2017-09-21 2018-01-23 深圳智盾信息技术有限公司 一种分布式跨数据库保持事务一致性的方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102073540A (zh) * 2010-12-15 2011-05-25 北京新媒传信科技有限公司 分布式事务提交方法和装置
US20120166407A1 (en) * 2010-12-28 2012-06-28 Juchang Lee Distributed Transaction Management Using Two-Phase Commit Optimization
CN105988862A (zh) * 2015-02-04 2016-10-05 阿里巴巴集团控股有限公司 分布式事务处理方法及装置
CN106502769A (zh) * 2016-09-30 2017-03-15 华为技术有限公司 分布式事务处理方法、装置及系统
CN107622119A (zh) * 2017-09-21 2018-01-23 深圳智盾信息技术有限公司 一种分布式跨数据库保持事务一致性的方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
田向阳: """分布式事务一致性"看这一篇就够了"", 《HTTPS://WWW.SOHU.COM/A/228496709_609518》 *

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110599330B (zh) * 2019-09-12 2023-04-07 中国工商银行股份有限公司 银行通用的反交易装置、方法及系统
CN110599330A (zh) * 2019-09-12 2019-12-20 中国工商银行股份有限公司 银行通用的反交易装置、方法及系统
CN110597923A (zh) * 2019-09-29 2019-12-20 腾讯云计算（北京）有限责任公司 区块链资源管理方法、装置及存储介质
CN110597923B (zh) * 2019-09-29 2024-02-02 腾讯云计算（北京）有限责任公司 区块链资源管理方法、装置及存储介质
CN110992188A (zh) * 2020-03-03 2020-04-10 支付宝(杭州)信息技术有限公司 交易处理方法、装置及设备
CN111414266A (zh) * 2020-03-23 2020-07-14 山东浪潮通软信息科技有限公司 一种分布式事务的同步异步通信方法和装置
CN111414266B (zh) * 2020-03-23 2024-04-05 浪潮通用软件有限公司 一种分布式事务的同步异步通信方法和装置
CN111626858A (zh) * 2020-05-28 2020-09-04 北京金山云网络技术有限公司 冲正交易的处理方法、装置、电子设备和计算机可读介质
CN111415146A (zh) * 2020-06-08 2020-07-14 浙江口碑网络技术有限公司 资源数据的处理方法、装置及设备
CN112035269A (zh) * 2020-09-10 2020-12-04 蔡国凤 一种分布式系统多节点锁定方法
CN112035269B (zh) * 2020-09-10 2021-06-01 湖南文盾智链科技有限公司 一种分布式系统多节点锁定方法
CN112395104B (zh) * 2020-11-16 2023-12-01 中国工商银行股份有限公司 一种分布式事务上下文在路由层传递的实现方法与装置
CN112395104A (zh) * 2020-11-16 2021-02-23 中国工商银行股份有限公司 一种分布式事务上下文在路由层传递的实现方法与装置
CN112598520A (zh) * 2020-12-28 2021-04-02 中国农业银行股份有限公司 交易管理的方法、装置、电子设备以及存储介质
CN114764405A (zh) * 2020-12-31 2022-07-19 正链科技(深圳)有限公司 一种分布式应用程序的事务数据一致性存储方法
CN114764405B (zh) * 2020-12-31 2024-04-26 正链科技(深圳)有限公司 一种分布式应用程序的事务数据一致性存储方法

Similar Documents

Publication Publication Date Title
CN108596768A (zh) 一种分布式事务处理方法、装置及系统
CN103782574B (zh) 用于数据库事务的幂等性
CN108459919A (zh) 一种分布式事务处理方法及装置
Brewer CAP twelve years later: How the" rules" have changed
US9569473B1 (en) Method of controlling whether an uncompleted transaction applied against a database goes forward using either synchronous or asynchronous replication, or using either encrypted replication or unencrypted replication
CN109087431B (zh) 银行网点的业务调度处理方法、设备和存储介质
US7805482B2 (en) Method of correlating events in data packet streams
CN106775959A (zh) 分布式事务处理方法和系统
CN103995691B (zh) 基于事务的服务状态一致性维护方法
CN104636878B (zh) 一种银行自动处理任务的调度方法及装置
CN112700329A (zh) 一种风控规则引擎的响应方法和风控规则引擎
US7523113B2 (en) Distributed system, computer and state transition control method for distributed system
CN110163572B (zh) 一种链码函数处理方法、装置及设备
CN109801156A (zh) 一种放贷风险管控方法及放贷风险管控设备
US10296759B1 (en) Method of controlling whether an uncompleted transaction applied against a database goes forward or is aborted, and for modifying the uncompleted transaction so that it can go forward
CN106293744A (zh) 一种应用版本动态切换方法及装置
CN103562853B (zh) 用于管理程序代码的实例的方法和系统
CN106294611A (zh) 银行核心系统及新老核心系统数据切换方法
CN105703941B (zh) 配置事务的处理方法及装置
US10176243B1 (en) Method and apparatus for logging non-durable attributes of an uncompleted transaction so as to make such attributes durable
CN110535939A (zh) 一种服务发现与抢占方法、装置、计算机设备及存储介质
CN113377875A (zh) 跨链数据处理方法、装置、电子设备及可读存储介质
CN113112358A (zh) 基于区块链的决策方法及装置和电子设备
CN109408201A (zh) 基于分布式数据库的事务管理方法
CN112597762A (zh) 一种具有智能合约数据监管功能的区块链系统及监管方法

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
WW01 Invention patent application withdrawn after publication

Application publication date: 20180928

WW01 Invention patent application withdrawn after publication