两阶段提交
XA模式
两阶段提交，三阶段提交，需要数据库本身支持
两阶段提交
1、准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回 失败(如权限验证失败)，要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交，到达一 种“万事俱备，只欠东风”的状态。
2、提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则， 发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过 程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
AT 模式（这里用seate的AT模式来讲）
XA模式和AT模式的主要区别在于 AT模式在准备阶段就会提交本地事务，释放本地锁，而XA模式在准备阶段不会提交事务，也就不会释放本地锁，性能比较差
写隔离
一阶段本地事务提交前，需要确保先拿到 全局锁 。
拿不到 全局锁 ，不能提交本地事务。
拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
本地事务提交前，需要拿到 全局锁
提交本地事务后，会释放 本地锁但是会保留全局锁（其他的线程可用对本地事务进行操作）
当需要回滚的时候，需要对比 UndoLog表中的数据 和 当前数据库数据，如果不一致，需要进行人工操作。 CAS操作，如果不一致，就说明有其他事务修改了表中的数据
提交机制
回滚机制
当提交成功后，需要删除另外创建的表中的数据
branch、 global、Lock
两阶段提交的问题：
1.单点故障，事务管理器宕机
2.数据不一致，发送的commit事件，并没有全部的参与者都受到，导致事务不一致
3.相应时间较长
三阶段提交
解决了 两阶段的单点故障
三阶段也存在问题
当第三阶段 Docommit 要返回false的时候,TM宕机，这时候 RM会提交事务
TCC
TCC，基于业务层面实现，不需要数据库支持
try commit cancel 这三个单词的缩写
Try阶段，进行扣减，然后加一个标志位，（支持资源预留和中间状态）标定还在 try 阶段
基于消息队列+本地消息表
一半需要消息队列的支持，且需要保证幂等性
本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。
-
在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
-
之后将本地消息表中的消息转发到消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
-
在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。
注意点：单纯的保证消息 百分百发送 和百分百消费，存在问题，如果当执行完写入业务数据后，机器宕机，这时候会导致数据已经写入，但是消息并没有发送，所以需要讲 业务数据的写入和本地消息表的写入放在同一个事务里面，可以采用Mysql实现
如果消息一直消费不成功，可以转 死信队列让人工处理
