15.1 WMS（仓储管理系统）库存防超卖与仓内作业项目串讲

口述边界：本册按“背景、约束、目标、方案、权衡、失败、结果证据、复盘”组织项目。简历明确写到的项目背景、职责和技术动作标为 E1（直接证据）；由库存、缓存、事务、消息与履约唯一正文映射出的机制标为 E2（已有材料映射）；所有示例数字、故障注入和公式标为 E3（演练设计）；缺少源码、配置、监控、事故记录或业务制度的生产细节标为 E0（待核对）。E2（已有材料映射）与 E3（演练设计）都不能说成生产已经采用或取得真实收益。

图解读：图从值班人员限流与暂停批量任务开始，先固化库存快照、流水、版本、消息和仓内作业证据，再按业务键重放并核对拣货、复核、过账和实物。证据唯一且动作可逆时，系统通过原幂等键追加补偿流水；结果未知、证据冲突或已经出库时转人工复核。恢复不是“服务启动成功”，而是可售、冻结、已扣与实物守恒，积压和未知态收敛，最后按仓库与 SKU（库存单位）分批放量并持续对账。可编辑源见 wms-inventory-talk.puml。

1. 背景：四套仓储系统统一与个人职责

1.1 从账实不一致到统一库存与作业语言

E1（直接证据）显示，原有白电、空调等事业部分别使用 4 套仓储系统，手工作业多，容易出现账实不一致、错发和漏发；建设目标是用一套 WMS（仓储管理系统）覆盖多品类、多仓库和多事业部。个人负责成品和部分原材料模块，参与库存表模型设计以及入库、在库、出库、送检、过账公共方法，经历 R1、R2、R3 版本上线与现场问题处理。项目故事因此应从“统一业务语义与责任阶段”讲起，而不是从 Redis（远程字典服务）或锁开始。

sequenceDiagram
    participant 采购 as 采购与生产
    participant WMS as WMS（仓储管理系统）
    participant 库存 as 库存账本
    participant 仓内 as 仓内作业
    participant 销售 as 销售与订单
    采购->>WMS: 入库与生产交接
    WMS->>库存: 增加实物并记录来源流水
    销售->>WMS: 提交履约需求
    WMS->>库存: 建立库存承诺
    WMS->>仓内: 创建可追踪仓内任务
    仓内->>库存: 拣货、复核、出库过账
    库存-->>销售: 返回可解释履约状态
    alt 数量或状态不一致
        仓内-->>WMS: 建立异常与盘点证据
        WMS->>库存: 受控补偿并再次对账
    end

图解读：正常路径把采购或生产交接形成的入库事实，转化为销售订单可消费的库存承诺，再由仓内作业完成过账；失败路径不直接改余额，而是先形成异常、盘点与补偿证据。箭头表达责任转移，不代表生产中一定采用同名服务。

数据演绎 1：统一口径为何先于性能优化

E3（演练设计）：假设 4 套旧系统分别把同一批货记录为 98、100、101、99，实物盘点为 100。四套账面合计没有业务意义，单套相对实物差异分别为 -2、0、+1、-1；若只取平均值，(98+100+101+99)/4=99.5，仍无法判断哪笔入库、冻结或出库缺失。统一后用期初 80、入库 30、出库 10 复算期末 80+30-10=100。状态从“多个余额争论”变为“同一业务键的因果流水”；观测信号是缺失来源、重复过账和盘点差；结论是先统一事实语义，再谈缓存命中率。

热门面试题

1. 问题：这个项目的业务背景应该怎样开场？
   • 考点：业务冲突、个人职责、证据边界。
   • 回答思路：先说 4 套旧系统与账实、错发、漏发问题，再落到个人负责范围。
   • 详细答案：可以依据简历说明，多个事业部原有 4 套仓储系统，流程和数据不统一，手工作业较多，容易出现账实不一致、错发和漏发；新 WMS（仓储管理系统）要覆盖多品类、多仓库和多事业部。个人负责成品和部分原材料模块，参与库存模型及入库、在库、出库、送检、过账公共方法，并经历 R1、R2、R3 上线。不要一开场就堆组件，也不要补写没有证据的订单峰值和收益。
   • 进阶追问：为什么“统一系统”不等于“数据自然一致”？
   • 进阶回答：统一部署只消除入口分散，库存仍会受并发、重复消息、人工调整和实物差异影响；必须继续统一业务键、状态机、流水、权限和对账。
2. 问题：入库、在库、出库、送检和过账为什么要做公共方法？
   • 考点：业务语义复用、约束集中、审计一致。
   • 回答思路：说明公共方法承载统一校验与流水，不只是减少重复代码。
   • 详细答案：这些动作都改变库存责任或数量，如果各事业部自行写余额，会出现不同状态、不同幂等规则和不同审计字段。公共方法应集中校验货主、仓库、SKU（库存单位）、批次、来源单据和允许状态，在同一边界写数量变化、版本与流水，并给异步传播稳定事件。简历能证明负责这些公共方法，具体接口、表名和事务范围仍应以源码为准。
   • 进阶追问：公共方法会不会形成巨型服务？
   • 进阶回答：会有风险，因此应按入库、库存、出库等清晰能力拆接口，共享不变量与流水合同，而不是用一个万能方法承载所有分支。
3. 问题：怎样区分项目事实与候选方案？
   • 考点：E1（直接证据）、E2（已有材料映射）、E3（演练设计）、E0（待核对）。
   • 回答思路：逐句给来源和允许语气。
   • 详细答案：简历明确写到的 4 套旧系统、负责模块、公共方法、618 热点缓存与分布式锁、可靠消息和版本上线属于 E1（直接证据）。条件更新、稳定幂等键、仓内责任状态和补偿模型来自现有唯一正文，属于 E2（已有材料映射）；示例数量与恢复时间属于 E3（演练设计）；真实峰值、故障时间线和收益属于 E0（待核对）。回答时直接说出等级与取证方法。
   • 进阶追问：方案图真实渲染后能否证明生产采用？
   • 进阶回答：不能。渲染只能证明文档资产可复现，生产结论仍需源码、配置、运行记录或明确简历事实。

2. 约束：库存正确性、热点竞争与跨域异步

2.1 五类约束决定同步与异步边界

库存系统同时受业务、并发、数据、外部协同和运维约束。可售量不能为负，重复请求不能重复冻结；热点 SKU（库存单位）会把并发集中到同一库存键；支付、订单和仓内消息可能延迟或重复；实物作业不可像数据库事务一样随意回滚；人工补偿必须可审计。E1（直接证据）支持“热点缓存、分布式锁、可靠消息和对账”这些项目主题，下面的约束分解属于 E2（已有材料映射）。

sequenceDiagram
    participant 请求 as 并发订单
    participant 缓存 as Redis（远程字典服务）读模型
    participant 闸门 as 热点闸门
    participant 数据库 as MySQL（关系型数据库）库存
    participant 消息 as Kafka（分布式日志消息系统）
    participant 仓内 as 仓内作业
    请求->>缓存: 查询聚合可售与版本
    缓存-->>请求: 返回预判结果
    请求->>闸门: 按仓库与 SKU（库存单位）削峰
    闸门->>数据库: 短事务条件更新与流水
    alt 条件满足
        数据库-->>请求: 返回冻结结果
        数据库->>消息: 提交后传播库存事实
        消息->>仓内: 至少一次驱动作业
    else 余额不足或版本冲突
        数据库-->>请求: 明确拒绝或读取既有结果
    end

图解读：缓存只提供预判，热点闸门只减少竞争，MySQL（关系型数据库）库存事务才裁决冻结结果；消息在提交后传播事实，重复消费由仓内幂等吸收。缓存命中和拿到锁都不是库存成功凭证。

数据演绎 2：热点约束如何改变容量判断

E3（演练设计）：假设入口每秒 1000 个预占请求，其中 40% 集中在一个热点 SKU（库存单位），热点键到达率为 1000×40%=400 次/秒。若单次权威事务平均占用该键 4 毫秒，串行理论上限约 1000/4=250 次/秒，热点每秒净积压 400-250=150，10 秒即积压 1500。增加应用实例不会提高单键上限；把入口限制到 220 次/秒后保留约 12% 余量。状态从无界等待变为有界拒绝；观测信号是单键到达率、锁等待、事务时长和拒绝率；结论仅用于说明方法。

热门面试题

1. 问题：为什么库存链路不能只追求高吞吐？
   • 考点：正确性优先级与失败成本。
   • 回答思路：比较少卖、超卖和重复出库的损失。
   • 详细答案：库存承诺一旦超过实物，会把技术错误转成缺货、改仓、赔付和客户沟通；重复出库还可能造成真实资产损失。因此入口可以限流、排队或明确售罄，报表和投影可以延迟，但可售非负、同一业务意图只生效一次和出库可追踪不能放宽。吞吐优化必须在这些不变量通过后进行。
   • 进阶追问：宁可少卖是否总是正确？
   • 进阶回答：不是永久策略；未知态窗口内保守冻结通常更可控，随后要通过查证、补偿和人工时限尽快释放，长期少卖同样需要容量与流程改进。
2. 问题：分布式锁在约束中承担什么职责？
   • 考点：锁与业务正确性分层。
   • 回答思路：先承认削峰价值，再列出租约、切换与旁路风险。
   • 详细答案：分布式锁可以把同一热点键的并发请求收敛，降低数据库锁等待和重复计算；但锁可能因租约到期、网络分区、进程暂停或故障切换出现双持有者，释放后消息也可能再次到达。库存最终仍要由业务幂等键、数据库唯一约束、条件更新、合法状态迁移和流水对账兜底。
   • 进阶追问：拿到锁后数据库更新失败怎么办？
   • 进阶回答：以数据库结果为准，回滚本次业务动作并释放锁；不能为了“锁已成功”而绕过条件，也不能在结果未知时换业务键重试。
3. 问题：为什么实物作业会改变取消策略？
   • 考点：可逆阶段与物理副作用。
   • 回答思路：按未分配、已分配、拣货、复核、出库说明。
   • 详细答案：未分配时可以条件释放冻结；已分配要先取消任务；拣货中需要拦截并回库；已复核可能要拆包返拣；已出库通常只能走运输拦截、退货或售后。订单状态不能直接覆盖仓内事实，每个阶段都要用任务、扫描或过账证据裁决库存动作。
   • 进阶追问：仓内回执迟到时先释放可以吗？
   • 进阶回答：不可以。迟到只表示本地尚未确认，仓内可能已经执行；应保持处理中并查证，明确未执行后才释放。

3. 目标：定义库存守恒与仓内完成标准

3.1 可售、冻结、已扣、实物与作业状态共同验收

目标不是“请求成功”或“锁没有报错”，而是库存数量守恒、业务副作用唯一、仓内状态单调和差异可恢复。建议将可售理解为当前还能承诺的数量，冻结表示已承诺但尚未完成出库的数量，已扣表示已经通过可信出库或过账消耗的数量，实物表示系统认定仍在仓的数量。分配、拣货、复核是冻结内部的责任阶段，不能每经过一步都再次扣可售。

stateDiagram-v2
    [*] --> 待冻结
    待冻结 --> 已冻结: 条件更新成功
    待冻结 --> 库存不足: 条件更新失败
    已冻结 --> 已分配: 波次分配
    已冻结 --> 已释放: 取消或超时且仍可逆
    已分配 --> 拣货中: 领取任务
    拣货中 --> 待复核: 实拣完成
    待复核 --> 已复核: 商品与数量一致
    已复核 --> 已过账: 出库确认
    已分配 --> 异常: 少货或破损
    拣货中 --> 异常: 实拣差异
    异常 --> 已分配: 证据确认后恢复
    异常 --> 人工终态: 无法自动裁决

图解读：条件更新成功才形成冻结；冻结在分配前可释放，进入拣货后要依赖仓内证据，复核通过后才能过账。异常不是失败垃圾桶，而是保存差异、责任和人工裁决的正式状态；迟到取消不能让已过账状态倒退。

数据演绎 3：库存守恒与责任阶段

E3（演练设计）：期初实物 120，其中质检冻结 10，订单冻结 30，因此可售为 120-10-30=80。波次把订单冻结中的 18 分配到库位，拣货 16、少货 2；分配与拣货只改变责任阶段，可售仍为 80。复核通过并出库 16 后，实物变 120-16=104，订单冻结剩 30-16=14，质检冻结仍为 10，可售仍是 104-10-14=80。若把分配 18 再扣一次可售，会错误得到 62。观测信号是各阶段变化与总冻结守恒。

热门面试题

1. 问题：可售、冻结、已扣和实物分别回答什么问题？
   • 考点：库存语义与责任边界。
   • 回答思路：从能否承诺、是否占用、是否出库、仓内是否存在四个角度回答。
   • 详细答案：可售回答还能给新订单承诺多少；冻结回答已有多少承诺尚未完成；已扣回答多少数量已经由可信出库或过账消耗；实物回答系统认定仓内还剩多少。分配、拣货、复核是冻结从计划到物理作业的内部阶段。字段是否独立存储可按模型决定，但每种语义必须有唯一来源和可复算转换。
   • 进阶追问：为什么可售不一定等于实物减冻结？
   • 进阶回答：还可能有质检、破损、监管、批次效期和安全库存等不可售调整；真实公式属于 E0（待核对），需结合业务制度和表模型确认。
2. 问题：为什么分配与拣货不能重复扣可售？
   • 考点：同一承诺的阶段转换。
   • 回答思路：说明可售在冻结成立时已经减少。
   • 详细答案：冻结成功时已经把数量从可售池移出；分配只是把冻结绑定到库位或批次，拣货只是把责任交给作业人员或设备。如果每一阶段再次减少可售，同一业务承诺会被重复计算。正确做法是让冻结内部各阶段总量守恒，出库时减少实物并消耗对应冻结。
   • 进阶追问：拣货少货的 2 件应立即释放吗？
   • 进阶回答：不能直接释放，要先冻结差异并核对错位、漏扫、破损或账实不符；确认可用替代货或真实缺失后，再按证据释放、重分配或盘亏。
3. 问题：怎样定义“恢复完成”？
   • 考点：技术健康与业务正确分离。
   • 回答思路：同时检查新流量、历史存量和实物抽样。
   • 详细答案：恢复完成至少要求新请求的条件更新稳定，积压净下降，最老未知态回到目标，重复和冲突事件不再扩大副作用；历史上可售、冻结、已扣与实物能够由流水复算，异常单和人工队列收敛；最后按仓库与 SKU（库存单位）抽样核对仓单、复核、过账和盘点。服务存活或错误率下降都不足以结案。
   • 进阶追问：差异暂时无法裁决怎么办？
   • 进阶回答：保留冻结和异常单，明确责任人、截止时间与取证路径；不能为了清零指标直接改余额或关闭工单。

4. 方案：条件更新、幂等、缓存、消息与仓内作业闭环

4.1 核心事实同步裁决，可恢复副作用异步推进

E2（已有材料映射）的推荐方案是：订单请求携带稳定业务键，MySQL（关系型数据库）用条件更新裁决可售并在同一事务写冻结记录、库存流水和待发布事件；Redis（远程字典服务）保存聚合读模型、热点预判或短期闸门，不能成为最终账本；Kafka（分布式日志消息系统）传播已提交事实；仓内按波次、分配、拣货、复核和过账推进，消费者用事件键、职责和版本幂等；取消、支付超时与消息延迟通过查询、补偿与对账收敛。

sequenceDiagram
    participant 客户 as 订单请求
    participant 订单 as 订单服务
    participant 缓存 as Redis（远程字典服务）
    participant 库存 as MySQL（关系型数据库）库存
    participant 消息 as Kafka（分布式日志消息系统）
    participant 仓内 as 波次与作业
    客户->>订单: 订单号、订单行、仓库、SKU（库存单位）、数量
    订单->>缓存: 查询热点可售与版本
    缓存-->>订单: 仅作预判
    订单->>库存: 以稳定幂等键条件冻结
    alt 首次且库存充足
        库存->>库存: 更新可售、写冻结流水与待发布事件
        库存-->>订单: 返回冻结号和版本
        库存->>消息: 提交后发布已冻结事实
        消息->>仓内: 重复可达的仓内任务
        仓内->>仓内: 波次、拣货、复核、过账
    else 重复请求
        库存-->>订单: 返回原冻结结果
    else 库存不足
        库存-->>订单: 明确拒绝
    end

图解读：缓存读只能提前拒绝或减少回源，最终冻结必须由权威事务决定；事务同时形成数量变化、幂等结果和可重放事件。消息重复不会重复创建作业，仓内每一步以状态和动作键推进；过账后的库存事实再通过流水和事件回传。

数据演绎 4：并发冻结、重复下单与释放

E3（演练设计）：某库存键期初可售 100。请求 A 和 B 各申请 60，A 先完成条件更新后可售变 40，B 因 available >= 60 不成立而受影响 0 行；随后 A 的网络响应丢失，客户端用同一幂等键重试，唯一约束返回原冻结结果，不再把 40 扣成负数。若支付超时经查证确认订单未支付且仓内未分配，释放动作引用原冻结 60，使可售回到 100；重复释放只返回原结果。观测信号是条件失败、唯一冲突、冻结年龄与释放结果。

热门面试题

1. 问题：条件更新和幂等键分别解决什么问题？
   • 考点：数量竞争与重复意图区分。
   • 回答思路：一个守住余额底线，一个守住动作唯一。
   • 详细答案：条件更新把“可售足够”和“减少可售、增加冻结”放在同一权威写边界，并以受影响行数裁决不同订单的并发竞争；幂等键把同一订单行的同一动作映射到原结果，阻止客户端重试、消息重投或任务重启重复冻结。二者必须与流水和状态机配合，不能互相替代。
   • 进阶追问：幂等键建议包含哪些维度？
   • 进阶回答：可用租户、仓库、SKU（库存单位）、订单行、动作和业务版本组成；实际粒度需按合法重复动作核对，参数摘要还要防止同键换数量。
2. 问题：缓存与数据库怎样分工？
   • 考点：性能路径与正确性路径。
   • 回答思路：说明缓存可丢可重建，数据库记录可审计事实。
   • 详细答案：Redis（远程字典服务）适合保存聚合可售、热点标识、限流令牌和短期请求合并，减轻读流量与热点冲击；MySQL（关系型数据库）保存库存快照、冻结记录、唯一流水和状态版本，负责最终条件裁决。缓存显示有货但数据库失败时必须以数据库为准，并失效旧缓存；缓存全失时限流回源重建，不能切换成无条件扣减。
   • 进阶追问：用 Lua（脚本语言）原子扣减缓存是否足够？
   • 进阶回答：只保证单个 Redis（远程字典服务）执行点内原子，仍有持久化、切换、数据库落地和消息双写窗口；除非缓存本身被设计为权威且具备完整恢复协议，否则不能单独作为库存事实。
3. 问题：消息延迟为什么不应回滚已经成立的冻结？
   • 考点：事实与传播分离。
   • 回答思路：冻结事务已提交，消息只是向仓内传播。
   • 详细答案：库存条件更新、冻结记录和待发布事件一旦同事务提交，冻结事实已经成立；Kafka（分布式日志消息系统）延迟只表示仓内尚未消费。若因消息慢直接增加可售，会让同一库存再次承诺。正确做法是监控待发布与消息年龄，补发原事件，仓内按事件键幂等消费，超过履约时限再依据订单和作业事实决定取消或人工。
   • 进阶追问：消息恢复后怎样避免瞬时压垮仓内？
   • 进阶回答：实时流和历史积压分配独立配额，按仓库与业务键限速，小批放量并观察数据库、作业队列和最老年龄，不能一次全量重放。

5. 权衡：缓存、锁、事务、消息与批量作业如何取舍

5.1 用失败成本决定边界，而不是追求单一技术最优

方案的关键权衡是：数据库强约束会让热点写入串行，但能守住数量底线；Redis（远程字典服务）削峰快，却存在切换与持久化窗口；分布式锁减少竞争，却不能覆盖跨时间重试；Kafka（分布式日志消息系统）解耦仓内作业，却接受重复和延迟；大波次提高调度效率，却放大事务、回滚和恢复范围。选择标准应是“错误承诺、重复出库、暂时少卖、作业延迟和运维复杂度谁的失败成本更高”。

sequenceDiagram
    participant 入口 as 订单入口
    participant 策略 as 权衡策略
    participant 库存 as 权威库存
    participant 批量 as 波次批量
    participant 观测 as 业务与技术观测
    入口->>策略: 新订单与热点分布
    批量->>策略: 待作业量与最老年龄
    策略->>库存: 为在线预占保留容量
    策略->>批量: 分配剩余令牌与批次
    库存->>观测: 条件失败、锁等待、事务时长
    批量->>观测: 批次耗时、回滚量、积压年龄
    alt 在线正确性或尾延迟受威胁
        观测-->>策略: 缩小波次、暂停低优先任务
    else 核心链路稳定且积压增长
        观测-->>策略: 小步提高批量并发
    end

图解读：在线库存承诺先获得保底容量，波次批量使用剩余资源；策略根据数据库锁等待和仓内最老年龄反馈调节。正常路径小步提升吞吐，失败路径牺牲批量速度保护库存正确性，不用增加应用实例硬顶共享热点。

数据演绎 5：波次拆批与在线容量

E3（演练设计）：假设库存事务安全能力为每秒 1200 次，在线请求每秒 900 次，波次任务计划每秒 500 次，直接叠加利用率为 (900+500)/1200=116.7%。给在线保留 900 次并设置 10% 总余量，批量上限为 1200×90%-900=180 次/秒。待处理 2400 个仓单、平均每单 3 行，按 50 单一批则每批 150 行；若每行 2 毫秒，理论事务工作量约 300 毫秒，而 600 单一批会放大到 3600 毫秒。状态从过载大事务变为有界小批与检查点。

热门面试题

1. 问题：为什么数据库条件更新比纯缓存扣减更保守？
   • 考点：权威事实、吞吐与恢复成本。
   • 回答思路：比较写入串行代价与缓存切换后的数据风险。
   • 详细答案：数据库条件更新在同一权威记录上原子判断余量，结果有事务、唯一约束和流水可追溯，代价是热点键会串行并产生锁等待。纯缓存扣减延迟更低，但要额外解决持久化、主从切换、数据库回补、消息丢失和双写对账。库存失败成本高时，通常让数据库守底线，缓存承担预判与削峰。
   • 进阶追问：什么时候可以把缓存提升为权威源？
   • 进阶回答：只有业务接受其一致性模型，并具备持久日志、故障切换、重放、数据库投影和端到端对账协议时；这是一套新架构，不是增加一个原子脚本。
2. 问题：波次越大为什么不一定效率越高？
   • 考点：锁范围、事务日志、回滚和故障隔离。
   • 回答思路：区分调度分组与数据库提交批次。
   • 详细答案：大波次可以减少调度次数，但若整波放进一个事务，会扩大锁持有、日志、复制延迟和失败回滚范围，一条异常可能拖住大量正常仓单。应保留波次成员全局视图，再按有限批次完成分配与任务创建，用检查点聚合完成度。批次大小依据压测和锁等待校准，不凭经验固定。
   • 进阶追问：分批后怎样防止漏处理成员？
   • 进阶回答：波次保存期望成员数、每批游标和成员终态，关闭前比较完成、异常与未处理总数；未扫描对象不能被当成成功。
3. 问题：为什么未知态期间常选择保留冻结？
   • 考点：错误释放与暂时少卖的失败成本。
   • 回答思路：比较仓内可能已执行和可售占用两类后果。
   • 详细答案：支付、仓单或出库结果未知时，远端或仓内可能已经成功；此时释放会把同一实物再次承诺，随后形成超卖或重复履约。保留冻结会暂时降低可售，但风险可见、可查证、可设置升级时限。系统应优先查询原业务键，明确未执行才释放，长期未知进入人工，而不是永久占用。
   • 进阶追问：如何避免保守策略变成大量库存沉淀？
   • 进阶回答：监控冻结年龄分布、查询命中、人工积压与释放时长，按风险分级设置查证预算和责任人，并用对账发现孤儿冻结。

6. 失败：重复下单、支付超时、消息延迟与人工补偿

6.1 五类故障必须先查证事实，再决定重试或释放

失败回答采用“现象、假设、证据、止血、查证、修复、恢复验收、复盘”。重复下单先看稳定幂等键；并发扣减看条件更新和流水；支付超时不能直接解释为订单失败；消息延迟不能回滚已提交库存；人工补偿不能执行任意脚本或覆盖余额。任何自动动作都要受当前状态、版本、动作唯一键和重试预算约束。

sequenceDiagram
    participant 订单 as 订单与支付
    participant 库存 as 库存账本
    participant 消息 as 消息链路
    participant 仓内 as 仓内作业
    participant 补偿 as 补偿与人工
    订单->>库存: 以稳定业务键申请冻结
    库存-->>订单: 冻结成功但响应可能丢失
    订单->>库存: 同键重试并读取原结果
    订单--x订单: 支付响应超时，结果未知
    订单->>订单: 主动查支付单，不立即释放
    库存->>消息: 已提交事实等待传播
    alt 消息延迟或重复
        消息->>仓内: 原事件补发或重投
        仓内->>仓内: 事件键与状态版本去重
    else 支付明确失败且仓内未开始
        订单->>库存: 引用原冻结幂等释放
    end
    补偿->>库存: 对差异只读预览
    补偿->>仓内: 核对拣货、复核与过账
    补偿->>库存: 审批后追加补偿流水

图解读：重复请求复用原业务键，支付超时进入查询，消息延迟通过原事件补发，只有支付明确失败且仓内未开始才释放。人工补偿先预览和核对物理作业，再追加可审计流水；任何路径都不通过换键或直接改余额绕过历史事实。

数据演绎 6：故障组合如何收敛

E3（演练设计）：期初可售 50，订单 O1 申请 20 并冻结成功，可售变 30；响应丢失后 O1 重试 2 次，稳定幂等键使冻结仍为 20。支付超时 10 分钟期间消息已延迟到仓内但尚未消费，系统保持冻结。主动查单最终确认支付失败，释放任务执行 2 次，只有首次从已冻结迁移到已释放，可售回到 50。若人工误用新动作键再加 20，可售会错误变 70，因此补偿必须引用原冻结并检查状态。观测信号是同键接收次数、冻结年龄、支付查证结果和释放影响行数。

热门面试题

1. 问题：重复下单为什么不能用每次请求的新编号去重？
   • 考点：业务意图与传输尝试区分。
   • 回答思路：说明新编号会绕过原冻结身份。
   • 详细答案：客户端超时后如果每次重试都生成新编号，系统会把同一购买意图识别为多个订单动作，分布式锁释放后仍可能逐个冻结。幂等键必须在重试、消息重投和实例切换中稳定，并绑定订单行、动作、数量摘要和版本；重复参数一致时返回原结果，参数不同则拒绝并告警。
   • 进阶追问：用户确实再次购买同一商品怎么办？
   • 进阶回答：新的业务意图应有新的订单行或明确业务版本；不能仅凭商品相同判断重复，也不能复用旧键误杀合法订单。
2. 问题：支付超时后为何不能立即释放库存？
   • 考点：跨域未知态与迟到成功。
   • 回答思路：超时只证明没有收到响应，不证明支付失败。
   • 详细答案：支付可能已经在渠道成功，只是响应或回调延迟；立即释放会让库存再次承诺，迟到成功又要求履约，形成资金成功却无库存。应保留支付单与原请求号，主动查单或等待可信回调；明确失败并确认仓内仍可逆后才引用原冻结释放，长期未知进入受审计人工队列。
   • 进阶追问：支付成功但冻结已经合法过期怎么办？
   • 进阶回答：不能复活旧冻结；按业务政策重新申请库存，成功则继续，失败则退款、缺货沟通或人工处理，并关联原支付与新尝试。
3. 问题：人工补偿怎样避免造成第二次事故？
   • 考点：权限、预演、幂等与复验。
   • 回答思路：按只读预览、审批、分批执行、停止条件和对账回答。
   • 详细答案：补偿工具只能选择预定义动作和明确业务范围，先展示将影响的库存键、原流水、当前状态与预计变化；高风险动作由不同角色复核，执行使用稳定补偿键、小批限速和版本条件，参数冲突立即停止。修复通过新增冲正或调整流水保留因果，执行后逐批复算并抽样仓内实物，不能提供任意脚本或直接覆盖快照。
   • 进阶追问：补偿批次部分成功怎么办？
   • 进阶回答：保存每个业务键结果和检查点，只重试未完成且仍满足条件的对象；已成功对象命中幂等结果，证据冲突对象转人工。

7. 结果证据：用可定位事实表达成果

7.1 项目结果必须区分已证明、可验证与待核对

E1（直接证据）能证明参与 R1、R2、R3 上线并处理现场问题，负责库存模型与核心公共方法，在 618 版本设计库存性能和安全方案，使用热点缓存、分布式锁、可靠消息、对账和可观测工具。它不能证明“超卖率降为零”“吞吐提升十倍”或具体恢复时长。结果表达应给出已交付范围、机制验证方法和仍需取证的业务效果；演练结果只能说明方案在给定输入下如何收敛。

sequenceDiagram
    participant 面试官 as 面试官
    participant 候选人 as 候选人
    participant 事实卡 as E1（直接证据）事实卡
    participant 方案 as E2（已有材料映射）方案
    participant 演练 as E3（演练设计）数据
    participant 待核对 as E0（待核对）清单
    面试官->>候选人: 项目取得了什么结果
    候选人->>事实卡: 提取职责、上线与明确动作
    候选人->>方案: 说明不变量和恢复机制
    候选人->>演练: 给公式、状态变化和验证方法
    候选人->>待核对: 列真实峰值、收益和事故证据
    候选人-->>面试官: 分层陈述，不越过证据等级

图解读：回答先从 E1（直接证据）提取可定位交付，再用 E2（已有材料映射）解释设计，借 E3（演练设计）展示推理，最后主动列 E0（待核对）。四条箭头不是强弱排序，而是控制陈述范围，防止把候选方案和样例数字包装成生产成果。

数据演绎 7：结果指标如何避免只看接口成功

E3（演练设计）：某演练窗口 1000 个冻结请求，数据库成功 700、库存不足 250、重复请求 50；业务有效冻结仍为 700，而不是接口处理 750。仓内完成 680、未知 15、明确取消并释放 5，完成覆盖率为 680/700=97.14%，未闭环为 15+5=20；其中 5 已合法释放，真实待查为 15。若只报接口成功率会掩盖未知态。结果验收还需核对 700 条唯一冻结、680 条过账、5 条释放与 15 条异常总数守恒。

热门面试题

1. 问题：没有真实收益数字时怎样讲项目结果？
   • 考点：可信表达与验证意识。
   • 回答思路：先说可证明交付，再说指标定义和取证路径。
   • 详细答案：可以明确说参与 3 个版本上线、负责核心库存和仓储公共方法、承担 618 库存性能与安全方案以及现场问题收敛，这些有简历支持；随后说明会用可售负数拦截、重复动作吸收、冻结年龄、过账完成、差异清单和盘点结果验证正确性。真实改善比例、峰值和恢复时间保持 E0（待核对），不虚构百分比。
   • 进阶追问：这样会不会显得结果不够强？
   • 进阶回答：资深表达的强度来自不变量、失败路径、可复算验证和证据边界；未经证明的亮眼数字在深入追问时反而降低可信度。
2. 问题：为什么消息积压清零不代表业务恢复？
   • 考点：技术信号与业务结果分离。
   • 回答思路：列出重复消费、历史未知和账实差异。
   • 详细答案：积压清零只说明消息被取走，消费者可能因状态冲突跳过、因错误代码重复执行，或把失败转入死信；历史冻结也可能仍无仓单，已过账实物可能没有正确流水。恢复必须看有效完成率、最老未知态、死信和人工单，并按业务键对账库存、仓单、复核与实物。
   • 进阶追问：哪一个指标最容易暴露长期遗漏？
   • 进阶回答：最老未完成业务年龄通常比平均延迟和总量更敏感，再结合差异对象数能发现少量长期卡死订单。
3. 问题：如何界定个人贡献与团队成果？
   • 考点：职责证据与协作边界。
   • 回答思路：用“负责、参与、推动、验证”区分动作。
   • 详细答案：个人可陈述负责成品和部分原材料模块、库存模型、公共核心方法和 618 仓储端方案，参与业务边界梳理与多版本上线，并处理现场问题；系统统一和业务收益属于团队结果。若主导某次评审或事故，需要需求、代码、评审、发布或复盘记录支撑，不能把协作产出全部归于个人。
   • 进阶追问：小组长角色最应体现什么？
   • 进阶回答：不仅是分任务，还应体现如何统一规则、评审风险、协调上下游、推进验收和让现场问题闭环；具体组织动作仍以记录为准。

8. 复盘：从组件方案升级为可恢复业务系统

8.1 复盘关注绕过路径、未知态与下一次演练

复盘不是再列一次 Redis（远程字典服务）、MySQL（关系型数据库）和 Kafka（分布式日志消息系统），而是确认为什么原有防线没有更早发现问题。重点检查是否存在绕过条件更新的旁路、幂等键是否过粗或不稳定、支付超时是否被错误当失败、消息和补偿是否共享重试预算、波次是否形成大事务、人工是否能直接改余额，以及恢复标准是否只有技术指标。行动项要有负责人、截止时间、完成证据和下一次演练。

sequenceDiagram
    participant 事故 as 故障时间线
    participant 复盘 as 复盘会议
    participant 规则 as 状态与幂等规则
    participant 演练 as 故障注入
    participant 门禁 as 发布与恢复门禁
    事故->>复盘: 提交确认事实、推断与未知
    复盘->>规则: 修正旁路、竞态和人工边界
    规则->>演练: 注入重复、超时、延迟和重启
    演练->>门禁: 提交守恒、积压与恢复证据
    alt 验证通过
        门禁-->>复盘: 关闭行动项并登记复审日期
    else 仍出现差异或未知放大
        门禁-->>规则: 退回改进并限制扩面
    end

图解读：事故时间线必须区分确认事实、推断与未知；规则改进要经过相同故障注入，只有业务守恒和恢复证据通过才关闭行动项。失败分支会限制扩面并继续修正，避免“代码已发布”被误当成复盘完成。

数据演绎 8：消息积压与恢复演练

E3（演练设计）：消息到达每秒 800 条，消费者每秒完成 500 条，持续 10 分钟后积压 (800-500)×600=180000。修复后处理能力提升到每秒 1400 条，新流量仍为 800 条，净恢复为 1400-800=600 条/秒，理论清空需 180000/600=300 秒。若重试失败率为 10%，有效完成约 1400×90%=1260，净恢复变 460，清空约 391.3 秒。状态从增长转为收敛；验收还要抽样确认重复消息没有重复冻结、建波或过账。

热门面试题

1. 问题：一次库存事故复盘最容易漏掉什么？
   • 考点：存量数据、旁路与行动项验证。
   • 回答思路：说明修代码不等于修历史事实。
   • 详细答案：最容易漏掉在途请求、旧消息、已经形成的错误流水、人工临时权限和绕过主流程的写入口。新版本只能阻止新增问题，存量必须按业务键盘点、查证、补偿和对账；行动项还要用原故障组合重新演练，确认重复、超时、延迟和重启不会再次扩大副作用。
   • 进阶追问：复盘何时才可以关闭？
   • 进阶回答：修复、历史处置、监控门禁和演练证据都完成，负责人和复核人确认，且在约定业务窗口内没有反弹时才关闭。
2. 问题：为什么重试预算也是架构能力？
   • 考点：反馈控制与故障放大。
   • 回答思路：说明无限重试会抢占正常流量并掩盖未知态。
   • 详细答案：同一依赖故障时，订单、消息和补偿若各自无限重试，会共同耗尽线程、连接和数据库，形成自激放大。预算应同时限制单对象次数、故障域速率、最大年龄和全局恢复资源；预算耗尽不是丢弃，而是保存证据并转死信或人工。恢复时先小流量探测，再逐步提升。
   • 进阶追问：人工点击重试能否重置预算？
   • 进阶回答：不能静默重置；应生成恢复单，继承原尝试与查证记录，高风险动作复核后使用独立受控配额。
3. 问题：下一阶段最值得演进什么？
   • 考点：收益、风险与可逆性。
   • 回答思路：先补事实和门禁，再决定是否服务化或分片。
   • 详细答案：优先统一稳定业务键、库存流水、未知态、对账和人工审计，因为这些能力无论单体还是微服务都需要；随后根据真实热点、独立扩缩容和团队边界决定是否拆库存或仓内服务。若要迁移，先影子读和事件镜像，保持单主写，按仓库或租户灰度，并用差异率与回退演练控制扩面。
   • 进阶追问：什么时候不应继续拆服务？
   • 进阶回答：当独立部署收益没有超过网络失败、数据一致性、版本兼容和运维成本，或团队无法维护恢复门禁时，应保留清晰模块边界而不继续拆分。

9. 综合题库与项目口述训练

1. 问题：请按八段式完整讲述 WMS（仓储管理系统）库存防超卖与仓内作业项目。

   • 考点：背景、约束、目标、方案、权衡、失败、结果证据、复盘。
   • 回答思路：先声明证据，再按不变量、数据流、失败恢复和结果边界展开。
   • 详细答案：项目主线必须从多系统统一与账实风险出发，数据库库存事实承担正确性，缓存和锁承担减压，仓内状态与消息承担可恢复推进，最后用对账而非接口成功验收。
   • 进阶追问：八段中哪一段最能区分高级与普通回答？
   • 进阶回答：失败、结果证据与复盘最能体现边界意识，因为它们要求说明未知态、存量修复、恢复门禁和证据等级。
   • 口述答案：我先说明证据边界。简历明确写到原有白电、空调等事业部分别使用 4 套仓储系统，存在账实不一致、错发漏发等问题；我负责成品和部分原材料模块，参与库存表模型以及入库、在库、出库、送检、过账公共方法，并参与 R1、R2、R3 上线，这些属于 E1（直接证据）。约束是热点库存并发、跨系统消息延迟、物理作业不可随意回滚和人工调整风险。目标不是“拿到锁”，而是可售不为负，同一订单行只冻结、释放和扣减一次，快照能由流水复算。方案上让 MySQL（关系型数据库）用条件更新、唯一键、状态机和流水裁决库存；Redis（远程字典服务）只做热点查询、预判和削峰；Kafka（分布式日志消息系统）传播已提交事实；仓内按波次、分配、拣货、复核、过账推进。权衡是接受热点写串行和短时少卖，换取库存可解释；接受消息至少一次，要求消费幂等。重复下单返回原结果，支付超时先查单，消息延迟补发原事件，人工补偿追加调整流水。结果只能说简历证明了职责、方案主题和上线支持，真实吞吐、超卖率与收益保持 E0（待核对）。复盘则检查旁路写、幂等键、重试预算和恢复门禁，并用对账与故障注入验证，而不是再堆一遍组件名称。恢复验收还要把新流量与历史存量分开：新请求稳定只是第一步，旧冻结、迟到消息、异常仓单和临时人工权限都必须收敛。只有积压净下降、未知态回到目标、库存守恒并完成实物抽样，才按仓库逐级解除保护。
   • 追问 1：为什么先讲 4 套系统？ 直答 1：它解释了统一业务语义、库存口径和作业责任的必要性，技术选择才有因果。
   • 追问 2：一句话概括核心方案？ 直答 2：核心事实同步守恒，可恢复副作用异步推进，未知先查证，差异靠对账补偿收敛。
   • 追问 3：哪些结果不能说？ 直答 3：没有监控、流水和复盘支持的峰值、提升比例、事故规模与恢复时间不能作为生产事实。
   • 对应知识正文

2. 问题：高并发下如何保证库存不超卖？

   • 考点：条件更新、唯一流水、幂等键、热点保护。
   • 回答思路：把不同订单竞争与同一订单重试分开处理。
   • 详细答案：条件更新守住数量不变量，业务唯一键吸收重复意图，状态机约束确认与释放，缓存与锁只减少无效竞争。
   • 进阶追问：数据库更新影响行为零时应怎样分类？
   • 进阶回答：读取当前状态与幂等记录，区分库存不足、并发版本冲突、已完成重复和参数冲突，不能统一重试。
   • 口述答案：我会先把不超卖写成可执行不变量：以货主、仓库、SKU（库存单位）及必要批次形成库存键，可售始终不小于零，同一订单行的冻结动作只成功一次。请求携带稳定业务键和数量摘要，库存事务执行“可售大于等于申请量且状态、版本符合预期”的条件更新，以受影响行数判定成功；成功时同事务写冻结记录、前后余额流水和待发布事件。不同订单同时竞争时，由条件更新决定谁成功；同一订单因网络超时重复请求时，由数据库唯一约束返回原冻结结果，不能再次减少可售。Redis（远程字典服务）可以保存聚合可售、识别热点并在入口提前拒绝，分布式锁也可以把同键并发收敛，但二者都不能替代数据库裁决，因为缓存会陈旧，锁会过期、切换或被旁路绕过。多商品订单还要统一库存键顺序、限制事务行数，并把远程仓调用移出事务，降低死锁与长事务。线上关注条件失败、唯一冲突、热点键、锁等待和事务时长；恢复时从可信期初重放冻结、释放、扣减与调整流水，再核对订单、仓单和实物。没有源码证据时，我会把条件语句和键结构标为 E2（已有材料映射），把并发数字标为 E3（演练设计），只把简历中的热点缓存、分布式锁与库存安全职责作为 E1（直接证据）。压测不能只做均匀流量，还要让大量请求集中到同一个库存键，并注入锁过期、响应丢失和重复提交。验收既看余额不为负，也看成功冻结数、唯一流水数和有效订单数完全对应，防止“数值正确但业务重复”。
   • 追问 1：隔离级别提高能否替代条件更新？ 直答 1：不能自动表达“余额足够”这一业务条件，还可能扩大锁范围与等待。
   • 追问 2：锁失效是否一定超卖？ 直答 2：若条件更新、唯一键和状态机仍在，锁失效只增加竞争；只有把锁当唯一防线才会直接破坏正确性。
   • 追问 3：热点单键达到上限怎么办？ 直答 3：先限流、短事务和按键排队，再评估分桶；分桶必须解决碎片、释放、迁移和总量对账。
   • 对应知识正文

3. 问题：可售、冻结、已扣、释放和实物库存如何建模？

   • 考点：库存语义、阶段转换、守恒公式与流水投影。
   • 回答思路：先定义每种数量回答的问题，再说明快照与流水关系。
   • 详细答案：可售表达还能承诺的量，冻结表达已承诺未完成的量，已扣表达可信出库消耗，实物表达仓内持有；释放是引用原冻结的反向动作。
   • 进阶追问：所有数量是否都必须做成独立列？
   • 进阶回答：不必须，可由快照、明细与流水投影，但语义、转换条件和可复算来源必须独立。
   • 口述答案：库存模型不能只放一个余额。实物库存回答系统认定仓里还有多少；可售库存回答扣除质检、破损、安全库存和有效承诺后还能卖多少；冻结库存回答已经承诺给订单但尚未完成出库的数量；分配、拣货、复核是冻结内部的仓内责任阶段；已扣表示已经由可信出库或过账消耗的数量；释放则是原冻结在仍可逆时的反向动作。冻结成功时减少可售并增加冻结；波次分配和拣货只转移责任，不再次减少可售；复核通过并出库时减少实物、消耗对应冻结；取消只能引用原冻结，在未分配或仓内明确拦截成功后增加可售。实现上可用库存快照服务在线判断，用不可变流水记录业务键、动作、来源单据、前后余额和版本，二者同事务提交并定期对账。遇到少货、破损或账实差时先冻结相关库位和数量，不能为了让订单继续而直接增加可售。对账按同一库存键从期初加减入库、冻结、释放、出库、盘盈盘亏和调整，任何差异先找缺失、重复或旁路流水，再决定重建投影或追加补偿。真实项目的批次、质检和安全库存公式没有直接证据时保持 E0（待核对），面试中讲清建模原则而不虚构字段。仓内任务还要保存操作者或设备、库位、批次、包裹和复核版本，使每次数量转换都能回到物理证据。退货不能删除原出库，而应形成新的入库或冲正动作；盘盈盘亏也要审批并独立留痕。这样即使投影损坏，仍能由事实流水重建，并区分系统差异与真实货损。 库存口径升级时还要用同一批历史流水重放新旧模型，逐键比较差异，不能让字段迁移改写历史承诺。
   • 追问 1：分配为何不再次扣可售？ 直答 1：它消耗的是已成立冻结，重复扣减会把同一承诺计算两次。
   • 追问 2：释放后迟到出库怎么办？ 直答 2：拒绝状态倒退并建立冲突单，核对实物；已出库则用补扣或调整流水显式修正。
   • 追问 3：快照错但流水守恒怎么办？ 直答 3：在隔离影响后重建快照投影，不修改原始流水，并验证重放结果。
   • 对应知识正文

4. 问题：重复下单和重复消息如何设计幂等键？

   • 考点：业务意图、动作粒度、唯一约束与参数冲突。
   • 回答思路：区分请求幂等、库存动作幂等和消费幂等。
   • 详细答案：订单行与动作标识业务意图，库存流水号标识库存事实，消费者职责与事件号标识一次消费，三层不能混用。
   • 进阶追问：一个订单允许多次部分操作时如何避免误杀？
   • 进阶回答：使用独立动作单号或业务版本，例如每次释放、补发或调整都有自己的身份并引用原事实。
   • 口述答案：幂等键要标识稳定业务意图，不能标识每次网络尝试。订单入口可以由租户、订单号、订单行、仓库、SKU（库存单位）、动作和业务版本组成冻结键，并保存数量等参数摘要；同键同参数重复时返回原结果，同键不同参数直接拒绝和告警。库存侧的冻结、确认、释放和调整是不同动作，分别建立唯一约束并通过预占状态机裁决，不能用一个粗粒度订单号挡住所有合法变化。消息侧使用“消费者职责加事件号”作为 Inbox（收件箱）键，因为仓内建单、库存投影和通知都应各处理一次；库存流水号可作为事件稳定标识。去重记录与业务更新应在同一本地事务中提交，避免先写去重后业务失败造成永久遗漏，或先执行业务后去重失败造成重复副作用。Redis（远程字典服务）短期键可以拦截瞬时重复，但会过期、淘汰和故障丢失，不能保护长时间重放。外部仓调用还要使用稳定请求号，超时后先按原号查询，不能换号绕过对方幂等边界。归档幂等记录时至少覆盖消息保留、最大重试、售后和人工重放窗口。验收要并发注入同一请求、重复消息和参数冲突，证明业务只变化一次，同时每次接收都有审计证据。还要区分“重复已完成”和“同键处理中”：前者直接返回保存的结果，后者不能启动第二个副作用，应返回处理中或由查询任务确认。若历史数据缺少稳定键，不能简单批量生成随机值，而要根据订单、动作和原流水建立迁移映射，冲突对象单独审计。
   • 追问 1：为何“先查有没有”不安全？ 直答 1：两个并发事务可同时查到不存在，必须由写入点唯一约束或条件更新裁决。
   • 追问 2：事件号可以全系统共用吗？ 直答 2：要加消费者职责，否则一个订阅方处理后会误阻止另一个独立订阅方。
   • 追问 3：去重记录多久删除？ 直答 3：至少覆盖传输保留、重试、售后和人工恢复窗口，删除前还要确认业务唯一约束能阻止历史副作用。
   • 对应知识正文

5. 问题：支付超时与库存释放竞争时如何裁决？

   • 考点：未知态、状态机、迟到成功和补偿边界。
   • 回答思路：不按到达顺序判断，回到支付、履约、冻结和仓内权威事实。
   • 详细答案：支付超时保持未知并查单，释放必须确认支付明确失败且冻结未被仓内不可逆作业消耗。
   • 进阶追问：支付、取消和到期扫描三方并发怎样测试？
   • 进阶回答：枚举不同提交顺序并注入响应丢失，验证都收敛到唯一终态，资金和库存动作均有原事实引用。
   • 口述答案：支付超时只说明本地在时间预算内没有收到结果，不能证明渠道失败。订单、支付、履约和库存应分别保存权威状态：支付事件按支付单和渠道事件幂等，取消按订单版本推进，冻结到期扫描只领取候选，真正释放由库存事务二次检查。若支付先确认成功，履约放行后取消要按仓内阶段处理；若取消先合法提交，迟到支付成功不能复活旧订单，应进入退款或人工政策；若到期释放先完成，后到支付成功不能把已释放流水改回有效，只能按业务规则重新申请库存，失败则退款或缺货处置。支付超时时系统保留原请求号主动查单，确认成功则继续履约，确认失败且仓内尚未分配、拣货、复核或过账时，才引用原冻结键幂等释放；仍未知则保留冻结并升级人工。这样会暂时少卖，但避免资金成功后库存被二次承诺。监控重点是支付未知年龄、已支付无有效冻结、已取消仍建仓单、冻结超龄和重复释放冲突。真实支付窗口、取消规则和自动释放阈值属于 E0（待核对），技术方案只能说明如何裁决，不能代替业务政策。到期扫描本身也要有稳定任务键、游标和处理能力，扫描到候选后必须重读当前状态，不能根据缓存过期通知直接增加可售。人工裁决要同时查看渠道结果、订单意图、原冻结和仓内动作，任何退款、重冻或释放都生成独立可审计事实。最终验收需回放支付、取消、到期的多种顺序，证明资金与库存都只有一个终态。 每种竞态排列还要核对退款、重新冻结和仓内拦截没有遗漏，不能只验证订单状态。
   • 追问 1：能延长全部冻结时间解决吗？ 直答 1：会降低可售利用率，应按支付时延、商品稀缺度和承诺成本分级校准。
   • 追问 2：查单也超时怎么办？ 直答 2：继续保持未知，退避并限制总预算，超过最大年龄进入人工，不把多次超时投票成失败。
   • 追问 3：仓内已经拣货还能释放吗？ 直答 3：要先完成仓内拦截和回库证据；已复核或出库通常转售后，不能直接增加可售。
   • 对应知识正文

6. 问题：Redis（远程字典服务）缓存与 MySQL（关系型数据库）各承担什么职责？

   • 考点：权威源、缓存一致性、热点保护与降级。
   • 回答思路：用“缓存可丢可重建，库存事实可审计”划边界。
   • 详细答案：缓存服务查询、预判和削峰，数据库服务最终条件裁决、状态、流水和对账；两者版本差不能通过信任缓存解决。
   • 进阶追问：缓存故障时怎样避免数据库被回源压垮？
   • 进阶回答：按数据库安全容量限流、合并同键请求、分批预热，核心库存事务优先，非核心查询返回旧值或明确降级。
   • 口述答案：我的分工原则是“正确性路径与性能路径分离”。MySQL（关系型数据库）保存库存快照、冻结记录、业务唯一键、状态版本和不可变流水，使用条件更新决定一次冻结、释放或出库是否成立，是最终可审计事实。Redis（远程字典服务）保存按仓库和 SKU（库存单位）聚合的可售读模型、热点标识、限流令牌或短期请求合并，用来减少回源与锁竞争，但缓存命中不等于库存承诺成功。写路径先提交数据库，再通过事务事件失效或刷新缓存；删除失败要重试，回填携带版本，低版本不能覆盖高版本。缓存显示有货而数据库条件失败时，返回库存不足并删除旧值；缓存显示无货可以提前拒绝，但若业务要求更高准确度可回源确认。缓存全失时按数据库安全容量建立回源闸门，热点请求合并，分仓分批预热，在线冻结和出库优先，报表与聚合查询降级，不能为了可用性绕过条件更新。Lua（脚本语言）可以保证单个缓存执行点原子，却不能自动解决持久化、主从切换、数据库落地与消息双写。线上除了命中率，还要看回源绝对量、单键高分位、版本落后、删除失败、重建耗时和数据库连接等待。真实缓存键、过期时间和一致性窗口没有配置证据时保持 E0（待核对）。版本差持续扩大时要先关闭错误回填路径，保留数据库写入并限制查询流量，再按库存键从权威源重建。恢复后不能只看命中率回升，还要确认缓存版本追平、回源降到安全范围、删除补偿无滞留，并抽样证明缓存读不会改变冻结和出库结果。
   • 追问 1：为何通常更新数据库后删除缓存？ 直答 1：先稳定权威事实，再让后续未命中加载新值，能缩短旧值长期回填窗口，但仍需版本和重试。
   • 追问 2：命中率 99% 为什么仍可能过载？ 直答 2：总流量足够大或 1% 未命中集中到同一慢查询时，回源绝对量仍会超过数据库容量。
   • 追问 3：缓存能否保存冻结明细？ 直答 3：可做加速副本，但关键冻结必须在持久权威边界可查询、可重放和可对账。
   • 对应知识正文

7. 问题：为什么分布式锁不能作为库存正确性的唯一方案？

   • 考点：租约、所有权、故障切换、幂等与栅栏。
   • 回答思路：区分进入权与结果接纳权。
   • 详细答案：锁只能协调某一时刻的竞争，不能撤销暂停中的旧进程，也不能处理锁释放后的重复消息；资源端仍需条件与版本裁决。
   • 进阶追问：RedLock（红锁）已在简历出现，应怎样表述？
   • 进阶回答：可以说简历写明用于任务领取和库存预配竞态；多数派节点、租约和生产版本需配置与源码核对，不能外推绝对安全。
   • 口述答案：分布式锁的价值是减压，不是定义业务事实。它可以让同一仓库与 SKU（库存单位）的热点请求少量进入，减少数据库锁等待和重复计算；但租约可能在进程暂停时过期，网络分区或主从切换可能短时出现两个持有者，旧进程恢复后仍可能继续写，消息也可能在锁释放后再次投递。锁服务只知道授权过期，无法强制停止已经运行的代码。因此库存最终要在资源端用稳定业务键、数据库唯一约束、可售条件更新、前置状态和版本决定是否接纳结果，流水负责解释变化，对账负责发现旁路。释放锁还要比较持有者令牌，避免误删新持有者的锁；长任务需要有界续租，若存在旧执行者迟到写风险，可让提交点比较单调版本或栅栏令牌。即使锁完全不可用，系统也应能降低入口并依赖数据库条件更新保持不超卖，只是吞吐和等待会变差。简历能直接证明使用 RedLock（红锁）处理任务领取和库存预配竞态，但具体节点数、租约、客户端版本和事故表现属于 E0（待核对）。面试时我会明确：锁失效若只增加一次无效竞争，说明后面的幂等和条件防线有效；若直接造成负库存，说明把性能机制误当成正确性机制。测试要覆盖持有者暂停超过租约、旧持有者恢复、解锁请求迟到和锁服务切换，让两个执行者同时到达数据库提交点。正确结果应是最多一个业务动作生效，另一个命中唯一结果或版本失败；恢复后锁指标正常还不够，必须复算库存流水并确认没有迟到副作用。
   • 追问 1：锁过期后旧线程如何阻止？ 直答 1：旧线程自身可能停不住，必须在数据库提交或权威资源端比较状态版本或栅栏令牌拒绝迟到结果。
   • 追问 2：有幂等后还需要锁吗？ 直答 2：正确性可能不依赖锁，但热点计算、外部查询和锁等待成本高时，锁仍能提升性能。
   • 追问 3：锁不可用时是否直接放行？ 直答 3：不能；应限流并进入数据库条件裁决，必要时明确繁忙，不能降低库存约束。
   • 对应知识正文

8. 问题：波次、拣货、复核与过账怎样保证仓内状态单调？

   • 考点：责任转移、任务版本、实物差异与不可逆点。
   • 回答思路：沿仓单从计划到实物离仓逐段说明输入、结果和失败去向。
   • 详细答案：波次是调度分组，分配绑定库位，拣货记录实拣，复核确认商品包裹，过账形成出库事实；每段都要条件状态和动作唯一键。
   • 进阶追问：设备离线后补传作业记录怎样处理？
   • 进阶回答：沿用原动作号逐条幂等接收，校验事件时间、复核版本和当前终态，冲突进入异常单而非按到达顺序覆盖。
   • 口述答案：仓内作业不是一条可以整体回滚的数据库事务，而是责任逐步转移。波次按仓库、截单时间、库区和承运条件组织待作业仓单；分配把已冻结数量绑定到具体库位、批次或容器；拣货记录实际拿取的商品和数量；复核核验 SKU（库存单位）、数量、批次与包裹；过账在可信复核版本基础上消耗冻结、减少实物并发布出库事实。每个任务都携带仓单、动作号、版本、操作者或设备身份，状态条件只允许合法前驱推进，重复扫描或消息返回原结果，迟到任务不能让已过账状态倒退。波次成员可以很多，但库存分配和任务创建应按有限批次提交检查点，避免整波大事务。拣货少货、破损或错位时先冻结差异，建立异常单并核对库位和实物，不能直接增加可售；取消到达时按当前阶段选择释放、取消任务、仓内拦截、返拣或售后。过账反馈通过可靠消息传播，但消息确认不代替出库流水；重复反馈由出库动作键和状态机吸收。简历直接支持负责入库、在库、出库、送检和过账公共方法，波次、拣货与复核的具体生产状态属于 E0（待核对），本回答按 E2（已有材料映射）说明完整责任链。波次完成不能只保存一个成功标志，应比较期望成员、已完成、异常和未处理总数；任务重启从检查点继续。恢复时按仓单抽样核对分配明细、实拣数量、复核结论、出库流水与包裹，发现设备补传冲突就保留原记录和异常单，不能选择最后到达的事件覆盖物理事实。 波次关闭前还要证明成员总数守恒、异常有责任人，并且不存在未领取或失租任务。
   • 追问 1：波次为何不是一个大事务？ 直答 1：调度完整性可由成员状态聚合，大事务会放大持锁、日志、回滚和单点失败范围。
   • 追问 2：复核通过后还能取消吗？ 直答 2：要看是否已过账与物理交接，通常需要拆包返拣或转售后，不能直接释放冻结。
   • 追问 3：过账反馈丢失怎么办？ 直答 3：按出库动作号查询权威流水并补发原事件，不能再次执行出库扣减。
   • 对应知识正文

9. 问题：库存消息延迟和积压时如何恢复？

   • 考点：事实与传播、净恢复率、优先级、幂等回放。
   • 回答思路：先保护库存事务，再判断积压增长，最后小批回放并业务对账。
   • 详细答案：库存事实与待发布记录同事务存在，延迟不回滚冻结；恢复依据到达率、有效完成率和最老年龄控制实时流与历史流。
   • 进阶追问：消费者扩容为什么可能让数据库更慢？
   • 进阶回答：更多消费者会同时争抢热点库存、仓单和连接，若下游处理能力不变，只会放大锁等待与重试。
   • 口述答案：消息延迟时先分清库存事实是否已经提交。若条件冻结、库存流水和待发布事件在同一事务成功，冻结已经成立，Kafka（分布式日志消息系统）积压只表示仓内尚未收到，不能因此释放或重复冻结。排障先看待发布滞留、分区或队列积压、最老消息年龄、有效消费完成率、数据库延迟和错误指纹；毒消息应隔离，避免反复占用消费者。止血时保留库存、释放和出库等关键订阅，暂停报表、推荐和低价值投影；入口按数据库安全水位限流，防止新冻结继续扩大仓内承诺。恢复时间用 积压/(完成率-到达率) 估算，若净完成不为正，就先修消费者、降入口或增加有用容量。恢复后实时事件与历史积压使用独立配额，按仓库和业务键小批回放，原事件标识不变，消费者通过 Inbox（收件箱）、业务唯一键和状态版本吸收重复与乱序。不能一次全量重放，也不能只看消息数归零；还要确认冻结超龄下降、仓单和波次补齐、迟到释放没有覆盖已出库状态，并按库存流水、仓单与实物抽样对账。真实分区数、处理能力和告警阈值属于 E0（待核对），演练数字必须标 E3（演练设计）。若消费确认丢失导致同一事件反复到达，去重记录与仓内更新必须同事务提交，重复命中快速返回原结果。发布器、消费者和补偿器分别设置预算，避免同时恢复形成尖峰；每次提高回放速率都检查数据库连接、锁等待、仓内任务年龄和错误率，任一反弹立即退回前一档。
   • 追问 1：积压下降多久可以放开入口？ 直答 1：还要看最老年龄、数据库余量和业务差异，稳定一个约定窗口后再小步放量。
   • 追问 2：死信能否直接丢弃？ 直答 2：不能；先检查当前状态、版本、时效和幂等，分类为可重放、已完成、过期或人工。
   • 追问 3：消息发送成功能否关闭冻结任务？ 直答 3：不能，发送成功只到传输边界，仓内业务完成还需消费结果、仓单状态和对账证明。
   • 对应知识正文

10. 问题：怎样设计库存人工补偿流程？

• 考点：差异分类、只读预演、权限、补偿幂等与审计。
• 回答思路：从证据保全到再次对账，强调不能直接改快照。
• 详细答案：补偿先分类投影、流水、实物和外部事实差异，再选择重建、冲正、调整或人工裁决，并保留原因果。
• 进阶追问：哪些差异不应自动修复？
• 进阶回答：涉及实物、已出库不可逆动作、证据冲突、大额批量、跨账期或权限异常的差异应人工复核。
• 口述答案：人工补偿首先是受控业务能力，不是开放一条改库通道。发现差异后先按仓库、货主、SKU（库存单位）、订单行和动作建立清单，冻结会扩大影响的新增预占、波次或自动释放，并保全库存快照、不可变流水、仓单、拣货复核、过账、消息和人工操作证据。对账先判断是投影错误、漏流水、重复动作、外部或仓内结果未知，还是实物差异；投影错误可以从流水重建，确认缺失的业务事实通过引用原动作的补偿流水修正，重复消息读取原结果，实物和不可逆出库必须盘点或人工裁决。工具执行前提供只读预览，展示影响对象、当前状态、预计变化与停止条件；操作人只能选择预定义动作和授权范围，高风险批量释放、调整和重放由不同角色复核。执行使用稳定补偿键、版本条件、小批限速和检查点，部分成功时只继续未完成对象，不重做已成功对象。修复不覆盖原流水，而是追加冲正或调整并关联差异单、审批人与原因。每批完成后复算可售、冻结、已扣与实物，抽样核对仓内作业；证据不足的对象保持冻结和人工状态。真实角色矩阵、额度和审计保留期属于 E0（待核对）。补偿工具还要记录执行版本、输入摘要、操作者、复核者、开始结束时间和每个对象结果，并提供硬性批次与速率上限。审计存储不可用时高风险动作默认拒绝或进入独立可靠缓冲；恢复完成后撤销临时权限，确认没有未关闭的补偿任务和孤儿差异单。 补偿若需要撤销，也必须生成引用原调整的新流水并再次审批，不能删除既有修复记录。
• 追问 1：为什么不能把负库存改成零？ 直答 1：会掩盖缺失或重复事实，也可能凭空增加可售；修正必须有来源流水和实物证据。
• 追问 2：运维紧急改库怎么办？ 直答 2：应走审批、备份、脚本评审、限范围执行和前后对账，随后补录业务审计，不能无痕修改。
• 追问 3：补偿失败如何重试？ 直答 3：沿用补偿键和检查点，先重读当前状态，仍满足条件才在预算内重试，否则转人工。
• 对应知识正文

11. 问题：订单、库存、仓单和实物如何做对账？

• 考点：对象范围、双时间、流水重放、差异分类与批次覆盖。
• 回答思路：从库存内部守恒逐层核对订单承诺、仓内责任和实物结果。
• 详细答案：对账不能只比较两个余额，要统一库存键、时间窗口和口径版本，并保证未扫描对象不从分母中消失。
• 进阶追问：迟到消息怎样避免被误判为永久差异？
• 进阶回答：同时保存业务发生时间和系统处理时间，在修订窗口内回填；窗口关闭后仍迟到的对象进入专项差异而非静默覆盖。
• 口述答案：对账先统一对象、窗口和口径。对象按货主、仓库、SKU（库存单位）及必要批次分片，既保存业务发生时间，也保存系统处理时间，避免消息迟到被误判成永久缺失。第一层核对库存内部守恒：可信期初加上入库、冻结、释放、出库、盘盈盘亏和调整流水，应等于期末快照；第二层核对订单承诺，每个有效订单行应有唯一有效冻结或明确失败；第三层核对冻结、仓单和任务，已经放行的履约应能找到波次、分配、拣货或异常责任；第四层核对仓内与实物，复核、过账、出库和盘点证据应指向同一结果。差异不能统一修余额：有流水无投影就重建投影，有冻结无仓单就检查待发布和消费，有仓内成功无本地状态就补关联，重复释放或出库由幂等结果吸收，实物差异冻结库位并盘点。补偿通过新流水引用原事实，执行后再次对账。对账任务自身保存批次、分片检查点、口径版本、已扫描数和失败数，不能把扫描失败对象计入“零差异”。关闭批次前复算总数与校验摘要，并抽样原始记录。真实对账频率、差异阈值和盘点制度属于 E0（待核对），但“可追踪、可复算、可补偿”是必须守住的设计合同。例如期初实物 120、订单冻结 20，窗口内新增冻结 30、释放 8、过账 12、盘盈 2，则期末实物应为 110，冻结为 30，可售为 80；在线快照若显示 78，差异就是 -2。恢复验收要求定位这 2 件来自漏流水、重复投影还是盘点差，而不是直接把快照改成 80；同时确认对账分片全覆盖、失败对象有清单、补偿后再次复算仍守恒。
• 追问 1：为什么快照等于流水还不够？ 直答 1：两者可能一起漏掉实物动作，还要核对订单、仓单、过账和盘点证据。
• 追问 2：对账差异能否全自动修？ 直答 2：只有证据唯一且动作可逆的低风险差异可自动，实物、不可逆和冲突证据必须人工。
• 追问 3：批次失败后怎样重跑？ 直答 3：沿用口径版本和分片检查点幂等重跑，已完成分片校验后跳过，不能新建口径混合结果。
• 对应知识正文

12. 问题：线上发现可售为负，怎样从止血到恢复？

• 考点：事故证据链、流水重算、存量处置和恢复门禁。
• 回答思路：按现象、假设、证据、止血、修复、验收和复盘回答。
• 详细答案：先冻结受影响键和批量任务，保全快照、流水、消息与人工证据，再区分真实超卖和投影错误。
• 进阶追问：如何证明根因不是缓存陈旧？
• 进阶回答：缓存只影响展示或预判；对比数据库条件更新、唯一流水、订单承诺和实物，若权威链守恒而缓存旧，才是缓存问题。
• 口述答案：我会把可售为负定义为业务正确性事故，而不是先执行修正语句。第一步按仓库、货主、SKU（库存单位）和批次隔离新增预占，暂停相关波次、自动释放和补偿，保留只读查询，防止错误继续扩大。第二步冻结时间线与版本，保存当前快照、最近可信期初、冻结释放出库流水、订单与仓单状态、消息位点、死信、人工调整审计、事务和锁等待证据。第三步提出可证伪假设：条件更新被旁路绕过、重复扣减、双重释放、迟到旧版本覆盖、投影计算错误或人工直接改库。按业务键从期初重放到当前，比较计算快照、在线快照、有效订单承诺和实物；流水守恒而快照错误属于投影问题，有效承诺确实超过实物才是超卖。修复时，投影错误从流水重建；确认缺失或重复事实则通过审批追加冲正或调整流水；涉及实物就盘点，证据不足继续冻结，绝不把负数直接改零。恢复先选少量库存键影子复算，再按仓库分批放量，持续观察条件失败、锁等待、未知态和差异，确认历史订单与仓单也闭环。复盘补上旁路权限、架构检查、对账告警和原故障注入。真实影响范围与恢复时间没有记录时保持 E0（待核对）。例如实物 80、有效冻结 50、已分配 20，理论可售为 10，快照却是 -5；流水发现同一过账动作重复扣减 15，则追加引用原动作的冲正后回到 10。验证时再次投递该过账、重复执行冲正并重建缓存，数值都不得变化；仓内还要确认确有一次包裹出库，而不是用数学守恒掩盖重复实物发货。
• 追问 1：为什么先停波次？ 直答 1：批量会扩大写入、锁竞争和错误快照传播，先保护在线库存事实更重要。
• 追问 2：是否应清空全部缓存？ 直答 2：只处理受影响键并限流回源，盲目全清可能制造数据库雪崩。
• 追问 3：何时恢复全量流量？ 直答 3：守恒、历史差异、未知态和人工队列收敛，并在小流量完整业务窗口内无反弹后逐步扩面。
• 对应知识正文

13. 问题：618 大促前怎样做库存容量与故障演练？

• 考点：热点分布、流量放大、单故障域余量、恢复时间与退出条件。
• 回答思路：从订单率推导库存动作，再用真实热点和故障注入验证。
• 详细答案：容量不能只报机器数，应拆订单行、重试、缓存回源、消息与仓内任务放大，并预留故障后核心路径余量。
• 进阶追问：压测平均吞吐达标为什么仍可能上线失败？
• 进阶回答：真实热点会集中到单键，尾延迟、锁等待、外部限额和恢复流量都可能被平均值掩盖。
• 口述答案：618 容量准备先取真实业务输入，而不是先拍实例数。需要订单峰值、每单商品行高分位、热点 SKU（库存单位）集中度、重复请求和取消比例、缓存命中与回源、每次冻结产生的快照、流水和事件写放大、波次与仓内任务量、消息保留及外部系统额度。由订单率乘商品行、重试和候选仓得到库存尝试率，再用到达率乘高分位事务时间估算在途；热点键还要单独计算，因为总吞吐分散并不代表单行没有串行瓶颈。容量以失去一个约定故障域后仍能承受核心冻结、释放和出库为门槛，报表、看板和低优先同步可暂停。压测采用阶梯流量和接近生产的热点分布，观察可售不变量、条件失败、锁等待、尾延迟、连接等待和消息年龄；随后注入缓存全失、锁租约过期、数据库慢、消息重复与延迟、消费者重启、支付超时和人工回放。恢复时间按 积压/(有效完成率-新到达率) 计算，实时与历史流分配独立额度。退出条件包括任何负库存、重复副作用、净恢复非正或对账差异超门槛。简历能证明参与 618 库存性能与安全方案，但真实峰值、压测结果和收益必须从报告与监控取证，不能把演练输入当生产数据。演练可设入口每秒 1000 单、平均 3 行、5% 重试，库存尝试约 3150 次；若前 1% 商品占 40%，必须为热点键单独限流。故障 10 分钟形成 180000 条积压，恢复有效完成每秒 1300、新到达 700，理论 300 秒清空。放量前还要确认波次等待、冻结年龄和数据库余量同时达标，不能只看消息吞吐。
• 追问 1：为什么必须压热点分布？ 直答 1：同一库存键是共享串行点，均匀流量会显著高估实际能力。
• 追问 2：容量余量越大越好吗？ 直答 2：要结合扩容时延、失败成本和预算，核心是单故障域后仍满足承诺而非无限冗余。
• 追问 3：演练通过就能全量上线吗？ 直答 3：还需灰度、真实输入校准、回退脚本和业务对账门禁，先小流量再扩面。
• 对应知识正文

14. 问题：项目结果与个人贡献怎样做到可信且有力度？

• 考点：证据等级、职责边界、业务指标与口述可信度。
• 回答思路：先给 E1（直接证据）交付，再给验证方法和 E0（待核对）缺口。
• 详细答案：力度来自可定位职责、决策因果、失败处理和验收口径，不来自未经证明的百分比。
• 进阶追问：面试官坚持追问“提升多少”时怎么办？
• 进阶回答：明确现有证据不足，给指标定义、计算公式和应取的监控或业务报表，不编造近似值。
• 口述答案：我会把“做了什么、怎样证明、哪些还未知”分层表达。E1（直接证据）层可以说：项目要统一多个事业部原有 4 套仓储系统，我负责成品和部分原材料模块，参与库存表模型，负责入库、在库、出库、送检、过账公共方法，参与 R1、R2、R3 上线与现场问题处理，并在 618 版本负责库存性能和安全方案，使用热点缓存和分布式锁，消息用于低耦合协同与过账反馈。个人贡献用需求、代码、评审、发布和现场处置描述，系统统一和业务收益则属于团队。E2（已有材料映射）层可以解释条件更新、稳定幂等键、状态机、仓内责任和对账为何形成闭环，但不能说生产一定按这套细节实现。E3（演练设计）层用可售 100、并发 140、最多 100 次条件更新成功等样例展示推理，并明确不代表真实峰值。E0（待核对）层列出锁版本、真实流量、超卖与错发指标、人工成本、事故时间线和收益，需要源码、配置、监控、库存流水、盘点、工单和复盘核验。结果指标也不能只报接口成功，应看有效冻结、过账完成、未知年龄、差异收敛和实物抽样。这样既有具体职责和机制深度，也不会把团队成果、建议方案或演练数字包装成个人生产业绩。例如演练 1000 个请求中 700 个有效冻结、250 个库存不足、50 个重复，业务成功是 700 而不是接口处理 750；仓内过账 680、合法释放 5、未知 15，总数必须与冻结一致。若面试官追问提升比例，我会给出这套口径和所需报表，不把演练完成率说成生产收益。
• 追问 1：小组长贡献如何体现？ 直答 1：说明规则统一、风险评审、任务协调、上线门禁和现场闭环，具体动作由评审与发布记录支撑。
• 追问 2：E2（已有材料映射）有没有价值？ 直答 2：有，它展示方案理解与迁移能力，但语气必须是“可采用、已有材料提出”，不是“生产已上线”。
• 追问 3：如何避免只讲个人不讲协作？ 直答 3：明确订单、仓储、生产、销售和运维责任边界，说明自己负责的接口和推动动作，不吞并团队成果。
• 对应事实账本

15. 问题：这个项目最重要的复盘与下一步演进是什么？

• 考点：业务不变量、旁路治理、故障注入、可逆迁移与停止条件。
• 回答思路：先总结认知升级，再给行动项、门禁和演进顺序。
• 详细答案：复盘应从“加缓存和锁”升级到“权威事实、状态、幂等、未知查证和对账恢复”，演进先补基础合同再拆服务。
• 进阶追问：什么情况下应该推翻当前方案？
• 进阶回答：不变量无法满足、恢复窗口不可接受、热点成本失控、外部依赖无法查证或团队无法安全运维时，应重新评审边界和技术路线。
• 口述答案：我最大的复盘是，库存安全不能被概括成“Redis（远程字典服务）加分布式锁”。缓存和锁解决的是性能与竞争，真正决定业务正确的是权威库存键、条件更新、稳定幂等身份、合法状态迁移、不可变流水、未知态查证、人工边界和对账。复盘会从事故时间线检查五类薄弱点：是否存在绕过库存服务直接写表的旁路；幂等键是否在客户端重试和消息重投中稳定；支付或仓内超时是否被错误当成失败；实时流与补偿流是否共享资源形成重试风暴；恢复是否只看服务和消息，而没有核对历史冻结、过账与实物。行动项必须有负责人、截止时间、完成证据和下一次演练，修代码后还要处理在途请求、旧消息、历史差异和临时权限。下一步优先统一业务键、库存流水、异常状态、对账批次与人工补偿工具，这些能力不依赖是否微服务；再依据真实热点、团队边界和独立扩缩容收益决定拆分。若迁移库存权威写，先做事件镜像和影子读，双写只用于校验且保持单主裁决，按仓库或租户灰度，差异、未知年龄或恢复演练超限就切回旧路径。停止条件同样重要：服务化收益不足以覆盖网络失败、版本兼容和运维成本时，保留清晰模块边界更合适。所有真实改进效果仍按 E1（直接证据）与 E0（待核对）边界表达。我会专门注入“旧执行者失租后迟到过账、新执行者已接管”的场景：数据库只接受当前版本，旧结果进入审计；再模拟回退，确认路由切回后事件可追平、冻结与实物仍守恒。行动项只有在这类反例通过、历史异常清零且临时权限回收后才关闭。
• 追问 1：最先补哪项能力？ 直答 1：先统一稳定业务键、流水与对账，因为它们同时支撑幂等、排障、补偿和迁移。
• 追问 2：库存服务为何最后拆？ 直答 2：它承担最强数量不变量，双主冲突难以合并，先拆可回退副作用风险更低。
• 追问 3：如何证明行动项关闭？ 直答 3：用原故障组合重新注入，提交守恒、积压、未知态、人工队列和回退证据，并经过复核。
• 对应知识正文

10. 复习与审计清单

• 能在三分钟内按八段式讲完整项目，并在每个结果旁指出 E1（直接证据）、E2（已有材料映射）、E3（演练设计）或 E0（待核对）。
• 能写出可售、冻结、已扣、实物之间的关系，并解释分配、拣货和复核为何不重复扣可售。
• 能说明 MySQL（关系型数据库）、Redis（远程字典服务）、分布式锁与 Kafka（分布式日志消息系统）的职责边界。
• 能用条件更新、稳定幂等键和状态机演绎并发扣减、重复下单与重复释放。
• 能处理支付超时、消息延迟、波次大事务、仓内迟到回执和人工补偿。
• 能按业务键完成库存、订单、仓单、复核、过账与实物对账。
• 能按现象、假设、证据、止血、查证、修复、恢复验收和复盘回答可售为负事故。
• 能复算 8 组演练输入、公式、状态变化、观测信号和结论，不把演练数字当成生产数据。
• 能定位 8 张主题唯一 Mermaid（图表语法）图、9 张标准表和正式 PlantUML（开源建模工具）故障恢复图。
• 能完成 15 道综合题的 560–900 有效字符口述，并继续回答每题 3 组独特追问。