获课：xingkeit.top/9253/

分布式事务全套方案：TCC、SAGA、本地消息表落地实战

在微服务架构大行其道的今天，一个业务操作往往跨越多个服务、多个数据库。经典的“下单扣库存”场景，就涉及订单服务、库存服务和账户服务。当这些服务部署在不同的物理节点上时，传统的单机数据库ACID事务便失去了用武之地。分布式事务，正是为解决这种跨服务数据一致性而生的技术体系。

本文将从实战角度，深度剖析三种主流分布式事务方案——TCC、SAGA 和 本地消息表 的核心原理、适用场景及落地要点。

一、CAP定理与BASE理论：分布式事务的哲学基础

在深入具体方案前，必须先理解分布式事务的“不可能三角”——CAP定理：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）中的两项。在真实的分布式环境中，网络分区是常态，因此我们必须在C和A之间做出权衡。

基于此，现代分布式事务普遍遵循 BASE理论：

• Basically Available（基本可用）：允许系统在故障时损失部分功能。

• Soft state（软状态）：允许系统存在中间状态，数据在短时间内可以不一致。

• Eventually consistent（最终一致性）：经过一段时间的异步修复，系统数据最终达到一致。

TCC、SAGA、本地消息表，本质上都是实现最终一致性的具体工程手段，而非强一致性。

二、TCC方案：业务代码层面的“手动事务”

TCC（Try-Confirm-Cancel） 是一种补偿型的分布式事务方案，它将一个完整的业务操作拆分为三个阶段，需要业务开发者显式实现每个阶段的逻辑：

1. Try（尝试）：业务资源的预留和检查阶段。例如，在扣库存时，Try阶段只将库存“冻结”起来，并不真正扣减；在扣款时，Try阶段只将金额“挂起”，不从余额中划走。

2. Confirm（确认）：如果所有参与者的Try阶段全部成功，协调者会向所有参与者发送Confirm指令。此时，参与者将Try阶段预留的资源真正提交，如“冻结库存”转为“实际扣减”。

3. Cancel（取消）：如果任一参与者的Try阶段失败，协调者会向所有已成功Try的参与者发送Cancel指令，释放之前预留的资源。

TCC的落地要点：

• 幂等性：Confirm和Cancel操作可能因网络重试被调用多次，必须保证幂等。

• 业务侵入性强：每个业务方法都需要拆分为Try/Confirm/Cancel三个接口，开发成本较高。

• 适用场景：适合对一致性要求极高、短事务且业务逻辑相对固定的场景，如金融转账、支付扣款。但对于长事务或涉及外部系统（如第三方API）的场景，TCC的Cancel逻辑难以实现，此时需考虑SAGA。

三、SAGA方案：长事务的“状态机”解药

SAGA 起源于1987年的数据库论文，它允许将一个大事务拆分为一组本地事务序列，每个本地事务都有对应的补偿事务。SAGA的核心思想是：如果序列中某个事务执行失败，则通过反向执行前面事务的补偿操作，来回滚整个流程。

SAGA有两种实现模式：

• 协同式（Choreography）：每个参与者通过事件发布/订阅机制，触发下一个参与者的执行。优点是去中心化，无需协调器；缺点是逻辑分散在多个服务中，流程难以追踪。

• 编排式（Orchestration）：引入一个SAGA协调器，集中控制整个事务流程。协调器按顺序调用各个服务，并记录执行状态；一旦某步骤失败，协调器立即按相反顺序调用补偿服务。这是企业落地中的主流选择。

SAGA的落地要点：

• 补偿操作的设计：补偿操作必须是业务意义上的回滚，而非数据库层面的回滚。例如，订单已发货时，补偿逻辑不能简单“删除订单”，而应触发“退款+退货”流程。

• 悬挂与空补偿：需要防止“空补偿”（补偿先于执行发生）和“悬挂”（补偿后执行又出现）问题，通常通过事务ID去重表来解决。

• 适用场景：非常适合涉及多个外部系统、业务流程长、中间状态可对外可见的场景，如旅游预订（订机票+订酒店+租车）、电商订单全生命周期管理。

四、本地消息表方案：基于消息队列的最终一致性

本地消息表 是分布式事务中最经典、最易落地的方案之一，它巧妙地将本地事务与消息队列结合，利用数据库的ACID保证消息的可靠存储。

核心执行流程如下：

1. 业务操作 + 消息记录在同一个本地事务中：订单服务在本地数据库中插入一条订单记录，同时插入一条“待发送”的扣库存消息。这两个操作在同一个@Transactional中，要么全成功，要么全失败。

2. 定时任务轮询发送：一个后台线程定时扫描本地消息表中的“待发送”记录，将消息投递到消息队列（如RocketMQ、RabbitMQ）。

3. 消费者订阅处理：库存服务订阅该消息，执行扣库存操作。处理成功后，向订单服务发送确认回执，订单服务将消息状态更新为“已处理”。

4. 异常重试机制：若消费者处理失败，消息队列会自动重试（按指数退避策略）。若多次重试仍失败，则转入死信队列，由人工介入处理。

本地消息表的落地要点：

• 接口幂等性：消费者必须保证幂等，防止因消息重复消费导致库存多扣。

• 消息可靠性：消息表记录必须包含唯一ID、重试次数、下一次重试时间等字段，便于监控和故障恢复。

• 适用场景：这是“最务实”的方案，适用于绝大多数不需要强一致性的业务场景，如积分发放、日志归档、订单状态同步等。它不依赖复杂的协调器，开发成本适中，维护直观。

五、三大方案的对比与选型决策树

选型建议：

• 若业务要求强一致性且资源冲突风险高（如秒杀超卖），首选TCC，尽管开发成本高，但能最大程度避免数据错乱。

• 若业务流程跨越多达5个以上服务，且包含外部不可控系统，SAGA的状态机模式是最安全的选择，它能清晰地呈现每一步的执行状态和补偿路径。

• 若业务对延迟不敏感、允许秒级甚至分钟级不一致，且团队希望快速上线，本地消息表是最稳健的“万金油”方案。

六、实战中的三条“血泪教训”

在训练营和真实项目中，以下三点是分布式事务落地的关键：

1. 一定要打印全局事务ID日志：分布式环境排查问题如同大海捞针，必须在每次调用时透传全局事务ID（XID），并在所有参与服务中记录该ID，这样才能通过链路追踪快速定位是哪个环节失败。

2. 补偿逻辑必须完善“重试+回查”机制：无论是SAGA还是本地消息表，必须设计“正向重试”和“反向回查”的双保险。即如果消费者长时间未反馈结果，生产者应主动回查业务状态，而非盲目重复发送消息。

3. 避免分布式事务大行其道：并非所有跨服务调用都需要分布式事务。应优先通过领域模型重构，将强关联的数据聚合到一个微服务内，从设计层面减少跨服务依赖，这才是解决一致性的根本之道。

结语

分布式事务没有银弹。TCC的严谨、SAGA的灵活、本地消息表的务实，分别对应着不同业务场景下的权衡取舍。作为架构师，核心能力不是记住某个方案的代码实现，而是理解每种方案背后的“权衡哲学”——在一致性、可用性、性能与开发成本之间，做出符合业务现状的最佳抉择。

掌握了这三套方案，你便拥有了应对微服务下数据一致性的“标准工具箱”。无论是支付核心链路，还是异步通知旁路，都能从容应对，设计出既优雅又可靠的分布式系统。