分布式事务怎么处理？微服务场景下的方案取舍

本文定位：面向已经采用或准备采用微服务架构的研发、架构和平台团队，重点讨论分布式事务的处理思路、方案取舍和落地风险，不展开某个框架的源码实现。

分布式事务是微服务架构落地后绕不开的问题。单体系统里，订单、库存、账户等逻辑往往共用一个数据库事务；拆成微服务后，每个服务拥有自己的数据库和发布节奏，一次业务操作可能跨越多个服务、消息队列和外部支付接口。此时如果仍然用“一个事务包住所有操作”的思路设计系统，往往会遇到性能下降、锁等待扩大、故障恢复困难和服务边界被重新耦合的问题。

更实际的做法是先判断业务到底需要什么级别的一致性，再选择合适的实现模式。分布式事务不是单一技术，而是一组围绕一致性、可用性、补偿能力和治理成本的架构取舍。 如果业务允许短时间不一致，就不一定要追求强一致；如果资金、额度、库存占用等场景不能出错，则需要把确认、回滚、对账和幂等设计成完整闭环。

图1：微服务分布式事务边界与一致性目标

先判断：你要处理的是哪类分布式事务问题

很多团队讨论分布式事务时，第一反应是问“用不用 TCC”或“要不要上 Saga”。但方案之前，更重要的是把问题分类。不同业务链路对一致性的要求差异很大，用同一套机制覆盖所有场景，通常会让系统变得又重又脆。

常见问题可以分成三类：

• 跨库写入一致性：一个业务动作需要同时更新多个数据库，例如创建订单后扣减库存、生成账户流水。
• 服务调用一致性：一个服务成功后，另一个服务超时或失败，例如订单已创建但支付状态未确认。
• 消息与数据库一致性：本地数据已经提交，但事件没有可靠发出，导致下游系统没有感知变化。

这三类问题的处理重点并不相同。跨库写入更关注事务边界和隔离级别，服务调用更关注超时、重试、补偿和幂等，消息一致性则关注“本地状态变更”和“事件发布”是否能形成可靠链路。

如果系统刚开始服务化，可以先阅读微服务拆分怎么做这类基础内容，确认服务边界是否合理。很多分布式事务难题不是技术方案不够多，而是服务拆分过细、数据职责不清，导致原本应该在一个业务聚合内完成的操作被过早切到多个服务之间。

强一致还是最终一致，决定了方案重量

处理分布式事务前，建议先把业务一致性目标写清楚。强一致强调所有参与方要么一起成功、要么一起失败；最终一致允许短时间状态不一致，但要求系统能通过补偿、重试或对账恢复到正确状态。

一致性要求越高，运行耦合越强

表格里的差异说明一个关键事实：一致性要求越高，系统运行时耦合通常越强。 如果所有链路都按强一致设计，系统会更难水平扩展，也更容易因为某个依赖异常而阻塞整个业务流程。反过来，如果把本该强一致的资金类操作简单异步化，又会带来数据错误和审计风险。

业务语义比技术名词更重要

同样是“扣库存”，不同业务语义可能对应不同方案。秒杀活动中，库存可以先冻结再支付，超时释放；普通电商中，可以下单后占用库存，再由支付结果推动状态变化；企业内部审批系统中，资源占用甚至可以先记录申请，再由后台异步确认。技术方案只有放到业务语义里才有意义。

设计时建议把每个关键操作拆成状态机，而不是只看接口成功或失败。例如订单可以经历“待确认、已占用、待支付、已完成、已取消、补偿中、补偿失败”等状态。状态越清楚，补偿和对账越容易落地。

常见分布式事务方案怎么取舍

微服务场景下常见方案包括 2PC、TCC、Saga、事务消息、本地消息表和 Outbox。它们并不是互斥关系，在一个系统里经常会组合出现。

可以按下面的取舍路径理解：

1. 能否把操作收敛到单服务内？如果能，通过重新划分服务边界或聚合根解决，优先避免分布式事务。
2. 是否必须强一致？如果必须，考虑 TCC 或受控的事务协调，但要接受更高实现成本。
3. 是否能业务补偿？如果能，将长事务拆成多个本地事务，用 Saga 或状态机推进。
4. 是否主要是事件可靠投递？如果是，优先考虑 Outbox、本地消息表或事务消息。
5. 是否需要人工兜底？对外部系统、跨机构或财务核对场景，要补对账和工单流程。

图2：分布式事务方案取舍决策树

2PC：强一致但对参与方要求高

两阶段提交把事务拆成准备阶段和提交阶段。协调者先询问所有参与者是否可以提交，全部确认后再发出提交指令；如果有参与者失败，则发出回滚指令。它的优势是语义接近传统事务，适合少量参与方、可控网络和强一致要求明确的场景。

但在微服务里，2PC 的问题也很明显。参与方需要支持协议，协调者成为关键组件，锁可能跨服务和网络持续存在，故障恢复会变复杂。对高并发、长链路、跨团队服务来说，2PC 往往不是默认选择。

TCC：把强一致交给业务动作表达

TCC 将操作拆成 Try、Confirm、Cancel 三个阶段。Try 阶段预留资源，Confirm 阶段确认提交，Cancel 阶段释放或回滚。相比通用 2PC，TCC 更强调业务语义，适合库存预占、额度冻结、账户授权等能明确“预留”和“确认”的场景。

它的难点在于每个参与服务都要实现三套接口，并处理空回滚、悬挂、幂等、重复确认等异常。TCC 不是简单加一个框架，而是要求业务模型天然支持预留与撤销。 如果某个步骤无法安全撤销，TCC 的复杂度会迅速上升。

Saga：用一组本地事务和补偿动作完成长流程

Saga 把一个跨服务业务流程拆成多个本地事务，每个本地事务提交后触发下一步。如果后续步骤失败，则按相反方向执行补偿动作。它常用于订单履约、开户流程、异步审批等长链路场景。

Saga 的优势是避免长时间分布式锁，服务之间可以保持相对独立；代价是系统必须接受中间状态，并认真设计补偿动作。补偿不一定是“反向 SQL”，有时是发起退款、释放库存、取消工单、通知人工介入。要让 Saga 可运维，必须有状态机、事件日志、重试策略和可观测性。

事务消息、Outbox 和本地消息表：解决数据变更与事件发布一致性

很多微服务链路并不需要把多个服务放进一个强事务，而是需要确保“本地数据库提交成功后，事件一定能被下游看到”。这时可以采用事务消息、Outbox 或本地消息表。

典型做法是在同一个本地事务中写业务表和消息表，事务提交后由后台任务或消息中继发布事件；如果发布失败，消息仍然留在本地表中等待重试。Outbox 模式也常结合 CDC，把数据库变更转成事件流。Apache Kafka 官方文档中对事务能力、生产者幂等和 exactly-once 语义有明确说明，但在业务系统里仍然需要处理消费者幂等和状态恢复，不能只依赖消息系统承诺。

这种方案的优势是服务边界清晰、吞吐能力好，适合订单状态同步、通知、积分、搜索索引、数据同步等场景。缺点是链路变成异步后，用户界面和下游系统要能容忍短时间延迟。

微服务分布式事务落地要补哪些基础能力

只选方案还不够。分布式事务真正落地时，很多故障不是发生在“正常路径”，而是发生在超时、重复请求、消息乱序、补偿失败和人工处理缺失这些边界上。可以结合服务治理怎么做中的治理能力，把事务方案放到完整运行体系里考虑。

至少要补齐以下基础能力：

• 幂等设计：接口、消息消费者和补偿动作都要能安全重复执行。
• 唯一业务键：订单号、事务号、请求号要贯穿调用链，避免重复扣减或重复确认。
• 状态机：每个业务对象的状态流转要可枚举、可审计、可恢复。
• 超时与重试：重试要有上限、退避策略和死信处理，不能无限放大故障。
• 补偿与对账：自动补偿失败后，要有对账任务、告警和人工处理入口。
• 可观测性：日志、指标、链路追踪要能按事务号串起全流程。

图3：分布式事务运行治理闭环

幂等是所有方案的底座

无论采用 TCC、Saga 还是事务消息，都无法假设网络请求只发生一次。调用方可能超时重试，消息队列可能重复投递，补偿任务也可能被人工重新触发。没有幂等，所谓分布式事务很容易变成“重复扣款、重复发券、重复释放”的事故源。

常见做法包括使用业务唯一键、请求去重表、乐观锁版本号、状态条件更新和消息消费记录。设计接口时，要让重复调用返回同一个业务结果，而不是每次都产生新的副作用。

补偿动作要当成一等业务能力

很多项目把补偿看成异常分支，只有等故障发生才补脚本。这种做法风险很高。补偿动作应该和正向动作一样经过设计、测试和监控。例如库存预占需要释放，支付成功但订单关闭需要退款，优惠券核销失败需要恢复可用状态。

补偿还要考虑“补偿失败怎么办”。如果外部支付网关不可用，取消流程无法立即完成，系统要把任务放入待处理队列，并提供告警、重试和人工介入入口。

常见错误做法与风险

分布式事务问题经常被低估，尤其是在系统刚拆分、业务量还不大时。等到调用链变长、服务数量增多、跨团队协作变复杂，早期没有设计好的边界和补偿就会成为稳定性隐患。

常见风险包括：

• 把远程调用放进本地数据库事务：数据库锁被网络延迟放大，容易拖慢核心链路。
• 没有区分查询失败和写入失败：超时不等于失败，重复补偿可能破坏正确状态。
• 依赖同步调用串完整流程：任何一步慢或失败都会影响用户请求响应。
• 只做重试不做幂等：故障恢复时可能造成重复扣减、重复创建或重复通知。
• 没有对账闭环：少量异常长期沉淀，最终变成财务、库存或审计问题。

这些风险说明，分布式事务不只是开发框架选择，也涉及业务流程、数据建模、服务治理和运维机制。对于调用链特别复杂的系统，还要和熔断、限流、降级策略配合，避免异常补偿任务进一步压垮依赖服务。

一套可执行的分布式事务设计流程

在实际项目中，可以把分布式事务设计拆成几个步骤，避免一开始就陷入工具争论。

推荐按下面顺序推进：

1. 画出业务链路：列出参与服务、数据库、消息队列和外部系统。
2. 标注一致性等级：对每个状态变更标注强一致、准实时最终一致或异步最终一致。
3. 定义状态机：明确每个业务对象的正常、异常、补偿和终态。
4. 选择事务模式：强一致场景评估 TCC 或受控协调，长流程评估 Saga，事件投递评估 Outbox 或事务消息。
5. 补齐幂等与重试：所有写接口、消费者和补偿动作都要设计幂等键。
6. 建设观测与对账：按事务号追踪全链路，建立异常积压、补偿失败和状态不一致告警。
7. 压测异常路径：不要只测成功路径，要模拟超时、重复投递、参与方宕机和补偿失败。

这套流程的价值在于把“分布式事务怎么处理”从抽象方案变成可评审的设计产物。评审时不只问用了什么框架，还要问状态是否可恢复、失败是否可观测、补偿是否可重复执行。

小结

分布式事务处理的核心，不是找到一个能覆盖所有微服务场景的万能方案，而是根据业务一致性目标、服务边界、补偿能力和运维成熟度做取舍。强一致场景可以考虑 TCC 或受控协调，但要接受复杂度；大多数长业务流程更适合通过 Saga、事务消息、Outbox、本地消息表和对账机制实现最终一致。

好的分布式事务设计，通常是在业务上承认中间状态，在技术上保证幂等、可补偿、可观测和可恢复。 如果服务边界本身不清晰，应优先回到微服务拆分和数据职责设计，而不是直接叠加更复杂的事务框架。

常见问题

分布式事务一定要用强一致方案吗？

不一定。只有资金、额度、库存硬约束等不能容忍中间不一致的场景，才需要优先评估强一致或 TCC。订单状态同步、通知、积分、报表等场景通常可以采用最终一致，但必须有幂等、补偿、重试和对账机制。

微服务分布式事务里 Saga 和 TCC 怎么选？

如果业务动作可以明确拆成预留、确认、取消，并且对一致性要求较高，可以考虑 TCC。如果业务流程较长、步骤多、允许中间状态，并且每一步都有可定义的补偿动作，更适合 Saga。两者都需要幂等和状态管理，不能只靠框架自动完成。

事务消息能完全解决分布式事务吗？

事务消息主要解决本地数据库变更和消息发布之间的一致性，不能自动保证所有下游业务都成功完成。消费者仍然需要幂等、重试、死信、补偿和监控。对于跨服务长流程，还需要结合状态机或 Saga 编排。

分布式事务设计最容易忽略什么？

最容易忽略异常路径。比如调用超时后实际已经成功、补偿请求重复执行、消息乱序到达、人工修复没有审计记录等。上线前应把这些异常路径加入测试和演练，而不是只验证成功链路。

权威参考资料

• Microsoft Azure Architecture Center: Compensating Transaction pattern
• Microsoft Azure Architecture Center: Saga distributed transactions pattern
• Microservices.io: Pattern: Saga
• Microservices.io: Pattern: Transactional Outbox
• Apache Kafka Documentation: Transactions