数据库事务方案（2PC/XA）
https://blog.csdn.net/define_us/article/details/83184753
是唯一一个两阶段提交不能解决的困境是：当协调者在发出commit T消息后宕机了，而唯一收到这条命令的一个参与者也宕机了，这个时候这个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他节点也最终也会收到commit T的信息。
TCC方案
显然执行者需要至少执行三个接口。
一般而言，协调者的决策可以让事务的一个参与方进行。但是，一般大公司都会采用单独的协调者，即提供单独应用作为事务服务。
空回滚
所谓空回滚，是指并没有收到try，就要进行cancel操作
事务悬挂问题
表示先收到cancel，在收到try
总结
TCC特别适合在电商场景。用户支付先完成自己的事务，付款
最大努力通知
本地消息表
本地消息表其实就是利用了 各系统本地的事务来实现分布式事务。
本地消息表顾名思义就是会有一张存放本地消息的表，一般都是放在数据库中，然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中，这样就能保证消息放入本地表中业务肯定是执行成功的。
然后再去调用下一个操作，如果下一个操作调用成功了好说，消息表的消息状态可以直接改成已成功。
如果调用失败也没事，会有 后台任务定时去读取本地消息表，筛选出还未成功的消息再调用对应的服务，服务更新成功了再变更消息的状态。
消息事务
