一、引言

在当今复杂的分布式系统中，数据的一致性和事务的可靠性至关重要。分布式事务管理成为了确保分布式系统中数据完整性和业务逻辑正确性的关键手段。其中，XA 事务与 TCC 模式是两种重要的分布式事务管理方式。

XA 事务是一种由 X/Open 组织提出的分布式交易处理规范，它定义了事务管理器（TM）和资源管理器（RM）之间的接口，通过两阶段提交协议来保证数据的强一致性。许多分布式关系型数据管理系统都采用此协议来完成分布式事务。然而，XA 事务也存在一些缺点，如性能不好，无法满足高并发场景等。

TCC 模式则是一种业务层的两阶段提交方案，事务分为 Try（尝试执行）、Confirm（确认提交）和 Cancel（取消回滚）三个阶段。每个阶段都有相应的业务接口，由业务系统自行实现。TCC 模式具有较高的性能，减少了锁竞争，灵活性高，能够明确控制每个事务阶段，但开发复杂，需要定义和实现 Try、Confirm 和 Cancel 接口，且需要业务系统对事务一致性负责。

二、XA 事务

1. XA 事务介绍

XA 是由 Tuxedo 提出，由 X/Open 组织定义的分布式事务协议。目前主流数据库如 Oracle、MySQL 等支持该协议。XA 协议主要定义了事务管理器（TM）和局部资源管理器（RM）之间的接口，通过两阶段提交协议来保证数据的强一致性。

2. XA 事务原理

1. 两阶段提交：

• 将事务分为 prepare 和 commit 两个阶段。以电商系统为例，分布式系统中有订单、账户和库存三个服务。第一阶段，事务协调者向事务参与者发送 prepare 请求，事务参与者收到请求后，如果可以提交事务，回复 yes，否则回复 no。第二阶段，如果所有事务参与者都回复了 yes，事务协调者向所有事务参与者发送 commit 请求，否则发送 rollback 请求。

• 优点是保证数据强一致性，但也存在一些问题，比如同步阻塞，本地事务在 prepare 阶段锁定资源，如果有其他事务也要修改数据，就必须等待前面的事务完成，这样就造成了系统性能下降；协调节点单点故障，如果第一个阶段 prepare 成功了，但是第二个阶段协调节点发出 commit 指令之前宕机了，所有服务的数据资源处于锁定状态，事务将无限期地等待；数据不一致，如果第一阶段 prepare 成功了，但是第二阶段协调节点向某个节点发送 commit 命令时失败，就会导致数据不一致。

2. 三阶段提交：

• 在两阶段提交基础上引入超时机制和 preCommit 阶段。第一阶段的 prepare 阶段分成了两步，canCommit 和 preCommit。引入 preCommit 阶段后，协调节点会在 commit 之前再次检查各个事务参与者的状态，保证它们的状态是一致的。

• 但仍存在问题，那就是如果第三阶段发出 rollback 请求，有的节点没有收到，那没有收到的节点会在超时之后进行提交，造成数据不一致。

3. XA 事务语法介绍：

• 三阶段的第一阶段：开启 xa 事务，这里 xid 为全局事务 id：XA {START|BEGIN} xid [JOIN|RESUME]；结束 xa 事务：XA END xid [SUSPEND [FOR MIGRATE]]。

• 三阶段的第二阶段，即 prepare：XA PREPARE xid。

• 三阶段的第三阶段，即 commit/rollback：XA COMMIT xid [ONE PHASE]；XA ROLLBACK xid。

• 查看处于 PREPARE 阶段的所有事务：XA RECOVER；XA RECOVER [CONVERT XID]。

3. seata XA 简介

seata 的 XA 模式利用分支事务中数据库对 XA 协议的支持实现，对传统三阶段提交做了优化，改为两阶段提交。具体流程如下：第一阶段首执行 XA 开启、执行 sql、XA 结束三个步骤，之后直接执行 XA prepare；第二阶段执行 XA commit/rollback。但对 oracle 支持不太好，因为 oracle 实现的是标准的 xa 协议，即 xa end 后，协调节点向事务参与者统一发送 prepare，最后再发送 commit/rollback。

三、TCC 模式

1. TCC 模式定义

TCC 是 Try-Confirm-Cancel 的缩写，是一种用于分布式事务处理的解决方案。它需要实现的方法包括 Try（资源的检测和预留）、Confirm（完成资源操作业务，要求 Try 成功 Confirm 一定要能成功）、Cancel（预留资源释放，可以理解为 try 的反向操作）。

2. TCC 模式原理

TCC 模式将事务拆分为三个阶段：Try 阶段进行资源预留，Confirm 阶段确认提交，Cancel 阶段取消操作并回滚预留资源。

例如在一个分布式事务中，涉及到订单服务和库存服务。在 Try 阶段，订单服务可能会检查订单信息是否完整，并预留订单编号等资源；库存服务则会检查库存是否充足，并预留相应的库存数量。如果 Try 阶段所有服务都成功预留了资源，那么进入 Confirm 阶段。在 Confirm 阶段，订单服务会正式生成订单，库存服务会确认扣除预留的库存数量。如果在 Try 阶段有任何一个服务出现问题，或者在 Confirm 阶段出现异常，就会进入 Cancel 阶段。在 Cancel 阶段，订单服务会取消预留的订单编号等资源，库存服务会释放预留的库存数量。

3. TCC 模式的优缺点

1. 优点：

• 高性能，将事务分为多个小事务减少锁持有时间。在 TCC 模式中，由于事务被拆分为多个小的阶段，每个阶段只对部分资源进行操作，因此减少了锁的持有时间，提高了系统的并发性能。

• 灵活性强，可根据需要灵活实现三个阶段逻辑。TCC 模式不依赖于特定的数据库事务机制，开发人员可以根据业务需求灵活地实现 Try、Confirm 和 Cancel 三个阶段的逻辑，更好地满足复杂业务场景的需求。

• 不依赖数据库事务，适用于非事务型数据库。TCC 模式完全不依赖数据库的事务支持，而是通过业务逻辑的控制来实现事务的一致性，因此适用于非事务型数据库或者在分布式环境下跨数据库的事务处理。

2. 缺点：

• 代码入侵，需要人为编写 try、Confirm 和 Cancel 接口。TCC 模式要求开发人员在业务代码中显式地编写 Try、Confirm 和 Cancel 三个接口，这增加了开发的难度和工作量，同时也对业务代码造成了一定的侵入性。

• 软状态，事务最终一致，需考虑 Confirm 和 Cancel 的失败情况及幂等处理。在 TCC 模式中，事务并不是在一个时刻完全一致的，而是通过一系列的操作逐步达到最终一致的状态。因此，开发人员需要考虑 Confirm 和 Cancel 阶段可能出现的失败情况，并进行相应的重试和幂等处理，以保证事务的最终一致性。

• 可能出现事务悬挂和空回滚问题。事务悬挂指的是当一个分布式事务在执行过程中，一个或多个资源长时间被锁定，导致其他分布式事务无法访问该资源，进而产生阻塞和死锁的问题。空回滚指的是分布式事务中已经提交了修改，但是由于某些原因无法回滚的情况，导致整个事务无法提交，只能回滚，造成了资源的浪费和性能的降低。

4. TCC 模式的实现

通过一个订单服务和库存服务的示例展示 TCC 模式在 Java 中的实现。假设在一个电商系统中，有订单服务和库存服务两个微服务。当用户下单时，订单服务需要创建订单并扣除库存。在 TCC 模式下，订单服务和库存服务需要分别实现 Try、Confirm 和 Cancel 三个接口。

在 Try 阶段，订单服务会检查订单信息是否完整，并预留订单编号等资源。库存服务会检查库存是否充足，并预留相应的库存数量。如果 Try 阶段所有服务都成功预留了资源，那么进入 Confirm 阶段。在 Confirm 阶段，订单服务会正式生成订单，库存服务会确认扣除预留的库存数量。如果在 Try 阶段有任何一个服务出现问题，或者在 Confirm 阶段出现异常，就会进入 Cancel 阶段。在 Cancel 阶段，订单服务会取消预留的订单编号等资源，库存服务会释放预留的库存数量。

四、XA 事务与 TCC 模式对比

1. 设计模式区别

1. XA 有预提交过程，两阶段提交在第二阶段才执行 commit；TCC 在第一阶段就 commit 了，没有预提交过程。

• XA 事务在两阶段提交过程中，有一个协调者在中间起到重要作用。当所有的事务都执行成功，会把执行成功的状态通知协调者，这个阶段是第一阶段。协调者监听到所有的事务执行成功后，执行第二阶段的 commit。

• 而 TCC 模式不同，其在第一阶段就 commit 了。TCC 的第二阶段是一个确认（Confirm）的阶段，只需要调用各个子系统里的 confirm 逻辑，把原来没有更新到数据库的那些 “缓存” 数据更新到数据库。因为这个时候已经把更改的数据缓存起来了，只是还没更新到数据库，所以在执行 confirm 逻辑的时候，并不会持有数据库的锁。

2. 应用场景区别

1. XA 更多应用在单体架构，TCC 更多应用在分布式架构。

• XA 事务更多应用在单体架构上，因为其在并发量不大的时候性能更高，不需要远程的 api 调用。

• TCC 模式更多应用在分布式架构上，因为其将事务拆分为三个阶段，每个阶段只对部分资源进行操作，减少了锁的持有时间，提高了系统的并发性能。

3. 性能区别

1. 并发量不大时，XA 性能更高，因无需远程 api 调用；高并发场景下，TCC 优势大，因其第一阶段就提交事务，不继续持有数据库锁。

• 当并发量不大的时候，XA 的性能更高。因为 XA 事务不需要远程的 api 调用，所以在低并发场景下，XA 事务的性能优势明显。

• 但是在高并发场景下，TCC 优势很大。因为 TCC 模式在第一阶段就把事务提交了，不需要在后面像 XA 一样继续持有数据库的锁，影响并发的性能。

五、总结

在分布式事务管理中，XA 事务与 TCC 模式各有特点和适用场景。

XA 事务是一种由 X/Open 组织提出的分布式交易处理规范，通过两阶段提交协议来保证数据的强一致性。它适用于单体架构，在并发量不大的时候性能较高，不需要远程的 API 调用。然而，XA 事务也存在一些缺点，如性能不好，无法满足高并发场景；存在同步阻塞问题，本地事务在 prepare 阶段锁定资源，影响系统性能；协调节点单点故障可能导致事务无限期等待；数据不一致风险较高等。

TCC 模式是一种业务层的两阶段提交方案，分为 Try、Confirm 和 Cancel 三个阶段。它具有高性能、灵活性强、不依赖数据库事务等优点，适用于分布式架构。在 TCC 模式中，由于事务被拆分为多个小的阶段，每个阶段只对部分资源进行操作，因此减少了锁的持有时间，提高了系统的并发性能。开发人员可以根据业务需求灵活地实现三个阶段的逻辑，更好地满足复杂业务场景的需求。同时，TCC 模式完全不依赖数据库的事务支持，而是通过业务逻辑的控制来实现事务的一致性，因此适用于非事务型数据库或者在分布式环境下跨数据库的事务处理。但是，TCC 模式也存在一些缺点，如代码入侵，需要人为编写 try、Confirm 和 Cancel 接口，增加了开发的难度和工作量，同时也对业务代码造成了一定的侵入性；存在软状态，事务最终一致，需考虑 Confirm 和 Cancel 的失败情况及幂等处理；可能出现事务悬挂和空回滚问题等。

综上所述，开发者在选择分布式事务管理方式时，需要根据实际情况进行权衡。如果系统并发量不大，且对数据强一致性要求较高，可以选择 XA 事务；如果系统是分布式架构，对性能要求较高，且能够接受最终一致性，可以选择 TCC 模式。