[发明专利]分布式事务的处理系统

说明书

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

技术领域

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

背景技术

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

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

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

一是，两阶段提交(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方案主要缺点：没有提供事务的隔离性保证：每个子事务依次提交，此时另外一个交易查询到该资源时会读到中间过程的数据，这样如果同时操作同一个资源，可能导致操作覆盖、脏数据等问题。