基于XA的两阶段提交
XA协议由Tuxedo首先提出，交给X/Open组织，作为资源管理器(DB)与事务管理器的接口标准。目前，大部分数据库厂商都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。
两阶段提交，对业务侵入很小，他最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务，能够严格保障事务ACID特性。
第一阶段：事务管理器要求每个涉及到事务的数据库(资源管理器)预提交sql操作(完成基本sql语句，但是不会提交)，并反应是否可以进行提交。
第二阶段：事务管理器确认每个参与者(资源管理器)都ready后，通知参与者进行commit操作，如果有参与者fail，则发送rollback命令，各个参与者回滚。
问题
- 单点故障：一旦事务管理器出现故障，整个系统不可用（参与者都会阻塞）
- 数据不一致：在阶段二，如果事务管理器只发送了部分commit消息，此时网络发生异常，那么只有部分参与者接收到了commit消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
- 响应时间较长：参与者和事务管理器都被锁住，提交或者回滚之后才能释放
- 不确定性：当事务管理器发送commit之后，并且此时只有一个参与者收到了commit，那么当该参与者和事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。
三阶段协议：主要是针对两阶段的优化，解决了2PC单点故障的问题，但是性能问题和不一致问题仍然没有根本解决。
引入了超时机制解决参与者阻塞的问题，超时后本地提交，2pc只有事务管理器有超时机制。
- 第一阶段：CanCommit阶段，协调者(事务管理器)询问事务参与者，是否有能力完成此次事务。
- 如果都返回yes，则进入第二阶段
- 有一个返回no或等待响应超时，则中断事务，并向所有参与者发送abort请求
- 第二阶段：PreCommit阶段，此时协调者会像所有参与者发送preCommit请求，参与者收到后开始执行事务操作。参与者执行完事务操作后(此时属于未提交事务的状态)，就会像协调者反馈"ACK"表示，我已经准备好提交了，并等待协调者下一步指令。
- 第三阶段：DoCommit阶段，在阶段二中如果所有参与者节点都返回了ack，那么协调者就会从"预提交状态"转变为"提交状态"。然后向所有的参与者节点发送doCommit请求，参与者节点（资源管理器）在收到提交请求后就会各自执行事务提交操作，并向协调器节点反馈"ACK"消息，协调者收到所有参与者的ACK消息后完成事务。相反，如果有一个参与者节点未完成preCommit的反馈或者反馈超时，那么协调者都会想所有参与者节点发送abort请求，从而中断事务。
TCC（补偿事务）：Try Confirm Cancel
针对每个操作，都要注册一个与其对应的确认和补偿操作。它是在业务层编写代码实现两阶段提交。
以下单扣库存为例，Try阶段去占库存，Confirm阶段则实际扣库存，如果库存扣减失败 Cancel阶段进行回滚，释放库存。
TCC 不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常则通过Cancel来进行回滚补偿。
原本一个方法，现在却需要三个方法来支持，可以看到 TCC 对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。
消息事务(最终一致性)
消息事务其实就是基于消息中间件的两阶段提交，将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功。
- 订单系统向 MQ 发送一条预备扣减库存消息，MQ保存预备消息并返回成功ACK
- 接收到预备消息执行成功 ACK，订单系统执行本地下单操作，为防止消息发送成功而本地事务失败，订单系统会实现 MQ的回调接口，其内不断地检查本地事务是否执行成功，如果失败，则rollback 回滚预备消息；成功则对消息进行commit。
- 库存系统消费扣减库存消息，执行本地事务，如果扣减失败，消息会重新投放，一旦超出重试次数，则本地表持久化失败消息，并启动定时任务作为补偿。
基于消息中间件地两阶段提交方案，通常在高并发场景下使用，牺牲数据地强一致性换取性能地大幅提升，不过实现这种方式地成本和复杂度是比较高地，还要看实际业务情况。
Seata
TODO