本文目录导读：
这是一个非常核心且复杂的问题，开源项目中处理分布式事务没有“银弹”，关键在于根据业务场景选择最合适的一致性模型和实现方案。
下面我会从几个主流开源项目的实践出发,梳理它们处理分布式事务的思路和方法。
核心思想：从强一致性到最终一致性
首先要明确一点，分布式环境下，传统的ACID（原子性、一致性、隔离性、持久性）强一致性事务（如单机数据库的本地事务）性能极差，且难以实现，现代分布式系统普遍遵循CAP理论和BASE理论，从追求“强一致性”转向追求“最终一致性”。
主流开源项目的处理方案
| 方案/项目 | 核心思路 | 优点 | 缺点 | 典型开源项目 |
|---|---|---|---|---|
| XA协议 | 两阶段提交（2PC），有协调者，先准备（Prepare），再提交（Commit）或回滚。 | 强一致性，实现简单（数据库原生支持）。 | 性能差（同步阻塞），单点问题（协调者），协议复杂，扩展性差。 | Atomikos（Java JTA）、Narayana（JBoss） |
| TCC模式 | 业务层面的两阶段：Try（预留资源）、Confirm（确认执行）、Cancel（回滚）。 | 性能比XA好，没有全局锁，侵入性强（需业务层实现）。 | 实现复杂，需定义3个接口；空回滚、幂等性、悬挂问题难以处理。 | Seata（阿里）、ByteTCC、EasyTransaction |
| Saga模式 | 将长事务拆分为一系列本地事务，每个本地事务有对应的补偿（Compensation）操作。 | 异步执行，性能高，适合长事务和业务流程。 | 隔离性弱（中间状态可见），补偿业务逻辑复杂。 | Seata、ServiceComb Saga（华为）、Axon Framework |
| 可靠消息最终一致性 | 利用消息队列（MQ）实现异步解耦，发送方确保消息可靠发送，接收方确保消息可靠消费。 | 解耦能力强，性能高，应用最广泛。 | 最终一致性，不支持回滚（如订单已发，取消订单需发补偿消息）。 | RocketMQ（事务消息）、RabbitMQ（需结合本地消息表） |
| 最大努力通知 | 发起方尽力通知接收方，不保证100%成功，适用于对实时性要求不高的场景。 | 实现最简单，对系统侵入小。 | 一致性最弱，需要接收方做幂等。 | MQ（重试+回调接口） |
深入解析：几个重量级开源项目的实践
Apache Seata（最热门的分布式事务解决方案之一）
Seata是一个一站式分布式事务解决方案，提供了AT、TCC、Saga、XA四种模式，它的核心设计是TC（事务协调器）、TM（事务管理器）、RM（资源管理器）。
- AT模式：Seata的杀手锏，它通过代理数据源，自动生成对数据库的
UNDO_LOG，并利用全局锁实现自动回滚，对业务代码零侵入，性能损耗小（弱于Saga，但强于XA）。- 工作流程：TM向TC开启全局事务 -> 各RM（数据库）执行业务SQL，TC自动记录前后镜像（UNDO_LOG）-> 所有RM成功后，TM通知TC全局提交，TC删除UNDO_LOG；否则全局回滚,TC调用UNDO_LOG反向执行SQL恢复数据。
- 其他模式：TCC（需业务层实现Try/Confirm/Cancel）、Saga（适合长流程）、XA（兼容原XA）。
适用场景：大规模微服务架构,希望用最小改动实现分布式事务。
Apache RocketMQ（可靠消息最终一致性的标杆）
RocketMQ提供了事务消息功能,完美解决了消息发送和业务操作的原子性问题。
- 核心机制：两阶段提交 + 服务端回调。
- 第一阶段：发送方发送
Half消息（半消息）到RocketMQ Broker,此时消息对消费者不可见。 - 第二阶段：发送方执行本地事务（如扣库存）。
- 提交/回滚：根据本地事务结果，发送
Commit或Rollback指令给Broker，Commit后，消息对消费者可见；Rollback则删除半消息。 - 事务反查：如果发送方本地事务执行完毕，但Commit/Rollback指令未发送（如宕机），Broker会定期回调发送方接口，询问本地事务状态,保证最终一致性。
- 第一阶段：发送方发送
适用场景：业务逻辑解耦明显，能接受最终一致性的场景，如订单中心、积分系统、消息通知等。
ServiceComb Saga（华为开源的Saga实现）
它通过事件驱动的方式编排Saga事务。
- 核心机制：定义Saga流程（一个抽象类或注解），包含正向服务调用和对应的反向补偿方法，Saga Coordinator负责编排，当正向步骤执行失败时,自动反向执行已成功步骤的补偿方法。
- 优势：与Seata Saga的不同在于，它更强调事件驱动和服务编排,适合大型复杂的业务流程编排。
适用场景：长业务流程，如预订系统（机票+酒店+租车）、订单状态流转等。
如何选择？ —— 决策指南
| 业务场景 | 推荐方案 | 原因 |
|---|---|---|
| 银行转账、扣款（强一致性要求） | Seata AT / XA模式 | 需要保证金额分毫不差，优先保证一致性，性能可接受。 |
| 下单扣库存（核心业务，需要回滚） | Seata AT / TCC模式 | AT自动回滚，TCC则需业务实现，但性能更好，通常选AT。 |
| 用户注册送积分（最终一致性） | RocketMQ事务消息 | 解耦，高性能，允许短时间内积分未到账。 |
| 订单履约流程（创建->支付->发货->评价） | Saga模式 | 长流程，每个步骤独立，失败时可灵活选择回滚或挂起。 |
| 数据同步、日志记录（弱一致性） | 最大努力通知 + 幂等 | 实现简单，稳定可靠。 |
- 没有万能方案：分布式事务的核心是“业务妥协”和“架构选择”，必须根据业务的数据一致性要求（强、弱）和性能要求选择。
- 幂等性是基石：无论选择哪种方案，接口的幂等性都是必须做好的，网络重试、消息重复是常态。
- 补偿业务是难点：在TCC和Saga中，反向的Cancel/Compensate业务逻辑非常复杂,需要在设计时就规划好。
- 监控和告警不可少：分布式事务链路长，需要完善的日志、链路追踪（如Skywalking）和告警系统，以便快速定位问题，比如Seata长时间未提交的事务、RocketMQ中长时间未消费的消息等。
一个实用的建议：
如果业务一致性要求极高、实时性要求也高，且团队有能力做技术攻坚，Seata AT是一个很好的起点，如果业务允许放松一致性、追求高吞吐量，RocketMQ事务消息是业界成熟的首选。
面试/实践时，可以这样回答： “分布式事务处理的核心是权衡一致性与可用性，我了解的开源项目中，主要分为几类：一是基于XA协议的强一致性方案，如Atomikos，但性能是瓶颈；二是业务层面的TCC模式，如Seata，通过Try/Confirm/Cancel实现；三是最终一致性方案，如RocketMQ的事务消息和Seata Saga，在实际项目中，我倾向优先使用消息队列（如RocketMQ）实现可靠消息最终一致性，因为对业务侵入小、性能高，对于核心资金链路，会考虑引入Seata的AT模式，通过代理数据源实现自动回滚，但需注意其对数据库锁的影响。”
