3.3 方案总结
优点
xxxxxxxxxx 相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。
缺点
xxxxxxxxxx 数据不一致问题依然存在，当在参与者收到preCommit请求后等待do commite指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
4 TCC
4.1 方案简介
TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
TCC是服务化的二阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现，基本类似两阶段提交
Try操作作为一阶段，负责资源的检查和预留。
Confirm操作作为二阶段提交操作，执行真正的业务。
Cancel是预留资源的取消。
TCC事务的Try、Confirm、Cancel可以理解为SQL事务中的Lock、Commit、Rollback。
TCC 为在业务层编写代码实现的两阶段提交。TCC 分别指 Try、Confirm、Cancel ，一个业务操作要对应的写这三个方法。
Github 上有诸多具体的实现，例如 https://github.com/changmingxie/tcc-transaction
4.2 处理流程
为了方便理解，下面以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建2个步骤，库存服务和订单服务分别在不同的服务器节点上。
4.2.1 阶段1：Try 阶段
从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：
完成所有业务检查( 一致性 )
预留必须业务资源( 准隔离性 )
Try 尝试执行业务 TCC事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。
假设商品库存为100，购买数量为2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。
4.2.2 阶段2：Confirm / Cancel 阶段
根据Try阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。 Confirm和Cancel操作满足幂等性，如果Confirm或Cancel操作执行失败，将会不断重试直到执行完成。
Confirm：确认
当Try阶段服务全部正常执行， 执行确认业务逻辑操作
这里使用的资源一定是Try阶段预留的业务资源。在TCC事务机制中认为，如果在Try阶段能正常的预留资源，那Confirm一定能完整正确的提交。Confirm阶段也可以看成是对Try阶段的一个补充，Try+Confirm一起组成了一个完整的业务逻辑。
Cancel：取消
当Try阶段存在服务执行失败， 进入Cancel阶段
Cancel取消执行，释放Try阶段预留的业务资源，上面的例子中，Cancel操作会把冻结的库存释放，并更新订单状态为取消。
4.3 方案总结
TCC事务机制相对于传统事务机制（X/Open XA），TCC事务机制相比于上面介绍的XA事务机制，有以下优点:
性能提升 具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
数据最终一致性 基于Confirm和Cancel的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
可靠性 解决了XA协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点：
TCC的Try、Confirm和Cancel操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
5 本地消息表
5.1 方案简介
本地消息表的方案最初是由ebay提出，核心思路是将分布式事务拆分成本地事务进行处理。
方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。
这样设计可以避免”业务处理成功 + 事务消息发送失败“，或”业务处理失败 + 事务消息发送成功“的棘手情况出现，保证2个系统事务的数据一致性。
5.2 处理流程
下面把分布式事务最先开始处理的事务方成为事务主动方，在事务主动方之后处理的业务内的其他事务成为事务被动方。
为了方便理解，下面继续以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建2个步骤，库存服务和订单服务分别在不同的服务器节点上，其中库存服务是事务主动方，订单服务是事务被动方。
事务的主动方需要额外新建事务消息表，用于记录分布式事务的消息的发生、处理状态。
整个业务处理流程如下：
步骤1 事务主动方处理本地事务。 事务主动方在本地事务中处理业务更新操作和写消息表操作。 上面例子中库存服务阶段在本地事务中完成扣减库存和写消息表(图中1、2)。
步骤2 事务主动方通过消息中间件，通知事务被动方处理事务通知事务待消息。 消息中间件可以基于Kafka、RocketMQ消息队列，事务主动方法主动写消息到消息队列，事务消费方消费并处理消息队列中的消息。 上面例子中，库存服务把事务待处理消息写到消息中间件，订单服务消费消息中间件的消息，完成新增订单（图中3 - 5）。
步骤3 事务被动方通过消息中间件，通知事务主动方事务已处理的消息。 上面例子中，订单服务把事务已处理消息写到消息中间件，库存服务消费中间件的消息，并将事务消息的状态更新为已完成(图中6 - 8)
为了数据的一致性，当处理错误需要重试，事务发送方和事务接收方相关业务处理需要支持幂等。具体保存一致性的容错处理如下：
1、当步骤1处理出错，事务回滚，相当于什么都没发生。
2、当步骤2、步骤3处理出错，由于未处理的事务消息还是保存在事务发送方，事务发送方可以定时轮询为超时消息数据，再次发送的消息中间件进行处理。事务被动方消费事务消息重试处理。
3、如果是业务上的失败，事务被动方可以发消息给事务主动方进行回滚。
4、如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚。
5.3 方案总结
方案的优点如下：
从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对MQ中间件特性的依赖。
方案轻量，容易实现。
缺点如下：
与具体的业务场景绑定，耦合性强，不可共用。
消息数据与业务数据同库，占用业务系统资源。
业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限
6 MQ事务
MQ事务保证最终一致性。
6.1 方案简介
基于MQ的分布式事务方案其实是对本地消息表的封装，将本地消息表存于MQ 内部，其他方面的协议基本与本地消息表一致。
6.2 处理流程
下面主要基于RocketMQ4.3之后的版本介绍MQ的分布式事务方案。
在本地消息表方案中，保证事务主动方发写业务表数据和写消息表数据的一致性是基于数据库事务，RocketMQ的事务消息相对于普通MQ，相对于提供了2PC的提交接口，方案如下：
6.2.1 正常情况——事务主动方发消息
这种情况下，事务主动方服务正常，没有发生故障，发消息流程如下：
1、发送方向 MQ服务端(MQ Server)发送half消息。
2、MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功。
3、发送方开始执行本地事务逻辑。
4、发送方根据本地事务执行结果向 MQ Server 提交二次确认（commit 或是 rollback）。
5、MQ Server 收到 commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 rollback 状态则删除半消息，订阅方将不会接受该消息。
6.2.2 异常情况——事务主动方消息恢复
在断网或者应用重启等异常情况下，图中第4步提交的二次确认超时未到达 MQ Server，此时处理逻辑如下：
5、MQ Server 对该消息发起消息回查。
6、发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
7、发送方根据检查得到的本地事务的最终状态再次提交二次确认
8、MQ Server基于commit / rollback 对消息进行投递或者删除
介绍完RocketMQ的事务消息方案后，由于前面已经介绍过本地消息表方案，这里就简单介绍RocketMQ分布式事务：
事务主动方基于MQ通信通知事务被动方处理事务，事务被动方基于MQ返回处理结果。 如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等。 如果是事务被动方业务上的处理失败，可以通过MQ通知事务主动方进行补偿或者事务回滚。
6.3 方案总结
相比本地消息表方案，MQ事务方案优点是：
消息数据独立存储 ，降低业务系统与消息系统之间的耦合。
吞吐量优于使用本地消息表方案。
缺点是：
一次消息发送需要两次网络请求(half消息 + commit/rollback消息)
业务处理服务需要实现消息状态回查接口
