分布式事务有哪些解决方案 ？

分析&回答

什么是分布式事务

• 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
• 分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务必须产生一致的结果（全部提交或全部回滚）

常见的分布式事务解决方案

1、基于XA协议的两阶段提交 (强一致性)

XA是X/Open DTP组织定义的两阶段提交协议，XA模型包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

XA优劣

• 效率低下，准备阶段的成本持久，全局事务状态的成本持久，性能与本地事务相差10倍左右；
• 提交前，出现故障难以恢复和隔离问题。
• 作用于资源层，对业务几乎没有侵入

2、消息事务 + 最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作。A系统中消息事务保证要么本地操作和对外发消息同时成功，要么两者都失败。B系统的操作由消息驱动，如果 B本地操作失败，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。原理如下：

消息事务优劣

• 如果B一直执行不成功，那么一致性会被破坏。
• 基于消息中间件的两阶段提交往往用在高并发场景下。

3、TCC补偿模式 + 最终一致性

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。

• a) Try 阶段主要是对业务系统做检测及资源预留。这个阶段主要完成：
  • 完成所有业务检查( 一致性 ) 。
  • 预留必须业务资源( 准隔离性 ) 。
  • Try 尝试执行业务。
• b) Confirm 阶段主要是对业务系统做确认提交。Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
• c) Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。

TCC优劣

• 需要实现确认和补偿逻辑、需要支持幂等，都是通过代码人为实现，不能很好地被复用，业务耦合度较高，提高了开发成本。
• 性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
• 数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
• 可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

反思&扩展

TCC 分布式事务解决方案适用于执行时间确定且较短的业务，比如互联网金融企业最核心的三个服务：交易、支付、账务。

具体用哪种方式，最终还是取决于业务场景。针对不同业务进行技术选型也是一种很重要的能力！

扩展思考

• XA 事务和 TCC 的区别？
• 如果让你优化XA，你会如何优化？
• 什么是TCC，它的工作过程？