[发明专利]一种分布式事务最终一致性处理方法及装置

说明书

本发明公开了一种分布式事务最终一致性处理方法及装置，包括步骤S1，在事件定义，事件流程节点定义和发布订阅关系过程中创建补偿通道；步骤S2，在运行阶段，通过切面技术在事件流程节点执行过程中根据执行结果自动上报当前节点执行结果，采用接口幂等技术对所述事件流程节点进行重试补偿，以达到事务最终一致性。该基于事件补偿机制的数据最终一致性办法，不仅降低了配置的技术难度，减少了最终用户的配置的工作量，还保证了发送事件与业务数据的事务一致性，保证了事件数据不会丢失；同时，在运行阶段实现了业务和事务控制的分离，灵活高效，自动化程度高，适宜推广应用。

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式事务最终一致性处理方法及装置。

背景技术

IT系统架构向高性能、高可用、高伸缩方向发展导致微服务技术的广泛应用，在微服务架构下分布式事务场景大量出现，如电商、ERP、物流系统等领域广泛存在。

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。

现有的常用的分布式事务的解决方案有：第一种（如附图1）是两阶段提交协议，通过引入协调者来协调参与者的行为，并最终决定这些参与者是否要真正执行事务，包括阶段一:开始向事务涉及到的全部资源发送提交前信息。此时，事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务，则整个事务取消，不会进行资源的更新。否则，事务将正常执行，除非发生灾难性的失败。为了防止会发生灾难性的失败，所有资源的更新都会写入到日志中。这些日志是永久性的，因此，这些日志会幸免于难并且在失败之后可以重新对所有资源进行更新。阶段二:只在阶段一没有异常结束的时候才会发生。此时，所有能被定位和单独控制的资源管理器都将开始执行真正的数据更新。在分布式事务两阶段提交协议中，有一个主事务管理器负责充当分布式事务协调器的角色。事务协调器负责整个事务并使之与网络中的其他事务管理器协同工作。为了实现分布式事务，必须使用一种协议在分布式事务的各个参与者之间传递事务上下文信息，IIOP便是这种协议。这就要求不同开发商开发的事务参与者必须支持一种标准协议，才能实现分布式的事务。

存在的问题是：1、同步阻塞，所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其他操作。2、单点问题，协调者在这两个阶段中起到非常大的作用，发生故障将会造成很大影响，特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其他操作。3、数据不一致，在阶段二，如果协调者只发送了部分commit消息，此时网络发生异常，那么只有部分参与者接收到commit消息，也就是说只有部分参与者了提交了事务，使得系统数据不一致。4、太过保守，任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

第二种是补偿事务，采用补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：1）try阶段主要是对业务系统做检测及资源预留；2）confirm阶段主要是对业务系统做确认提交，try阶段执行成功并开始执行confirm阶段时，默认confirm阶段是不会出错的。即：只要try成功，confirm一定成功。3）cancel阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。例如，假设甲要向乙转账，思路大概是：我们有一个本地方法，里面依次调用。首先在try阶段，要先调用远程接口把甲和乙的钱给冻结起来。然后在confirm阶段，执行远程调用的转账操作，转账成功进行解冻。最后，如果第二步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解决方法。存在的问题是第二步和第三步都有可能失败，补偿事务属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用事务补偿不太好定义处理。