XA模式

• 优点：实现简单
• 缺点：
  • 一致性风险：必须保证网络在提交的可靠性，必须假设设备crach后可恢复。
  • 单点问题：协调者如果crash了所有参与者必须等待（3PC进行了优化变为提交）
  • 性能问题：将所有参与者绑定为一个整体，要经过两次RPC，三次持久化操作（写redo日志，协调者commit，参与者 commit record），会因为木桶效应等待最慢的一个操作结束，导致性能较差。
• 使用场景：适用于单服务使用多数据源的场景，JTA使用的就是XA模式。

TCC模式

• 优点：在满足最终一致性的情况下保证了隔离性。有较高的灵活性，可以根据需要设计资源锁定的粒度。TCC 在业务执行时只操作预留资源，几乎不会涉及锁和资源的争用，具有很高的性能潜力。
• 缺点：更高的开发成本和业务侵入性，意味着有更高的开发成本和更换事务实现方案的替换成本。
• 使用场景：它是一种业务侵入式较强的事务方案，要求业务处理过程必须拆分为“预留业务资源”和“确认/释放消费资源”两个子过程。阿里开源的Seata就支持TCC模式。

SAGA模式

• 优点：相比TCC侵入性低，并且不需要为资源设计冻结状态和撤销冻结的操作。保证所有子事务都得以提交（正向恢复）或者补偿（反向恢复），使用数据补偿来代替回滚。
• 缺点：保证正向、反向恢复过程的能严谨地进行需要花费不少的工夫。SAGA 系统本身也有可能会崩溃，所以必须设计成与数据库类似的日志机制（被称为 SAGA Log）以保证系统恢复后可以追踪到子事务的执行情况。
• 使用场景：SAGA是将一个分布式环境中的大事务分解为一系列本地事务的设计模式。

AT模式

• 优点：AT是基于XA 2PC的模式实现的，针对于木桶效应，通过业务数据提交时自动拦截所有 SQL，将 SQL 对数据修改前、修改后的结果分别保存快照，生成行锁，通过本地事务一起提交到操作的数据源中，相当于自动记录了重做和回滚日志。这样每一个数据源都可以单独提交，然后立刻释放锁和资源。
• 缺点：提高了吞吐量的同时，破坏了隔离性，会出现脏写的情况（在回滚前数据发生了改变，导致无法逆向SQL来补偿数据）
• 使用场景：无侵入性补偿，数据库支持本地事务。GTS使用AT模式。
• tips:GTS为了解决脏读 增加了一个全局锁，要求必须拿到锁才能写数据；AT的隔离等级为读未提交，意味着有脏读的情况，也可以加全局读锁来解决，相应的性能会受到一定的影响。

总结

分布式事务中没有万能的解决办法，只能够具体情况具体分析。