TCC模式

TCC模式是try，confirm，cancel。不依赖本地事务，通过业务代码解决。try先预留事务所需的资源，confirm确保任务的执行并且消耗第一阶段预留的资源，如果在这个阶段出现差错就进入cancel。

优点：

  • 不依赖数据库的事务，可以用在非事务型数据库
  • 不用全局锁，无需生成快照，效率较高。

缺点：

  • 代码侵入：需要程序员手动设计事务逻辑，增加了开发的复杂度
  • 中间有软状态，是最终一致性，confirm和cancel出现问题会有一致性问题。
  • 幂等问题：如果由于在confirm和cancel阶段出现网络波动，可能多次释放资源，出现严重后果。所以为了保证信息只被回滚一次需要保证幂等性。可以用状态表来实现（但是我觉得还是会有并发问题）
  • 空回滚：try的期间阻塞一条，回滚的时候也会回滚这个空的。可能造成资源无故释放。解决方法也是状态表，如果第一阶段有记录成功过了就执行回滚。如果没有就不用
  • 资源倒挂：也是网络环境变化，try阶段某个分支事务阻塞了直到最后回滚了才执行，是空回滚的另一个结果。解决方案是空回滚的时候加一条状态记录。在try阶段如果没有这个就执行，如果有分支事务的id。说明已经被空回滚发现，不再执行。

saga模式

Saga模式是一种用于处理分布式事务的模式，它通过将长时间的、复杂的事务分解为多个小的、可逆的事务片段，以实现事务的一致性和可靠性。

在Saga模式中，每个事务片段称为一个补偿操作。每个补偿操作都与一个正向操作相对应，正向操作是事务的一部分，而补偿操作是用于撤销或修复正向操作的。Saga模式通过按照事务执行的顺序，依次执行正向操作和补偿操作，来确保事务在发生失败或异常时能够进行回滚或恢复。

Saga模式的执行过程如下：

执行正向操作：按照事务的逻辑顺序，依次执行正向操作。每个正向操作都会记录事务的执行状态。
如果所有的正向操作都成功执行，则事务提交完成。
如果某个正向操作失败，将会触发相应的补偿操作。补偿操作会撤销或修复正向操作的影响。
执行补偿操作：按照逆序依次执行已经触发的补偿操作。补偿操作应该具备幂等性，以便可以多次执行而不会造成副作用。
如果所有的补偿操作都成功执行，则事务回滚完成。
如果补偿操作也失败，需要人工介入或其他手段来解决事务的一致性问题。

Seata的Saga模式：

Seata的Saga模式通过Seata框架来管理和协调分布式事务，提供了对事务的编排和状态管理的支持。它与Seata的其他特性（如AT模式、TCC模式）结合在一起，构成了Seata全面的分布式事务解决方案。

Seata的Saga模式相对于传统的Saga模式，具有以下特点：

  • 集成性：Seata的Saga模式与Seata框架紧密集成，可以与Seata的其他特性一起使用，如分布式事务日志和分布式锁等。
  • 强一致性：Seata的Saga模式提供了强一致性的事务支持，确保事务的执行顺序和一致性。
  • 可靠性：Seata的Saga模式在补偿操作的执行过程中，支持重试和恢复机制，提高了事务的可靠性和恢复能力。

适用场景：

  • 业务流程长、业务流程多
  • 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

优点：

  • 一阶段提交本地事务，无锁，高性能
  • 事件驱动架构，参与者可异步执行，高吞吐
  • 补偿服务易于实现，不用编写TCC中的三个阶段，实现简单

缺点：

  • 没有锁，不保证隔离性，会有脏写；
  • 软状态持续时间不确定，时效性差；

XA模式

就是二阶段提交2pc模式。保证强一致性，只能一起提交或者失效。效率最低。