分布式事务

个人理解： 分布式事务一般有两种方案解决，一个是在数据库层面，锁住全局事务；一起提交一起回滚，就是AT模式

一种是业务层面的，提供业务接口，单据有一个中间状态接口，一起提交，一起回滚也是业务接口；

对于事务中可能出现网络终端导致某一条分支丢失的情况，我们可以用日志的形式进行补偿等；

Seata也是采取每个微服务的一阶段提交拿到全局锁，但是回滚是通过日志回滚；

1. 事务的模式: XA、AT、TCC、Saga、本地消息表、MQ消息事务、最大努力通知
   1. XA、
      1. 。XA 的全称是eXtended Architecture，它是一个分布式事务协议，它通过二阶段提交协议保证强一致性
      2. 基于XA协议实现的分布式事务是强一致性的分布式事务，典型应用场景如JAVA中有关分布式事务的规范如JTA（Java Transaction API）和JTS（Java Transaction Service）中就涉及到了XA
   2. AT、(automic transaction) 基于xa演化而来（针对关系型数据库，redis是不支持的）
      1. AP（Application Program，应用程序）
      2. RM（Resource Manager，资源管理器）
      3. TM（Transaction Manager，事务管理器）：TM能与AP和RM直接通信，协调AP和RM来实现分布式事务的完整性。负责管理全局事务，分配全局事务标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
   3. TCC、(try commit cancel)（对数据库类型没有要求，因为是业务的）
   4. Saga、()
      1. Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
   5. 本地消息表、
   6. MQ消息事务、
   7. 最大努力通知
2. 这些模式的实现
   1. Seata（Simple Extensible Autonomous Transaction Architecture，一站式分布式事务解决方案）对业务无侵入
      1. Transaction Coordinator（TC）
      2. 一阶段提交事务，同事提交undo日志
      3. 二阶段提交成功则删掉undo日志，回滚则执行undo日志。他这个这个undo日志是根据修改前的数据生成的
      4. Tc独立于业务系统存在就是为了可以高可用；集群部署
   2. 其他