分布式事务的“核”与“术”：Seata AT/TCC 与本地消息表的落地取舍

本文深入探讨了微服务架构下分布式事务的处理策略与落地取舍，主要包含以下核心内容：

理论基础与选型原则：文章指出分布式事务的本质是 CAP 定理的权衡（在分区容错性P存在的前提下，在一致性与可用性之间做取舍）。选型必须基于业务需求：电商大促等场景适合 AP（最终一致性），而金融转账等场景则必须选择 CP（强一致性）。
主流方案深度对比：
- 本地消息表：对业务代码侵入极小，无需额外中间件，但存在较高的延迟。
- Seata AT模式：业务代码零侵入，实现简单，适合大多数非核心业务，但在高并发下受全局锁限制，性能瓶颈明显。
- Seata TCC模式：性能高且支持强一致性，但开发成本高，需编写三段式逻辑，并重点解决幂等性、空回滚及悬挂等复杂问题。
TCC 模式机制与坑点：详细解析了 TCC 的三阶段（Try、Confirm、Cancel）执行流程，强调了幂等性设计的重要性。同时指出了 TCC 实践中常见的“空回滚”和“悬挂”问题及其解决思路，指出 TCC 是对业务流程的深度重构。
分阶段落地建议：
- 单体阶段：使用数据库事务（ACID）。
- 微服务拆分初期：推荐使用 本地消息表 配合 MQ，性价比高。
- 服务增多或一般强一致性需求：推荐使用 Seata AT模式。
- 核心交易链路：在高并发要求下，必须使用 Seata TCC模式，并需配合 JVM 调优和线程池配置。
总结：强调了监控（如事务提交成功率、Confirm/Cancel 失败率）在分布式事务中的重要性，并指出 AT 模式适合常规业务，TCC 适合核心业务，没有绝对的对错，只有适不适合。

微服务架构将单体应用拆分为多个独立的服务，虽然提升了系统的可维护性和伸缩性，但也带来了数据一致性的挑战。当调用链路跨越多个服务时，如何保证“扣减库存”的同时完成“扣减余额”，成为了后端开发中最棘手的工程问题之一。许多开发者在这一阶段容易陷入“为了分布式而分布式”的误区，盲目引入复杂的中间件，反而引入了不必要的系统复杂度和故障点。理解这些技术方案的内在机制和适用边界，是构建高可用系统的必修课。

核心判断：分布式事务的本质是 CAP 定理的权衡，不存在既强一致又高可用的银弹，选型必须基于业务的强一致性和最终一致性需求。

分布式事务的困境与 CAP 理论

分布式事务的核心矛盾在于，当服务 A 和服务 B 存在于不同的网络节点时，网络的不确定性会导致局部的成功无法转化为全局的成功。根据 CAP 定理，一个分布式系统最多只能同时满足一致性、可用性和分区容错性中的两点。在分布式环境下，分区容错性（P）通常是必须保证的，因此我们只能在一致性和可用性（CP 或 AP）之间做取舍。

在站内讨论中，经常出现因为过度追求强一致性而阻塞用户请求，或者为了高可用而不得不接受数据延迟的情况。例如，在电商大促场景下，交易服务扣减库存后，如果为了等待库存服务的异步确认而阻塞前端响应，将严重影响用户体验，这时选择 AP（最终一致性）往往更合适。反之，在金融转账场景中，资金的不一致将导致严重的业务损失，此时必须牺牲部分可用性来换取 CP（强一致性）。

主流方案的利弊对比与选择

目前的业界主流方案主要包括本地消息表、Seata AT 模式、Seata TCC 模式以及 Saga 模式。这些方案在实现原理、性能损耗和代码侵入性上存在显著差异，下表对比了它们的核心特性。

方案	核心原理	优点	代价	适用场景
本地消息表	在业务库中维护一个“消息表”，由定时任务轮询发送到 MQ。	对业务代码侵入极小；无需引入额外中间件。	需要额外的数据库表；消息可靠性依赖本地 DB；延连性较高。	对强一致性要求不高的业务；初期微服务拆分阶段。
Seata AT 模式	自动解析 SQL，生成前后镜像，利用日志表自动回滚。	业务代码无感知（零侵入）；实现简单。	锁定全局锁，高并发下性能受限；回滚日志表占用空间。	标准的 CRUD 业务；数据量中等，并发量一般的系统。
Seata TCC 模式	将业务逻辑拆分为 Try（预留资源）、Confirm（确认）、Cancel（取消）。	性能高，无锁；支持强一致性；灵活性高。	业务代码侵入大，需编写三段式逻辑；需处理空回滚、悬挂等问题。	高并发、高精度的金融或核心交易场景。

其中，Seata 作为阿里巴巴开源的分布式事务解决方案，通过事务协调器协调各个服务，AT 和 TCC 是其最常用的两种模式。TCC 模式虽然性能最好，但编写 try、confirm、cancel 三个接口且保证幂等性（idempotent）对于开发者的代码质量要求极高。而 AT 模式虽然对代码侵入为零，但其通过拦截 SQL 生成反Sql来实现回滚，在极高并发下的“全局锁”竞争可能会导致系统瓶颈。

TCC 模式的深层机制与坑点

TCC 模式的核心优势在于它不依赖数据库事务，而是通过代码层面的逻辑来控制资源。这里涉及一个关键的幂等性设计。在 Confirm 或 Cancel 阶段，如果网络超时导致请求重试，系统必须保证执行多次的效果与执行一次相同。通常的做法是利用 Redis 或 DB 的唯一索引来防止重复执行。例如，我们可以定义幂等 Key 为 tcc_action:order_id:biz_type。

为了更清晰地理解 TCC 的执行流程，我们可以通过以下时序图来展示服务 A 与服务 B 之间的交互：

流程图

渲染中...

在实践 TCC 时，开发者常遇到“空回滚”和“悬挂”问题。空回滚是指业务还没执行 Try 阶段，Cancel 就被调用了。解决方法是记录中间状态，Cancel 阶段检查是否执行过 Try。悬挂则是指 Try 阶段没有执行完，Confirm 阶段却先执行了，导致资源永远无法释放。这种对状态机的精细控制，使得 TCC 不仅是技术的选择，更是对业务流程的深度重构。

依据业务阶段的落地建议

面对众多方案，如何选择并非一成不变。对于初创项目或业务复杂的场景，建议遵循以下分阶段策略：

单体应用阶段：直接使用数据库事务（@Transactional），利用 MySQL 的行锁保证 ACID。
微服务拆分初期（2-3 个服务）：推荐使用 本地消息表 配合 MQ。这种方式解耦性好，实现成本低，且符合 BASE 理论中的“最终一致性”。你只需要在业务表中加一个状态字段和消息记录表，通过定时任务扫描发送即可。
服务数量增多或强一致性要求高：此时引入 Seata AT 模式 是性价比最高的选择。它适合大多数非核心交易的业务，如订单状态同步、积分发放等。需要注意的是，要合理设置数据源代理，避免性能损耗。
核心交易链路（如支付、转账）：当对并发性能和一致性要求极高时，必须使用 TCC 模式。此时，性能优化应该放在 JVM 调优和线程池配置上，例如调整 -Xms 和 -Xmx，以及配置合理的 ThreadPoolTaskExecutor，以应对 TCC 高并发的调用压力。

总结与讨论

分布式事务的设计没有绝对的对错，只有适不适合。AT 模式以其“零侵入”的特性成为了 Spring Boot 微服务开发的甜点，适合大多数常规业务；而 TCC 模式则是处理高并发核心业务的利器，代价是更高的开发成本和更深的逻辑理解。

注意：无论选择哪种方案，监控都是不能忽视的一环。对于 Seata，要监控事务的提交成功率；对于 TCC，要监控 confirm 和 cancel 的失败率，及时通过人工补偿或重试机制介入。

最后，请思考一个问题：在你的业务场景中，如果要求强一致性（数据绝对不能出错），你会选择 TCC 还是 Saga 模式？为什么？