分布式事务的核心目标是在分布式环境下保证数据的一致性，通过2PC、TCC、Saga等不同强度的协议在一致性与可用性之间寻找平衡点。
微服务架构下分布式事务如何实现
在微服务架构中,原本属于单一数据库的业务逻辑被拆分到了多个独立的数据库实例中，当一个业务流程跨越多个服务时，传统的本地事务机制失效，必须引入分布式事务协议，实现的核心逻辑在于如何协调多个参与者（Participant）的状态，确保要么全部成功，要么全部回滚。
强一致性协议：两阶段提交 (2PC)
两阶段提交（Two-Phase Commit, 2PC）是分布式事务中最经典的实现方式，它通过一个中心化的事务协调者（Coordinator）来管理所有参与者的状态。
第一阶段：准备阶段 (Prepare Phase)
协调者向所有参与者发送“准备”请求，每个参与者在执行完本地事务后，会将资源锁定，并向协调者反馈执行结果，如果参与者在执行过程中遇到问题，会返回失败。
第二阶段：提交或回滚阶段 (Commit/Rollback Phase)
- 如果所有参与者都返回成功,协调者发送“提交”指令，各参与者正式提交本地事务并释放锁。
- 如果有任何一个参与者返回失败,或者协调者在等待过程中超时，协调者会发送“回滚”指令，所有参与者撤销已做的更改。
业内专家指出,2PC 虽然保证了强一致性，但其最大的缺陷在于同步阻塞，在等待协调者指令期间，所有参与者持有的数据库锁无法释放，这会导致系统吞吐量在并发量升高时急剧下降。
最终一致性方案：TCC 与 Saga
为了解决 2PC 的性能瓶颈，行业共识认为应当转向追求“最终一致性”的方案，即允许在极短的时间内数据不一致，但最终能达到一致状态。
TCC (Try-Confirm-Cancel) 模式
TCC 是一种侵入性较强的补偿型事务模式，它将业务逻辑拆分为三个阶段：
- Try 阶段：完成业务检查，并预留业务资源（冻结账户余额，而不是直接扣款）。
- Confirm 阶段：在 Try 成功后，真正执行业务逻辑（正式扣除冻结的余额），此阶段必须保证幂等性，因为可能会被多次调用。
- Cancel 阶段：Try 失败，则执行补偿逻辑（解冻之前预留的余额）。
Saga 模式
Saga 适用于业务流程极长、参与方众多的场景，它将长事务拆分为一系列连续的本地事务。
- 正向流程：按顺序执行 T1, T2, …, Tn。
- 补偿流程：Tn 失败，则按照相反的顺序执行补偿操作 C(n-1), …, C1。
Saga 模式不需要在执行过程中锁定资源，因此性能极高，但它无法应对“脏读”问题，因为在事务完成前，其他业务可以看到中间状态的数据。
分布式事务解决方案对比
在实际工程落地中,选择哪种方案取决于业务对一致性的容忍度以及开发成本，下表展示了主流方案的核心差异。
| 方案类型 | 一致性级别 | 性能表现 | 业务侵入性 | 典型应用场景 |
|---|---|---|---|---|
| 2PC (XA) | 强一致性 | 低 (阻塞严重) | 低 | 金融核心账务、对一致性要求极高的单点系统 |
| TCC | 最终一致性 | 高 | 高 (需编写补偿逻辑) | 电商订单支付、库存预扣、账户转账 |
| Saga | 最终一致性 | 极高 | 中 | 跨组织的长流程审批、旅游订票组合流程 |
| 可靠消息 | 最终一致性 | 高 | 中 | 异步解耦、日志收集、非核心业务通知 |
2PC与TCC的区别是什么
在面试或架构设计评审中,这是最常被问到的问题，理解两者的区别，核心在于资源锁定机制与实现层级的不同。
资源锁定机制的差异
2PC 的锁定发生在数据库层，当事务进入 Prepare 阶段，数据库会自动对涉及的数据行加锁，在整个事务结束前，这些锁一直存在，这种机制虽然简单，但在高并发环境下会造成严重的锁竞争。
TCC 的锁定发生在应用层，它通过业务逻辑来模拟锁定，在电商场景下，2PC 是直接锁定数据库中的 balance 字段，而 TCC 是在 frozen_balance 字段中增加数值，这种方式避免了数据库层面的物理锁，极大地提升了并发能力。
业务侵入性的权衡
2PC 的侵入性极低，开发者只需要使用标准的 XA 协议，大部分逻辑由数据库驱动和事务管理器自动完成。
TCC 的侵入性极高，开发者必须为每一个业务操作手动编写三个方法：Try、Confirm 和 Cancel，这不仅增加了代码量，还对逻辑的严密性提出了极高要求，必须处理好以下三个问题：
- 幂等性：Confirm 和 Cancel 可能会因为网络抖动被重复调用。
- 空回滚：Cancel 被调用时，Try 可能根本没执行成功。
- 悬挂问题：Cancel 比 Try 先到达（由于网络延迟）。
分布式事务性能损耗如何解决
随着微服务规模的扩大,分布式事务带来的性能损耗（如网络延迟、锁等待、协调者压力）会成为系统瓶颈。
优化策略与实操路径
缩小事务作用域
不要试图在一个分布式事务中完成所有事情,应尽可能将逻辑拆分为“核心事务”与“非核心事务”。
- 核心事务：使用 TCC 或 2PC 保证核心资产（如钱、库存）的一致性。
- 非核心事务：使用消息队列（MQ）进行异步处理，通过最终一致性来降低主流程的延迟。
引入高性能分布式事务框架
目前业内主流的实践是使用如 Seata 这样的开源框架，Seata 提供了多种模式来适配不同场景：
- AT 模式：基于标准的本地事务，通过解析 SQL 自动生成回滚日志（undo_log），实现了类似 2PC 的效果但性能更好，对业务几乎无侵入。
- TCC 模式：手动实现业务补偿。
- Saga 模式：处理长事务。
优化消息驱动的一致性
对于不需要强一致性的场景,使用“可靠消息最终一致性”是最高效的路径。
- 操作路径：
- 开启本地事务。
- 在本地事务中同时完成“业务数据变更”和“发送事务消息”。
- 事务提交后,消息队列将消息投递给下游服务。
- 下游服务消费消息并执行业务,若失败则通过重试机制保证最终成功。
数据库分库分表与本地事务结合
如果业务可以被设计为“数据路由到同一个分片”，那么分布式事务就可以退化为本地事务，通过合理的 Sharding Key 设计，尽量让关联的操作落在同一个物理节点上，从根源上消除分布式事务的需求。
分布式事务的选择本质上是在 CAP 定理中对一致性（Consistency）与可用性（Availability）的权衡，没有完美的方案，只有最适合业务场景的权衡。
分布式事务解决方案对比 Q&A
如何选择合适的分布式事务方案？
应根据业务价值和并发需求进行分层,对资金、库存等核心资产，优先选择 TCC 或 Seata 的 AT 模式以保证准确性；对于订单状态更新、积分发放等非核心业务，应优先选择基于消息队列的最终一致性方案。
Saga 模式在什么场景下最有效？
Saga 模式在跨多个外部系统（如第三方支付接口、物流系统）且无法控制对方数据库实现时最为有效，由于这些外部系统不提供 XA 或 TCC 接口，只能通过业务层面的补偿逻辑来维持一致性。
分布式事务会导致数据不一致吗？
在极端情况下,如协调者（Coordinator）发生不可恢复的硬件故障且缺乏持久化日志，或者补偿逻辑（Cancel/Compensate）本身存在 Bug 时，会导致数据不一致，分布式事务的设计必须包含完善的监控、对账机制以及人工介入的兜底方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/493446.html
