在微服务架构里待久了你会发现一个铁律只要拆了服务原本简单的“一个事务搞定”就变成奢侈品。尤其是在 Java 技术栈下订单、库存、积分三个服务各管一个库用户下单时库存扣了、订单建了、积分加了结果最后一步超时用户看到的是“下单失败”数据库里却是“库存已扣、积分已加”——这就是典型的分布式事务事故现场。这篇文章就是来聊清楚这件事的。我会先把分布式事务的底层逻辑拆开讲透然后对比几种主流方案的适用场景再给出一套基于 Java 生态的实操落地步骤最后把我自己踩过的一些坑整理成问题清单。不管你是在做电商、支付、OTA还是企业内部系统重构只要你的服务拆了、库也分了这篇文章都值得你花十分钟读完。1. 先搞清楚分布式事务到底难在哪很多人一上来就背方案、记框架结果遇到实际问题照样懵。根本原因是对“难在哪”没有体感。这一节先把底层矛盾讲清楚。1.1 单体时代的事务是“本地事务”在单体应用里所有业务逻辑在一个进程内数据存储在一个数据库实例中。你通过Transactional开启一个数据库事务操作多张表要么全部提交要么全部回滚数据库自带 ACID 保证原子性Atomicity要么全部成功要么全部失败一致性Consistency事务前后数据满足约束隔离性Isolation并发事务互不干扰持久性Durability提交后数据不丢失。这套机制之所以能成立前提是事务的参与者表和行锁都归同一个数据库管理。回滚时数据库只要检查 undo log 就能恢复现场。整个过程没有网络调用没有跨进程状态同步可靠性极高。1.2 拆成微服务后事务的“地基”没了当你把单体拆成订单服务、库存服务、支付服务、积分服务每个服务独立部署、独立数据库事务就变了味事务边界被切碎了。原来一个OrderService.createOrder()内部可以同时操作 order 表、inventory 表、coupon 表现在这三张表分属三个服务的三个库。你无法再用一个数据库连接开启一个事务本地事务的“原子性”立刻失效。网络调用引入了不确定性。跨服务调用本质是网络 IO对方服务可能接收请求后处理成功但响应在返回途中丢失也可能处理失败但你收到的是超时。你无法区分“没处理”和“处理了但通知不到”。这就是分布式系统里著名的“幽灵请求”问题。无法全局回滚。本地事务里一条rollback就完事了分布式场景下订单服务想回滚但库存服务的扣减已经提交了你得调用一个“回滚接口”去把库存加回来。靠什么保证这个回滚调用一定能成功很难。再叠加并发和其他服务故障复杂度指数级上升。1.3 用生活化类比理解这件事你把分布式事务想象成“四个人一起去餐厅吃饭AA 制买单但每个人单独结账”单人结账时发现钱不够一个按钮退回大家钱包不动。四个人各自结账后有人发现套餐里有过敏原需要退单。这时候你得分别通知其他三个人退各自那份。第三个人电话打不通你退不干净。更麻烦的是可能有人已经吃了已提交有人还没吃未提交状态各不相同——你要让所有人回到“没吃”的状态几乎不可能。这就是分布式事务的处境。所以标准的 ACID 在分布式环境下很难直接满足业界普遍采用“放弃部分一致性换取可用性和性能”的思路也就是 BASE 理论基本可用、软状态、最终一致性。1.4 一个关键结论需要先记住分布式事务没有银弹。不存在一个框架能解决所有场景且永远高性能、永远强一致。你必须在一致性强度、性能损耗、实现复杂度、业务侵入性这四个维度之间做取舍。选型之前先问自己这笔业务真的需要强一致吗还是可以允许几秒甚至几分钟的最终一致想明白这个问题后面的方案选择才不会走偏。2. 主流方案全景从强一致到最终一致你的选择依据是什么业界处理分布式事务的成熟方案大体分两类强一致型和最终一致型。强一致型以 XA 两阶段提交为代表最终一致型以 TCC、SAGA、发件箱模式为代表。我逐个说完适用场景再给出选型建议。2.1 XA 两阶段提交2PC理论最完美现实最骨感XA 协议是数据库层面支持的标准分布式事务协议Java 生态里对应的是 JTAJava Transaction API。它的流程是准备阶段prepare事务协调者向所有参与者发送 prepare参与者执行本地事务但不提交锁定资源返回“准备好了”或“失败”。提交阶段commit/rollback协调者收集所有 prepare 结果如果全部成功就广播 commit只要有任意一个失败就广播 rollback。优点非常明显强一致要么全成功要么全失败业务代码无侵入。但它的问题也同样致命准备阶段要持有数据库行锁/表锁直到全局提交锁持有时间随着参与者增多和网络延迟拉长系统吞吐量会急剧下降高峰期很容易把数据库拖死。协调者是单点一旦协调者宕机且没有持久化状态所有参与者都会卡死在“已 prepare 未 commit”状态数据库锁不释放业务直接瘫痪。主流互联网公司基本不会在生产环境大规模用 XA更多是留给银行、电信这类对强一致要求极高、但并发量不恐怖的场景。我的判断Java 微服务架构里除非你的业务真的无法容忍任何最终一致窗口而且并发量可控否则不要轻易选 XA。更多时候你听到的“分布式事务”其实是下面这些柔性方案。2.2 TCCTry-Confirm-Cancel性能好业务侵入性高TCC 是一种基于业务层的补偿方案核心是把一个分布式事务拆成三个阶段Try完成资源预留不真正执行业务。比如下单时在库存服务里冻结库存而不是直接扣减。Confirm所有 Try 成功后真正执行业务。比如把冻结的库存真正扣掉。Cancel任意一个 Try 失败把已经预留的资源释放。比如把冻结的库存解冻。TCC 的优点在于事务控制粒度细性能比 XA 好得多因为它只在业务层操作不需要长时间持有数据库锁。缺点也非常明显每个服务都要实现三个接口而且每个接口都要做幂等处理因为网络重试和框架回调都可能让同一个接口被调用多次。空回滚是经典坑Try 还没执行成功Cancel 先被调用了。比如订单服务超时框架直接发起 Cancel但库存服务的 Try 请求才刚发出还没落地。Cancel 如果直接执行“解冻”就会把一笔没冻结过的库存解冻掉数据全乱了。状态机设计复杂Confirm 和 Cancel 失败后的重试策略要靠业务方自己兜底。TCC 适合那些需要强资源约束、业务动作明确可拆为三步的场景比如扣减余额、扣减库存、锁定优惠券。如果只是简单的“插入一条记录”TCC 就是杀鸡用牛刀。2.3 SAGA长事务的最优解靠“异步补偿”换取松耦合SAGA 模式的核心思想把一个长事务拆成一系列有顺序的本地子事务每个子事务都有对应的补偿操作compensation。流程走到第 N 步失败时执行第 N-1 步的补偿第 N-2 步的补偿……直到全部回滚完成。举个例子订单创建 扣库存 加积分订单创建 - 扣库存 - 加积分 cancel订单创建 - cancel扣库存 - cancel加积分如果加积分失败则执行扣库存的补偿库存回补再执行订单创建的补偿订单置为失效。SAGA 有两种执行方式编排式Orchestration由一个中心协调者如状态机引擎负责调用各个服务。好处是流程清晰、可集中管理坏处是协调者本身可能成为瓶颈和单点。协同式Choreography每个服务完成后发布领域事件触发下一个服务。好处是没有中心节点、调用关系解耦坏处是流程隐晦出了问题时排查链路很费劲。SAGA 的优点是不需要 Try 阶段那种侵入性强的资源预留业务代码相对自然也没有 XA 那种长时间锁表问题。它能优雅地处理跨十几个服务的长流程事务在互联网场景中应用极广。它的问题在于最终一致性窗口——中间状态是对外可见的。比如库存扣了但订单还没创建成功用户查库存时可能会看到“少了一件”。另外补偿动作本身也可能失败需要靠重试机制 日志追踪来保证最终收敛。我的判断如果你的业务模型是“长流程 多步骤”并且能接受短暂的中间状态SAGA 是最优先考虑的方案。配合可靠消息和定时任务做最终兜底能覆盖绝大部分微服务业务场景。2.4 可靠消息发件箱模式 / Outbox把分布式事务变成“本地事务 消息”发件箱模式是我个人最推荐优先考虑的一种轻量方案。它的核心思路非常巧妙把分布式事务的范围缩小到“业务操作 本地消息表”这两个动作然后用消息中间件异步传播最终一致性。具体做法在业务数据库里建一张outbox表发件箱表。业务操作和消息插入在同一个本地事务里完成。通过一个后台任务或 CDCChange Data Capture组件读取 outbox 表把消息发给消息队列RocketMQ / Kafka / RabbitMQ。下游服务消费消息执行自己的本地事务。如果业务操作提交成功outbox 表里就一定有数据如果业务操作提交失败outbox 表里也没有数据。这样你就不需要跨服务调用来保证一致性了只需要保证本地事务的完整性即可。消息是否发送成功、下游是否消费成功全交给消息队列的重试机制处理。这个方案的精髓在于完全避免网络调用参与事务边界。大多数时候你的业务根本不需要同步调用来完成比如“订单创建成功后给用户发通知”“积分累计后更新会员等级”这些都是天然适合异步的。2.5 一张表看懂选型思路方案一致性强度侵入性性能影响适用场景不适用场景XA / 2PC强一致低高锁表银行、金融核心账务高并发互联网业务TCC强约束高中资源预留类业务扣减库存/余额简单消息通知类SAGA最终一致中中长流程、多步骤、可补偿需要严格实时一致的场景发件箱支持“错误是真实存在的需要正视但不必恐惧。做分布式事务和做单机事务最大的区别就是你不能指望一个“万能组件”帮你搞定所有一致性而是要预判每一步可能出的错提前设计好兜底策略。数据模型支持幂等处理唯一约束/业务主键。真正的稳定来自于对每个环节失败情况的充分理解和周密准备。文章接近尾声我把个人认为最宝贵的经验总结一下。首先分布式事务不是“引入框架”就能解决的技术选型必须紧跟业务场景。强一致场景可以优先考虑 XA高并发资源约束用 TCC长流程多步骤用 SAGA链路简单/弱一致性用发件箱或自动员队列。其次无论选哪种方案幂等机制和保留中间状态日志都是必须的基础配置。最后不妨用数据一致性模板重构团队协作方式在经常出现的场景里建立统一的异常反馈和处理机制减少重复踩坑降低排查时间。分布式事务的世界里没有魔法棒但每个细节打磨到位后系统会逐渐变得可靠运行得越来越顺。