分布式事务方案总结

事务的不同操作位于不同节点上，需要保证事务的ACID特性。

1、2PC

两阶段提交Two-phase Commit，2PC，通过引入协调者来协调参与者的行为。并最终决定参与着是否要真正执行事务。

1. 准备阶段：协调者给每个参与者发送prepare消息，参与者事务执行失败返回失败，或执行本地事务，写本地的redo和undo日志但是不提交，参与者回发事务执行结果。
2. 提交阶段：如果每个参与者上事务都执行成功，事务协调者发出通知让参与者提交事务，否则发送通知回滚事务。
   存在问题：
   ● 同步阻塞：所有事务参与者在等待其他事务参与者响应是都处于阻塞状态
   ● 单点问题：协调者作用非常大，故障会导致很大影响
   ● 数据不一致，在阶段二提交信息只发送一部分会导致数据不一致
   ● 太过保守，一个节点失败导致整个事务失败，容错性能差

3PC：

2PC的改进，参与者与协调者都设置了超时事件，二2PC只有协调者有超时机制。解决了协调者挂掉的情况下参与者无法释放资源的问题。并多设置了一个缓冲阶段保证了最后提交阶段之前各参与节点状态一致。还是没有完全解决数据不一致问题。
1、 CanCommit阶段：协调者向参与者发送CanCommit请求，询问事务是否可以执行；参与者收到请求，尝试获取数据库锁，获取到返回yes并进入预备状态，否则NO
2、 PreCommit阶段：所有参与者返会Yes，进入此阶段进行事务预提交。与2PC第一阶段差不多。区别是此处协调者与参与者都引入超时机制。
3、 DoCommit阶段：与2PC第二阶段差不多。每个参与者执行成功，协调者通知所有参与者提交任务。
2、补偿事务TCC try-confirm-cancel
TCC采用补偿机制，核心思想是针对每个操作，都要注册一个与其相对应的确认和补偿即撤销的操作，分为三个阶段：
1、 Try阶段对服务的资源做检测，对资源进行锁定或预留
2、 Confirm阶段在各个服务中执行实际操作
3、 Cancel阶段：如果任何一个服务的业务方法执行出错，进行补偿，即回滚成功的业务。
一致性强。缺点业务代码难维护，手写回滚逻辑。

3、本地消息表

本地消息表与业务数据表处于同一个数据库中，利用本地事务来保证对这两个表的操作满足事务特性。并使用消息队列保证最终一致性。
1、 消息生产方需要建立本地消息表，记录消息发送状态。消息表和业务数据要在一个事务里提交。接着将消息发送到MQ。
2、 消息消费方接收消息，向本地消息表插入消息数据，并处理这个消息并完成业务逻辑，若处理过了此事务则回滚保证不会重复执行。此时如果本地事务处理成功，则更新本地消息表状态和发送方消息表状态。若是业务上失败，可以给生产方发送一个业务补偿消息，通知生产方回滚。
3、 生产方和消费方定时扫描本地消息表，吧还没处理完成或失败的消息再发送一遍。
实现了分布式事务的最终一致性。消息接收方失败了，发送方会不断重发直到成功。

4、可靠消息最终一致性方案

基于MQ实现事务，如RocketMQ支持消息事务。
1、 系统A发送prepared消息到MQ，发送失败则直接取消操作。
2、 prepared成功发送，系统A执行本地事务，执行成功则向MQ发送confirm信息，失败则发送回滚信息。
3、 A发送confirm信息，MQ则让B系统消费到这条信息，执行本地事务。
4、 MQ没有收到confirm的情况，定时轮询prepared信息回调接口，询问消息时回滚还是重新发送确认。
5、 系统B事务执行失败则继续重试。B中保证幂等性（可以使用redis或Zookeeper