分布式事务模式：AT、TCC、Saga、XA模式

AT模式

2PC使用二阶段提交协议：Prepare提交事务请求，

我认为就是执行分布式的方法，当所有方法都执行完毕，且没有错误，也就是ack为yes。然后开始第二阶段：

commit:提交事务

TCC模式和消息队列模式：

都是以try、confirm、cancel，就和java的异常处理非常相似，如果这个服务的方法发生异常，就执行cancel，回滚事务，如果正常就执行confirm提交方法。也就是说，在这两个模式都需要手动完成回滚的业务逻辑，菜逼表示，太难了啊！！

消息队列则是通过消费消息，一旦执行分布式方法失败，、发生异常，机会发出一个异常消息，消费者读取消息，然后回滚。也就是说，每调用一个分布式方法，都需要监听一个失败队列。

Saga方式就是流水式：

可以把调用方法看做是一条流水线，中间有一个出错后，一个一个的往后回滚，

需要一个状态机，同一管理事务，而且每一个都需要程序员自己实现，很复杂。

XA模式：

这种模式就很好理解，只要各个服务用的是相同的数据库，因为数据库已经实现了分布式事务处理标准

例如mysql，在执行一个分布式事务时：

1. A服务执行完毕后，会将这次执行的数据暂存起来，等待XA的提交命令。
2. B服务也执行完毕后，XA就会给AB服务发送提交事务命令，
3. 这个时候AB服务就会把刚才执行语句产生的数据提交到数据库中。

也就是说，A服务执行完毕，还未提交时，我们是无法看见这次执行产生的数据的。

如果在后续服务执行过程中发生错误，XA就会给所有服务发送回滚命令。