CN109933412A - 基于分布式消息中间件的分布式事务处理方法 - Google Patents

Abstract

本发明公开了基于分布式消息中间件的分布式事务处理方法，包括如下步骤：步骤一：业务模块开启，通过事务模块判断此业务处理方案为XA或者TCC，并将此判断结果生成事务ID注册到事务树以及消息中间件中；步骤二：业务模块执行业务代码，并将执行结果通知给事务模块，根据上述事务ID将此执行结果对应记录至事务树中，并同步通知到消息中间件；步骤三：消息中间件推送多个事务执行结果给异步消息模块，异步消息模块查询事务树中各节点执行结果，并比较与消息中间件推送的执行结果是否一致，判断是否需要提交或回滚。本发明融合XA方案和TCC方案的优点，并结合消息中间件高效可靠地特点，解决了处理多场景下事务一致性的问题。

Description

基于分布式消息中间件的分布式事务处理方法

技术领域

本发明涉及计算机技术领域。更具体地说，本发明涉及基于分布式消息中间件的分布式事务处理方法。

背景技术

目前云计算、大数据、互联网领域的很多系统都采用了分布式的架构。涉及到全链路的业务操作往往会由多个服务和数据库实例共同完成。因此，在一致性要求较高的业务场景中，分布式事务则成为关键点。目前主流的分布式事务解决方案主要有三种，XA方案、补偿方案(TCC方案)以及消息一致性方案。

XA方案主要用于解决分布式事务库的事务问题，这个方案有标准化的接口，使用门槛低、可以达到数据的强一致性。但是由于采用了阻塞式的协议，影响系统吞吐和可伸缩性，性能在高并发场景下不是很理想，而且无法解决服务化事务问题。补偿方案可以解决服务化的事务问题，但是开发成本比较高，而且每个方法都要提供回滚接口，代价比较大，开发成本较高。消息方案，开发相对简单，但要求应用和消息系统紧耦合，要求实现幂等操作，而且是最终一致性。

发明内容

本发明的一个目的是提供基于分布式消息中间件的分布式事务处理方法，融合XA方案和TCC方案的优点，并结合消息中间件高效可靠地特点，解决了处理多场景下事务一致性的问题。

为了实现根据本发明的这些目的和其它优点，提供了基于分布式消息中间件的分布式事务处理方法，包括如下步骤：

步骤一：业务模块开启，其业务进入事务模块，并通过事务模块判断此业务处理方案为XA或者TCC，并将此判断结果生成事务ID注册到事务树以及消息中间件中，并通过事务模块开启事务；

步骤二：业务模块执行业务代码，并将执行结果通知给事务模块，根据上述事务ID将此执行结果对应记录至事务树中，并同步通知到消息中间件；

步骤三：多个业务对应的多个事务ID构成事务树的各节点，消息中间件推送多个事务执行结果给异步消息模块，异步消息模块查询事务树中各节点执行结果，如果其中一个节点执行结果与消息中间件推送的执行结果不一致，则通知消息中间件当前整个事务树的所有节点需要回滚，并同步回滚当前业务，异步消息模块将需要回滚的消息传送给事务模块进行回滚；若每个节点的执行结果与消息中间件推送的执行结果均一致，则通过异步消息模块通知事务模块将业务执行结果提交给XA或者TCC处理方案。

优选的是，事务树的生成具体为：业务服务器A中的业务模块A在开启事务后向事务树注册形成父事务ID值A，业务模块A开始执行业务代码时，需要调用业务服务器B1和业务服务器B2，此时其内的业务模块B1和业务模块B2分别开启事务，生成对应的子事务ID值B1和B2，并向事务树的父事务ID值A下注册；当业务模块B1或业务模块B2开始执行业务代码时，需要调用业务服务器C1和业务服务器C2或业务服务器D1和业务服务器D2，此时其内的业务模块C1和业务模块C2或业务模块D1和业务模块D2分别开启事务，生成对应的子事务ID值C1和C2或D1和D2，并向事务树ID值B1或B2下注册，此时B1或B2为父事务；依次类推，生成事务树，并将上述事务树结果推送至消息中间件。

优选的是，如果子事务对应的节点执行结果不一致需要回滚，则通过消息中间件推送回滚数据，在事务树中向上逐级回滚父事务；如果子事务对应的节点执行结果全部一致，则逐级提交父事务的执行结果，最后关闭事务树。

优选的是，所述消息中间件采用Kafka，所述事务树存储采用Redis。

优选的是，与事务树同步记录事务ID以及事务所需要的参数数据的为日志记录系统，其记录所有服务的事务执行的事务树节点的日志以及切面事务数据，子服务在执行子事务业务时与父服务进行心跳连接，如果出现父服务节点宕机，则子服务事务模块立刻主动回滚当前的子服务事务；如果子服务宕机，则父服务通过事务树中记录的各个子事务ID，查询到对应子事务的日志记录信息，排查出需要主动回滚TCC类型的事务，然后主动调用对应子业务中的Cancel代码进行重试Cancel。

优选的是，父服务节点在启动时设置事务挂起超时时间，如果子服务也设置事务挂起超时时间，整个事务树动态调整整个事务最终超时时间，如果事务执行超过最终超时时间则整个事务树全部回滚。

优选的是，与事务树同步记录事务ID以及事务所需要的参数数据的为日志记录系统，其记录所有服务的事务执行的事务树节点的日志以及切面事务数据，当执行关闭事务树时，若父事务接受到关闭失败的状态后，将会把父事务识别为待补偿事务，然后父事务将该次事务数据异步通知补偿回调地址，然后得到父事务日志切面的数据进行再次执行该次请求事务。

优选的是，事务模块中设置超时控制机制，即每个业务执行时间设置有预设值，如果每个业务执行的时间超过预设值，则直接通知消息中间件以及事务树，事务进入超时状态需要回滚。

优选的是，子服务通过事务模块开启事务前，判断业务代码标记的方法中是否包含支持XA的数据库操作；如果存在则开启事务并生成事务ID并注册到事务树中；如果没有则默认为采用TCC方案进行。

优选的是，业务代码执行在数据持久层进行切面判断是否配置Cancel机制；如果业务配置了Cancel机制，当前业务结束前需要Confirm子服务是否全部成功，异常则执行Cancel业务代码。

本发明至少包括以下有益效果：

1、本发明通过消息中间件代替事务协调控制中心，推送各个事务节点的状态，达到统一事务处理方案，减少开发成本的目的，融合XA方案和TCC方案的优点并结合消息中间件高效可靠地特点，解决了处理多场景下事务一致性的问题。

2、采用事务树方式记录整个链路业务下的所有事务的状态以及数据，达到可以监控的目的，可以分析出某个事务节点超时、迟缓等指标时候，结合分布式框架的特点调整该服务节点，部署分布式系统一般会采用集群部署每一个服务都部署多台服务器，通过此项监控分析我们可以灵活增加服务节点。

3、本发明能够对整个事务树快速处理并能够保证事务的一致性，再结合现有的分布式事务解决方案的优点，在确保分布式事务的稳定、高效的情况下提供统一事务处理方案，减少开发成本。

本发明的其它优点、目标和特征将部分通过下面的说明体现，部分还将通过对本发明的研究和实践而为本领域的技术人员所理解。

附图说明

图1为本发明分布式事务系统；

图2为本发明事务树生成示意图。

具体实施方式

下面结合附图对本发明做进一步的详细说明，以令本领域技术人员参照说明书文字能够据以实施。

需要说明的是，下述实施方案中所述实验方法，如无特殊说明，均为常规方法，所述试剂和材料，如无特殊说明，均可从商业途径获得；在本发明的描述中，术语“横向”、“纵向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，并不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

如图1至2所示，本发明提供一种基于分布式消息中间件的分布式事务处理方法，包括如下步骤：

步骤一：业务模块开启，其业务进入事务模块，并通过事务模块判断此业务处理方案为XA或者TCC，并将此判断结果生成事务ID注册到事务树以及消息中间件中，并通过事务模块开启事务；

步骤二：业务模块执行业务代码，并将执行结果通知给事务模块，根据上述事务ID将此执行结果对应记录至事务树中，并同步通知到消息中间件；

步骤三：多个业务对应的多个事务ID构成事务树的各节点，消息中间件推送多个事务执行结果给异步消息模块，异步消息模块查询事务树中各节点执行结果，如果其中一个节点执行结果与消息中间件推送的执行结果不一致，则通知消息中间件当前整个事务树的所有节点需要回滚，并同步回滚当前业务，异步消息模块将需要回滚的消息传送给事务模块进行回滚；若每个节点的执行结果与消息中间件推送的执行结果均一致，则通过异步消息模块通知事务模块将业务执行结果提交给XA或者TCC处理方案。

在上述技术方案中，本发明的处理方法主要包括：事务发起方服务生成父事务ID并注册到消息中间件中，再调用子服务，子服务依据自己的业务情况生成子事务ID。整个链式事务中形成树状结构事务树，并将此结构事务结果推到消息中间件和分布式缓存中。各个业务服务会异步接收消息中间件的事务结果数据通知，并结合查询事务树中子节点的执行结果来判断当前业务是否需要提交或回滚，然后把执行结果进一步往上级节点通知，如果子事务需要回滚则通过消息中间件推送回滚数据，则逐级回滚父事务。如果子事务全部成功则逐级提交父事务。

结合图1所示的分布式事务系统，业务模块、事务模块和异步消息模块均为业务服务器，支持XA方案的数据库和非XA方案数据资源为数据库服务器，非XA方案即TCC方案。业务模块业务开始，进入事务模块进行判断业务事务处理方案XA(对应支持数据库)或者TCC(非XA数据资源)，然后生成事务ID注册到事务树(事务树会同步记录该事务ID的切面数据)以及消息中间件中，并开启事务。然后业务模块开始执行业务代码，执行结束后事务模块收集执行结果，根据事务ID将业务执行结构记录到事务树中，并同步通知到消息中间件，并会确认消息是否成功记录到消息中间件。单业务服务下，业务异步消息模块不会接收到消息中间件通知，直接会根据业务执行结果提交或回滚事务(TCC下执行Cancel)。多业务服务下，业务异步消息模块会异步接收消息中间件通知，然后查询事务树中当前事务ID下的各个树节点的执行结果。如果存在失败结果，通知到消息中间件所有当前整个业务树种的所有节点需要回滚，并同步回滚当前业务。消息中间件只是记录状态和结果，不做存储，只做消息的接收和传送。

本发明的分布式处理方法放弃使用事务协调控制中心，采用可靠性消息中间件提高传输的稳定性以及效率；全链路下的业务，以事务树状态呈现，可以记录各个节点的事务处理状态以及数据，方便事务的重试以及问题的分析。

在另一种技术方案中，事务树的生成具体为：业务服务器A中的业务模块A在开启事务后向事务树注册形成父事务ID值A，业务模块A开始执行业务代码时，需要调用业务服务器B1和业务服务器B2，此时其内的业务模块B1和业务模块B2分别开启事务，生成对应的子事务ID值B1和B2，并向事务树的父事务ID值A下注册；当业务模块B1或业务模块B2开始执行业务代码时，需要调用业务服务器C1和业务服务器C2或业务服务器D1和业务服务器D2，此时其内的业务模块C1和业务模块C2或业务模块D1和业务模块D2分别开启事务，生成对应的子事务ID值C1和C2或D1和D2，并向事务树ID值B1或B2下注册，此时B1或B2为父事务；依次类推，生成事务树，并将上述事务树结果推送至消息中间件。

在上述技术方案中，结合图2所示，业务服务模块A在开始事务后向事务树注册了父事务ID值A，成为此业务树的定点。在业务服务模块A开始执行业务代码时，需要调用业务服务器B1以及业务服务器B2，此时业务模块B1和业务模块B2分别开启事务，生成对应的事务ID值B1和B2，向事务树的父事务ID值A下注册，此时形成了事务树状态。当业务模块B1和B2根据当前业务是否存在需要调用其他业务服务器，会否再生成下一级的事务树节点，此处就不在继续赘述。

在另一种技术方案中，如果子事务对应的节点执行结果不一致需要回滚，则通过消息中间件推送回滚数据，在事务树中向上逐级回滚父事务；如果子事务对应的节点执行结果全部一致，则逐级提交父事务的执行结果，最后关闭事务树。事务管理流程从事务树的顶端从上至下逐级执行，最后业务结果则从下至上通知。

在另一种技术方案中，所述消息中间件采用Kafka但不仅限Kafka，所述事务树存储采用Redis但是不仅限Redis。

在另一种技术方案中，与事务树同步记录事务ID以及事务所需要的参数数据的为日志记录系统，其记录所有服务的事务执行的事务树节点的日志以及切面事务数据，子服务在执行子事务业务时与父服务进行心跳连接，如果出现父服务节点宕机，意味着子服务无法与服务器进行心跳联系，子服务内部的事务模块就会探测到异常，则子服务事务模块立刻主动回滚当前的子服务事务；如果子服务宕机，父服务无法与子服务进行联系，则父服务通过事务树中记录的各个子事务ID，查询到对应子事务的日志记录信息即子事务开启事务时记录的参数数据，排查出需要主动回滚TCC类型的事务，然后主动调用对应子业务中的Cancel代码进行重试Cancel，这里的子业务为分布式情况下保证相同业务存在集群部署的情况下，如果子服务为单机部署，则无法执行Cancel此处为异常信息记录日志。

在另一种技术方案中，父服务节点在启动时设置事务挂起超时时间，如果子服务也设置事务挂起超时时间，整个事务树动态调整整个事务最终超时时间，如果事务执行超过最终超时时间则整个事务树全部回滚。

在另一种技术方案中，与事务树同步记录事务ID以及事务所需要的参数数据的为日志记录系统，其记录所有服务的事务执行的事务树节点的日志以及切面事务数据，在执行某个业务方法时，本应该执行成功的操作却因为服务器挂机或者网络抖动等问题导致事务没有正常提交，此种场景就需要通过补偿来完成事务，从而达到事务的一致性。当执行关闭事务树时，若父事务接受到关闭失败的状态后，将会把父事务识别为待补偿事务，然后父事务将该次事务数据异步通知补偿回调地址，然后得到父事务日志切面的数据进行再次执行该次请求事务。关闭失败下整个业务链下的所有事务都会标记为待补偿，在事务树的记录下只需要记录父事务为待补偿即可。当进行日志记录时会记录调用父事务开启事务时候的切面参数数据，补偿回调地址就是设计一个外部记录的接口，从此接口处携带刚才的切面参数数据重新调用此父事务的业务代码。

在上述三个技术方案中，均为本发明分布式处理方法中的容错机制处理方案，基于日志记录用来进行宕机回滚以及重试、超时回滚、事务补偿。

在另一种技术方案中，事务模块中设置超时控制机制，即每个业务执行时间设置有预设值，如果每个业务执行的时间超过预设值，则直接通知消息中间件以及事务树，事务进入超时状态需要回滚。

在另一种技术方案中，子服务通过事务模块开启事务前，判断业务代码标记的方法中是否包含支持XA的数据库操作；如果存在则开启事务并生成事务ID并注册到事务树中；如果没有则默认为采用TCC方案进行。在业务代码中，开发人员必须标记当前方法中是否包含的事务类型，如XA、TCC等，程序就可以在开启事务前进行判断。

在另一种技术方案中，业务代码执行在数据持久层进行切面判断是否配置Cancel机制；如果业务配置了Cancel机制，当前业务结束前需要Confirm子服务是否全部成功，如果成功则commit所有挂起的事务，异常则执行Cancel业务代码。如果没有配置，则不是事务，是一个正常的业务代码，则不体现在本系统中。

在上述技术方案中，此方案结合本地事务以及TCC方案，用户根据具体场景选择方案，也可以同时支持本地事务以及TCC在一个业务方法，可以解决跨资源的事务问题，灵活处理提高事务的执行效率。具有统一事务处理方案，减少开发成本的优点。

尽管本发明的实施方案已公开如上，但其并不仅仅限于说明书和实施方式中所列运用，它完全可以被适用于各种适合本发明的领域，对于熟悉本领域的人员而言，可容易地实现另外的修改，因此在不背离权利要求及等同范围所限定的一般概念下，本发明并不限于特定的细节和这里示出与描述的图例。

Claims (10)

1.基于分布式消息中间件的分布式事务处理方法，其特征在于，包括如下步骤：

步骤一：业务模块开启，其业务进入事务模块，并通过事务模块判断此业务处理方案为XA或者TCC，并将此判断结果生成事务ID注册到事务树以及消息中间件中，并通过事务模块开启事务；

步骤二：业务模块执行业务代码，并将执行结果通知给事务模块，根据上述事务ID将此执行结果对应记录至事务树中，并同步通知到消息中间件；

步骤三：多个业务对应的多个事务ID构成事务树的各节点，消息中间件推送多个事务执行结果给异步消息模块，异步消息模块查询事务树中各节点执行结果，如果其中一个节点执行结果与消息中间件推送的执行结果不一致，则通知消息中间件当前整个事务树的所有节点需要回滚，并同步回滚当前业务，异步消息模块将需要回滚的消息传送给事务模块进行回滚；若每个节点的执行结果与消息中间件推送的执行结果均一致，则通过异步消息模块通知事务模块将业务执行结果提交给XA或者TCC处理方案。

2.如权利要求1所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，事务树的生成具体为：业务服务器A中的业务模块A在开启事务后向事务树注册形成父事务ID值A，业务模块A开始执行业务代码时，需要调用业务服务器B1和业务服务器B2，此时其内的业务模块B1和业务模块B2分别开启事务，生成对应的子事务ID值B1和B2，并向事务树的父事务ID值A下注册；当业务模块B1或业务模块B2开始执行业务代码时，需要调用业务服务器C1和业务服务器C2或业务服务器D1和业务服务器D2，此时其内的业务模块C1和业务模块C2或业务模块D1和业务模块D2分别开启事务，生成对应的子事务ID值C1和C2或D1和D2，并向事务树ID值B1或B2下注册，此时B1或B2为父事务；依次类推，生成事务树，并将上述事务树结果推送至消息中间件。

3.如权利要求2所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，如果子事务对应的节点执行结果不一致需要回滚，则通过消息中间件推送回滚数据，在事务树中向上逐级回滚父事务；如果子事务对应的节点执行结果全部一致，则逐级提交父事务的执行结果，最后关闭事务树。

4.如权利要求1至3所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，所述消息中间件采用Kafka，所述事务树存储采用Redis。

5.如权利要求2所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，与事务树同步记录事务ID以及事务所需要的参数数据的为日志记录系统，其记录所有服务的事务执行的事务树节点的日志以及切面事务数据，子服务在执行子事务业务时与父服务进行心跳连接，如果出现父服务节点宕机，则子服务事务模块立刻主动回滚当前的子服务事务；如果子服务宕机，则父服务通过事务树中记录的各个子事务ID，查询到对应子事务的日志记录信息，排查出需要主动回滚TCC类型的事务，然后主动调用对应子业务中的Cancel代码进行重试Cancel。

6.如权利要求2所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，父服务节点在启动时设置事务挂起超时时间，如果子服务也设置事务挂起超时时间，整个事务树动态调整整个事务最终超时时间，如果事务执行超过最终超时时间则整个事务树全部回滚。

7.如权利要求2所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，与事务树同步记录事务ID以及事务所需要的参数数据的为日志记录系统，其记录所有服务的事务执行的事务树节点的日志以及切面事务数据，当执行关闭事务树时，若父事务接受到关闭失败的状态后，将会把父事务识别为待补偿事务，然后父事务将该次事务数据异步通知补偿回调地址，然后得到父事务日志切面的数据进行再次执行该次请求事务。

8.如权利要求1所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，事务模块中设置超时控制机制，即每个业务执行时间设置有预设值，如果每个业务执行的时间超过预设值，则直接通知消息中间件以及事务树，事务进入超时状态需要回滚。

9.如权利要求2所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，子服务通过事务模块开启事务前，判断业务代码标记的方法中是否包含支持XA的数据库操作；如果存在则开启事务并生成事务ID并注册到事务树中；如果没有则默认为采用TCC方案进行。

10.如权利要求9所述的基于分布式消息中间件的分布式事务处理方法，其特征在于，业务代码执行在数据持久层进行切面判断是否配置Cancel机制；如果业务配置了Cancel机制，当前业务结束前需要Confirm子服务是否全部成功，若异常则执行Cancel业务代码。