1、XA方案(即两阶段提交方案)

有一个事务管理器，负责协调多个数据库的事务，先询问各个数据库prepare好了吗，如果都回复ok，就正式提交事务，否则回滚事务。此方案可基于spring+JTA+atomikos可以实现，但效率低，严重依赖数据库层面来完成，适合单应用多库连接，微服务一般不会直连库，不适合

2、TCC方案(Try-Confirm-Canel)

Try阶段：对资源锁定或预留
Confirm阶段：在各个服务中执行实际的操作
Canel阶段：如果任何一个服务执行出错，进行补偿，就是执行成功的需回滚
此方案需要自己手写回滚逻辑，业务代码难以维护

3、本地消息表

A系统在本地事务操作同时，插入一条数据到消息表，然后将消息发送到MQ中去，B系统接收到消息后，在本地消息表中插入一条数据(数据有唯一约束，避免重复执行)，然后执行业务操作。靠A系统的消息表和B系统的消息表保证数据一致性。此方案严重依赖数据库的消息表来管理事务，无法应对高并发场景

4、可靠消息最终一致性方案

直接基于MQ来实现事务，如阿里的RocketMQ就支持消息事务，此方案是大公司的流行做法，可以考虑此方案

5、最大努力通知方案

系统A事务执行成功后，把消息放进MQ，然后由专门消费MQ的最大努力通知服务处理，它会先写入到数据库或内存队列，接着调用系统B接口，如果系统B执行失败，就尝试重新调用系统B，反复N次，还是不行就放弃

金额操作使用TCC可保证强一致性，其它场景可基于阿里的RocketMQ来实现分布式事务

最后

以上就是神勇小蜜蜂为你收集整理的分布式事务实现的5种方案1、XA方案(即两阶段提交方案)2、TCC方案(Try-Confirm-Canel)3、本地消息表4、可靠消息最终一致性方案5、最大努力通知方案的全部内容，希望文章能够帮你解决分布式事务实现的5种方案1、XA方案(即两阶段提交方案)2、TCC方案(Try-Confirm-Canel)3、本地消息表4、可靠消息最终一致性方案5、最大努力通知方案所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。