入库出库链路重构从本地事务到 Saga 分布式事务副标题一条出库单要走 6 个服务事务怎么保证1. 问题引入出库单创建到发货中间崩了怎么办最近咱们团队在重构 WMS仓储管理系统的出库链路说实话这事儿让我掉了不少头发。事情是这样的以前系统是个大单体创建出库单、扣库存、生成拣货任务、复核、发货……所有逻辑都在一个服务里一个Transactional注解往方法头上一拍Spring 帮你把事务管得明明白白。出了问题回滚就完事儿了简单粗暴相当安逸。但安逸的日子总是短暂的。随着业务扩张库存、拣货、复核、物流、财务……各个模块都拆成了独立服务。这时候问题来了——用户下了一张出库单系统开始干活订单服务创建出库单库存服务预占库存拣货服务生成拣货任务复核服务扫描复核发货服务通知物流发货库存服务正式扣减库存这 6 个步骤跨越了 5 个服务。假设第 4 步复核服务突然挂了前面库存已经占了拣货任务也生成了后面怎么办回滚可Transactional管不到别的服务啊更惨的是现实里真出过这种事儿某天夜里库存服务成功扣了 2000 件货结果拣货服务因为数据库连接池打满没生成任务。第二天仓库大哥一脸懵——“系统显示库存少了可我这边没任务啊货发还是不发”说白了微服务时代长事务怎么拆分布式事务怎么选这就是咱们今天要聊的核心问题。2. 分布式事务方案对比遇到这个问题我第一反应是业界不是有好几套分布式事务方案吗挑一个合适的就行。但真去研究才发现没有银弹每个方案都有它的脾气。2.1 2PC强一致但太重了两阶段提交2PC大家应该都听过Prepare Commit讲究一个要么全成功要么全回滚数据强一致。但问题也很明显性能差整个过程要锁定资源其他请求得排队等着单点风险协调者挂了所有参与者都得干等着不适合高并发WMS 这种业务高峰期一秒几百单2PC 能把数据库锁哭我一开始也想过要不要用 Seata 的 AT 模式毕竟它对业务侵入小用起来也顺手。但仔细一研究AT 模式底层其实也是基于 2PC 的思路虽然做了不少优化比如异步提交、全局锁细化但本质上还是有全局事务协调的开销。对于咱们这种一步走错就要回滚五六步的长链路来说风险收益比不太划算。咱们这出库链路虽然重要但也不是金融转账那种差一分钱都不行的场景。为了强一致牺牲性能和可用性不值当。2.2 TCC性能好但业务侵入大TCCTry-Confirm-Cancel思路不错先预留资源再确认或取消。性能比 2PC 好得多不锁全局资源。但缺点也很扎心每个接口要拆成 Try/Confirm/Cancel 三个业务代码改造成本巨大Confirm/Cancel 还要保证幂等脑子嗡嗡的我算了算咱们出库链路 6 个步骤每个步骤都要写 TCC 三套逻辑。比如预占库存这个操作Try 阶段要冻结库存Confirm 阶段要把冻结转成正式扣减Cancel 阶段要解冻库存。听起来清晰但落地的时候你会发现库存表结构得改加冻结数量字段原来的业务代码全得重构调用方也要改空回滚、幂等、悬挂这三个 TCC 经典坑一个都不能少团队至少得折腾一个月。工期不允许pass。2.3 Saga长事务友好流程型业务的菜Saga 模式的思路特别简单把长事务拆成一连串本地事务每个本地事务执行完就提交。如果中间某步失败了就按相反顺序执行补偿操作把前面的改动抹回去。我第一次看到 Saga 的时候脑子里冒出的念头是这不就是手动回滚嘛但真用到业务里才发现它简直太适合 WMS 了业务流程本身就是按步骤走的一步接一步天然好拆分每一步都有明确的反向操作占库存 ↔ 释放库存生成任务 ↔ 取消任务不需要全局锁性能影响小业务侵入度比 TCC 低很多现有接口稍微改造一下就能接入而且 Saga 有两种实现方式编排式Choreography和协调式Orchestration。编排式是每个服务做完自己的事发消息通知下一个服务协调式是有一个中央编排器统一调度所有步骤。咱们选的是协调式因为出库链路步骤多、顺序固定有个总指挥看着更踏实出问题也更好排查。2.4 本地消息表简单可靠但实现繁琐本地消息表的思路是在业务库旁边建个消息表业务操作和消息写入用本地事务保证一致。然后有个定时任务去扫表把消息发给下游服务。这个方案简单、可靠、不依赖外部中间件但要自己写消息表、定时任务、消费逻辑异常处理、重试、死信队列都得自己管链路 visibility可观测性比较差出问题不好排查2.5 我们的选择Saga 本地消息表混合使用最后咱们定的方案是主链路用 Saga 编排关键步骤的异步通知用本地消息表兜底。为啥这么搭Saga 负责把 6 个步骤串起来正向执行 反向补偿逻辑清晰本地消息表负责处理一些不需要实时回滚但必须可靠送达的通知比如发货成功后给财务系统发消息两者互补既保证了事务一致性又不过分复杂说白了选方案不是选最牛的是选最适合自己团队和业务的。3. Saga 模式在出库链路中的应用好方案定了咱们看看 Saga 在出库链路里具体怎么落地。3.1 出库流程拆解一条出库单的生命周期咱们拆成 6 个步骤步骤正向操作补偿操作1创建出库单取消出库单2预占库存释放库存3生成拣货任务取消拣货任务4复核通过复核回退5通知发货取消发货6正式扣减库存回滚库存扣减注意不是每一步都会真的触发补偿。比如复核通过了如果发货失败理论上要回退复核状态。但实际业务中复核回退可能涉及扫描数据撤销、PDA 设备状态同步甚至已经打印的面单也要作废非常复杂。所以咱们在方案评审的时候定了一个原则补偿操作的设计一定要结合业务实际能简单回滚的就回滚实在复杂的可以走人工介入或异常工单流程。不能为了技术完美而硬搞否则补偿逻辑比正向逻辑还复杂得不偿失。3.2 Saga 编排器伪代码下面这段是咱们 Saga 编排器的核心思路用伪代码展示// Saga 编排器定义出库单的正向步骤和补偿步骤classOutboundSaga{ListSagaStepstepsArrays.asList(newSagaStep(创建出库单,this::createOrder,this::cancelOrder),newSagaStep(预占库存,this::occupyStock,this::releaseStock),newSagaStep(生成拣货任务,this::createPickTask,this::cancelPickTask),newSagaStep(复核通过,this::confirmCheck,this::rollbackCheck),newSagaStep(通知发货,this::notifyShip,this::cancelShip),newSagaStep(扣减库存,this::deductStock,this::rollbackDeduct));// 执行 Sagapublicvoidexecute(StringorderNo){intcurrentStep0;try{for(;currentStepsteps.size();currentStep){SagaStepstepsteps.get(currentStep);// 关键每步执行前记录状态方便异常恢复sagaLog.save(orderNo,currentStep,EXECUTING);step.getAction().execute(orderNo);sagaLog.save(orderNo,currentStep,SUCCESS);}}catch(Exceptione){// 某步失败了从当前步骤开始反向补偿log.error(步骤 {} 执行失败开始补偿,currentStep);compensate(orderNo,currentStep-1);thrownewSagaException(出库 Saga 执行失败,e);}}// 补偿逻辑从失败前一步开始倒序执行补偿privatevoidcompensate(StringorderNo,intlastSuccessStep){for(intilastSuccessStep;i0;i--){SagaStepstepsteps.get(i);sagaLog.save(orderNo,i,COMPENSATING);try{step.getCompensation().execute(orderNo);sagaLog.save(orderNo,i,COMPENSATED);}catch(Exceptionex){// 补偿也失败了记录告警需要人工介入sagaLog.save(orderNo,i,COMPENSATE_FAILED);alertService.send(Saga 补偿失败单号orderNo步骤i);throwex;// 中断后续补偿避免状态更乱}}}}关键点在哪sagaLog是个持久化日志记录每个步骤的状态。这是 Saga 的黑匣子编排器挂了也能靠它恢复正向操作每成功一步就提交不锁全局事务补偿是倒序执行的先补偿最后成功的步骤一步步往回滚补偿也可能失败比如下游服务也挂了这时候要发告警不能默默吞掉异常3.3 单个步骤的伪代码以预占库存为例看看正向和补偿怎么写// 正向预占库存voidoccupyStock(StringorderNo){// 调用库存服务 RPC 接口stockService.occupy(orderNo,skuList);}// 补偿释放库存voidreleaseStock(StringorderNo){// 调用库存服务释放接口stockService.release(orderNo);}是不是比 TCC 简单多了不用写 Try/Confirm/Cancel 三套正向和补偿各一个方法就行。当然简单的前提是每个服务的接口本身要支持幂等这个咱们下一节专门讲。4. 幂等设计分布式事务的保命符说到幂等这可是分布式系统的生命线。Saga 模式里幂等更是重中之重。4.1 为什么 Saga 步骤必须幂等你想啊Saga 编排器调用库存服务预占库存网络超时了。编排器不知道到底成功没成功只能重试。如果库存服务的预占接口不幂等重试一次就扣两次库存那仓库大哥得拿刀来找你了。再比如补偿阶段释放库存的接口如果被调了两次结果把别人的库存也释放了这谁顶得住还有一个更隐蔽的场景Saga 恢复任务扫描到一笔未完成的记录它不确定某步到底执行成功没于是决定补偿一下保险。如果补偿接口不幂等就可能出现正向其实成功了补偿又执行了一次的双向灾难。所以Saga 的每一步——正向操作和补偿操作都必须幂等。这不是可选项是保命符。4.2 幂等实现业务单号 操作类型 状态机咱们的幂等设计比较简单粗暴但有效幂等键业务单号:操作类型比如SO202404140001:OCCUPY_STOCK每个服务维护一张幂等表记录这个操作是否执行过、执行结果是什么接口进来先查幂等表执行过了直接返回上次结果这里有个小技巧幂等键里一定要包含操作类型。如果你只用业务单号做幂等键那预占库存和释放库存就会互相冲突——同一个单号两种完全不同的操作不能混为一谈。看看幂等拦截器的伪代码// 幂等拦截器在 RPC 接口入口统一处理Around(annotation(Idempotent))publicObjectidempotentIntercept(ProceedingJoinPointpoint){// 从请求参数或 Header 里取幂等键StringidempotentKeyextractKey(point);// 1. 先查幂等表IdempotentRecordrecordidempotentDao.selectByKey(idempotentKey);if(record!null){if(record.getStatus()SUCCESS){// 执行过了直接返回缓存结果returnrecord.getResult();}if(record.getStatus()PROCESSING){// 正在执行可能是并发重入根据业务决定是等待还是抛异常thrownewDuplicateRequestException(请求处理中请稍后);}}// 2. 没执行过插入 PROCESSING 记录idempotentDao.insert(idempotentKey,PROCESSING);try{// 3. 执行业务逻辑Objectresultpoint.proceed();// 4. 成功更新为 SUCCESS 并缓存结果idempotentDao.update(idempotentKey,SUCCESS,serialize(result));returnresult;}catch(Exceptione){// 5. 失败删除或标记为 FAILED允许下次重试idempotentDao.delete(idempotentKey);throwe;}}关键点在哪PROCESSING状态是为了防并发两个相同请求同时进来只有一个能执行业务逻辑成功了缓存结果下次直接返回保证幂等失败了清掉记录让重试有机会重新执行4.3 状态机辅助幂等除了幂等拦截器业务表本身也可以加个状态机。比如出库单表有个status字段CREATED - OCCUPIED - PICKED - CHECKED - SHIPPED - DEDUCTED每次操作前先校验状态预占库存接口收到请求时发现出库单已经是OCCUPIED状态直接返回成功。这是业务层面的幂等和拦截器双保险。5. 异常场景演练纸上得来终觉浅咱们来演练几个真实会踩坑的场景。场景 1占库存成功生成拣货任务失败 → 释放库存这是 Saga 最经典的补偿场景。步骤 1 创建出库单成功 步骤 2 预占库存成功 步骤 3 生成拣货任务失败拣货服务数据库挂了Saga 编排器捕获异常后从步骤 2 开始倒序补偿// 补偿流程cancelPickTask(orderNo);// 步骤 3 还没成功跳过或空操作releaseStock(orderNo);// 步骤 2 补偿释放库存cancelOrder(orderNo);// 步骤 1 补偿取消出库单最终状态出库单取消库存释放数据一致。用户看到的就是下单失败请重试。这里有个细节要注意cancelPickTask在步骤 3 失败时其实还没执行过但咱们的补偿逻辑是统一遍历的。所以cancelPickTask本身也要做成幂等如果查不到这个单号的拣货任务直接返回成功不要抛异常。否则 Saga 编排器会以为补偿失败整个链路就卡住了。场景 2发货成功扣减库存重复调用 → 幂等返回成功假设步骤 5 通知发货成功了步骤 6 扣减库存第一次调用时网络超时Saga 编排器重试第二次。// 第一次调用网络超时实际库存服务已经扣成功了stockService.deduct(orderNo);// - 实际成功但响应丢失// Saga 重试第二次调用stockService.deduct(orderNo);// - 幂等拦截器拦截返回上次成功结果库存服务的幂等表里有记录SO202404140001:DEDUCT_STOCK SUCCESS所以第二次直接返回成功不会重复扣减。场景 3Saga 编排器挂了 → 恢复机制怎么设计这是最吓人的场景。假设 Saga 执行到步骤 4编排器自己所在的服务突然重启了。等它恢复后怎么知道该继续执行还是该补偿答案就是前面提到的Saga 日志sagaLog。// Saga 恢复任务定时扫描未完成的 Saga 记录classSagaRecoveryJob{Scheduled(fixedDelay30000)publicvoidrecover(){ListSagaLogunfinishedsagaLog.selectUnfinished();for(SagaLoglog:unfinished){StringorderNolog.getOrderNo();intlastSteplog.getLastStep();Stringstatuslog.getStatus();if(statusEXECUTING){// 上次正在执行某步时挂了不确定那步到底成功没// 策略先查下游服务状态或者直接补偿重来if(checkStepSuccess(orderNo,lastStep)){// 实际成功了从下一步继续sagaExecutor.resume(orderNo,lastStep1);}else{// 实际没成功从当前步开始补偿sagaExecutor.compensate(orderNo,lastStep-1);}}if(statusCOMPENSATING){// 上次补偿到一半挂了继续补偿sagaExecutor.continueCompensate(orderNo,lastStep);}}}}关键点在哪没有日志编排器挂了就是死无对证EXECUTING状态是最麻烦的因为不知道那步到底执行成功没。所以每个下游服务最好提供查询操作状态的接口方便恢复时确认如果查不了状态保守策略是直接补偿宁可多回滚一次也不要留下不一致数据6. 验证与总结6.1 改造前后的异常恢复能力对比咱们来直观对比一下场景改造前单体 Transactional改造后Saga 幂等库存服务成功拣货服务失败无法回滚其他服务数据不一致自动触发补偿释放库存网络超时导致重复调用可能重复扣减库存幂等拦截返回缓存结果服务宕机事务悬而未决需要人工介入Saga 恢复任务自动处理新增业务步骤改大事务风险高在 Saga 编排器里加一步就行从人工救火到自动恢复这就是重构的价值。6.2 一个血的教训最后分享一个真事儿希望大家引以为戒。Saga 上线后的第一周一切正常。第二周某天仓库反馈有批货明明没发出去系统却显示库存被占了。一查日志发现是一笔出库单在预占库存后“生成拣货任务失败了Saga 也触发了补偿。但补偿逻辑里releaseStock写漏了一个分支——当库存服务返回库存已释放时补偿方法直接抛了个异常说释放失败”。结果呢Saga 编排器以为补偿没成功就反复重试。重试了几次后触发了告警人工介入一看库存其实早释放了但出库单状态因为补偿中断还卡在CREATED。更坑的是那张出库单后来被另一个定时任务重新捞起来又走了一遍预占库存……幽灵库存就是这么来的。那天晚上我盯着日志看了三个小时最后发现问题出在不到十行代码的分支遗漏上。你说气人不气人教训是什么补偿逻辑必须和正向逻辑一样认真写不能因为是回滚就敷衍补偿方法也要幂等下游返回已处理要当成成功不能抛异常上线前一定要把每个步骤的补偿场景跑一遍不能只在脑子里过异常告警要配全但更重要的是告警来了要有人看、有人跟写在最后从单体到微服务分布式事务是绕不开的坎。2PC 太重、TCC 太繁Saga 对于 WMS 这种流程型业务来说是个相当务实的选择。再配合好幂等设计和恢复机制基本能覆盖大部分异常场景。当然Saga 也不是万能的。它保证的是最终一致性不是实时强一致。如果你的业务是转账、对账那种一分都不能差的场景可能还是得考虑更严格的方案。你在项目中是怎么处理分布式事务的用过 Saga 吗有没有踩过什么印象深刻的坑欢迎在评论区交流咱们一起唠唠