CN109739624B - 分布式事务处理方法、装置、电子设备及计算机可读介质 - Google Patents

Abstract

本公开提供一种分布式事务处理方法、装置、电子设备及计算机可读介质，属于互联网技术领域。该分布式事务处理方法包括：根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件；通过spring AOP的方式将所述公共组件融合到业务逻辑中。该方法通过对多个消息处理逻辑进行抽象，提取出公共组件，使得提取的公共组件中的核心处理逻辑得到最大可能的复用；通过spring AOP的方式将所述公共组件的核心处理逻辑融合到业务逻辑中，降低耦合度，降低使用者的难度，使得程序逻辑便于理解，提升研发效率。

Description

分布式事务处理方法、装置、电子设备及计算机可读介质

技术领域

本公开总体涉及互联网技术领域，具体而言，涉及一种分布式事务处理方法、装置、电子设备及计算机可读介质。

背景技术

微服务是将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。

因此，现有技术中的技术方案中还存在有待改进之处。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种分布式事务处理方法、装置、电子设备及计算机可读介质，解决上述问题中的至少一个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一方面，提供一种分布式事务处理方法，包括：根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件；通过spring AOP的方式将所述公共组件融合到业务逻辑中。

在本公开的一个实施例中，根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件之后，通过spring AOP的方式将所述公共组件融合到业务逻辑中之前，还包括：

根据所述公共组件生成通用消息表；

在所述通用消息表中针对每个消息配置一个消息id。

在本公开的一个实施例中，所述根据所述公共组件生成通用消息表之前，还包括：

执行业务逻辑，调用与所述业务逻辑相对应的代理服务。

在本公开的一个实施例中，所述通过spring AOP的方式将所述公共组件融合到业务逻辑中包括：

采用spring AOP的方式将所述公共组件中的核心处理逻辑实时织入到所述业务逻辑中。

在本公开的一个实施例中，采用spring AOP的方式将所述公共组件中的核心处理逻辑实时织入到所述业务逻辑中包括：

通过AOP切面针对所述代理服务进行入参序列化，得到序列化代理服务；

记录调用所述序列化代理服务的方法名和bean名；

保存所述通用消息表；

事务提交后通过钩子返回到所述AOP切面。

在本公开的一个实施例中，事务提交后，还包括：

将所述业务处理逻辑加入到线程池；

根据所述通用消息表中的消息id获取消息上下文；

反射调用所述消息id对应的bean名和方法名，并将调用结果发送给消费方对应的服务。

在本公开的一个实施例中，反射调用所述消息id对应的bean名和方法名，并将调用结果发送给消费方对应的服务包括：

如果调用成功，则将调用结果发送给消费方对应的服务；如果调用不成功，则等待重试，直到调用成功。

根据本公开的再一方面，提供一种分布式事务处理装置，包括：提取模块，配置为根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件；织入模块，配置为通过spring AOP的方式将所述公共组件融合到业务逻辑中。

根据本公开的又一方面，提供一种电子设备，包括处理器；存储器，存储用于所述处理器控制如上所述的方法步骤的指令。

根据本公开的另一方面，提供一种计算机可读介质，其上存储有计算机可执行指令，所述可执行指令被处理器执行时实现如上所述的方法步骤。

根据本公开实施例提供的分布式事务处理方法、装置、电子设备及计算机可读介质，一方面，通过对多个消息处理逻辑进行抽象，提取出公共组件，使得提取的公共组件中的核心处理逻辑得到最大可能的复用；另一方面，通过spring AOP的方式将所述公共组件的核心处理逻辑融合到业务逻辑中，降低耦合度，降低使用者的难度，使得程序逻辑便于理解，提升研发效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1示出本公开相关实施例中通过本地消息表实现最终一致性的流程示意图。

图2示出以通过本地消息表实现事务的最终一致性为例进行介绍的原理图。

图3示出本公开一实施例中提供的一种分布式事务处理方法的流程图。

图4示出本公开一实施例图3中步骤S320的流程图。

图5示出本公开一实施例图3中步骤S320事务提交后的流程图。

图6示出本公开一实施例中结合一具体实例对分布式事务处理的原理图。

图7示出本公开另一实施例中提供的一种分布式事务处理装置的示意图。

图8示出本公开一实施例提供的适于用来实现本申请实施例的电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现、材料或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

在本发明的相关实施例中，对数据库的操作就是涉及数据库事务(DatabaseTransaction)，简称事务，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行，事务是数据库运行中的逻辑工作单位。

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足以下3个属性：

一致性(Consistency)：客户端知道一系列的操作都会同时发生(生效)；

可用性(Availability)：每个操作都必须以可预期的响应结束；

分区容错性(Partition tolerance)：即使出现单个组件无法可用，操作依然可以完成。

对于分布式系统而言，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。

而XA是一个两阶段提交(2PC)协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。

第二阶段：事务协调器要求每个数据库提交数据。

但是两阶段提交协议的锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

2PC方案的实现复杂，还会造成可用性降低，会性能影响较大，不适合高并发高性能场景。

除了一致性，在分布式系统中还需要保证可用性，可用性的重要程序比一致性要高。BASE理论是用来对CAP定理进行进一步扩充的。BASE理论指的是：

Basically Available(基本可用)

Soft state(软状态)

Eventually consistent(最终一致性)

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

图1示出本公开相关实施例中通过本地消息表实现最终一致性的流程示意图，一个应用程序通常需要实现多个业务逻辑，如图1所示，在消息生产方需要根据多个业务逻辑分别额外建一个本地消息表，并记录消息发送状态。消息表和业务数据(业务逻辑的数据)在一个数据库中，并在一个事务里提交，然后消息会经过消息队列MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。而消息消费方需要接收并处理消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功，如果处理失败，则就会重试执行。如果是业务上的失败，可以给消息生产方发送一个业务补偿消息，通知消息生产方进行回滚等操作。该方案中消息的生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。

图2示出以通过本地消息表实现事务的最终一致性为例进行介绍的原理图，如图2所示，首先A系统通过业务逻辑(包括业务逻辑1和业务逻辑2)开启消息处理事务，然后保存表(表1和表2)和消息(消息1和消息2)，并提交事务，发送消息(消息1和消息2)到kafka队列，由于kafka队列负责日志数据的接收，存储和转发，再由kafka队列分别发送给B系统的服务X和C系统的服务Y。在该方案中除了开发对应的业务逻辑以外，还必须定义一张消息表，然后将需要远程传输的信息保存到消息表中。除此之外，当业务逻辑的数据操作事务提交后，还需要专门编写处理消息的代码，执行远程调用，以及重试逻辑相关的代码。整个过程开发异常繁琐，事务一致性的逻辑和业务逻辑紧密耦合，逻辑程序不易理解，开发难度大。

基于上述，可以通过本地消息表实现异步确保实现最终一致性，本地消息表主要思路是将分布式事务分成多个本地事务，可以称之为主事务与从事务。首先主事务本地先行提交，然后通过消息通知从事务，从事务从消息中获取信息进行本地提交。该方案依靠下游业务的重试机制达到最终一致性，但是对应用侵入性也很高，消息表会耦合到业务系统中，如果没有封装好的解决方案，会应用需要进行大量业务改造，成本较高。

基于上述相关方案存在的问题，本公开的一些实施例提供一种分布式事务处理方法、装置、电子设备及计算机可读介质。

图3示出本公开一实施例中提供的一种分布式事务处理方法的流程图，包括以下步骤：

如图3所示，在步骤S310中，根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件。

如图3所示，在步骤S320中，通过spring AOP的方式将所述公共组件融合到业务逻辑中。

通过本示例性实施例中的分布式事务处理方法，一方面，通过对多个消息处理逻辑进行抽象，提取出公共组件，使得消息处理逻辑得到最大可能的复用；另一方面，通过spring AOP的方式将所述公共组件融合到业务逻辑中，降低耦合度，降低使用者的难度，使得程序逻辑便于理解，提升研发效率。

下面，将对本公开实施例中的分布式事务处理方法中的各步骤作进一步的说明。

在步骤S310中，根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件。

其中组件是对数据和方法的简单封装，公共组件就是对多个消息处理逻辑中公共的部分(也就是核心的部分)进行封装。

在本公开的一个实施例中，该步骤中将本地消息表中的多个消息处理逻辑进行抽象，提取出多个消息处理逻辑的核心处理逻辑，得到公共组件。这里的公共组件具有黑盒性，其他的开发者在快速阅读使用文档之后可以立刻上手，而不用关心内部实现；独立性，即做好解耦，不与父组件有过多关联；以及自定义性，适当地暴露一些输入接口或者方法给外部用于自定义，同时也要设置好这些属性在外部未输入时的默认值，这样公共组件可以使得消息处理逻辑得到最大可能的复用。

另外，该步骤根据本地消息表中的多个消息处理逻辑提取得到公共组件之后，通过spring AOP的方式将所述公共组件融合到业务逻辑中之前，还包括：

根据所述公共组件生成通用消息表；

在所述通用消息表中针对每个消息配置一个消息id。

通过构建通用消息表，可以使消息生产方的系统能够共用一个消息表，可以消除消息处理逻辑和业务处理逻辑之间的耦合。同时在消息表中每个消息都有一个对应的消息id，这样便于管理。

在本公开的一个实施例中，根据所述公共组件生成通用消息表之前，还包括：

调用与所述业务逻辑相对应的代理服务。例如，如果需要实现与服务X的最终一致性，则调用代理服务X，服务X和代理服务X均是针对同一业务逻辑的。

AOP框架创建的对象用来实现切面契约(包括通知方法执行等功能)。在Spring中，AOP代理可以是JDK动态代理或者CGLIB代理。

在步骤S320中，通过spring AOP的方式将所述公共组件融合到业务逻辑中。

在本公开的一个实施例中，通过spring AOP的方式将所述公共组件融合到业务逻辑中包括：

采用spring AOP的方式将所述公共组件中的核心处理逻辑实时织入到所述业务逻辑中。

在本实施例中，调用代理服务，代理服务具体可以通过AOP(AspectOrientedProgramming，面向切面编程)切面进行横向切入。

AOP适合于具有横切逻辑的应用：如性能监测、访问控制、事务管理以及日志记录，本实施例中所涉及的就是事务管理。AOP将这些分散在各个业务逻辑中的代码通过横向切割的方式抽取到一个独立的模块中。Spring AOP的规则解析引擎负责解析切点所设定的查询条件，找到对应的连接点；其实更为准确的说应该是执行点而非连接点，因为连接点是方法执行前、执行后等包括方位信息的具体程序执行点，而切点只定位到某个方法上，所以如果希望定位到具体连接点上，还需要提供连接点的方位信息。

在本公开的一个实施例中，该步骤具体可以采用spring AOP的方式将所述公共组件中的核心处理逻辑实时织入到所述业务逻辑中，图4示出步骤S320的流程图，具体包括以下步骤：

如图4所示，在步骤S401中，通过AOP切面针对所述代理服务进行入参序列化，得到序列化代理服务。由于范围传递的数据只能是序列化的数据(例如xml数据)，因此在入参时需要进行序列化，在服务中进行反序列化。通常把对象转换为字节序列的过程称为对象的序列化；而把字节序列恢复为对象的过程称为对象的反序列化。

如图4所示，在步骤S402中，记录调用所述序列化代理服务的方法名和bean名。其中获取spring容器的bean的方法可以为以下中的一种：

在初始化时保存ApplicationContext对象；

通过Spring提供的工具类获取ApplicationContext对象；

继承自抽象类ApplicationObjectSupport；

继承自抽象类WebApplicationObjectSupport；

实现接口ApplicationContextAware。

需要说明的是，id和name都是spring容器中bean的唯一标识符。id是一个bean的唯一标识，命名格式必须符合XML ID属性的命名规范。name可以用特殊字符，并且一个bean可以用多个名称：name＝“bean1,bean2,bean3”用逗号或者分号或者空格隔开。如果没有id，则name的第一个名称默认是id。同一个spring配置文件中，bean的id、name是不能够重复的，否则spring容器启动时会报错。如果一个spring容器从多个配置文件中加载配置信息，则多个配置文件中是允许有同名bean的，并且后面加载的配置文件的中的bean定义会覆盖前面加载的同名bean。

如图4所示，在步骤S403中，保存所述通用消息表。通过该步骤将所述通用信息表保存到数据库。

如图4所示，在步骤S404中，事务提交后通过钩子返回到所述AOP切面。由于钩子可以监视系统或进程中的各种事件消息，截获发往目标窗口的消息并进行处理，因此该步骤中通过钩子对事务提交的事件进行监控，如果监控到有事务提交，则钩子就将事务提交的消息反馈给AOP切面。

基于上述图4所示的步骤S401～S404，完成公共组件内的业务逻辑，但是到此为止仅完成了消息发送方的消息处理逻辑和业务逻辑，之后还需要对相关的服务进行同步，实现消息的最终一致性。采用AOP的方式将公共组件中的核心处理逻辑实时织入到业务逻辑中，降低耦合度，降低使用者的难度，使得程序逻辑便于理解，提升研发效率。

需要说明的是，织入是将增强添加到目标类具体连接点上的过程，AOP就像一台织布机，将目标类、增强或者引介编织到一起，AOP有三种织入的方式：

a.编译期间织入，这要求使用特殊的java编译器；

b.类装载期织入，这要求使用特殊的类装载器；

c.动态代理织入，在运行期为目标类添加增强生成子类的方式。

Spring采用动态代理织入，而AspectJ采用编译器织入和类装载期织入，SpringAOP就是负责实施切面的框架，将切面所定义的横切逻辑织入到切面所指定的连接点中，AOP的主要工作就是如何将增强应用于目标对象的连接点上。

在本公开的一个实施例中，图5示出步骤S320事务提交后的流程图，如图5所示，包括以下步骤：

如图5所示，在步骤S501中，将所述业务处理逻辑加入到线程池。

如图5所示，在步骤S502中，根据所述通用消息表中的消息id获取消息上下文。该步骤从线程池中逐一提取出消息，并根据消息id获取到消息的上下文。这里的消息上下文是指需要调用对应的业务逻辑所需的信息，例如哪个类的哪个方法，入参信息以json格式存储在消息表中，使用的时候根据消息id找到对应记录，然后将json中的信息反序列化到内存对象，以便程序执行。

如图5所示，在步骤S503中，反射调用所述消息id对应的bean名和方法名，并将调用结果发送给消费方对应的服务。

在本公开的一个实施例中，反射调用机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性。对于Spring框架，为了保证框架的通用性，可能需要根据配置文件加载不同的对象或类，调用不同的方法，此时就必须用到反射——运行时动态加载需要加载的对象。反射机制在运行时才知道要操作的类是什么，并且可以在运行时获取类的完整构造，并调用对应的方法。

在本公开的一个实施例中，步骤S503中如果调用成功，则将调用结果发送给消费方对应的服务；如果调用不成功，则等待重试，直到调用成功。在本实施例中，使用者也不用关心消息的重试，重试过程统一由框架来完成的，减少使用者的工作。

基于上述，图6示出结合一具体实例对分布式事务处理的原理图，其中包括A系统(消息生产方)、B系统(消息消费方)及C系统(消息消费方)。

第一阶段：

在A系统中请求服务触发业务逻辑1和业务逻辑2，开启事务，保存表1和表2，然后调用服务代理X和代理服务Y，访问AOP切面，AOP切面在公共组件内执行上述步骤S401～S404，即针对所述代理服务进行入参序列化；记录调用所述代理服务的方法名和bean名；保存所述通用消息表；以及事务提交后通过钩子返回到所述AOP切面。AOP切面将组件内执行结果反馈给代理服务，然后提交事务。

第二阶段：

将所述业务处理逻辑加入到线程池，从线程池中逐一提取出消息，并根据消息id获取到消息的上下文，然后反射调用所述消息id对应的bean名和方法名，将相应的业务逻辑的结果发送给B系统的X服务和C系统的Y服务。接下来判断调用是否成功，如果调用成功，则过程结束，实现最终一致性；如果调用不成功(如网络等原因)，则更新状态为失败，等待spring框架来进行重试，直到调用成功。

综上所述，本实施例提供的分布式事务处理方法，一方面，通过对多个消息处理逻辑进行抽象，提取出公共组件，使得提取的公共组件中的核心处理逻辑得到最大可能的复用；另一方面，通过spring AOP的方式将所述公共组件的核心处理逻辑融合到业务逻辑中，降低耦合度，降低使用者的难度，使得程序逻辑便于理解，提升研发效率。

图7示出本公开另一实施例中提供的一种分布式事务处理装置的示意图，如图7所示，该装置700包括：提取模块710和织入模块720。

提取模块710配置为根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件；织入模块720配置为通过spring AOP的方式将所述公共组件融合到业务逻辑中。

该装置中各个模块的功能参见上述方法实施例中的相关描述，此处不再赘述。

综上所述，本实施例中的分布式事务处理装置，一方面，通过对多个消息处理逻辑进行抽象，提取出公共组件，使得提取的公共组件中的核心处理逻辑得到最大可能的复用；另一方面，通过spring AOP的方式将所述公共组件的核心处理逻辑融合到业务逻辑中，降低耦合度，降低使用者的难度，使得程序逻辑便于理解，提升研发效率。

另一方面，本公开还提供了一种电子设备，包括处理器和存储器，存储器存储用于上述处理器控制以下方法的操作指令：

根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件；通过spring AOP的方式将所述公共组件融合到业务逻辑中。

下面参考图8，其示出了适于用来实现本申请实施例的电子设备的计算机系统800的结构示意图。图8示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分805加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分808；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送图片获取请求的单元”。

另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括以下方法步骤：

根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件；通过spring AOP的方式将所述公共组件融合到业务逻辑中。

应清楚地理解，本公开描述了如何形成和使用特定示例，但本公开的原理不限于这些示例的任何细节。相反，基于本公开公开的内容的教导，这些原理能够应用于许多其它实施方式。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (8)

1.一种分布式事务处理方法，其特征在于，包括：

根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件，其中，所述公共组件为封装所述多个消息处理逻辑中公共的部分得到的；

通过spring AOP的方式将所述公共组件融合到业务逻辑中；

在根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件之后，通过spring AOP的方式将所述公共组件融合到业务逻辑中之前，所述方法还包括：

根据所述公共组件生成通用消息表；

在所述通用消息表中针对每个消息配置一个消息id；

事务提交后，还包括：

将所述业务逻辑加入到线程池；

根据所述通用消息表中的消息id获取消息上下文；

反射调用所述消息id对应的bean名和方法名，并将调用结果发送给消费方对应的服务。

2.根据权利要求1所述的分布式事务处理方法，其特征在于，所述根据所述公共组件生成通用消息表之前，还包括：

调用与所述业务逻辑相对应的代理服务。

3.根据权利要求2所述的分布式事务处理方法，其特征在于，所述通过spring AOP的方式将所述公共组件融合到业务逻辑中包括：

采用spring AOP的方式将所述公共组件中的核心处理逻辑实时织入到所述业务逻辑中。

4.根据权利要求3所述的分布式事务处理方法，其特征在于，采用spring AOP的方式将所述公共组件中的核心处理逻辑实时织入到所述业务逻辑中包括：

通过AOP切面针对所述代理服务进行入参序列化，得到序列化代理服务；

记录调用所述序列化代理服务的方法名和bean名；

保存所述通用消息表；

事务提交后通过钩子返回到所述AOP切面。

5.根据权利要求1所述的分布式事务处理方法，其特征在于，反射调用所述消息id对应的bean名和方法名，并将调用结果发送给消费方对应的服务包括：

如果调用成功，则将调用结果发送给消费方对应的服务；如果调用不成功，则等待重试，直到调用成功。

6.一种分布式事务处理装置，其特征在于，包括：

提取模块，配置为根据本地消息表中的多个消息处理逻辑的核心处理逻辑提取得到公共组件，其中，所述公共组件为封装所述多个消息处理逻辑中公共的部分得到的；

织入模块，配置为通过spring AOP的方式将所述公共组件融合到业务逻辑中；

在根据本地消息表中的多个消息处理逻辑提取的核心处理逻辑得到公共组件之后，通过spring AOP的方式将所述公共组件融合到业务逻辑中之前，所述装置还配置为根据所述公共组件生成通用消息表；在所述通用消息表中针对每个消息配置一个消息id；以及

将所述业务逻辑加入到线程池；

根据所述通用消息表中的消息id获取消息上下文；

反射调用所述消息id对应的bean名和方法名，并将调用结果发送给消费方对应的服务。

7.一种电子设备，其特征在于，包括：

处理器；

存储器，存储用于所述处理器控制如权利要求1-5任一项所述的方法步骤的指令。

8.一种计算机可读介质，其上存储有计算机可执行指令，其特征在于，所述可执行指令被处理器执行时实现如权利要求1-5任一项所述的方法步骤。

Images