分布式事务详解

1. XA 事务

   • 这个唯一一个强一致的事务，效率最低，全局事务执行过程中，任意子事务可提交阶段都只能等待，一直到所有子事务都走到这个节点才能一起提交。因为没有单独的提交，可见性依赖于数据库的可见性，可以避免脏读问题。

   • 总结：强一致性，效率低，和依赖数据库实现XA协议,是强一致性的不二选择。

2. AT 事务

   • 执行阶段：AT事务理论很简单，事务开启的时候生成一个全局事务ID，远程调用的时候带过去，全局事务Id一样的加入到一个事务组，有事务协调者管理，每个子事务执行完成就独立的提交了，锁也释放了，但是执行的过程自动记录了undo日志，undo日志里面记录反向的补偿操作，执行undo操作可以让数据回到和没有执行这个事务的时候等价的状态。

   • 执行成功：如果这个分布式事务组里面的所有事务都正常提交，那么久删除各自数据里面undo日志。

   • 执行失败：如果分布式事务组里面有任意一个事务执行失败，那么久对已经执行成功的执行undo之日里面的反向补偿。

   • 总结：锁的粒度低，使用方便，依赖seata的统一undo操作，编程简单，但是统一undo可能没有明确的cancel操作效率高，但是也省下了预留资源的操作。能接受中间状态选这个。

3. TCC事务

   • 需要注意的点：对三个方法都默认不是用事务的方式执行,如果不是事务方式执行，那么 后面 cancel 阶段 就很难做（不知道try 阶段做了那些已经写入成功），所以try 接单需要在事务环境执行，confirm 和 cancel 的幂等也比较难做，所以建议一定要加上事务注解

   • TCC的try阶段一定要检查资源，并且预留资源，confirm阶段不会在检查资源，只会直接从预留中扣除。这是TCC事务的最基本的要求。

   • try 执行有失败有3中情况

     1. 有一种特殊的情况，try正在执行，然后超时触发了cancel回滚，然后try事务提交了，但是它已经永远等不到事务管理中心来调用它的二阶段，这个try里面的内容永远悬挂起来了(悬挂问题)，这时候需要在try前判断 cancel是否被执行.
        --备注:confirm不会有悬挂的问题，因为只有所有try都成功才会 调用confirm，程序里面有个远程成功的肯定是成功，失败的不一定失败，try失败走cancel，不一定是try没有正常执行。confirm的时候一定是try 已经成功。

     2. try 阶段失败了，这时候如果在事务环境，那么就回滚了，cancel阶段判断到try是没有执行完成，那么直接什么都不做(空回滚问题)

     3. try 阶段完成了，这时候try的预留资源已经写到数据库，try事务提交，预留资源已经可见，但是真实资源还没有修改。如果事务组里面别的try执行失败，导致本事务cancel 执行，获取到本事务try执行成功，cancel 里面做try相关的undo操作

   • confirm 阶段的2中种情况

     1. confirm 执行成功，事务直接提交

     2. confirm 执行失败，这时候只能无限重试，所以confirm必须实现幂等，并且confirm 必须有事务环境（保证即便失败也是失败的干干净净）。

   • cancel节点

     1. cancel 执行成功，事务完成回滚

     2. cancel 执行失败，冻结资源没有释放，只能无限重试，所以confirm必须是幂等的，必须有事务环境事务环境的(重试的时候如果前面回滚了一般很麻烦，幂等比较难做)，

关于confirm和cancel seata-server会在数据库里面记录这个事务的状态，等程序可用的时候还是会无限重试，
            seata重启会删除已经完结的事务状态，没完成的继续重试

总结：锁的粒度低，但是编程复杂，需要考虑幂等性，悬挂，空回滚，等问题。然后人工写，效率可能比较高，也容易错。然后就是可见性方面的数据隔离和脏读问题比AT好，在confirm阶段也存在脏读问题，不是太明显的有点，有这需求的直接上XA。

5. TCC 和 AT 的区别

   • 都是全局事务，都是2阶段事务，他们锁的粒度都比XA小，没有全事务的过程都锁定数据库记录，事务都是执行完就提交，依赖undo操作对冲，而不是数据库的回滚

   • 我们可以认为 AT 事务把TCC的try和confirm阶段做的事情合一了，并且自动生成了对应的undo日志来代替 cancel回滚

   • 执行阶段的区别:因为 try 和 confirm 合一了，所以不需要预留资源，缺点是中间状态的时间变长(AT事务提交以后就可见了，TCC try以后只有预留资源可见，真实资源还没动)，TCC也存在 部分confirm 的时候的可见性问题，但是confirm阶段不会在回滚，所以不是脏读，只是中间状态，AT事务过程中的数据除了中间状态可见以外，还有回滚带来的脏读问题。

   • 回滚阶段的区别：AT的 undo日志和 TCC 的 cancel 方法是对应，都是回滚的时候回收资源，AT 的 undo是自动的，简单方便，但是通用的 回盾考虑的东西比较多，效率可能比 明确逻辑手动写的cancel 低。TCC 和 AT 的区别 ，都是全局事务，都是2阶段事务，他们锁的粒度都比XA小，没有全事务的过程都锁定数据库记录，事务都是执行完就提交，依赖undo操作对冲，而不是数据库的回滚

6. SAGA事务

7. 一般mq的事务

8. rocketMQ的预消息事务

9. 不支持事务消息的mq方式的事务

10. 其他全局事务框架 LCN