分布式事务

2PC（数据库层面的）
将整个事务分为两阶段，准备阶段、提交阶段。
准备阶段：事务管理器给每个参与者发送prepare消息，每个数据库参与者在本地执行事务，并写本地Undo/Redo日志，此时事务还没提交。
提交阶段：事务管理者接收到了参与者执行成功或者失败、超时的消息，直接给所有参与者发送回滚消息，否则发送提交消息，参与者提交或者回滚事务Commit。
注意：在没提交之前，会出现锁住资源的情况，其次就是协作者出现故障，在恢复之前执行者会出现阻塞。

3PC
基于2PC，引入的超时机制，协调者和执行者都有超时机制。在第一阶段和第二阶段中间新增了一个阶段，保证了最后提交阶段之前参与的节点状态是一致的。
协调者在执行Prepare之前发送，询问是否可以执行事务提交操作，如果可以返回给协调者Yes。
如果协调者在指定时间内没收到其中一个参与者的消息，那么将会给其他参与者发送中断事务。

XA（标准接口）制定的分布式协议。
XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚
AT模式
参考：https://www.cnblogs.com/linchenguang/p/13887010.html#/c/subject/p/13887010.html

Seata
性能较好，不长时间占用连接资源
正常提交场景：

异常提交

摘自某课学院。

TCC 是Try（业务检查和资源预留）、Confirm（业务确认操作）、Cancel（和try相反的操作及回滚操作）。

try 做业务检查及资源预留。
confirm 确认提交，如果分支事务执行try成功，如果confirm执行异常，那么默认执行重试机制，或者人工介入。
cancel 在业务执行出错的情况下执行分支事务的取消，预留资源释放，如果cance执行出错，默认是会重试，或者人工介入的。

TCC在实际开发中出现的问题
没有执行try方法，却执行了cancel方法-空回滚，解决方法：添加分支事务表，执行了往分支事务表中写数据，cancel执行的时候检查一下。
重复执行，导致数据不一致-幂等，往往是由于超时重试导致的。
cancel比try先执行-悬挂，rpc请求出现了网络拥塞，cancel请求先到达。