两阶段提交（2PC）
XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定义的TM（Transaction Manager）与RM（Resource Manager）之间进行通信的接口。
在XA规范中，数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务。
二阶段提交是XA的标准实现。它将分布式事务的提交拆分为2个阶段：prepare和commit/rollback。
2PC模型中，在prepare阶段需要等待所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发高以及子事务生命周长较长的业务场景。两阶段提交这种解决方案属于牺牲了一部分可用性来换取的一致性。
补偿事务（TCC）
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC模型是把锁的粒度完全交给业务处理。它分为三个阶段：
Try 阶段主要是对业务系统做检测及资源预留
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
汇款服务和收款服务分别需要实现，Try-Confirm-Cancel接口，并在业务初始化阶段将其注入到TCC事务管理器中。、
由此可以看出，TCC模型对业务的侵入强，改造的难度大。
本地消息表（异步确保）
本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：
基本思路就是：
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
尽最大努力通知
最大努力通知方案主要也是借助MQ消息系统来进行事务控制，这一点与可靠消息最终一致方案一样。看来MQ中间件确实在一个分布式系统架构中，扮演者重要的角色。最大努力通知方案是比较简单的分布式事务方案，它本质上就是通过定期校对，实现数据一致性。
最大努力通知方案的实现
业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知。
主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息。
业务活动的被动方如果正常接收了数据，就正常返回响应，并结束事务。
如果被动方没有正常接收，根据定时策略，向业务活动主动方查询，恢复丢失的业务消息
最大努力通知方案的特点
1、用到的服务模式：可查询操作、幂等操作。
2、被动方的处理结果不影响主动方的处理结果；
3、适用于对业务最终一致性的时间敏感度低的系统；
4、适合跨企业的系统间的操作，或者企业内部比较独立的系统间的操作，比如银行通知、商户通知等；
案例：
eBay 本地消息表
本地消息表这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。
举个经典的跨行转账的例子来描述。第一步，扣款1W，通过本地事务保证了凭证消息插入到消息表中。第二步，通知对方银行账户上加1W了。那问题来了，如何通知到对方呢？
通常采用两种方式：
采用时效性高的MQ，由对方订阅消息并监听，有消息时自动触发事件
采用定时轮询扫描的方式，去检查消息表的数据。
类似使用本地消息表+消息通知的还有去哪儿，蘑菇街
各种第三方支付回调
最大努力通知型。如支付宝、微信的支付回调接口方式，不断回调直至成功，或直至调用次数衰减至失败状态。
我们可以怎么来做
2PC/3PC需要资源管理器(mysql, redis)支持XA协议，且整个事务的执行期间需要锁住事务资源，会降低性能。故先排除。
TCC的模式，需要事务接口提供try,confirm,cancel三个接口，提高了编程的复杂性。需要依赖于业务方来配合提供这样的接口。推行难度大，暂时排除。
最大努力通知型，应用于异构或者服务平台当中
可以看到ebay的经典模式中，分布式的事务，是通过本地事务+可靠消息，来达到事务的最终一致性的。但是出现了事务消息，就把本地事务的工作给涵盖在事务消息当中了。所以，接下来要基于事务消息来套我们的应用场景，看起是否满足我们对分布式事务产品的要求。
