规则算出优惠只是开始。真正进入支付、取消、超时和退款后系统必须保证同一权益只履约一次、预算不超卖、失败可补偿、余额可重算、资金流可审计。本篇用一次“确认超时后错误重试”的脱敏事故拆解 Reservation、Ledger、Outbox / Inbox、状态机与对账闭环。Benefit LedgerBudget ReservationOutbox / InboxRCA / Postmortem结论先行预算控制不是对一个余额字段做加减而是以稳定业务幂等键 Reservation 状态机 不可变 Ledger 条件更新 Outbox / Inbox 对账补偿共同构成的履约协议。超时后不能猜成功或失败必须查询状态并复用同一操作身份。案例边界与脱敏本文中的租户、预算账户、订单、支付单、优惠券和流水号均为示例值例如tenant_demo、budget_demo_monthly、order_demo_10001。案例保留技术机制、表关系与事故成因不包含真实业务标识。1. 背景与问题算出优惠不等于权益已经安全履约第九篇已经把营销规则收敛为可编译、可审批、可回放的 Rule Artifact但 Pricing 输出的 Benefit Candidate 只是“应该给多少优惠”。当订单进入支付、取消、超时和退款阶段系统还要回答预算是否已冻结、支付成功后是否正式核销、失败后何时释放、部分退款如何回补以及消息重复和服务超时是否会改变最终资金结果。一次支付演练中订单先成功预占 30.00 元预算支付成功后 Commit 在服务端已经完成但调用方等待超时。重试代码生成了新的 requestId并再次执行 Reserve。由于唯一约束只覆盖 requestId同一订单产生两个有效预占和两条扣减流水。表面症状是预算余额下降真正问题却是命令身份、状态机与账本没有形成统一契约。图 1预算被重复扣减的事故链2. 目标与约束把权益履约变成可证明的状态迁移目标可验证标准关键约束不重复履约相同业务操作重复调用返回同一 reservationId 与结果不能把每次 HTTP requestId 直接当业务幂等键预算不超卖available 永不小于 0并发成功金额不超过可用额度检查与扣减必须在同一原子条件更新中状态可解释每次 Reserve / Commit / Release / Reverse 都有合法前序状态禁止直接改余额绕过状态机跨服务可收敛消息重复、乱序、延迟后最终状态一致至少一次投递要求消费端幂等历史可审计账户余额可由不可变 Ledger 重算修复通过冲正流水不覆盖原记录核心不变量available reserved committed - reversed accountTotal任何余额视图都必须能够由 Ledger 在固定 cutoffTime 下重算。3. 系统架构计算平面、履约平面、账本平面与对账平面Pricing 只生成 Benefit PlanBenefit Orchestrator 以稳定业务键编排预占和确认Budget Service 在本地事务内更新 Reservation、Bucket、Ledger 和 OutboxPayment / Refund 只发送事实事件不直接改预算Reconciliation 使用订单、支付、退款和 Ledger 重新证明余额与状态。图 2营销权益执行与预算控制架构Benefit Orchestrator维护调用幂等、命令顺序和跨域补偿不保存资金事实。Budget Service拥有预算账户、分桶、预占状态机与账本是余额写入的唯一入口。Ledger / Outbox与状态迁移同事务写入分别提供审计事实和跨服务事件。Inbox Consumer以 consumerName eventId 去重重复消息不会重复更新业务视图。Reconciliation发现孤儿预占、状态漂移和余额差异生成受控补偿任务。4. 核心设计Reservation 状态机而不是余额 CRUDReserve 冻结预算Commit 将冻结金额转为正式消耗Release 退回未支付金额Reverse 对已 Commit 的金额做退款回补Expire 是由 TTL 驱动的特殊 Release。每个命令都必须验证当前状态和累计金额上限重复命令返回已有结果不再创建新流水。图 3预算预占、确认、释放与退款回补状态机命令允许前态目标状态 / 账本动作Reserve不存在RESERVED冻结 available增加 reservedCommitRESERVEDCOMMITTEDreserved 转 committedReleaseRESERVEDRELEASED释放冻结额度ExpireRESERVED 且 expiresAt nowEXPIRED RELEASE扫描器幂等执行ReverseCOMMITTEDREVERSED 或部分回补新增 REVERSAL 流水5. 幂等与并发控制业务身份、请求指纹和条件更新幂等键必须表达业务操作而不是网络请求。推荐键为tenantId orderId benefitKey operation同一键再次到达时如果 requestHash 相同就返回原结果如果参数不同则返回 IDEMPOTENCY_CONFLICT。Budget Bucket 使用带状态与余额条件的单条 UPDATE避免先查后改的竞态。UPDATE budget_bucket SET available available - :amount, reserved reserved :amount, version version 1 WHERE bucket_id :bucketId AND available :amount AND version :expectedVersion; -- affectedRows 0 时区分余额不足、版本冲突或账户停用 -- 任何重试先读取既有 reservation不重新生成业务幂等键唯一约束建议覆盖(tenant_id, business_key, operation)requestId 仅用于链路追踪。幂等记录保存 requestHash、响应摘要、reservationId 和状态避免同键不同参数静默复用。热点预算可分桶但一个订单必须确定性路由到同一 bucket不能在失败后随机换桶。数据库死锁或版本冲突可以有限重试余额不足属于业务结果不应无界重试。6. 数据模型与 ERD账户、预占、流水和订单证据分离budget_account 表示预算业务身份budget_bucket 承载并发余额视图benefit_reservation 保存一次业务操作的状态benefit_ledger 记录不可变资金变动order_benefit 建立订单与 PriceQuote / Reservation 的映射refund_allocation 控制累计回补上限benefit_outbox 保证状态变更可传播。图 4权益履约与预算账本 ER Diagram表主键 / 唯一键职责与关系budget_accountaccount_idtenant funder budget_key预算聚合根与 bucket 为 1:Nbudget_bucketbucket_idaccount_id shard_key高并发余额视图使用 version 条件更新benefit_reservationreservation_idbusiness_key operation预占状态、金额、过期时间与请求指纹benefit_ledgerledger_idreservation_id entry_type sequenceRESERVE / COMMIT / RELEASE / REVERSAL 不可变流水order_benefitorder_benefit_idorder_id benefit_key关联 quoteId、reservationId 与权益资金方refund_allocationallocation_idrefund_id order_benefit_id部分退款累计回补及原流水关联benefit_outboxevent_idaggregate_id event_type同事务事件与 payloadHash6.1 写入顺序与事务边界先以业务幂等键查询或插入 Reservation同键不同 requestHash 立即拒绝。在同一数据库事务中条件更新 Bucket、迁移 Reservation 状态、追加 Ledger。校验守恒与累计上限后写 Outbox再提交事务。Relay 至少一次投递消费者使用 Inbox 唯一键去重并更新本地投影。跨域异常由 Reconciliation 生成补偿命令补偿仍走同一状态机和账本。7. 预占与确认流程支付成功不等于可以重复 Commit试算阶段通常不应长期占用预算真正创建订单或拉起支付前才 Reserve并设置与支付窗口匹配的 expiresAt。支付成功事件触发 Commit。若调用超时Orchestrator 先按 reservationId 查询状态已 COMMITTED 就直接收敛仍 RESERVED 才用相同幂等键重试。图 5预占、支付与确认时序图超时语义客户端超时只说明它没有看到结果。禁止把 timeout 翻译成 failure 后直接新建 Reservation必须把命令当成 uncertain查询服务端状态后再决定下一步。8. 释放与过期避免孤儿预占长期占用额度取消订单、支付失败和支付窗口过期都需要释放冻结预算。业务事件是主路径TTL 扫描是兜底路径两者可能并发到达因此 Release 必须以状态条件和幂等键保证只执行一次。扫描器需要固定批次、游标和限速不能一次锁住整张 Reservation 表。boolean release(Reservation r, String commandKey) { if (r.status() RELEASED || r.status() EXPIRED) return true; if (r.status() ! RESERVED) return false; // 单事务CAS 状态 Bucket 回补 RELEASE Ledger Outbox return repository.releaseIfReserved(r.id(), commandKey, clock.instant()); }9. 退款回补基于原 Quote、原履约与原资金归属退款不能按当前规则重新计算权益也不能简单把订单优惠总额按比例塞回预算。Refund Service 应读取原 PriceQuote 的 Line / Adjustment、order_benefit 和 COMMIT Ledger计算本次 refundableAmountReverse 流水引用 originalLedgerId并验证累计回补不超过原消耗。图 6部分退款回补与冲正时序图整单退款按原资金方和 Benefit Adjustment 全量冲正。部分退款按原分摊与数量计算尾差归属沿用原 Quote Money Policy。多次退款使用 refund_allocation 累计已回补金额最后一次吸收合法尾差。退款撤销新增反向冲正不删除已经存在的 REVERSAL 流水。10. 分布式一致性数据库内强一致跨服务可证明收敛订单、支付、预算和退款不可能依靠一个数据库事务完成全局原子提交。更现实的目标是Budget Service 内部状态与 Ledger 强一致跨服务事件通过 Outbox 至少一次投递消费端通过 Inbox 幂等对账在固定时间截面发现并修复遗漏。图 7本地事务、Outbox、Inbox 与对账的一致性边界机制解决的问题不能解决的问题本地事务Reservation、Bucket、Ledger、Outbox 原子提交不能让远端服务同步提交Outbox数据库成功但消息未发送不能保证消费者只收到一次Inbox重复消息导致重复业务副作用不能自动修复业务顺序错误状态机乱序命令与非法迁移不能发现消息永久丢失Reconciliation长尾遗漏、孤儿与余额差异不能替代在线不变量和访问控制11. 预算分桶与热点治理单一活动预算可能成为全局热点。分桶可以按 tenant、region、storeGroup 或一致性 Hash 拆分可用额度但分桶不是无限扩容按钮需要定义总额下发、桶间再平衡、失败时是否允许借额以及如何将所有桶 Ledger 汇总回账户级审计。同一 orderId benefitKey 使用确定性 shardKey重试不得换桶。分桶额度只由控制面下发在线请求不能跨桶扫描寻找余额。P0 场景 fail closed低风险营销可按明确策略降级为“不享受该权益”。热点账户监控冲突率、锁等待、条件更新失败率和桶间余额偏斜。12. 对账与自愈余额视图必须接受 Ledger 的持续证明对账任务在固定 cutoffTime 下重算 Account / Bucket 余额并把 Reservation 与订单、支付、退款状态连接起来。差异不能只输出一条告警而要生成带 evidenceId、rootPath、建议动作和风险等级的可复现 CaseP0 可以冻结账户或停止新预占资金补偿本身仍需审批和幂等。图 8预算对账与自愈控制闭环13. Troubleshooting重复扣减事故的完整排查Symptoms预算账户budget_demo_monthly在 5 分钟内比订单权益汇总少 30.00 元同一 orderId 出现两个 RESERVED / COMMITTED Reservation。接口成功率正常只有少量调用记录了 Commit timeout。Investigation按 accountId 固定 cutoffTime 重算 Ledger确认余额视图确实多扣 30.00而非报表延迟。沿 orderId 查询 Reservation发现 businessKey 相同但 requestId 不同均通过唯一约束。检查第一条 Commit Ledger 和 Outbox证明服务端在超时前已经提交成功。回放调用时间线发现重试库默认重新生成 requestId并重新执行完整 Reserve 流程。核对接口契约未定义 order benefit operation 稳定键也没有同键 requestHash 冲突规则。图 9重复扣减事故的证据时间线Root Cause直接根因是 Commit 超时后的重试创建了第二个 Reservation系统性根因是 requestId 被误当成业务幂等身份Reservation 状态机、Bucket 更新与 Ledger 唯一性没有共享同一 businessKey。监控只观察接口错误率没有对孤儿预占和账户—Ledger 差异设置 Gate。图 10预算重复扣减的 5 WhysResolution引入tenantId orderId benefitKey operation稳定幂等键并保存 requestHash。Commit 超时后先查询 Reservation重复 Reserve / Commit 返回原状态和原 ledgerId。Bucket 条件更新、Reservation 迁移、Ledger 与 Outbox 收敛到同一事务。为历史重复记录追加 REVERSAL 修复流水不修改或删除原 Ledger。新增孤儿预占、重复业务键、账户余额重算与支付状态不一致 Gate。Verification修复后使用 100 个并发请求重复调用同一业务键仅产生 1 个 reservationId 和 1 条 RESERVE Ledger注入超时、重复消息、乱序支付与数据库死锁后最终状态和余额均收敛。对 36,420 条历史 Reservation 重算Account / Bucket / Ledger 差异为 0连续 48 小时未出现新孤儿预占。Lessons Learned超时、重试和至少一次消息不是异常边角而是分布式系统的常态。只有当业务命令身份、状态机和账本使用同一个关联键时重试才是安全的否则每次重试都有可能成为一次新的资金动作。14. 为什么原方案会失败最终方案为什么有效原方案失败机制最终方案为何有效requestId 作为幂等键网络重试会生成新 ID无法识别同一业务动作稳定 businessKey 表达 order benefit operation先查余额再 UPDATE并发请求都读到相同余额产生超卖单条条件更新或 CAS 把检查与扣减原子化直接修改余额无法解释金额变化也无法安全回滚不可变 Ledger 记录每次状态迁移和关联流水消息发送后再写状态发送成功但事务失败导致幽灵事件状态、Ledger 与 Outbox 同事务提交只监控接口成功率逻辑重复扣减仍返回 200账户重算、孤儿预占和支付状态对账持续证明15. 关键实现命令处理器、状态迁移与账本追加CommitResult commit(CommitCommand cmd) { return tx.execute(() - { Reservation r repo.lockByBusinessKey(cmd.businessKey()); idem.verifySameRequest(r, cmd.requestHash()); if (r.status() COMMITTED) return CommitResult.from(r); require(r.status() RESERVED); repo.markCommitted(r.id(), cmd.paymentId()); LedgerEntry e ledger.appendCommit(r, cmd.correlationId()); outbox.append(BenefitCommitted, r.id(), e.id()); return CommitResult.of(r.id(), e.id(), COMMITTED); }); }实现重点重复命令的快速返回必须发生在任何余额写入之前状态条件和账本唯一键是最后防线不能只依赖应用层 if 判断。16. 验证方案并发、故障注入、回放与对账四层测试State / Property随机生成命令序列验证非法迁移被拒绝、余额守恒、累计回补不超限。Concurrency同键 1001000 并发、不同键同桶竞争、死锁重试和热点分桶测试。Failure Injection事务提交前后超时、Outbox 重复、消息乱序、消费者宕机和时钟漂移。Replay / Reconcile用固定 cutoffTime 重放 Ledger验证 Account、Bucket、订单、支付和退款一致。Invariant 1: available 0 reserved 0 committed 0 Invariant 2: same businessKey same requestHash same result Invariant 3: same businessKey different requestHash conflict Invariant 4: total reversal original committed amount Invariant 5: every state transition has exactly one ledger entry Invariant 6: account balance equals ledger replay at cutoffTime Invariant 7: outbox duplicate delivery causes no duplicate side effect17. 方案取舍决策收益代价与控制数据库条件更新语义清晰、强一致、易审计热点行冲突通过分桶和限流治理不可变 Ledger可重算、可审计、可冲正数据增长冷热分层但不删除审计主线Outbox / Inbox避免数据库与消息双写不一致至少一次语义消费者必须幂等显式补偿而非分布式事务可用性高、故障边界清晰短暂不一致依赖状态机与对账预算分桶降低热点与锁竞争余额调度复杂控制面统一下发和汇总18. Lessons Learned第一requestId 是链路标识不一定是业务幂等标识。第二超时代表结果未知安全恢复依赖状态查询和同键重试。第三余额字段只是视图Ledger 才是能够证明资金变化的事实。第四补偿必须追加反向流水不能覆盖历史来制造表面一致。第五至少一次消息并不可怕可怕的是消费者没有 Inbox 和状态条件。第六对账不是月底脚本而是在线不变量的持续验证与自愈控制面。19. 后续优化建立按账户风险分级的实时 Gate余额负数、重复业务键、支付成功未 Commit 立即阻断。建设 Ledger Replay 工具输入 accountId cutoffTime 一键生成余额、差异和证据链。对热点预算引入自适应分桶和冲突率反馈但保持确定性路由。把故障注入纳入预发布Commit 响应丢失、Outbox 延迟、消费者重复和退款乱序。为补偿任务增加四眼审批、金额上限、dry-run 和补偿后自动复核。统一 Quote Adjustment、Order Benefit、Reservation 与 Ledger 的 correlationId缩短 RCA 路径。20. 总结营销权益真正的工程难点不是算出折扣而是在不可靠网络和多服务协作下仍能保证每个权益只履约一次、每一分钱都有来源、每次失败都有合法补偿。Reservation 把业务动作变成状态机Ledger 把余额变化变成事实Outbox / Inbox 让跨服务最终收敛对账则持续证明系统没有悄悄失真。最终结论预算系统必须把‘命令身份、状态迁移、余额更新、账本流水、领域事件和对账证据’视为一个整体契约。只做其中任何一部分都不足以抵抗超时、重试、并发和退款带来的真实风险。21. 下一篇第十一篇建议继续进入优惠券发放与领取链路《优惠券发放与领取系统资格判定、库存扣减、防刷限流、批量任务与幂等补偿》。重点讨论 Coupon Stock、User Coupon、领取资格快照、批次发券、热点库存、防重、防刷、延迟任务和失败补偿。Coupon System Engineering Case Study · Part 10单文件 HTML · 10 张 PNG 已 Base64 内嵌 · 面向 CSDN 富文本发布