Seata的四种事务模式的优缺点分析

Seata公有四种分布式事务模式，XA、AT、TCC和SAGA，下面简要记录一下这几种分布式事务的优缺点。

XA模式

Seata的XA模式工作原理：

1. RM一阶段的工作

• RM将分支事务注册到全局事务协调器(TC)
• RM 执行分支业务操作，但不提交。这确保了分支事务不会立即生效，等待全局协调后再决定是否提交。
• RM 报告分支事务执行状态给 TC

2. TC 二阶段的工作:

• TC 检测各个分支事务的执行状态
• 如果所有分支事务都成功，TC通知所有RM提交事务，即提交所有分支事务的更改
• 如果有任何分支事务失败，TC通知所有RM回滚事务，即回滚所有分支事务的更改

3. RM二阶段的工作

• RM 接收来自TC的指令，根据指令来提交或回滚分支事务

XA 模式的优缺点

优点：

• 强一致性： XA 模式保证了数据的强一致性，即要么所有事务都提交成功，要么都回滚失败。这对于需要高度一致性的应用非常重要，如金融系统或在线支付。

• 广泛支持： XA 模式是一种经典的分布式事务处理标准，几乎所有主流的数据库都支持 XA 规范，因此可以在不同的数据库和消息队列之间进行事务协调。

缺点：

• 性能开销： 由于涉及到两个阶段的协调，XA 模式通常性能开销较大。在第一阶段，需要等待所有分支事务执行完毕并报告状态，而在第二阶段，需要等待所有分支事务的提交或回滚完成。这导致了较长的事务执行时间。

• 单点问题： XA 模式中需要一个全局的事务协调器（Transaction Coordinator），这可能成为系统的单点故障。如果事务协调器发生故障，整个系统的可用性将受到影响。

• 资源锁定： 在第一阶段，分支事务执行后需要等待全局事务协调器的指令，这可能导致资源锁定时间较长，影响并发性能。

• 复杂性： 实现 XA 模式的分布式事务处理需要复杂的编程和配置，开发和维护成本较高

AT模式（默认模式）

工作原理：

1. 阶段一 RM 的工作：

• 注册分支事务：当一个分支事务开始时，它会在本地数据库中注册自己。记录 undo-log（数据快照）：在分支事务执行业务SQL之前，记录当前数据的快照，以便在回滚时恢复数据。
  执行业务SQL并提交：分支事务执行业务SQL并自动提交本地事务。这是AT模式的特点，不涉及两阶段提交。
  报告事务状态：RM报告分支事务的执行状态给TC

2. 阶段二提交时 RM 的工作

• 在提交时，RM只需删除相应的undo-log，因为分支事务已经自动提交，不需要额外的提交操作

3. 阶段二回滚时 RM 的工作

• 在回滚时，RM根据之前记录的undo-log来恢复数据到更新前的状态

优点：

• 一阶段完成直接提交事务： AT 模式的第一阶段（执行业务SQL并自动提交）不涉及全局事务协调器的参与，因此可以更快地完成事务操作，释放数据库资源，从而提高性能。

• 利用全局锁实现读写隔离： AT 模式引入全局锁和写隔离，可以防止脏写问题和提供写隔离。这有助于确保数据的一致性和避免并发写操作导致的问题。

• 没有代码侵入，框架自动完成回滚和提交： 在 AT 模式下，开发人员不需要编写特定的代码来处理分布式事务的提交和回滚，Seata 框架会自动处理这些事务管理的细节，降低了开发的复杂性

缺点：

• 两阶段之间属于软状态： AT 模式中的两阶段提交之间是一个软状态，全局事务在第一阶段已经提交了分支事务，但最终一致性要在第二阶段进行检查和修复。这可能导致一定程度的数据不一致性，尤其是在第二阶段出现问题时

TCC模式

工作原理：
TCC模式的三个方法：

Try（尝试）： 这个方法用于资源的检测和预留。在Try阶段，事务会尝试执行业务逻辑，检查是否有足够的资源来执行操作，并预留资源以确保后续的确认或取消操作可以成功执行。

Confirm（确认）： 这个方法用于完成资源操作业务。如果Try成功，那么在确认阶段将完成资源操作的实际业务。确认操作一定要能成功，以确保资源的变化被永久性地提交。

Cancel（取消）： 这个方法用于资源的释放和恢复。如果Try成功但后续的确认操作出现问题，那么需要执行取消操作来释放预留的资源并恢复原始状态。

优点：

• 一阶段完成直接提交事务，释放数据库资源，性能好： TCC的Try阶段可以迅速完成，无需等待其他事务，从而释放数据库资源，提高性能。

• 相比AT模式，无需生成快照，无需使用全局锁，性能最强： TCC模式相对于AT模式，减少了对数据库快照的依赖，同时也不需要全局锁，因此具有较高的性能。

• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库： TCC模式不要求数据库必须支持XA事务，因此可以用于非事务型数据库。

缺点：

• 有代码侵入，需要人为编写Try、Confirm和Cancel接口，较为繁琐： TCC模式需要开发人员编写特定的Try、Confirm和Cancel方法，这可能增加了开发的复杂性。

• 软状态，事务是最终一致： TCC模式的事务具有软状态，确认和取消操作可能出现问题，需要考虑如何处理失败情况以保证最终一致性。

可能存在空回滚和事务悬挂问题：

• 解决空回滚的方法是在执行 Cancel 操作时，应判断 Try 是否已经执行。如果 Try 尚未执行，那么 Cancel 操作应该记录当前的状态，以等待进行 Try 操作时判断这个操作是否是 Cancel
• 解决事务悬挂的方法是在执行 Try 操作时，判断是否已经执行了 Cancel 操作。如果 Cancel 操作已经执行，那么 Try 操作应该被阻止，以避免事务悬挂的问题

SAGA模式

优点：

• 分布式事务处理：SAGA 模式是专门用于处理分布式事务的模式，能够有效解决跨多个服务的复杂事务问题。

• 高可伸缩性：由于事务被分解成多个小事务，这些小事务可以并行执行，提高了系统的可伸缩性。

• 容错性：SAGA 模式可以容忍某些小事务失败，通过回滚操作来保持整体事务的一致性。

• 降低锁竞争：与传统的两阶段提交（2PC）相比，SAGA 模式可以减少全局锁的使用，从而降低锁竞争。

• 灵活性：SAGA 模式允许在事务的执行过程中动态调整事务的状态迁移路径，更加灵活适应不同的业务需求

缺点：

• 复杂性：SAGA 模式的实现相对复杂，需要编写和维护compensating和confirming操作，以及确保正确的状态迁移。

• 最终一致性：SAGA 模式只追求最终一致性，可能会在事务过程中出现一时的不一致，需要额外的处理来处理这些不一致。

• 性能开销：由于SAGA 模式需要在协调器上执行状态管理和协调操作，可能会引入一些性能开销。

• 难以调试：SAGA 模式中的事务状态管理和回滚操作可能会增加调试的难度，特别是在复杂的分布式环境中