一次聚合配送超时引发的状态不一致：从预扣退款到订单无法完成的全链路复盘

Engineering Case Study · Root Cause Analysis · Postmortem核心结论聚合配送在 30 秒等待边界把“结果未知”判成“确定失败”返还了商户配送预扣款第三方平台订单其实已经创建。骑手接单与取消补偿又在同一秒发生竞争最终系统留下“主订单待完成、配送单已取消、配送余额已返还”的状态。本文对订单号、商户、门店、账号、平台单号和真实表名进行了脱敏。示例订单号为ORD20261013****45623但技术架构、状态流转、问题机制和解决逻辑保持不变。1. 背景与问题外卖订单通过聚合配送服务管理平台询价、商户配送余额预扣、第三方发单、骑手状态回调和主订单状态流转。该流程跨越多个服务和数据库还包含无法由本地事务回滚的第三方平台调用。本次事件表面上出现了三个互相矛盾的现象商户配送余额先扣后退第三方平台存在真实配送单且骑手接单主订单却一直停留在“待完成”。顾客订单实付 27.92 元顾客退款累计为 0 元。商户配送余额预扣 9.10 元30 秒后全额返还。第三方平台 U 在退款前已经创建配送单退款后骑手接单。系统生命周期同时记录了接单与取消成功之后没有配送完成状态。2. 目标与约束排查目标区分顾客退款与商户配送余额返还。判断第三方平台是否真实创建配送单。还原订单、配送账本、平台订单和回调的时间线。解释订单为什么不会自动完成。给出适用于多跑腿平台的长期修复方案。证据边界事件发生两天后相关服务已经重新发布容器标准输出不再保留事发日志。排查主要依据数据库记录、订单生命周期、当前部署代码和老系统任务代码。30 秒时间差与代码超时配置能够形成高置信度证据链但无法恢复当时完整的请求 ID 和异常栈。3. 系统架构图 1聚合配送系统架构架构中最关键的边界是平台下单属于外部副作用。即使本地等待超时第三方平台仍可能已经创建订单。订单数据库与跑腿数据库之间也没有跨库事务只能依赖接口、事件和对账实现最终一致性。4. 数据模型与 ER 关系4.1 为什么在旧订单库查不到结论这不是同一套老系统里存在两张可以互相替代的主订单表也不是本次主订单被删除。系统拆分后旧单体应用和新订单域各自维护独立存储本次订单写入新订单域的主订单表没有双写到旧单体订单表因此在旧库按业务订单号查询自然返回空结果。排查时应先确认订单由哪个服务创建再到该服务的数据源查询。示例中旧库表记为legacy_order_main新订单域表记为order_main。两者可能保留相似字段和业务订单号格式但不构成主从表关系也不存在数据库外键是否同步取决于专门的迁移、事件或双写机制。存储边界表职责本次查询结果旧单体库legacy_order_main承载旧链路订单没有记录符合未双写的架构新订单域order_main承载当前订单全生命周期主订单存在逻辑删除标记为有效因此“查询无记录”和“记录被逻辑删除”必须分开判断前者可能是查错数据源后者需要在正确表中绕过默认逻辑删除过滤并核对删除标记。本次主订单属于前一种情况逻辑删除风险发生在平台配送记录层而不是主订单层。图 2核心数据模型与业务关联示例表职责关系本次事件中的表现order_main主订单、支付、退款和完成状态主记录保持待完成顾客退款为 0delivery_fee_occupation配送费预占、返还和结算逻辑 1:1预占 9.10 元并全部返还merchant_delivery_ledger商户配送余额流水逻辑 1:N产生 -9.10 和 9.10 两条流水platform_delivery_order平台询价、发单和骑手状态逻辑 1:N真实平台单创建、接单、取消随后失效delivery_operation_log配送操作和状态里程碑逻辑 1:N记录发单、接单和取消动作这些表通过业务订单号关联没有跨数据库外键。平台订单号则是回调、主动查询、取消和账务对账的关键映射。只要第三方已经返回真实平台订单号本地记录就必须可追踪、可回调、可恢复。5. 正常数据流与执行流程图 3正常聚合配送数据流正常流程应先预占余额再发起平台订单。平台成功后保存订单号并等待状态回调只有平台明确未创建订单或者平台订单确认取消成功后才能返还预扣款。询价 → 预占配送余额 → 并行调用所选平台 → 保存平台订单号 → 接单 → 取货/配送中 → 配送完成 → 更新主订单完成状态6. 事件时间线图 4故障事件时间线时间系统事实说明21:13:20顾客订单创建支付成功顾客退款为 021:16:20预扣配送费 9.10 元进入聚合发单阶段21:16:45平台 U 创建真实订单已经产生不可忽略的外部副作用21:16:50返还配送预扣费 9.10 元与预扣时间刚好相差 30 秒21:16:53骑手接单同时记录取消成功接单回调与补偿取消发生竞争21:19:07再次记录取消成功本地平台配送记录随后失效之后主订单保持待完成没有取货、送达或完成状态事实澄清系统证据只能证明平台单创建、骑手接单和取消成功不能证明已送达。如果业务现场确认实际送达必须以平台后台最终状态、轨迹和结算账单进一步对账。7. 核心设计与关键实现7.1 异步平台调用与固定超时聚合服务为所选平台创建异步任务再通过固定 30 秒上限等待结果DeliveryResult result future.get(30, TimeUnit.SECONDS);问题不在于设置了超时而在于超时后的语义。当前实现把超时结果直接加入失败集合当收集到的结果全部失败时系统立即返还配送预扣款。7.2 平台调用的外部副作用平台 U 在 21:16:45 已经创建真实订单但聚合层在 21:16:50 才到达等待边界。即使 Future 返回超时外部订单也不会自动消失。超时任务还可能继续运行平台回调也可能继续到达。7.3 接单与取消补偿竞争聚合层判失败后进入退款与取消补偿流程而平台侧骑手已经开始抢单。21:16:53 同时出现“骑手接单”和“取消成功”生命周期说明两个异步流程在同一平台订单上发生竞争。7.4 逻辑删除的语义混用平台记录的逻辑删除原本用于隐藏失效询价或取消订单但普通 ORM 查询会自动附加deleted 0。一旦真实平台订单被删除后续回调、主动查询和审计都会更难匹配。页面可见性不应决定第三方回调是否可达。7.5 自动完成任务覆盖范围老系统的凌晨自动完成任务只扫描自取和堂食订单不覆盖第三方外卖配送。外卖订单依赖平台完成回调平台单被取消后本单不会被定时任务自动完成。8. Symptoms → Investigation → Root CauseSymptoms商户配送余额先扣后退。订单显示待完成。业务反馈可能已经履约。平台侧曾创建订单并接单但系统没有完成状态。Investigation核对主订单退款字段确认顾客退款金额为 0。核对配送余额流水确认 9.10 元是商户配送预扣返还。核对平台订单号、发单时间和接单时间确认外部订单真实存在。核对订单生命周期发现接单与取消成功在同一秒出现。将预扣与退款时间差和代码中的 30 秒超时对齐。检查老系统自动任务确认第三方外卖不在自动完成范围内。Root Cause直接根因聚合服务把“30 秒内没有得到成功结果”当成“平台确定没有下单”。并发根因超时退款和取消补偿与平台接单回调并发执行缺少统一状态机。数据根因平台记录的逻辑删除同时影响展示、回调和对账职责混杂。逃逸根因没有主动查询和定时对账无法自动收敛超时、取消和回调丢失造成的不一致。9. 5 Whys 根因追踪为什么主订单一直待完成因为没有平台配送完成状态驱动主订单完成。为什么没有完成状态因为平台订单在接单附近进入取消流程没有形成正常的取货和完成链路。为什么已经创建的平台订单会被取消因为聚合层在 30 秒等待边界把本次发单判成失败并启动补偿。为什么超时会被当成确定失败因为结果模型只有成功和失败没有“结果未知”和“取消待确认”。为什么状态没有最终收敛因为缺少按平台订单号主动查询、定时对账和异常人工队列。根本原因系统没有正确建模分布式调用中的不确定状态把“没有及时收到成功响应”错误地等同于“外部操作没有发生”。10. 方案取舍方案优点问题结论延长固定超时改动小可降低部分超时只能降低概率无法消除不确定状态同步资源占用更久不作为根治方案超时后立即取消尝试回收外部副作用取消可能与接单并发取消结果本身也可能超时必须配合状态机和查询结果未知 主动查询 对账能够表达真实状态并最终收敛需要增加状态、任务和幂等设计推荐11. Resolution11.1 存量订单处理按脱敏平台订单号查询第三方后台最终状态、轨迹和结算费用。若确认实际送达人工完成主订单并记录处理原因。核对平台实际成本与商户配送余额本单预扣已经返还不能假设账务已经结清。顾客订单退款累计为 0不应重复向顾客退款。扫描同时间段“预扣已返还但平台订单号不为空”的订单排查同类事件。11.2 P0 热修复超时后进入RESULT_UNKNOWN禁止立即退款。按业务订单号主动查询平台是否已经创建订单。只有平台明确未创建订单或取消成功得到确认后才能返还预扣款。平台提示订单 ID 已存在时优先复用已有平台单禁止删除包含真实平台订单号的记录。回调使用平台订单号执行包含历史记录的专用查询并验证签名与状态迁移。11.3 P1 一致性改造PENDING ├─ SUCCESS ├─ FAILED_CONFIRMED ├─ RESULT_UNKNOWN ├─ CANCEL_PENDING └─ CANCELLED引入order_no dispatch_round业务幂等键。同一订单的发单、重试和重新询价使用分布式锁或唯一约束。每次发单尝试保存独立记录不覆盖历史询价和平台订单。余额预占、平台下单、取消和退款以 Saga 状态机推进。11.4 P2 对账与可观测性定时查询长时间未完成的第三方平台订单。扫描主订单、平台订单和配送账本之间的不一致状态。无法匹配的回调进入死信表并支持重放。日志统一记录业务订单号、平台订单号、发单轮次、请求 ID 和 Trace ID。监控聚合超时、未匹配回调、预扣已返还但平台单仍有效、外卖待完成超时等指标。12. Verification验证项当前事件结果顾客是否退款否累计退款为 0商户配送预扣是否返还是9.10 元已返还平台是否真实创建订单是存在平台订单号与发单时间骑手是否接单是存在接单时间平台订单是否进入取消是生命周期存在取消成功是否存在取货或完成状态否主订单是否完成否仍为待完成老系统是否会自动完成该外卖订单否修复后的必测场景平台在 29 秒返回成功聚合结果应为成功。平台已创建订单但客户端在 31 秒才收到结果应进入结果未知且不得退款。超时后主动查询到平台订单应补绑定订单并继续处理回调。平台明确返回订单不存在系统才允许退款。取消失败或取消状态未知时不得删除平台记录或返还预扣款。同一订单连续点击两次发起配送只能产生一个有效发单轮次。重复回调不得产生重复扣款、退款或订单状态回退。完成回调丢失后对账任务应能够主动查询并收敛主订单状态。13. Troubleshooting 手册查询主订单的支付、退款、配送方式、配送状态和完成时间。查询配送余额流水区分顾客退款与商户配送余额返还。查询配送费预占记录核对累计预占、累计返还和当前占用。查询各平台订单检查平台订单号、发单时间、接单时间、状态和逻辑删除标记。查询订单生命周期与配送操作日志确认发单、接单、取货、完成和取消事件。按平台订单号查询第三方最终状态和结算账单。把数据库时间线与应用超时阈值对齐识别时间边界问题。检查自动任务覆盖的订单类型避免误认为所有订单都有自动完成兜底。操作注意不要在未确认平台最终状态前直接恢复、删除或重新创建配送记录否则可能造成重复配送、重复扣款或错误退款。14. Lessons Learned超时不是失败而是结果未知。外部平台订单号是不可丢失的业务资产。页面隐藏、业务取消和回调可达性必须使用不同字段表达。账务退款必须建立在可验证的业务状态之上。回调不是唯一的状态收敛手段关键链路必须主动查询和定时对账。分布式流程需要显式状态机、幂等键和补偿机制。集中式日志和统一 Trace ID 是跨服务故障复盘的基础设施。15. 后续优化计划优先级工作项预期结果验收方式P0超时进入结果未知不再直接退款31 秒延迟响应测试P0保护真实平台订单记录重试询价不再删除有效订单订单 ID 已存在测试P0平台最终状态和账务对账消除存量影响平台账单与本地流水核对P1订单级幂等和并发控制避免重复发单和交叉补偿并发双击测试P1退款前确认未下单或取消成功避免平台单存在但余额已返还取消超时测试P2主动对账与死信重放回调丢失后仍能最终收敛丢弃完成回调演练P2集中日志和异常告警缩短发现与定位时间按业务订单号检索全链路16. 总结本次事件由“聚合发单超时被当作确定失败”触发并与平台接单、补偿取消并发交叉。系统虽然成功返还了配送预扣款但第三方已经创建平台订单导致本地账务、平台状态和主订单状态短时间内出现分裂。平台订单最终进入取消流程主订单没有完成回调也不在老系统自动完成任务的覆盖范围内因此长期停留在待完成。修复重点不是简单延长超时时间而是正确处理分布式调用的不确定状态超时后主动查询取消后确认结果退款前验证业务事实平台记录保持可追踪并通过幂等状态机和定时对账让所有状态最终收敛。