CN111651244A - 分布式事务的处理系统 - Google Patents

Abstract

本发明提供了一种分布式事务的处理系统，包括：事务配置模块，用于按照业务服务的应用场景对业务服务的业务服务名、业务服务方法名和事务模式的类型进行配置；服务端包括，第一分布式事务控制组件，用于在接收服务编排的开始分布式事务请求后，获得分布式事务的全局事务标识；根据分布式事务的全局事务标识、服务编排中业务服务的事务模式的类型，联合第二分布式事务控制组件，对分布式事务中已配置的业务服务进行控制；全局统一发号组件，用于生成分布式事务的全局事务标识；客户端包括：第二分布式事务控制组件，用于联合第一分布式事务控制组件，对分布式事务中已配置的业务服务进行控制。本发明可以解决分布式事务的数据一致性问题。

Description

分布式事务的处理系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式事务的处理系统。

背景技术

传统大型单体企业架构向微服务架构转型的过程中，通过将单体系统根据业务价值划分为一个个可独立部署的微服务，以达到高可用、灵活伸缩、敏捷开发的目的。然而，由于微服务架构下服务的数据库独立部署，服务间的数据如何保持一致成为转型过程中的一大难题。

现有的大多数分布式事务方案都是根据特定场景进行实现，各方案之间接口不统一，应用系统需要根据不同业务场景做定制和二次开发，对应用侵入性较强，增加开发测试维护成本。当系统规模变大后，由于接口的差异将导致难以维护。另外，由于传统的方式大多是根据不同的场景制定不同分布式锁的实现，存在着难以统一管理、容易死锁等问题。这种传统的分布式事务方式难以提供全局的分布式事务的状态视图，无法准确获知系统当前状态下哪些数据仍处于不一致的状态。

目前进行分布式事务处理的主要方法有以下几种：

一是，两阶段提交(2PC,Two-Phase-Commit)方案，两阶段提交是数据库分布式事务XA协议的实现原理，通过引入一个事务管理器(TM)来统一调度所有分布式节点的执行逻辑：1)参与分布式事务的业务应用(AP)注册在事务管理器(TM)上注册全局事务；2)各业务应用在资源管理器(RM)上进行更新操作；3)操作完成后，各业务应用将处理结果反馈给事务管理器；4)事务管理器收到所有业务应用的反馈后，通过数据库提供的XA接口进行数据提交或回滚操作。2PC方案主要缺点：1)同步阻塞：由于两个阶段都采用同步阻塞的方式，会造成性能损耗。2)事务管理者存在单点故障问题，如果二阶段出现故障，其他参与者将会一直处于锁定状态。

二是，Try-Confirm-Cancel(TCC)方案，TCC模式是在业务服务层实现的一种方案，业务服务提供Try、Confirm、Cancel 3个操作：1)Try：尝试执行业务，完成所有业务检查，预留必须的业务资源；2)Confirm：确认执行业务，真正执行业务，不做业务检查；3)Cancel：取消执行业务，释放Try阶段预留的业务资源。对比两阶段提交模式，TCC没有单独的数据准备阶段。TCC方案主要缺点：1)对业务服务侵入性较大，需改造业务服务提供Try、Confirm和Cancel接口；2)实现难度较大，对于不同情形的失败原因，需要业务服务层提供不同的回滚策略；3)业务服务实现Confirm和Cancel接口时，需保证幂等。

三是，长时处理过程Saga方案，Saga是Garcia-Molina和Salem在1987年提出的一种分布式处理方法，通过将长时事务(Long Lived transactions，LLTs)切分成一个个子事务，每个子事务都有对应的补偿事务，依次执行并提交子事务，如果所有子事务都提交成功，则分布式事务成功；如果其中某个子事务提交失败，则立即按反向顺序依次执行补偿事务，实现分布式事务回滚。Saga方案主要缺点：没有提供事务的隔离性保证：每个子事务依次提交，此时另外一个交易查询到该资源时会读到中间过程的数据，这样如果同时操作同一个资源，可能导致操作覆盖、脏数据等问题。

四是，基于消息队列的最终一致性方案，消息一致性方案是通过消息中间件保证上、下游系统数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游系统向消息系统订阅该消息，收到消息后执行相应操作。消息方案从本质上讲是将分布式事务分为两个本地事务，然后依靠下游系统的重试机制达到最终一致性。基于消息队列的最终一致性主要缺点：1)下游系统需与上游系统协商如何实现幂等。2)由于通过异步方式更新，为保证上下游系统的一致性，一般需要使用第三方对账系统进行对账。

实际上，对于一个业务交易过程，不同的业务服务间的一致性要求是不同的。以银行核心系统常见的贷款账户放款交易为例，主要涉及业务流程包括占用额度、利率定价、贷款账户余额增加、存款账户余额增加、还款计划计算、交易流水记录等。其中额度是热点资源，需先占用成功才可执行后续流程，占用额度成功对其他事务不要求完全隔离；利率定价、贷款账户余额增加、存款账户余额增加之间一致性要求较高，在交易结束时需同时提交，未全部完成提交时中间状态对外不可见；还款计划计算和交易流水记录的一致性要求较低，可以在交易结束后在后台异步更新，以降低交易的响应时间。

而以上现有技术方案之间相对独立，每种技术方案有多种实现，对于上述业务场景，就需要各业务服务自己实现对应功能或者引用第三方的实现，这样会造成服务间的接口、标准不统一，重复开发，系统的规模难以扩展，从而制约系统架构的持续演进，难以形成统一的企业级微服务业务中台架构。

综上所述，目前缺乏一套统一的分布式事务的处理系统，以解决分布式事务处理的数据的不一致问题。

发明内容

本发明实施例提出一种分布式事务的处理系统，用以解决分布式事务的数据一致性问题，该系统包括：服务端、客户端和事务配置模块，其中，

事务配置模块，用于按照业务服务的应用场景对业务服务的业务服务名、业务服务方法名和事务模式的类型进行配置，所述事务模式的类型包括分机一致性模式、强一致性模式和弱一致性模式；

服务端包括第一分布式事务控制组件和全局统一发号组件，其中，

第一分布式事务控制组件，用于在接收服务编排的开始分布式事务请求后，开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识；根据分布式事务的全局事务标识、服务编排中业务服务的事务模式的类型，联合第二分布式事务控制组件，对分布式事务中已配置的业务服务进行控制；

全局统一发号组件，用于生成分布式事务的全局事务标识；

客户端包括：

第二分布式事务控制组件，用于基于全局事务标识，联合第一分布式事务控制组件，对分布式事务中已配置的业务服务进行控制。

在本发明实施例的系统中包括事务配置模块，使得业务服务可灵活地根据自身的业务特点和不同业务场景进行配置，配置后由服务端和客户端协调各服务实现数据一致性；服务端包括全局统一发号组件，实现了对分布式事务控制的统一，确保了幂等，进一步保证了分布式事务的数据一致性。

附图说明

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

图1为本发明实施例中分布式事务的处理系统的示意图；

图2为本发明实施例中服务端的组成示意图；

图3为本发明实施例中客户端的组成示意图；

图4为本发明实施例中分机一致性模式下系统的架构及工作流图；

图5为本发明实施例中强一致性模式下系统的架构及工作流图；

图6为本发明实施例中强一致性模式下系统的架构及另一种工作流图；

图7为本发明实施例中弱一致性模式下系统的架构及工作流图；

图8为本发明实施例中对分机一致性模式下业务服务处理成功时的系统执行流程图；

图9为本发明实施例中对分机一致性模式下业务服务处理失败时的系统执行流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

在本说明书的描述中，所使用的“包含”、“包括”、“具有”、“含有”等，均为开放性的用语，即意指包含但不限于。参考术语“一个实施例”、“一个具体实施例”、“一些实施例”、“例如”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。各实施例中涉及的步骤顺序用于示意性说明本申请的实施，其中的步骤顺序不作限定，可根据需要作适当调整。

下面首先对本发明实施例涉及到的术语进行解释。

DDD：领域驱动设计(Domain-Driven Design)，是一套综合软件系统分析和设计的面向对象建模方法。

事务：指提供一种机制将一个活动设计的所有操作纳入一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败、都将导致整个事务的回滚。

分布式事务：指保证分布在不同服务器上的操作要么全部成功、要么全部失败的机制。

XA协议：指X/Open组织为分布式事务处理制定的标准协议。

图1为本发明实施例中分布式事务的处理系统的示意图，如图1所示，该系统包括：

服务端、客户端和事务配置模块，其中，

事务配置模块，用于按照业务服务的应用场景对业务服务的业务服务名、业务服务方法名和事务模式的类型进行配置，所述事务模式的类型包括分机一致性模式、强一致性模式和弱一致性模式；

服务端包括第一分布式事务控制组件和全局统一发号组件，其中，

第一分布式事务控制组件，用于在接收服务编排的开始分布式事务请求后，开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识；根据分布式事务的全局事务标识、服务编排中业务服务的事务模式的类型，联合第二分布式事务控制组件，对分布式事务中已配置的业务服务进行控制；

全局统一发号组件，用于生成分布式事务的全局事务标识；

客户端包括：

第二分布式事务控制组件，用于基于全局事务标识，联合第一分布式事务控制组件，对分布式事务中已配置的业务服务进行控制。

在本发明实施例的系统中包括事务配置模块，使得业务服务可灵活地根据自身的业务特点和不同业务场景进行配置，配置后由服务端和客户端协调各服务实现数据一致性；服务端包括全局统一发号组件，实现了对分布式事务控制的统一，确保了幂等，进一步保证了分布式事务的数据一致性。

具体实施时，使用本发明框架对业务服务有如下约束：

一是，提供业务服务对应的仓储服务。在DDD设计思想中，仓储服务的职责在于将领域层的业务模型、业务事件转换成数据表的形式并持久化到数据表中，通常在实现上是对DAO层的封装，实现面向领域层的业务模型存取接口。在本发明实施例中，分布式服务处理系统将调用仓储服务做持久化。

二是，业务服务返回业务事件或者仓储可识别的类型，系统会将业务服务的返回传入仓储做持久化。设计上建议业务服务都返回事件，事件是发生的业务事实，包含了业务数据的变化历程，可用于服务间依赖的解耦。业务事件需包含可用于加锁的业务服务处理的业务实体的标识，一般是id字段，如账号、客户号、合同号等，将作为锁id的一部分。表1为本发明实施例中以json格式表示的业务事件的格式示例。

表1

具体实施时，事务配置模块按照业务服务的应用场景对业务服务的业务服务名、业务服务方法名和事务模式的类型进行配置，在银行中一般以交易为维度进行配置，通过交易码识别。同一个业务服务(例如微服务)可以在不同场景下配置不同的事务模式，也可以在运行时动态修改某项业务服务的事务模式。具体如何区分场景可以根据系统自身维度进行区分。

在一实施例中，事务配置模块具体用于：

若业务服务的事务模式的类型为强一致性模式，配置冲正方法名；

若业务服务的事务模式的类型为分机一致性模式，配置业务服务的消息队列名和冲正方法名，所述分机一致性模式下的消息队列名用于所述系统识别仓储持久化的消息队列，所述消息队列包括分布式事务的全局事务标识；

若业务服务的事务模式的类型为弱一致性模式，配置业务服务的消息队列名，所述消息队列包括分布式事务的全局事务标识。

在上述实施例中，所述分机一致性模式下的业务服务的消息队列名用于所述系统识别仓储持久化的消息队列，所述弱一致性模式下的业务服务的消息队列名用于识别系统通过哪个消息队列异步调用业务服务。

事务配置模块实现的配置可以记录在事务配置表中，见表2。

表2

图2为本发明实施例中服务端的组成示意图，图3为本发明实施例中客户端的组成示意图，在一实施例中，服务端还包括第一资源管理组件，用于对业务服务处理的业务实体的标识进行加锁；

客户端还包括第二资源管理组件，用于对业务服务处理的业务实体的标识进行解锁。

在一实施例中，服务端还包括第一事务状态记录组件，用于记录服务端的分布式事务的状态；

客户端还包括第二事务状态记录组件，用于记录客户端的分布式事务的状态。

在一实施例中，服务端还包括RPC调用组件，用于调用业务补偿服务，对业务服务进行冲正。

具体实施时，所述事务模式的类型包括分机一致性模式、强一致性模式和弱一致性模式，下面分别对每个类型的事务模块的具体控制过程进行介绍。

1.分机一致性模式

分机一致性模式适用于业务服务与服务编排不在同一进程，并对事务的一致性和隔离性要求较高的场景，在这种情况下，业务服务不应对数据做持久化，而是无状态的服务，业务服务返回业务事件，由系统在所有业务服务都完成后再调用仓储服务做持久化。由于业务服务本身不会更改数据库的状态，具有良好的事务隔离性，其它查询交易查询时不会查询到中间状态。在一实施例中，若服务编排中业务服务的事务模式的类型为分机一致性模式，第一分布式事务控制组件具体用于：

在获得分布式事务的全局事务标识后，调用第一事务状态记录组件，记录所述分布式事务的状态，所述分布式事务的状态包括全局事务标识；

在接收到服务编排的提交事务请求后，将每个业务服务返回的变更事件分别写入对应的消息队列中，向服务编排发送通知信息，调用第一资源管理组件对每个业务服务处理的业务实体的标识进行加锁；

在接收到服务编排发送的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正；

在接收到分布式事务完成消息后，调用第一事务状态记录组件更新分布式事务的状态；

第二分布式事务控制组件具体用于：

从每个业务服务的消息队列中获得每个业务服务的变更事件，调用仓储服务将所述变更事件仓储持久化入数据库中；

在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态，调用第二资源管理组件对每个业务服务处理的业务实体的标识进行解锁；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

在一实施例中，第二分布式事务控制组件还用于：

在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；

第一分布式事务控制组件还用于：

在接收到事务失败消息后，重复执行以下步骤，直至该分布式事务达到最大重试次数：

将每个业务服务返回的变更事件分别写入对应的消息队列中，向服务编排发送通知信息，调用第一资源管理组件对每个业务服务处理的业务实体的标识进行加锁。

在一实施例中，第二分布式事务控制组件还用于：

拦截业务服务处理完成动作，调用第二事务状态记录组件记录分布式事务的状态；在接收到清除事务状态信息后，调用第二事务状态记录组件清除分布式事务的状态；

第一分布式事务控制组件还用于：在接收到回滚事务请求后，向第二分布式事务控制组件发送清除事务状态信息。

图4为本发明实施例中分机一致性模式下系统的架构及工作流图，结合图4，可以整理出整个分布式业务处理的工作流为：

S1、服务编排向第一分布式事务控制组件发送开始分布式事务请求；第一分布式事务控制组件开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识，该全局事务标识可以是ID，之后调用第一事务状态记录组件，记录所述分布式事务的状态，此时的状态为初始状态，所述分布式事务的状态包括全局事务标识；

S2、服务编排向业务服务推送订阅事件；

S3、业务服务返回变更事件；

S4、服务编排向第一分布式事务控制组件发送提交事务请求；

S5、第一分布式事务控制组件将每个业务服务返回的变更事件分别写入对应的消息队列中，向服务编排发送通知信息；

S6、第一分布式事务控制组件调用第一资源管理组件对每个业务服务处理的业务实体的标识进行加锁，该标识可以是客户号、账号等，加锁后形成一条锁记录，该锁记录采用业务实体的标识+消息队列标识(例如消息队列名)作为识别该条资源的标识；

S7、第二分布式事务控制组件从每个业务服务的消息队列中获得每个业务服务的变更事件，调用仓储服务将所述变更事件仓储持久化入数据库中；

S8、在仓储持久化成功时，第二分布式事务控制组件调用第二事务状态记录组件更新分布式事务的状态，调用第二资源管理组件对每个业务服务处理的业务实体的标识进行解锁；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。第一分布式事务控制组件在接收到分布式事务完成消息后，调用第一事务状态记录组件更新分布式事务的状态。

另外，在任何一个业务服务处理失败后，服务编排会向第一分布式事务控制组件发送回滚事务请求，第一分布式事务控制组件在接收到服务编排发送的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正。且在接收到回滚事务请求后，向第二分布式事务控制组件发送清除事务状态信息。第二分布式事务控制组件在接收到清除事务状态信息后，调用第二事务状态记录组件清除分布式事务的状态，保证数据的一致性。

除此之外，第一分布式事务控制组件在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；第一分布式事务控制组件在接收到事务失败消息后，重复执行以下步骤，直至该分布式事务达到最大重试次数：将每个业务服务返回的变更事件分别写入对应的消息队列中，向服务编排发送通知信息，调用第一资源管理组件对每个业务服务处理的业务实体的标识进行加锁。由于仓储持久化失败不会解锁，该系统可提供查询不一致状态的业务实体的标识(账号、客户号等)，服务编排可以查询该表识别出不一致状态的业务实体等，拒绝该业务实体的后续处理。

需要注意的是，第二分布式事务控制组件还会拦截业务服务处理完成动作，调用第二事务状态记录组件记录分布式事务的状态，以便随时掌握分布式事务的状态，且各处的分布式事务的状态一致。

此事务模式下可以准确的识别出哪个业务服务处理的业务实体的数据处于不一致的状态，运维可以针对性的对该业务服务处理的业务实体的数据进行修复。

2.强一致性模式

强一致性模式适用于业务服务与服务编排部署在同一进程中，或者业务服务中存在调用外部系统需做补偿的情况。由于业务服务于编排服务部署在同一进程中，则第一分布式事务控制组件将识别为本地事务，如果业务服务成功，客户端本地调用业务服务的仓储做数据持久化。

在一实施例中，若服务编排中业务服务的事务模式的类型为强一致性模式，第一分布式事务控制组件具体用于：

在获得分布式事务的全局事务标识后，调用第一事务状态记录组件，记录该分布式事务的状态，所述分布式事务的状态包括全局事务标识；

在接收到服务编排的提交事务请求后，调用第二分布式事务控制组件，将每个业务服务返回的变更事件推送至第二分布式事务控制组件；

在接收到服务编排的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正；

第二分布式事务控制组件，具体用于：

调用仓储服务将每个业务服务返回的变更事件仓储持久化入数据库中；

在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

在一实施例中，第二分布式事务控制组件还用于：

在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；

第一分布式事务控制组件还用于：

在接收到事务失败消息后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用业务补偿服务进行冲正。

基于上述实施例，图5为本发明实施例中强一致性模式下系统的架构及工作流图，对应的是业务服务处理成功的情况，可以整理出整个分布式业务处理的工作流为：

S1、服务编排向第一分布式事务控制组件发送开始分布式事务请求；第一分布式事务控制组件开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识，该全局事务标识可以是ID，之后调用第一事务状态记录组件，记录所述分布式事务的状态，此时的状态为初始状态，所述分布式事务的状态包括全局事务标识；

S2、服务编排向业务服务推送订阅事件；

S3、业务服务返回变更事件；

S4、服务编排向第一分布式事务控制组件发送提交事务请求；

S5、第一分布式事务控制组件在接收到服务编排的提交事务请求后，调用第二分布式事务控制组件，将每个业务服务返回的变更事件推送至第二分布式事务控制组件；

S6、第二分布式事务控制组件调用仓储服务将每个业务服务返回的变更事件仓储持久化入数据库中；在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

另外，在仓储持久化失败时，第二分布式事务控制组件调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；第一分布式事务控制组件还用于：在接收到事务失败消息后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用业务补偿服务进行冲正。

图6为本发明实施例中强一致性模式下系统的架构及另一种工作流图，对应的是业务服务处理失败的情况，可以整理出整个分布式业务处理的工作流为：

S1、服务编排向第一分布式事务控制组件发送开始分布式事务请求；第一分布式事务控制组件开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识，该全局事务标识可以是ID，之后调用第一事务状态记录组件，记录所述分布式事务的状态，此时的状态为初始状态，所述分布式事务的状态包括全局事务标识；

S2、服务编排向业务服务推送订阅事件；

S3、业务服务返回变更事件；

S4、服务编排向第一分布式事务控制组件发送回滚事务请求；

S5、在接收到服务编排的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正。RPC调用组件是调用业务补偿服务进行冲正的。

3.弱一致性模式

弱一致性模式适用于对一致性要求不高，允许一定时间内数据不一致的场景。

在一实施例中，若服务编排中业务服务的事务模式的类型为弱一致性模式，第一分布式事务控制组件具体用于：

在获得分布式事务的全局事务标识后，调用第一事务状态记录组件，记录所述分布式事务的状态，所述分布式事务的状态包括全局事务标识；

在接收到服务编排提交的订阅事件后，通过消息队列将订阅事件发送至第二分布式事务控制组件；

在接收到分布式事务完成消息后，调用事务状态记录组件更新分布式事务的状态；

第二分布式事务控制组件具体用于：

接收到订阅事件后，调用第二事务状态记录组件，记录该分布式事务的状态；

向业务服务发送订阅事件，接收业务服务返回的变更事件；

调用仓储服务将所述变更事件仓储持久化入数据库中；

在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

在一实施例中，第二分布式事务控制组件还用于：

在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；

第一分布式事务控制组件还用于：

在接收到事务失败消息后，重复执行以下步骤，直至该分布式事务达到最大重试次数：

通过消息队列将订阅事件发送至第二分布式事务控制组件。

图7为本发明实施例中弱一致性模式下系统的架构及工作流图，可以整理出整个分布式业务处理的工作流为：

S1、服务编排向第一分布式事务控制组件发送开始分布式事务请求；第一分布式事务控制组件开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识，该全局事务标识可以是ID，之后调用第一事务状态记录组件，记录所述分布式事务的状态，此时的状态为初始状态，所述分布式事务的状态包括全局事务标识；同时接收服务编排提交的订阅事件；

S2、第一分布式事务控制组件通过消息队列将订阅事件发送至第二分布式事务控制组件；

S3、第二分布式事务控制组件接收到订阅事件后，调用第二事务状态记录组件，记录该分布式事务的状态；向业务服务发送订阅事件；

S4、第二分布式事务控制组件接收业务服务返回的变更事件；

S5、调用仓储服务将所述变更事件仓储持久化入数据库中；

S6、在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

另外，第二分布式事务控制组件在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；第一分布式事务控制组件在接收到事务失败消息后，重复执行以下步骤，直至该分布式事务达到最大重试次数：通过消息队列将订阅事件发送至第二分布式事务控制组件。

由于服务端通过消息队列将订阅事件发送至第二分布式事务控制组件时，消息队列包括全局事务标识。如果同一全局事务标识的消息发送多次，客户端确保按序执行，如果本地事务已经成功，则同一全局事务标识后续未执行的消息都不再执行，直接返回成功，以确保幂等性。

下面给出一具体实施例，来说明本发明实施例提出的系统的具体应用。

以银行系统常见的贷款账户放款到存款账户联机交易为例，事务配置模块实现的配置可以记录在事务配置表中，见表3。

表3

其中，放款交易涉及的主要业务流程包括占用额度、利率定价、贷款账户余额增加、存款账户余额增加、还款计划计算、交易流水记录等，可根据各自业务特点进行事务模式的配置：

额度是热点资源，需先占用成功才可执行后续流程，可选择强一致性模式，并配置冲正方法；

利率定价、贷款账户余额增加、存款账户余额增加之间一致性要求较高，在交易结束时需同时提交，未全部完成提交时中间状态对外不可见，因此，可以选择分机一致性模式，并配置对应消息队列名；

还款计划计算和交易流水记录的一致性要求较低，可以在交易结束后在后台异步更新，以降低交易的响应时间，开配置为弱一致性模式。

下面以分机一致性模式为例，对业务服务处理成功和业务服务处理失败为例进行介绍。

图8为本发明实施例中对分机一致性模式下业务服务处理成功时的系统执行流程图，该图中给出了2个业务服务处理的情况，具体步骤如下：

步骤1：服务编排接收到外部网关的请求(1)；

步骤2：服务编排应向服务端发送开启分布式事务请求(2)，第一分布式事务控制组件开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识，之后调用第一事务状态记录组件，记录所述分布式事务的状态，此时的状态为初始状态；

步骤3：服务编排向业务服务1和2推送订阅事件，之后服务编排调起业务服务1(3)，业务服务1完成处理后不直接提交本地事务，将产生的变更事件返回服务编排(4)；

步骤4：服务编排应调起业务服务2(5)，业务服务2完成处理后不直接提交本地事务，将产生的变更事件返回服务编排(6)；

步骤5：服务编排判断服务编排已完成，向第一分布式事务控制组件发送提交事务请求(7)，第一分布式事务控制组件将业务服务1和业务服务2返回的变更事件分别写入对应的消息队列MQ1和MQ2中，第一分布式事务控制组件调用第一资源管理组件对业务服务1处理的业务实体的标识进行加锁(8)，对业务服务2处理的业务实体的标识进行加锁(9)。

步骤6：服务编排返回结果给请求方(10)。客户端定期轮询从消息队列MQ1和MQ2中获取变更事件，调用仓储服务将所述变更事件仓储持久化入数据库中，当完成数据库更新后，第二分布式事务控制组件调用第二事务状态记录组件更新分布式事务的状态，调用第二资源管理组件对每个业务服务处理的业务实体的标识进行解锁(11)(12)，向第一分布式事务控制组件发送分布式事务完成消息，此时业务服务1和业务服务2的数据状态已经一致，第一分布式事务控制组件在接收到分布式事务完成消息后，调用第一事务状态记录组件更新分布式事务的状态。

图9为本发明实施例中对分机一致性模式下业务服务处理失败时的系统执行流程图，该图中给出了2个业务服务处理的情况，具体步骤如下：

步骤1：服务编排接收到外部网关的请求(1)；

步骤2：服务编排应向服务端发送开启分布式事务请求(2)，第一分布式事务控制组件开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识，之后调用第一事务状态记录组件，记录所述分布式事务的状态，此时的状态为初始状态；

步骤3：服务编排向业务服务1和2推送订阅事件，服务编排先调起业务服务1(3)，业务服务1完成处理后不直接提交本地事务，将本产生的变更事件返回服务编排(4)

步骤4：服务编排应调起业务服务2(5)，业务服务2处理时发生错误，此时业务服务2本地事务回滚，并将错误信息返回服务编排；

步骤5：服务编排应接收到业务服务2错误信息后(6)，会停止调用后续业务服务，向第一分布式事务控制组件发送回滚事务请求，第一分布式事务控制组件在接收到服务编排发送的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正(8)(9)，在接收到回滚事务请求后，向第二分布式事务控制组件发送清除事务状态信息。第二分布式事务控制组件在接收到清除事务状态信息后，调用第二事务状态记录组件清除分布式事务的状态，保证数据的一致性。最后，将错误信息返回给请求方(10)。此时业务服务1和业务服务2数据一致。

综上所述，在本发明实施例提出的系统中事务配置模块，使得业务服务可灵活地根据自身的业务特点和不同业务场景进行配置，配置后由服务端和客户端协调各服务实现数据一致性；服务端包括全局统一发号组件，实现了对分布式事务控制的统一，确保了幂等，进一步保证了分布式事务的数据一致性。

在此基础之上，实现了多种一致性模式，并提供各个业务服务独立配置，降低了分布式事务逻辑与业务逻辑的耦合，同时扩展性良好，通过为服务端和客户端定制更多的策略，即可提供更丰富的分布式事务模式。本发明可实现同一业务服务在不同交易场景下做不同的一致性模式配置，可实现动态地在运行时修改并应用业务服务的一致性模式。

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

Claims (12)

1.一种分布式事务的处理系统，其特征在于，包括：服务端、客户端和事务配置模块，其中，

事务配置模块，用于按照业务服务的应用场景对业务服务的业务服务名、业务服务方法名和事务模式的类型进行配置，所述事务模式的类型包括分机一致性模式、强一致性模式和弱一致性模式；

服务端包括第一分布式事务控制组件和全局统一发号组件，其中，

第一分布式事务控制组件，用于在接收服务编排的开始分布式事务请求后，开启分布式事务，调用全局统一发号组件，获得分布式事务的全局事务标识；根据分布式事务的全局事务标识、服务编排中业务服务的事务模式的类型，联合第二分布式事务控制组件，对分布式事务中已配置的业务服务进行控制；

全局统一发号组件，用于生成分布式事务的全局事务标识；

客户端包括：

第二分布式事务控制组件，用于基于全局事务标识，联合第一分布式事务控制组件，对分布式事务中已配置的业务服务进行控制。

2.如权利要求1所述的分布式事务的处理系统，其特征在于，服务端还包括第一资源管理组件，用于对业务服务处理的业务实体的标识进行加锁；

客户端还包括第二资源管理组件，用于对业务服务处理的业务实体的标识进行解锁。

3.如权利要求2所述的分布式事务的处理系统，其特征在于，服务端还包括第一事务状态记录组件，用于记录服务端的分布式事务的状态；

客户端还包括第二事务状态记录组件，用于记录客户端的分布式事务的状态。

4.如权利要求3所述的分布式事务的处理系统，其特征在于，服务端还包括RPC调用组件，用于调用业务补偿服务，对业务服务进行冲正。

5.如权利要求4所述的分布式事务的处理系统，其特征在于，事务配置模块具体用于：

若业务服务的事务模式的类型为强一致性模式，配置冲正方法名；

若业务服务的事务模式的类型为分机一致性模式，配置业务服务的消息队列名和冲正方法名，所述消息队列包括分布式事务的全局事务标识；

若业务服务的事务模式的类型为弱一致性模式，配置业务服务的消息队列名，所述消息队列包括分布式事务的全局事务标识。

6.如权利要求5所述的分布式事务的处理系统，其特征在于，若服务编排中业务服务的事务模式的类型为分机一致性模式，第一分布式事务控制组件具体用于：

在获得分布式事务的全局事务标识后，调用第一事务状态记录组件，记录所述分布式事务的状态，所述分布式事务的状态包括全局事务标识；

在接收到服务编排的提交事务请求后，将每个业务服务返回的变更事件分别写入对应的消息队列中，向服务编排发送通知信息，调用第一资源管理组件对每个业务服务处理的业务实体的标识进行加锁；

在接收到服务编排发送的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正；

在接收到分布式事务完成消息后，调用第一事务状态记录组件更新分布式事务的状态；

第二分布式事务控制组件具体用于：

从每个业务服务的消息队列中获得每个业务服务的变更事件，调用仓储服务将所述变更事件仓储持久化入数据库中；

在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态，调用第二资源管理组件对每个业务服务处理的业务实体的标识进行解锁；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

7.如权利要求6所述的分布式事务的处理系统，其特征在于，第二分布式事务控制组件还用于：

在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；

第一分布式事务控制组件还用于：

在接收到事务失败消息后，重复执行以下步骤，直至该分布式事务达到最大重试次数：

将每个业务服务返回的变更事件分别写入对应的消息队列中，向服务编排发送通知信息，调用第一资源管理组件对每个业务服务处理的业务实体的标识进行加锁。

8.如权利要求6所述的分布式事务的处理系统，其特征在于，第二分布式事务控制组件还用于：

拦截业务服务处理完成动作，调用第二事务状态记录组件记录分布式事务的状态；在接收到清除事务状态信息后，调用第二事务状态记录组件清除分布式事务的状态；

第一分布式事务控制组件还用于：在接收到回滚事务请求后，向第二分布式事务控制组件发送清除事务状态信息。

9.如权利要求5所述的分布式事务的处理系统，其特征在于，若服务编排中业务服务的事务模式的类型为强一致性模式，第一分布式事务控制组件具体用于：

在获得分布式事务的全局事务标识后，调用第一事务状态记录组件，记录该分布式事务的状态，所述分布式事务的状态包括全局事务标识；

在接收到服务编排的提交事务请求后，调用第二分布式事务控制组件，将每个业务服务返回的变更事件推送至第二分布式事务控制组件；

在接收到服务编排的回滚事务请求后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用RPC调用组件进行冲正；

第二分布式事务控制组件，具体用于：

调用仓储服务将每个业务服务返回的变更事件仓储持久化入数据库中；

在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

10.如权利要求9所述的分布式事务的处理系统，其特征在于，第二分布式事务控制组件还用于：

在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；

第一分布式事务控制组件还用于：

在接收到事务失败消息后，判断前向业务服务是否配置了冲正方法，若前向业务服务配置了冲正方法，调用业务补偿服务进行冲正。

11.如权利要求5所述的分布式事务的处理系统，其特征在于，若服务编排中业务服务的事务模式的类型为弱一致性模式，第一分布式事务控制组件具体用于：

在获得分布式事务的全局事务标识后，调用第一事务状态记录组件，记录所述分布式事务的状态，所述分布式事务的状态包括全局事务标识；

在接收到服务编排提交的订阅事件后，通过消息队列将订阅事件发送至第二分布式事务控制组件；

在接收到分布式事务完成消息后，调用事务状态记录组件更新分布式事务的状态；

第二分布式事务控制组件具体用于：

接收到订阅事件后，调用第二事务状态记录组件，记录该分布式事务的状态；

向业务服务发送订阅事件，接收业务服务返回的变更事件；

调用仓储服务将所述变更事件仓储持久化入数据库中；

在仓储持久化成功时，调用第二事务状态记录组件更新分布式事务的状态；向第一分布式事务控制组件发送分布式事务完成消息，所述分布式事务完成消息包括全局事务标识。

12.如权利要求11所述的分布式事务的处理系统，其特征在于，第二分布式事务控制组件还用于：

在仓储持久化失败时，调用第二事务状态记录组件更新分布式事务的状态，向第一分布式事务控制组件发送事务失败消息，所述事务失败消息包括全局事务标识；

第一分布式事务控制组件还用于：

在接收到事务失败消息后，重复执行以下步骤，直至该分布式事务达到最大重试次数：

通过消息队列将订阅事件发送至第二分布式事务控制组件。

Images