做了几年的后端开发你会发现有个概念怎么都绕不开那就是“分布式事务”。尤其是当业务从单机单体架构走向微服务、走向分库分表之后事务问题就瞬间从“一条SQL回滚”变成了“一堆服务之间如何保持一致”。更别提单量一大订单系统、库存系统、支付系统各自为政用户下单付款之后发现库存扣了但订单没生成或者订单生成了但库存没扣这哪是bug这简直是事故。今天这篇内容是我自己从理论学习到落地实践把分布式事务完整摸了一遍之后的梳理包括它到底为什么难、主流的解决方案各自什么脾气、以及订单和库存这种典型场景下我实际采用的方案和踩过的坑。不管你是刚开始接触分布式系统的新手还是已经被数据一致性问题折磨过的老手这篇内容都能给你一个相对完整的参考。1. 分布式事务到底难在哪从业务场景说起很多人一上来就背各种方案名称但我觉得先把“为什么难”这个问题想透彻后面理解方案会轻松很多。分布式事务说白了就是要让跨多个独立资源数据库、服务、消息队列的一组操作要么全部成功要么全部失败。听起来好像跟本地事务一样但一个“分布式”三个字注定了它没那么简单。1.1 本地事务的“舒适区”和它的边界在单体时代数据都在一个数据库里事务依赖的是数据库原生的ACID特性。你一个方法里先update订单表再update库存表最后update账户表只要声明了Transactional数据库会通过redo log和undo log来保证这三条SQL要么全生效要么全回滚。整个过程中数据库自己管理锁和日志对应用层几乎是透明的。但到了分布式的场景业务不再是一个进程操作一个库了。订单服务挂在订单库上库存服务挂在库存库上支付服务挂在支付库上。用户下单这个动作变成了订单服务写自己的订单库再调库存服务扣库存还要调支付服务扣钱。问题就在于订单库里的事务已经提交了突然支付服务返回失败你让订单服务和库存服务怎么办它们各自的事务都已经提交完了谁也没法把别人已经提交的数据再撤回。这就是分布式事务最核心的矛盾本地事务只负责单个资源而业务的一致性要求跨越了多个资源。我见过不少团队在这个阶段走弯路比如试图用同一个数据库共享给多个微服务表面上解决了事务问题但其实违背了微服务拆分的初衷。服务是拆了数据还是耦合的后面想独立扩容、独立升级都是空谈。所以当业务真正走向微服务化之后分布式事务就成为一个绕不开的硬技术问题。1.2 分布式事务的两座大山网络不可靠与CAP的取舍除了资源不共享分布式事务还面对两座绕不开的大山网络不可靠以及CAP理论约束下的必然取舍。网络不可靠这一点其实很好理解。单机事务里数据库各组件之间通信是确定性的而在分布式环境里两个服务之间的每一次远程调用都可能出现超时。比超时更棘手的是“不确定状态”——一个请求发出去了到底是对方没收到还是对方处理成功了但响应丢了你根本无从判断。我曾遇到过类似情况调用库存服务扣减库存时超时了但实际库存已经扣了而订单服务这边因为超时认为是失败而做了回滚。两边各执一词对不上账。CAP理论则告诉我们在分布式系统中一致性Consistency、可用性Availability和分区容错性Partition tolerance三者不可兼得。网络分区在某些条件下是必然会发生的所以只能在C和A之间做选择。参与分布式事务处理的各个节点如果追求强一致CP那在有节点失败或分区时往往需要拒绝服务等到数据对齐才恢复如果追求高可用AP那在分区期间允许多个节点暂时不一致让业务继续运转然后在稍后的时间里通过补偿或重试来达到最终一致。明白了这一层你就知道为什么分布式系统里绝大多数场景接受的都不是“实时强一致”而是“最终一致性”了。1.3 为什么“最终一致性”成了必选项在单机数据库里事务ACID里的CConsistency是任何时刻都满足的事务一提交数据就是一致的。但分布式系统里特别是互联网场景下业务要求高并发、高可用不可能为了强一致把所有请求都卡住。所以“最终一致性”几乎成了唯一现实的选择。你可以这样理解最终一致性在某个较短的时间窗口内系统的各个节点数据可能是不一致的比如用户下单后订单已经生成但库存还没来得及扣减但系统会通过重试、补偿、消息确认等机制保证在若干秒或者更短的时间内各个节点的数据逐步对齐。对用户来说这个过程几乎无感知。选择最终一致性意味着在设计上要接受“可能的不一致状态”并且通过状态机、幂等等手段来兜底。比如订单状态可以设计为待支付 - 支付中 - 已支付或已取消、扣减库存可以做预占模式冻结库存 - 扣减、支付可以挂“支付凭证”。每一步都是一个可查询、可补偿的状态这样即使某一步出错了顺着状态机也能把流程拉回来。我个人的体会是很多复杂的分布式事务方案本质都是在“业务状态机”上叠加“消息驱动”或“补偿机制”而已底子都是那套状态流转的思想。2. 主流解决方案对照别急着写代码先选对武器理解了问题背景之后我们再来看看业界有哪些主流解法。每种方案都有自己的脾气和适用边界不存在银弹。我在这里把常见的几类方案拉出来逐一分析它们的核心思想、优缺点、适用场景都讲透。这也是你在方案选型时需要反复权衡的地方。2.1 2PC/XA教科书方案生产环境为啥慎用两阶段提交2PC是分布式事务最经典的协议很多教材和面试题都会考。它的核心思想是引入一个协调者Coordinator把提交过程分成两个阶段第一阶段协调者向所有参与者发送prepare请求参与者执行事务操作但先不提交并反馈是否可以提交如果所有参与者都返回成功协调者再发commit指令所有参与者正式提交事务。反过来只要有一个参与者prepare失败协调者就广播abort大家全部回滚。听起来很完美但2PC在真实生产环境里有几个致命问题。第一是同步阻塞。在prepare之后、commit之前参与者持有的资源锁不会释放如果某个节点出了故障其他所有参与者都要一直等待协调者的下一步指令这段时间里数据库连接和行锁都占着高并发下系统吞吐可以瞬间被拖垮。第二是协调者单点问题。协调者一旦挂了整个协议直接卡死所有参与者都停在“待定”状态。第三是脑裂风险。如果协调者在发送commit指令时网络分区了一部分参与者收到了commit并提交另一部分没有收到依然处于prepare状态两边数据就永久不一致了。所以尽管XA规范在商业数据库里支持得挺好很多互联网公司还是很少直接在核心链路里用2PC。它更适合参与方比较少、对强一致要求极高、而且能容忍低吞吐的场景比如一些金融核心账务操作。不过说实话即便在金融行业越来越多的新系统也在往TCC或Saga方向迁移。2.2 TCC业务侵入强但性能和一致性比较平衡TCC这个名字来自Try、Confirm、Cancel三个阶段。它的思想不是锁定资源等待提交而是用业务操作本身来保证最终一致性。Try阶段尝试执行业务检查并“预占”资源比如冻结用户账户里的部分金额、冻结库存数量但此时并不真正扣减。Confirm阶段如果所有Try都成功了就正式执行业务操作把预占变成真正的扣减。Cancel阶段只要任意一个Try失败就回滚已经预占的资源。整个过程中不需要数据库长时间持有锁吞吐量比2PC高出不少。但TCC的问题在于业务侵入性很强。每个业务操作都要拆成Try、Confirm、Cancel三段并且要处理空回滚和悬挂等异常场景。举个例子订单服务调库存服务时库存服务收到Try请求后成功冻结了库存但订单服务在Try阶段就失败了于是订单服务发起Cancel试图解冻库存。可如果Cancel请求比Try请求先到达库存服务呢或者Try请求丢了这就是“空回滚”和“悬挂”问题。不是说TCC不行而是它把复杂度转移到了业务代码里要求团队对每个细节都想清楚。我个人觉得TCC比较适合规模不大但参与方稳定、性能要求高且愿意投入开发成本的团队。2.3 Saga长事务的救星但要接受“不回滚”Saga的核心思想是把一个长事务拆成一系列有序的本地事务每个本地事务完成后都异步发布事件或调用下一步操作。如果中间某一步失败了就逆序执行对应的补偿操作。比如订单流程创建订单 - 扣库存 - 扣款 - 通知发货每一步都有对应的反向操作取消订单、加回库存、退款。和TCC不同Saga更强调在业务层面对长流程进行拆分与编排实际上更贴合真实的业务长流程。Saga的两种常见实现模式是事件编排和命令编排。事件编排每个服务监听事件并决定自己是执行还是触发新的操作服务之间通过事件总线交互耦合度低命令编排由一个中央协调器告诉各个参与方做什么逻辑更集中认知负担小一点。Saga最大的特点必须提前说清楚它不做“原子回滚”事务的中间结果对外是可见的。比如你创建了订单然后扣库存失败了Saga不会让“创建订单”这件事从数据库里消失而是需要用“取消订单”来补偿。这意味着业务表需要记录足够多的状态和补偿上下文。补偿逻辑写得好不好直接决定系统稳不稳。Saga非常适合那种流程长、跨服务多、允许短时间数据不一致的业务比如旅游订单、采购审批等。2.4 本地消息表与MQ事务消息最接地气的最终一致性方案除了上述几种“事务协议”还有一类非常务实的思路通过消息中间件来驱动数据一致性。其中最有名的就是本地消息表和MQ事务消息。本地消息表的思路是在业务数据库里创建一张消息表业务操作和消息写入放在同一个本地事务中。比如下单时同时向消息表插入一条“扣库存”的消息业务数据和消息一起提交。然后由一个后台任务不断扫描消息表把状态为“待发送”的消息发到MQ消费者收到消息后执行扣库存逻辑。如果执行成功就把消息状态置为“已处理”失败则重试。这个方案实现非常简单不依赖MQ的高级特性很多老系统里都能看到它。缺点是要多一张表、多一个定时任务且消息表会膨胀需要定期清理。MQ事务消息是把本地消息表的逻辑下沉到MQ Broker里面以RocketMQ的事务消息为代表。它的核心机制是先发送一条“半消息”half message到MQ消费者暂时看不到生产者执行业务本地事务执行完成后向MQ发送commit或rollback指令。如果MQ长时间没收到生产者的最终指令会反向请求生产者查询事务状态。这个方案把消息可靠投递的复杂度交给MQ处理对应用层来说相对轻量。我后来落地方案的时候用的就是这个思路的简化版本配合业务状态机和定时对账效果不错。3. 订单与库存的分布式事务我是这么落地的理论知识讲了这么多不落地都是空中楼阁。下面我用一个最典型、几乎每个电商系统都会遇到的场景——用户下单扣库存来完整展示一个分布式事务方案的设计和实现过程。这个方案不是追求理论上的完美而是我在实际业务中验证过的、可靠且可维护性较好的做法。3.1 业务场景拆解下单、扣钱、扣库存三件事用户下单流程看似简单实际参与方至少有三个订单服务创建订单记录、库存服务扣减库存、账户服务锁定或扣减用户余额。用一个分布式事务去包住这三个服务最直观的想法是让它们要么全成功、要么全失败。但真正的业务里一个订单从创建到最终完成中间还有超时未支付自动取消、支付失败退款、库存回补、订单金额优惠折算等一堆子流程如果一开始就把它们捆在一个“大事务”里系统会变得极其脆弱。所以我会把“订单”切成更小的业务动作组合第一步创建订单状态置为待支付第二步锁定库存预占/冻结而不是直接扣减第三步锁定用户资金也是预占避免用户支付的时候余额不足。这三个动作只要都成功订单就可以对外展示为“待支付”用户可以继续支付。如果某一步失败就按逆序做补偿解冻库存、解冻资金、把订单状态置为已关闭。这里的关键点在于“预占/冻结”而不是直接“扣减”。这会带来几点好处一是库存和资金在被真正消费前并不变更业务上更灵活二是如果用户最终不支付订单超时关闭时只需要解冻不用做逆向金额调整三是万一分布式事务失败了补偿逻辑做的就是“解冻”语义非常清晰不容易出错。3.2 整体设计本地事务 事务消息 状态机我最终采用的方案严格来说不是标准的RocketMQ事务消息因为很多系统不一定适合强行引入一套新的MQ。我采用的是一个更普适的组合本地事务 事务消息表 业务状态机 定时对账。这个方案的核心思路用一张表来解释组件职责设计要点订单服务创建订单回调库存和资金服务订单表记录状态机状态同时写入事务消息表事务消息表持久化待投递消息与订单同库同事务记录消息状态为待发送定时任务扫描并投递待发送消息失败重试、超时告警库存服务处理扣库存预占消息接口做幂等冻结库存表设计资金服务处理资金锁定消息接口做幂等余额冻结表设计对账任务定期核对订单、库存、资金状态发现不一致报警并自动补偿订单服务的核心流程是在同一个本地事务里插入订单记录状态为待支付并向事务消息表插入一条“冻结库存并锁定资金”的消息。订单事务提交成功消息生成成功如果订单事务回滚消息也跟着消失。这就是“本地消息表”方案的精髓它用同一个数据库事务来保证业务数据和消息的一致性避免先发消息后业务失败导致的无头消息。然后有一个定时任务比如每秒扫描一次把事务消息表中“待发送”的消息投递到MQ等库存服务和资金服务消费。消费者处理成功后回调标记消息状态为“已发送并处理成功”处理失败则根据重试次数决定继续重试还是报警。注意这里不要求严格实时允许秒级延迟。对绝大多数电商场景来说这个延迟是完全可接受的。3.3 关键代码实现订单服务、库存服务、MQ回调下面我把关键代码和落库设计贴出来并解释每一步的意图。订单服务创建订单的伪代码如下关键点就是TxMessageService和订单数据在同一事务内写入Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private TxMessageMapper txMessageMapper; Autowired private IdGenerator idGenerator; Transactional(rollbackFor Exception.class) public CreateOrderResult createOrder(CreateOrderRequest request) { // 1. 生成订单ID构建订单记录 Long orderId idGenerator.nextId(); Order order new Order(); order.setId(orderId); order.setUserId(request.getUserId()); order.setAmount(request.getAmount()); order.setStatus(OrderStatus.PENDING_PAYMENT.getCode()); order.setCreateTime(LocalDateTime.now()); // 2. 入库这条数据必须和消息在同一个事务里 orderMapper.insert(order); // 3. 构建事务消息消息内容包含冻结库存、锁定资金所需的信息 Long messageId idGenerator.nextId(); TxMessage message TxMessage.delay( messageId, ORDER_PLACE_EVENT, JSON.toJSONString(new OrderPlacedEvent(orderId, request)); ); // 4. 同库同事务写入消息表 txMessageMapper.insert(message); // 5. 返回结果本地事务在这里才真正提交 return new CreateOrderResult(orderId, OrderStatus.PENDING_PAYMENT); } }这里我特别想强调“同库同事务”这个点。很多人一开始容易把消息写入独立的消息服务或者直接用MQ发送但这样的问题是如果订单插入成功、发消息失败就会产生“有订单但未通知下游”的脏数据。而本地消息表方案让业务数据与消息数据共用同一个事务要么一起成功要么一起回滚。这是整个最终一致性方案的基石。库存服务消费消息的伪代码大致如下注意它的三个关键设计幂等表、冻结表、状态机Component public class InventoryMessageConsumer { Autowired private InventoryFrozenRecordMapper frozenMapper; Autowired private InventoryStockMapper stockMapper; Transactional(rollbackFor Exception.class) public void onOrderPlace(OrderPlacedEvent event) { Long orderId event.getOrderId(); Long skuId event.getSkuId(); Integer count event.getCount(); // 1. 幂等校验检查这个orderId是否已经处理过 if (inventoryFrozenRecordMapper.existsByOrderId(orderId)) { return; // 说明消息重复了直接忽略 } // 2. 预占库存更新冻结字段和可用库存 int updated stockMapper.freezeStock(skuId, count); if (updated 0) { throw new InsufficientStockException(库存不足); } // 3. 插入冻结记录这个记录本身就是幂等的凭证 InventoryFrozenRecord record new InventoryFrozenRecord(); record.setOrderId(orderId); record.setSkuId(skuId); record.setFrozenCount(count); record.setStatus(FrozenStatus.FROZEN); frozenMapper.insert(record); // 4. 业务成功后通知消息服务确认消息已处理 messageService.confirmProcessed(event.getMessageId()); } }再看一下freezeStock的SQL。它必须是一个原子操作防止多个订单同时扣减同一SKU导致的超卖UPDATE inventory_stock SET available_quantity available_quantity - #{count}, frozen_quantity frozen_quantity #{count} WHERE sku_id #{skuId} AND available_quantity #{count}这条SQL利用了数据库的行锁来保证并发安全并且通过available_quantity #{count}这个条件天然防止超卖。如果影响行数为0说明库存不够就抛出异常触发消息重试或人工干预。资金服务的设计思路跟库存服务几乎一致先校验幂等再在账户余额表上执行类似“冻结金额”的原子更新插入资金冻结记录。如果不支持冻结操作比如只有一张余额变动流水表也别慌可以用“锁定金额”字段来兜底效果是一样的。3.4 这套方案的优缺点和边界这套“本地事务 事务消息 状态机 对账”方案我用下来最大的感受是它不依赖某个特定的MQ产品也不要求所有服务都上线TCC框架侵入性相对可控。但它也有自己的适用边界。优点方面第一是可靠性很容易保障因为业务数据和消息数据在同一个库里天然拥有数据库事务的保障。第二是代码逻辑直观每个服务只需要关注自己的本地事务、幂等和消息消费不需要实现复杂的协议。第三是延迟可以接受定时任务兜底即使某个MQ消息丢了也能通过对账逻辑拉回状态。缺点方面最明显的是事务消息表会增加数据库负担尤其在高频下单场景下表数据增长很快需要定期归档。其次是“最终一致”的时间窗口可能稍长。如果定时任务扫描周期是1秒那么订单创建后到库存冻结完成通常有几秒的延迟。内部系统还好如果面对用户强感知的抢购场景可能还是需要引入实时调用或者TCC来加快反馈。还有一个很多人容易忽视的问题这套方案依赖消息中间件可靠投递。如果用的是开源的RocketMQ需要开启事务消息机制如果是自研的MQ就需要在Broker层做半消息机制或扩展。如果你们连MQ都没上那可以先把定时任务直接读事务消息表并调用下游HTTP接口效果也是类似的只是吞吐量低一些。4. 实战中踩过的坑与排查思路理论是理想化的实操里处处都是坑。这一节我整理了个人在实际落地分布式事务过程中绕不过去的几个问题每一个都对应具体的场景和排查办法。这些问题不解决方案哪怕设计得再漂亮上线之后也会原形毕露。4.1 消息重复消费幂等设计是底线消息队列的投递语义通常是“至少一次”at least once这意味着消费者可能收到重复消息。哪怕你的MQ号称是“恰好一次”在生产环境我们也永远要假设消费可能重复。最常见的情形是消费者的本地事务提交了但回执消息的处理超时了MQ判定消费失败于是重新投递了一条一模一样的消息。如果没有幂等设计库存就可能会被扣两次用户余额也可能被锁两次。我的经验是所有处理类消息的入口第一行代码必须是幂等校验校验的唯一键通常就是业务流水号比如订单ID。校验方式有两种主流选择。一种是查表判断在业务表里查一下这个订单ID是否已经存在处理记录存在就直接返回另一种是依赖数据库唯一索引利用主键冲突来让重复插入直接失败。我个人更推荐“唯一索引”方案因为查表判断在极端并发下依然存在竞态。比如两个重复消息同时到达都查不到记录都去执行扣减结果还是扣了两次。而唯一索引会在第二次插入时直接抛DuplicateKey异常天然兜底。还必须在设计之初就想清楚幂等记录包含哪些字段、谁负责插入、插入失败怎么处理。我见过不少团队上线后才发现“啊呀下个月账不平”一查就是当年幂等没做好。4.2 空回滚与悬挂TCC方案的两个魔鬼细节如果你最终选择了TCC模式有两个异常细节必须提前设计好否则上线必出大问题。第一个叫“空回滚”简单说就是订单服务在Try阶段失败了于是调用库存服务的Cancel去解冻库存但库存服务的Try请求因为网络延迟或丢包根本没到达Cancel却到了。库存服务发现没有对应的冻结记录直接返回成功还是抛异常都不对。直接返回成功账上没问题但如果你在处理Cancel时发现没有记录就抛异常就会导致订单服务误以为Cancel失败从而陷入重试死循环。规范的做法是Cancel接口要允许“空取消”即没有对应冻结记录时也返回成功。第二个是“悬挂”。和空回滚相反悬挂指的是Try请求在Cancel之后才到达。比如网络重试导致Try被延迟了Cancel已经执行完了后来Try才到达库存服务。此时如果没有状态机把关Try会在Cancel之后把库存又冻结一遍这笔冻结再也无人解冻永远悬挂住。解决办法是在每个参与库提供一张事务控制表以事务ID为唯一键记录当前事务的状态已Cancel、已Confirm、已Try。Try到达时如果发现该事务已经Cancel或Confirm了就直接忽略不再执行业务操作。这块一定要在编码时当作核心逻辑来做不能有贪图省事的想法。4.3 延迟与吞吐别让一致性方案拖垮了性能很多人在设计分布式事务时有一个误区只关注一致性不关注性能。尤其是2PC风格的方案如果参与方一多、执行时间长全局锁会让数据库连接池直接打满。之前我们上线过一个定时任务型的服务因为某个环节调了TCC框架把所有参与方的表都锁了一段时间结果高峰期数据库的活跃连接数直接飙到几千连接池被打爆整个系统响应都变慢了。最后我们调整了方案把强一致的链路拆成了“异步消息 本地事务”的组合吞吐立刻恢复。具体做性能评估时我一般会关注三个指标一是单条链路的最长执行时间二是消息积压的阈值和恢复策略三是补偿任务对数据库的额外压力。如果发现峰值期消息积压超过了预期可以先看看消费者是否有慢SQL或锁等待再看看定时任务是否有重复扫描和重复投递的问题。有一个很常见的坑定时任务扫描消息表时没有做好“分批 多线程 状态互斥”同一个消息被多个实例同时读到导致重复投递。解决办法是给消息表加“消费节点实例标识”或者采用SELECT ... FOR UPDATE SKIP LOCKED等方式锁定一批消息。4.4 排查思路一个分布式事务问题的完整定位流程分布式事务的问题往往不像单体事务那么容易复现。它经常是几个请求同时撞上或者消息堆积达到某个阈值才触发。这里我分享一个自己的排查流程不一定多高级但很实用。第一步先看数据库。把订单表、事务消息表、库存冻结表、资金冻结表的记录捞出来看状态是否匹配。我现在每设计一张关键业务表都会加上“最近更新时间”、“状态机版本”、“关联事务ID”字段就是为了排查用。第二步看日志。消息投递和消费的地方要打印完整的消息ID、业务ID、动作和耗时。对了别只在MQ的消费端打日志生产端的重试、确认、反查都要打。第三步看监控面板。重点看消息积压量、消费失败率、定时任务执行耗时这三个指标。如果是高峰时段异常很可能就是慢SQL或锁等待导致的消费变慢。第四步用对账任务和人工兜底。对账能发现90%的“隐性问题”比如订单已取消但冻结库存还在人工兜底则是对账之后依然无法自动修复的场景通过后台操作或者改数据来恢复。如果你连对账都懒得做那分布式事务基本上就剩“碰运气”了。所以我强烈建议每个团队凡是引入了消息驱动最终一致性的业务都配套建立一个周期性的对账脚本。对账脚本的核查原则很简单遍历订单主表逐条核对下游各参与方是否存在状态匹配的记录不匹配就进待处理队列自动触发重试或告警。几点个人体会做了这么多分布式事务相关的项目我最想跟大家说的是不要一遇到跨服务的数据一致性问题就立刻把“分布式事务”搬出来。很多时候你可以通过接口设计来规避——比如把需要同事务的操作在数据源头合并或者把一个操作从同步调用改成异步补偿系统反而更简单。分布式事务不是一个炫技的领域而是一个“能不用就不用必须用的时候一定要选对方案”的领域。方案选型上没有绝对的好坏只有适不适合你的业务场景、团队规模和可用基础设施。如果团队刚起步、并发也不大事务消息表状态机对账是最稳妥的起点如果业务链路复杂、性能要求高且开发能力强可以挑战TCC或Saga但无论选哪种幂等、状态机和对账这三板斧都是绕不开的地基。希望这篇内容能帮你少走一些弯路也欢迎有实战经验的朋友一起交流你们的方案取舍。