方案评审、失败路径、迁移演进与综合题库

章节定位：本章是架构案例库的横向收口章。案例事实与证据边界见案例索引、事实卡与迁移路线；纵向细节分别见库存与仓内作业、支付资金正确性、跨境履约与轨迹、异步导出、Runner（执行器）调度、IoT（物联网）报警治理和多模型数据方案。本章数字均为演练输入，不冒充生产事实。

1. 方案评审输入与结论分级

1.1 评审先验证输入完整性，再讨论架构图是否漂亮

方案评审的产物不是“通过”两个字，而是一组带证据等级、适用范围、停止条件和责任人的可执行结论。主持人先确认业务目标、峰值与增长、数据权威、不可违反的不变量、依赖配额、恢复目标、安全边界、成本上限和退出路径。缺失输入不能靠经验数字填平，应标为待核对，并把结论限制为可逆试验。七个案例虽然技术不同，但评审顺序一致：先问什么结果绝不能错，再问失败时怎样证明、怎样止血、怎样恢复，最后才比较吞吐和成本。

sequenceDiagram
    participant 业务 as 业务负责人
    participant 评审 as 方案评审组
    participant 数据 as 数据负责人
    participant 运行 as 运行负责人
    业务->>评审: 提交目标、损失与量级证据
    评审->>数据: 核对权威源、不变量与保留
    数据-->>评审: 返回已证实项和待核对项
    评审->>运行: 验证止血、恢复、回滚与退出
    alt 关键输入缺失
        运行-->>评审: 仅允许可逆试验并设置补证期限
    else 输入完整
        运行-->>评审: 按门禁批准有限范围实施
    end

数据演绎 1：评审覆盖率不是简单平均

某方案有 20 项输入，其中不变量、恢复和退出共 8 项被定义为关键项。已核对 17 项，表面覆盖率为 17 ÷ 20 = 85%；但若缺失的 3 项恰好是资金唯一入账、恢复起点和回滚开关，则关键项覆盖率仅为 5 ÷ 8 = 62.5%。结论不能按 85% 通过，而应停留在影子验证。补齐三项后，两种覆盖率才同时达到 100%。

热门面试题

1. 问题：方案评审为什么不能只给通过或不通过？
   • 考点：结论分级与可执行性。
   • 回答思路：从范围、证据、门禁和责任说明评审产物。
   • 详细答案：二元结论会隐藏适用范围和未决风险。合格结论应说明哪些事实已证实、哪些仍待核对，允许在哪些租户或流量实施，触发什么阈值必须停止，由谁补证、回滚和验收。这样实施者才能把评审意见转成发布动作，事故时也能追溯当时依据。
   • 进阶追问：待核对项很多时是否一定驳回？
   • 进阶回答：不一定；不触碰关键不变量的部分可做只读影子或离线试验，但资金写、库存裁决和不可逆控制必须等关键证据齐备。
2. 问题：怎样防止评审会上用假精确数字推动结论？
   • 考点：证据等级与敏感性分析。
   • 回答思路：区分实测、推导和演练输入。
   • 详细答案：每个数字都记录来源、时间范围、样本量和单位；没有生产证据时明确写成区间演练，并改变峰值、失败率和恢复吞吐观察结论是否翻转。若输入变化 20% 就使方案越过资源或风险红线，评审应要求压测或日志补证，而不是用小数位营造可信度。
   • 进阶追问：哪类数字最值得先核对？
   • 进阶回答：会改变架构选择或失败成本的数字最优先，例如热点集中度、渠道配额、最大在途量、恢复净吞吐和数据保留期。
3. 问题：七个案例如何使用同一套评审框架？
   • 考点：共性框架与领域差异。
   • 回答思路：框架统一，失败成本和验收口径分开。
   • 详细答案：所有案例都按目标、量级、不变量、权威源、正常路径、失败路径、容量、观测、恢复、成本和迁移评审；差别在于库存关注余额不为负，支付关注资金与分录守恒，物流关注外部未知态，导出关注资源隔离，调度关注旧执行者，报警关注高危不漏，多模型关注派生可重建。
   • 进阶追问：共用模板会不会导致内容空泛？
   • 进阶回答：会，所以每一格必须填写领域对象、可复算公式、具体失败动作和验收证据；只有标题相同而内容不同，模板才是检查表而不是话术套壳。

2. 约束排序、否决项与取舍边界

2.1 先写不能违反的硬约束，再对软目标做优化

约束分为法律与安全、业务不变量、外部合同、运行能力、成本预算和体验目标。硬约束一旦违反会造成资金、库存、隐私或物理安全损失，应作为候选否决项；软约束可以通过延迟、采样、排队或人工处理暂时退让。评审不能把所有目标放入加权总分，因为高吞吐得分不应抵消重复入账。正确做法是先用硬约束淘汰，再在合格候选中比较可用性、交付速度和单位正确结果成本。

sequenceDiagram
    participant 候选 as 候选方案
    participant 门禁 as 硬约束门禁
    participant 评分 as 软目标评分
    participant 决策 as 决策人
    候选->>门禁: 提交正确性、安全和外部合同证据
    alt 任一硬约束不满足
        门禁-->>决策: 否决或降为只读试验
    else 全部满足
        门禁->>评分: 比较时延、成本和交付复杂度
        评分-->>决策: 给出排序、敏感项和反例
    end

数据演绎 2：否决项不能被总分稀释

候选甲在性能、成本、交付速度上分别得 95、90、85 分，但资金幂等仅 40 分；候选乙分别为 80、75、70 分，资金幂等为 100 分。若四项平均，甲为 77.5 分、乙为 81.25 分，看似差距不大；若误给性能更高权重，甲甚至可能胜出。把资金幂等设为 100 分硬门槛后，甲直接淘汰，避免“优势抵消致命风险”。

热门面试题

1. 问题：硬约束和软目标怎样区分？
   • 考点：失败成本与可逆性。
   • 回答思路：看违反后是否可被延迟或补偿安全恢复。
   • 详细答案：若违反会造成不可接受的资金、库存、隐私、审计或物理控制后果，并且事后难以完整补偿，就是硬约束；若主要影响等待时间、查询新鲜度或人工成本，且有明确降级和恢复路径，可作为软目标。区分必须由业务和风险负责人共同确认。
   • 进阶追问：成本预算会成为硬约束吗？
   • 进阶回答：会；当预算是采购或经营上限时属于硬约束，但应先保证最低正确性方案存在，不能以预算不足为由静默降低资金和安全保证。
2. 问题：为什么不建议一开始就使用加权评分？
   • 考点：补偿性评分缺陷。
   • 回答思路：解释高分抵消致命缺陷的风险。
   • 详细答案：加权评分默认各指标可以互相补偿，而正确性和安全通常不可被性能补偿。应先用否决项、最低门槛和前置条件过滤候选，再对剩余方案评分；同时公开权重变化的敏感性，防止人为调整权重制造既定答案。
   • 进阶追问：候选都过不了硬门槛怎么办？
   • 进阶回答：回到需求缩减范围、分阶段建设或引入人工控制，不能从不合格候选中硬选一个进入生产主责。
3. 问题：怎样处理业务方提出的互相冲突目标？
   • 考点：约束协商。
   • 回答思路：量化失败成本并设计降级顺序。
   • 详细答案：把“低延迟、零差错、低成本”拆成具体对象和时间窗口，先固定不可退让的不变量，再列出峰值时可暂停的查询、导出、普通报警或历史回放。通过场景演练让决策人看到每种取舍的用户影响、恢复时间和费用，由业务签署优先级。
   • 进阶追问：优先级签署后是否永久有效？
   • 进阶回答：不是；流量、合同和风险变化会使边界失效，应设复审日期，并在事故或容量拐点后重新确认。

3. 权威事实、不变量与可验证成功

3.1 成功必须由权威事实证明，缓存、消息和派生结果只能提供线索

跨案例评审最先找“谁裁决成功”。库存由余额、预占流水和仓内实物关系裁决；支付由交易凭证、支付单和借贷分录裁决；跨境履约由本地意图、外部单号与原始轨迹裁决；导出由冻结条件、分片清单和不可变产物裁决；调度由任务尝试、租约代次和业务副作用裁决；报警由原始事件、规则版本、报警实例与通知控制记录裁决；多模型系统则由交易源裁决，搜索和分析可删除重建。成功定义必须能被对账重复计算，不能依赖某次接口返回或某条消息已经消费。

sequenceDiagram
    participant 请求 as 业务请求
    participant 权威 as 权威事实层
    participant 事件 as 事件传播层
    participant 派生 as 派生结果
    participant 对账 as 对账控制面
    请求->>权威: 条件提交状态与流水
    权威-->>请求: 返回权威版本
    权威->>事件: 发布已提交事实
    事件->>派生: 至少一次传播
    对账->>权威: 读取裁决集合
    对账->>派生: 读取投影集合
    对账-->>派生: 按版本修复差异，不反写权威

数据演绎 3：接口成功率不能替代业务正确率

演练中 100,000 次支付接口有 99,900 次返回成功，接口成功率为 99.9%。对账发现其中 8 笔没有唯一分录，另有 3 笔重复入账；真正正确闭环数为 99,900 - 8 - 3 = 99,889，业务正确率为 99.889%。同时 100 次接口失败中有 12 笔通道实际成功，必须查证后补记，说明返回码既会制造伪成功，也会制造伪失败。

热门面试题

1. 问题：为什么消息消费成功不能证明业务成功？
   • 考点：传输事实与业务事实。
   • 回答思路：区分消息确认、事务提交和外部副作用。
   • 详细答案：消费成功只证明处理器走到了确认位置，不能证明数据库事务、外部渠道或实物动作都唯一完成。处理器可能先调用外部再提交失败，也可能业务成功但确认丢失。必须用稳定业务键查询权威结果，并通过流水、版本和对账裁决。
   • 进阶追问：那消息系统还负责什么？
   • 进阶回答：负责可靠唤醒、削峰和传播已提交事实；它降低丢失概率，但业务唯一性和结果裁决仍由领域层承担。
2. 问题：怎样给“成功”下一个可测试定义？
   • 考点：状态、证据与副作用。
   • 回答思路：列出必须同时成立的权威条件。
   • 详细答案：成功定义应包含合法终态、对应不可变流水、唯一业务键、外部凭证或产物摘要、必要副作用状态以及可对账关系。测试时既验证正常提交，也注入响应丢失、重复投递、进程重启和旧版本写，确认重新查询仍得到同一结果。
   • 进阶追问：终态是否永远不可改变？
   • 进阶回答：业务终态不应被普通旧事件倒退；退款、冲正、订正等通过新动作和新流水表达，而不是覆盖原终态证据。
3. 问题：多模型系统出现差异时为什么不能多数投票？
   • 考点：唯一权威源。
   • 回答思路：说明派生副本可能共享同一错误来源。
   • 详细答案：搜索、分析和时序副本可能都由同一条错误或遗漏事件生成，数量多不代表更真实。裁决应回到交易源、外部凭证和不可变日志，确认正确版本后重建派生；投票会把传播错误放大为业务事实。
   • 进阶追问：权威源自身损坏怎么办？
   • 进阶回答：从最后可信备份、事务日志和外部凭证重建，并保留恢复批次与差异清单；在证据不足时冻结危险写，不能让派生副本自动晋升为权威。

4. 失败域、资源隔离与故障放大控制

4.1 按失败成本切分资源，让恢复流量不能拖垮实时主链

失败域是可独立限流、熔断、暂停、扩缩和恢复的影响边界，不等于部署服务数量。合理边界通常同时考虑租户、渠道、任务类型、数据分区和风险等级。支付渠道故障不能占满其他渠道查询预算；大导出和历史回放不能抢占在线交易数据库；长任务不能堵住短任务；大租户报警风暴不能挤出小租户高危事件；搜索重建不能反向压垮交易源。每个域需要独立队列、并发额度、连接预算、重试预算和最老年龄观测，跨域共享资源则必须预留核心保底份额。

sequenceDiagram
    participant 实时 as 实时主链
    participant 配额 as 分域配额器
    participant 普通 as 普通任务域
    participant 恢复 as 恢复回放域
    participant 下游 as 共享下游
    实时->>配额: 申请核心保底份额
    普通->>配额: 申请普通份额
    恢复->>配额: 申请剩余恢复份额
    配额->>下游: 按域发放并发和连接
    alt 下游水位越线
        下游-->>配额: 触发收缩
        配额-->>恢复: 先暂停回放
        配额-->>普通: 再降低普通并发
    else 水位稳定
        配额-->>恢复: 逐档增加净消化能力
    end

数据演绎 4：保底份额阻止恢复流量反噬

共享数据库稳定能力为每秒 2,000 次读写，实时主链预留 1,200，普通异步预留 400，恢复最多使用剩余 400。事故后积压恢复请求一度可产生每秒 1,500 次读写，若无隔离总需求为 1,200 + 400 + 1,500 = 3,100，超载 55%；启用预算后总量封顶 2,000。实时降到 900 且观察稳定后，才可把空出的 300 临时借给恢复，恢复上限升至 700。

热门面试题

1. 问题：失败域为什么不能简单等同于微服务？
   • 考点：部署边界与资源影响边界。
   • 回答思路：从共享数据库、线程池和外部配额解释。
   • 详细答案：两个服务可能共享同一数据库连接池或渠道配额，任一重试风暴都会拖垮另一个；同一服务内也可按租户、任务类型和严重等级形成多个独立域。失败域要用限流、暂停和恢复是否能独立执行来判断，而不是看代码仓库或进程数量。
   • 进阶追问：完全物理隔离是否最好？
   • 进阶回答：不是；物理隔离成本高且可能降低资源利用率。先按失败成本选择逻辑配额、独立队列和连接池，只有无法控制的高风险路径再做物理隔离。
2. 问题：恢复任务为什么必须单独限流？
   • 考点：恢复放大与在线保护。
   • 回答思路：说明回放会同时产生读取、写入和副作用压力。
   • 详细答案：恢复通常扫描历史、重复校验、重建投影并触发下游写，单条成本可能高于实时流量。若按积压量无限加速，会使数据库、渠道或对象存储再次过载，形成失败回流。应以稳定净消化率逐档放量并设置停止线。
   • 进阶追问：净消化率怎样计算？
   • 进阶回答：有效完成吞吐减去实时新增和失败重入吞吐；只看拉取数或请求数会把重试空转误算成恢复能力。
3. 问题：多租户报警风暴怎样保证公平？
   • 考点：租户隔离与高危优先。
   • 回答思路：先分租户，再分严重等级，并保留关键旁路。
   • 详细答案：入口按租户发放基础份额和可借用份额，租户内部再按严重等级调度；高危事件进入持久关键通道并独立对账，普通事件可聚合、延迟或暂停通知。这样大租户不能长期占满共享资源，小租户高危事件仍能到达。
   • 进阶追问：关键通道也满了怎么办？
   • 进阶回答：触发更保守的入口控制和人工接管，停止普通回放与低价值通知，同时保留原始高危事实，不能静默丢弃后宣称系统可用。

5. 失败分类、未知态与查询优先

5.1 超时只说明证据不足，重试前必须判断副作用是否可能已发生

失败路径至少分为前置拒绝、确定未执行、执行中失败、结果未知、确定成功但响应丢失和成功后派生失败。只有确定未执行才适合直接重试；结果未知时应复用稳定业务号查单，查询仍不确定则进入受控重试或人工队列。支付扣款、外仓建单、面单申请、对象发布、通知发送和设备控制都可能出现“对方已做、响应没回来”。把超时当失败会产生重复资金或重复实物副作用，把超时当成功又会掩盖真正失败，因此未知态必须是一等状态并有最大年龄、查询预算和升级责任。

sequenceDiagram
    participant 本地 as 本地服务
    participant 外部 as 外部系统
    participant 账本 as 未知态账本
    participant 人工 as 人工工作台
    本地->>外部: 携带稳定业务号执行
    外部--x本地: 响应丢失
    本地->>账本: 记录未知态、尝试号和截止时间
    账本->>外部: 以原业务号查单
    alt 查到成功
        外部-->>账本: 返回唯一结果
        账本-->>本地: 补记成功并停止重试
    else 明确未执行
        外部-->>账本: 返回不存在
        账本-->>本地: 在预算内复用原号重试
    else 长期未知
        账本->>人工: 升级并冻结冲突动作
    end

数据演绎 5：查询优先减少重复副作用

一批 10,000 个外部请求中有 200 个超时。演练查单后发现 120 个已成功、50 个明确未执行、30 个仍未知。若全部直接重试，至少可能重复执行 120 个；查询优先后只对 50 个确定未执行项重试，30 个进入人工或延迟复查，潜在重复暴露从 200 个降为 30 个，下降 85%，同时不把 30 个未知项伪装成失败。

热门面试题

1. 问题：超时为什么既不是成功也不是失败？
   • 考点：本地观测与远端事实。
   • 回答思路：解释请求、执行和响应是三个不同阶段。
   • 详细答案：超时只说明本地在期限内没拿到响应，远端可能没收到、正在执行、已成功但响应丢失。若直接标失败并换号重试，可能制造重复副作用；若直接标成功，又可能漏处理。应保存未知态并按原业务号查证。
   • 进阶追问：查单接口也超时怎么办？
   • 进阶回答：使用独立查询预算退避复查，达到最大年龄后升级人工并冻结冲突动作；不能在证据仍未知时无限执行写请求。
2. 问题：稳定业务号在失败恢复中有什么作用？
   • 考点：跨尝试身份与幂等。
   • 回答思路：区分业务意图和技术尝试号。
   • 详细答案：业务号标识同一个不可重复的意图，所有查询和重试都复用它；尝试号标识每次技术调用，用于记录时间、错误和路由。稳定业务号使外部系统能够返回既有结果，也让本地对账把多次尝试归并为一个副作用。
   • 进阶追问：外部不支持幂等号怎么办？
   • 进阶回答：通过本地串行、查询优先、渠道侧唯一字段和人工阈值降低风险；若资金或物理控制无法形成唯一性保证，该渠道不能承担自动主路径。
3. 问题：未知态积压怎样排查？
   • 考点：年龄、分布和依赖证据。
   • 回答思路：先分渠道与阶段，再看最老年龄和查证结果。
   • 详细答案：按外部渠道、操作类型、错误码、尝试次数和创建时间分桶，观察新增率、收敛率、最老年龄及成功、未执行、仍未知的比例；再核对网络、配额、签名和查单能力。止血时暂停高风险新写，保留查询和人工处理能力。
   • 进阶追问：为什么不能只看未知态总量？
   • 进阶回答：总量可能稳定但最老记录持续老化，也可能少数资金大额项被平均值掩盖；必须同时看年龄、金额或风险等级和收敛分布。

6. 回滚、降级与可逆恢复设计

6.1 回滚代码不等于回滚事实，恢复必须按数据和副作用分别处理

回滚先区分无状态代码、数据库模式、业务数据、外部副作用和派生投影。代码可切回旧版本，但新版本已写入的新状态、资金分录、外仓单、对象文件或控制动作不会自动消失。设计时应保留旧读兼容、单主写开关、状态版本、补偿动作、派生重建输入和人工清单。降级不是“关掉功能”这么简单，而是明确保护顺序：资金与库存裁决保持保守，物流新建可排队，搜索可回源有限查询，导出可暂停，普通报警可延迟聚合，自动控制可转人工。恢复时先查清已发生事实，再选择继续完成、补偿或隔离，不能用数据库回档抹掉外部已发生结果。

sequenceDiagram
    participant 监控 as 监控与门禁
    participant 新版 as 新版本
    participant 开关 as 单主写开关
    participant 旧版 as 旧版本
    participant 修复 as 数据修复控制面
    监控->>新版: 发现不变量或错误率越线
    监控->>开关: 停止新版写入并冻结扩量
    开关-->>旧版: 恢复唯一写主责
    监控->>修复: 生成受影响业务键和版本范围
    修复->>新版: 查询已发生事实与外部凭证
    alt 可继续完成
        修复-->>旧版: 补齐剩余步骤
    else 需要补偿
        修复-->>旧版: 追加反向动作并审计
    else 证据不足
        修复-->>监控: 隔离并转人工
    end

数据演绎 6：回滚窗口由事实扩散速度决定

新版本灰度 10% 流量，每分钟处理 6,000 个请求，其中 2% 产生外部副作用，即每分钟 120 个。监控在 4 分钟发现异常，停止写入和开关传播再用 1 分钟，受影响副作用上界为 120 × 5 = 600 个。若只在 15 分钟后看日报，暴露上界变为 1,800 个。将门禁从日报前移到实时业务差异，可把人工查证集合缩小三分之二。

热门面试题

1. 问题：为什么发布回滚后问题仍可能继续扩大？
   • 考点：在途请求与异步扩散。
   • 回答思路：列出消息、任务、缓存和外部副作用的滞后。
   • 详细答案：旧消息仍在队列，已领取任务仍在执行，缓存和配置传播有延迟，外部请求可能已受理，新数据也可能让旧代码解析失败。因此回滚要同时停新写、撤销租约或令牌、隔离在途、冻结回放，并生成受影响业务键清单持续查证。
   • 进阶追问：怎样缩短实际回滚时间？
   • 进阶回答：预置单主写开关、兼容旧读、独立控制面和业务差异告警，并定期演练从触发到停止副作用的完整时间，而不只演练部署切换。
2. 问题：降级方案怎样避免破坏正确性？
   • 考点：保守裁决与功能优先级。
   • 回答思路：先定义不能降级的不变量，再暂停非核心能力。
   • 详细答案：降级可牺牲时效和体验，但不能猜测资金、库存或控制结果。支付未知转查询和人工，库存证据不足拒绝危险扣减，搜索不可用时只开放有限精确回源，导出和历史回放暂停，普通通知延迟，高风险自动控制转人工。
   • 进阶追问：降级持续太久怎么办？
   • 进阶回答：设置最大持续时间和业务升级机制，展示积压与影响范围；超过能力边界时缩小入口或停止承诺，不能让临时降级变成无人负责的永久模式。
3. 问题：数据库回档为什么不是通用恢复方案？
   • 考点：内外部事实不一致。
   • 回答思路：说明回档会删除本地新事实但不会撤销外部动作。
   • 详细答案：回档可能丢掉已确认支付、仓单、通知和控制记录，而渠道、仓库或设备侧动作仍存在，导致本地认为未发生后再次执行。恢复应从可信点重建，再用事务日志和外部凭证补齐；需要纠正时追加补偿事实，保留原历史。
   • 进阶追问：什么情况下可以回档？
   • 进阶回答：只有明确恢复点、可证明外部副作用边界、能重放后续日志并完成全量对账时才可作为受控步骤，且危险写在验收前保持冻结。

7. 灰度发布、门禁与停止线

7.1 灰度不是按百分比赌博，而是按风险单元验证假设

灰度单元应选择可识别、可隔离、可比较且可回退的租户、仓、渠道、任务类型、规则版本或数据分区，不能只随机抽流量。发布前固定基线、核心不变量、观察窗和停止线；发布中同时比较技术指标与业务集合差异；发布后仍保留延迟故障观察。资金与库存变更优先影子计算和单主裁决，外部履约按低风险渠道切入，导出按小数据集和资源组切入，调度按无危险副作用任务切入，报警先只读影子再开放通知，多模型先建新投影再双读。任何关键差异出现都停止扩量，而不是等总体错误率显著上升。

sequenceDiagram
    participant 基线 as 旧路径基线
    participant 灰度 as 新路径灰度
    participant 对比 as 业务差异门禁
    participant 路由 as 单主路由
    基线->>对比: 提交旧结果、版本和水位
    灰度->>对比: 提交影子结果、资源和错误
    alt 不变量差异或停止线触发
        对比->>路由: 冻结扩量并保持旧主责
        对比-->>灰度: 输出差异业务键供查证
    else 观察窗稳定
        对比->>路由: 增加一个风险单元
        路由-->>灰度: 仅授予该单元主责
    end

数据演绎 7：总体错误率会掩盖关键小样本

灰度处理 200,000 个请求，普通查询错误 100 个，总错误率为 0.05%，看似低于 0.1% 门槛。但其中 5,000 个支付确认出现 2 笔重复入账，关键错误率为 0.04%，且硬约束要求零重复。若只看总体错误率会继续扩量；按风险分层后，支付门禁立即触发，受影响清单只有 5,000 个业务键而不是全部流量。

热门面试题

1. 问题：随机百分比灰度有什么局限？
   • 考点：风险单元与故障隔离。
   • 回答思路：说明随机样本可能跨越共享状态和外部副作用。
   • 详细答案：库存热点、支付渠道、承运商和租户配额都不是独立随机请求；同一业务对象走新旧路径还会产生并发裁决。按仓、渠道、租户或分区切分才能保证责任唯一、差异可归因、回退可执行，并覆盖对应失败窗口。
   • 进阶追问：风险单元太大怎么办？
   • 进阶回答：先做影子计算、只读双读或内部租户验证，再通过业务键哈希切出稳定子集，但同一业务键必须始终路由到同一主路径。
2. 问题：灰度观察窗怎样确定？
   • 考点：延迟故障与业务周期。
   • 回答思路：覆盖最慢副作用、重试、过期和对账周期。
   • 详细答案：观察窗不能只按发布时间设置，要覆盖支付回调与对账、库存预占过期、物流迟到轨迹、导出对象清理、调度租约过期、报警允许迟到和数据增量追平。短窗只能发现即时错误，不能证明延迟不变量。
   • 进阶追问：对账周期太长会拖慢发布吗？
   • 进阶回答：可先用小范围快速对账和历史回放获得早期证据，再保留低比例跨完整周期；不能因为周期长就取消关键验证。
3. 问题：停止线和告警阈值有什么区别？
   • 考点：自动动作与人工研判。
   • 回答思路：停止线对应明确风险动作。
   • 详细答案：告警提示需要调查，停止线一旦满足就自动冻结扩量或切回旧主责。资金重复、库存负数、高危报警差异和旧令牌生效应设硬停止线；时延轻微上升可先告警研判。两者都要有责任人和解除条件。
   • 进阶追问：误触发停止线会不会影响效率？
   • 进阶回答：会，但可通过双信号、最小持续时间和演练校准；对高损失事件宁可保守停止，也不应靠放宽阈值掩盖不可逆风险。

8. 迁移双写、双读与单主裁决

8.1 双写用于传播和验证，不允许两个系统同时独立决定业务结果

迁移通常经历兼容准备、历史快照、增量追平、影子写、双读比较、有限切读、单元切写和旧链退出。所谓双写应有一个主裁决者：主系统提交权威事实后，通过同事务待发布记录或变更日志把变化传播给新系统；若应用层同时调用新旧系统并允许各自成功，会出现半成功、顺序倒置和回滚困难。双读也要区分主结果与影子结果，差异只用于阻断切换和修复，不能在请求中随机挑一个。切写按稳定业务键进行，切换前冻结或排空该键在途，切换后旧系统只读并保留回退窗口。

sequenceDiagram
    participant 客户端 as 客户端
    participant 路由 as 迁移路由
    participant 旧 as 旧权威系统
    participant 日志 as 提交后变化日志
    participant 新 as 新系统
    participant 校验 as 双读校验器
    客户端->>路由: 携带稳定业务键请求
    路由->>旧: 由旧系统唯一裁决并提交
    旧->>日志: 同事务记录待传播事实
    日志->>新: 按业务键和版本幂等写入
    路由->>旧: 读取主结果
    路由->>新: 读取影子结果
    旧-->>校验: 返回权威版本
    新-->>校验: 返回迁移版本
    校验-->>路由: 只报告差异，不改变本次主结果

数据演绎 8：应用双写的半成功风险

演练迁移 1,000,000 次写入，旧系统成功率 99.99%，新系统成功率 99.95%，假设故障独立，至少一边失败概率约为 1 - 0.9999 × 0.9995 = 0.0006，即约 600 次需要裁决；真实故障往往相关，风险更高。改为旧系统同事务记录变化，再异步重试新系统后，主结果只由旧系统裁决，新侧 500 次暂时失败可通过同一版本重放，不再成为用户请求半成功。

热门面试题

1. 问题：为什么应用层顺序调用新旧系统不是可靠双写？
   • 考点：分布式半成功。
   • 回答思路：枚举第一步成功第二步失败和响应丢失。
   • 详细答案：无论先写哪边，都可能第一边提交后第二边失败，调用方又无法原子回滚两个系统；重试还可能改变顺序或重复副作用。应由一个权威系统提交业务事实和待传播事实，再让新系统按稳定键与版本幂等收敛。
   • 进阶追问：分布式事务能否解决？
   • 进阶回答：技术上某些场景可用，但会增加耦合、阻塞和恢复复杂度；迁移更需要可重放与可退出，通常单主提交加异步传播更可控。
2. 问题：双读发现差异时应该返回哪边？
   • 考点：主读责任。
   • 回答思路：在切读前始终返回既定主结果。
   • 详细答案：影子阶段返回旧权威结果，新结果只用于比较；切读后按稳定单元返回新结果，但关键命令仍可回权威源复核。不能按“谁快返回谁”或随机选择，否则相同对象会出现抖动且差异无法归因。
   • 进阶追问：新系统结果更正确怎么办？
   • 进阶回答：先确认旧权威是否存在缺陷，按变更流程修复权威或调整口径，再重放新系统；影子副本不能因一次比较自行夺取裁决权。
3. 问题：切写前为什么要处理在途请求？
   • 考点：同一业务键的并发主责。
   • 回答思路：说明旧请求迟到可能覆盖新版本。
   • 详细答案：路由切换瞬间，旧系统可能仍有排队、重试或长事务；若新系统已接管，同一键会被两个主责并发更新。应冻结该单元、等待在途归零或使用单调代次拒绝旧写，再记录切换水位。
   • 进阶追问：无法排空长任务怎么办？
   • 进阶回答：给新主责更高代次，并要求资源端校验；无法支持代次的任务留在旧单元直至完成，不能强行跨越切换边界。

9. 数据校验、对账与恢复回放

9.1 校验要从计数下钻到不变量，回放要从可信水位走到可解释差异

迁移与恢复校验分四层：文件或分区完整性、记录集合完整性、字段与版本一致性、业务不变量一致性。总数相等不能证明同一批记录，摘要相等也不一定证明权限、状态和删除语义正确。对账应使用稳定业务键、时间范围、版本和口径号，输出只旧有、只新有、字段不同、状态非法和副作用不一致五类差异。回放从一致快照和冻结位点开始，历史与实时使用同一幂等合同但隔离资源；先在影子空间生成结果，分层校验后切换。错误修复采用新批次和新版本，不能覆盖原始输入和旧结果。

sequenceDiagram
    participant 快照 as 一致快照
    participant 增量 as 增量事件流
    participant 回放 as 隔离回放器
    participant 影子 as 影子结果空间
    participant 对账 as 分层对账器
    participant 路由 as 读写路由
    快照->>回放: 提供快照水位和清单
    增量->>回放: 从下一位点持续追平
    回放->>影子: 按业务键和版本幂等重建
    对账->>影子: 校验介质、集合、记录与业务
    alt 差异未清或追不平
        对账-->>回放: 输出差异批次并限制速率
    else 差异可解释且水位稳定
        对账->>路由: 批准一个单元切换
    end

数据演绎 9：总数相等仍可能有成对差异

旧系统和新系统都显示 1,000,000 条记录。按业务键比较后发现旧有新无 240 条、新有旧无 240 条，因此总数仍相等；另有 600 条版本不同、80 条权限范围不同。集合差异率为 (240 + 240) ÷ 1,000,000 = 0.048%，但若其中包含 3 条支付分录或 1 条未传播删除，就不能按低比例放行。对账必须按风险类别而不是仅按总比例裁决。

热门面试题

1. 问题：迁移校验为什么不能只比行数？
   • 考点：集合错位与语义差异。
   • 回答思路：举出一进一出抵消和字段错误。
   • 详细答案：旧侧漏一条、新侧多一条时总数相同，状态、金额、权限和删除标记错误也不会改变行数。应先按稳定键做集合差，再比较版本和关键字段，最后验证库存、资金、终态和权限等业务不变量。
   • 进阶追问：全量逐行比较成本太高怎么办？
   • 进阶回答：按分区和业务键分桶计算摘要，先定位异常桶再下钻明细；高风险对象全量校验，低风险对象可结合分层抽样，但抽样边界要公开。
2. 问题：回放怎样避免重复通知或重复控制？
   • 考点：事实重建与副作用隔离。
   • 回答思路：默认影子回放，不直接连接副作用通道。
   • 详细答案：回放事件保留原业务键、事件标识和版本，在隔离空间重建状态；通知、支付、仓单和控制等副作用默认关闭。确需补发时先对账形成明确差集，再用独立补偿批次、审批和幂等键执行。
   • 进阶追问：历史事件缺少新字段怎么办？
   • 进阶回答：使用版本化转换规则和可解释默认值，无法推导的字段标为未知并限制用途，不能编造值让校验表面通过。
3. 问题：怎样判断恢复回放真的追得上？
   • 考点：净消化率与最老年龄。
   • 回答思路：同时观察有效吞吐、实时新增和失败回流。
   • 详细答案：净消化率必须持续为正，最老未处理年龄下降，失败重入率稳定，且在线主链资源不越线。短时吞吐很高但大量失败回流，或最老年龄不降，都说明没有真正恢复。
   • 进阶追问：追平后能立即切换吗？
   • 进阶回答：还要经过完整观察窗、业务差异验收和回退演练；追平只证明水位接近，不证明语义、权限和延迟故障都正确。

10. 技术债分级与架构演进路线

10.1 技术债要绑定风险、利息和退出触发器，不能只列重构愿望

技术债是为了交付速度或资源限制而接受的未来成本，必须记录债务本金、持续利息、风险暴露、适用边界、偿还触发器和负责人。架构演进不以服务数量为目标，而以风险是否需要独立治理为依据。库存可先在模块化单体中用事务守住不变量，热点和团队边界明确后再拆；支付先补齐流水、幂等和对账，再谈渠道平台化；物流先统一外部适配与状态合同；导出先流式化和隔离；调度先建立任务账本与租约；报警先保存原始事件和规则版本；多模型先明确权威与重建合同。每次演进只迁一个主责，保留回退和证据。

sequenceDiagram
    participant 业务 as 业务增长
    participant 台账 as 技术债台账
    participant 评审 as 演进评审
    participant 迁移 as 可逆迁移
    participant 验收 as 业务验收
    业务->>台账: 触发容量、故障或交付阈值
    台账->>评审: 提交利息、风险和候选动作
    评审->>迁移: 只批准一个主责的分阶段迁移
    迁移->>验收: 提交差异、成本和恢复证据
    alt 收益未覆盖复杂度
        验收-->>迁移: 回退并更新债务边界
    else 风险下降且可运维
        验收-->>台账: 关闭旧债并登记新债
    end

数据演绎 10：用利息判断偿还时机

某渠道硬编码每月造成 6 人日适配、4 人日回归和 2 人日事故处理，共 12 人日利息；平台化一次投入 60 人日，之后每月降为 3 人日，月节省 9 人日，静态回收期约 60 ÷ 9 = 6.67 个月。若业务预计仅运行 4 个月，立即平台化未必合理；若新增渠道使利息升到每月 21 人日，月节省 18 人日，回收期降为 3.33 个月，演进优先级明显上升。

热门面试题

1. 问题：怎样判断一个问题是技术债而不是缺陷？
   • 考点：已接受取舍与违反承诺。
   • 回答思路：看当前行为是否仍满足明确合同。
   • 详细答案：技术债是在当前边界内仍正确，但随着规模和变化产生额外成本；缺陷则已经违反不变量、安全或对外承诺。缺陷应立即止血修复，技术债可按利息、风险和触发器排期，不能用“债务”包装正在发生的资金或库存错误。
   • 进阶追问：没有负责人算技术债台账吗？
   • 进阶回答：不算；缺负责人、触发器和适用期限的条目只是愿望清单，无法在风险变化时进入决策。
2. 问题：微服务化为什么不一定是架构演进？
   • 考点：风险边界与复杂度收益。
   • 回答思路：说明拆服务会新增网络、一致性和运维成本。
   • 详细答案：若团队、数据所有权和失败域没有独立需求，拆服务只会把本地事务变成分布式协调，增加发布和排障面。演进应解决明确的锁竞争、资源隔离、独立扩展或团队责任问题，并用指标证明收益覆盖新复杂度。
   • 进阶追问：模块化单体怎样为未来拆分准备？
   • 进阶回答：明确模块所有权和接口，禁止跨模块直接改表，保留领域事件与契约测试，使将来的网络边界有现成语义。
3. 问题：偿还技术债时怎样控制范围？
   • 考点：单一主责迁移。
   • 回答思路：一次改变一个责任，保持旧链可退。
   • 详细答案：先建立基线和门禁，再通过适配层或事件传播引入新实现，按稳定业务单元双读校验，最后切一个主责。不要同时换数据库、消息、状态机和组织边界，否则差异无法归因，回退也找不到可信点。
   • 进阶追问：旧债关闭后是否就没有债务？
   • 进阶回答：不是；新架构会引入新的运维、兼容和成本债，应在验收时同步登记，避免把复杂度当作消失。

11. WMS（仓储管理系统）、支付、物流、任务、报警与数据串讲

11.1 用“事实、动作、证据、恢复”串联项目，而不是堆技术名词

跨项目串讲可以从订单意图开始：WMS（仓储管理系统）按库存不变量完成预占与仓内责任转移；支付以通道凭证和分录确认资金事实；跨境履约携带稳定业务号向外仓与承运商建单并吸收未知态；大批量导出在独立资源域生成可验证产物；Runner（执行器）用任务账本、租约与单调代次驱动补偿和对账；IoT（物联网）报警把原始事件、规则判断、通知和控制分账；多模型链路把已提交变化投影到搜索、分析和时序模型。共同原则是主链短事务、外部副作用可查证、异步至少一次但业务唯一、派生可重建、恢复有停止线。

sequenceDiagram
    participant 订单 as 订单意图
    participant 库存 as 库存与仓内
    participant 支付 as 支付与账务
    participant 物流 as 外仓与承运商
    participant 任务 as 异步任务与调度
    participant 报警 as 报警与控制
    participant 数据 as 搜索分析时序
    订单->>库存: 以业务键预占并生成流水
    订单->>支付: 以支付号确认并生成分录
    支付-->>库存: 已提交事件驱动履约资格
    库存->>物流: 创建唯一仓单与面单意图
    物流-->>任务: 未知态、补偿和对账任务
    任务-->>数据: 发布已确认状态与恢复水位
    报警-->>任务: 高危事件触发受控处置
    数据-->>订单: 提供查询候选，不反向裁决

数据演绎 11：端到端放大与恢复预算

演练每秒 500 个订单，平均产生 2 次库存写、1 次支付确认、1.2 次物流事件、0.3 个异步任务和 3 个派生写，逻辑动作峰值为 500 × (2 + 1 + 1.2 + 0.3 + 3) = 3,750 次每秒。若故障 20 分钟积压 600,000 个物流事件，恢复有效吞吐每秒 1,000、实时新增每秒 600、失败回流每秒 100，净消化率为 300，理论追平需 2,000 秒，即约 33.3 分钟。

热门面试题

1. 问题：怎样在五分钟内串讲多个项目而不显得散？
   • 考点：统一叙事主线。
   • 回答思路：围绕事实、失败、恢复和取舍递进。
   • 详细答案：先用订单到履约说明库存、支付和物流的业务链，再用导出与调度说明异步资源和恢复控制，用报警说明突发与安全边界，最后用多模型说明查询与分析。每段只讲一个最难失败、一项权威证据和一个取舍，并明确真实经历与候选设计边界。
   • 进阶追问：面试官只追问一个项目怎么办？
   • 进阶回答：立即回到对应纵向章节，展开状态机、数据模型、失败矩阵和数据演绎；其他案例只作为对比，不强行全部讲完。
2. 问题：这些项目共同的架构原则是什么？
   • 考点：跨领域抽象。
   • 回答思路：从唯一权威、稳定身份、可恢复异步和业务对账回答。
   • 详细答案：每个业务结果都有唯一裁决者，命令和事件有稳定身份，外部超时进入未知态，异步允许重复尝试但副作用唯一，派生数据可重建，恢复流量独立限流，技术指标最终要由余额、金额、终态或高危差异等业务证据验收。
   • 进阶追问：哪个原则最容易被忽略？
   • 进阶回答：停止线和退出路径；很多方案能跑通正常流程，却没有定义什么时候必须停、旧链什么时候能退和恢复后如何证明没有留下差异。
3. 问题：怎样避免把候选方案说成真实上线成果？
   • 考点：事实边界与面试诚信。
   • 回答思路：逐句区分直接经历、已有材料映射和演练假设。
   • 详细答案：真实负责范围只讲能提供代码、工单、监控或复盘依据的部分；候选改进使用“我会这样设计”表述；吞吐、比例和收益没有证据就明确是演练。面试价值在判断和推导，不在把架构图包装成生产事实。
   • 进阶追问：被问到真实结果数字怎么办？
   • 进阶回答：给出可核对的真实范围；若手头没有可靠数字，说明缺口并展示计算公式、所需日志和验收方法，不编造精确收益。

12. 事故复盘、成本与 SLO（服务等级目标）权衡

12.1 复盘从受损不变量出发，用单位正确结果连接可靠性与成本

事故复盘要还原时间线、影响集合、受损不变量、触发条件、故障放大器、止血动作、恢复证据和长期改进，避免只找最后改代码的人。技术指标解释系统哪里慢，业务指标裁决用户结果是否受损。SLO（服务等级目标）必须按业务链路分层：支付确认和高危报警要求更严格，搜索新鲜度和普通导出允许降级；错误预算消耗用于控制变更速度，但不能把资金重复等硬约束折算成可消费比例。成本分母采用正确闭环订单、正确入账、正确交付文件或已验收报警，而不是请求或尝试次数，并纳入恢复、对账、人工与退出成本。

sequenceDiagram
    participant 发现 as 业务与技术信号
    participant 指挥 as 事故指挥
    participant 止血 as 止血控制面
    participant 恢复 as 恢复与回放
    participant 对账 as 业务对账
    participant 复盘 as 复盘评审
    发现->>指挥: 报告受损不变量和影响集合
    指挥->>止血: 冻结危险写、回放或自动控制
    止血->>恢复: 交付可信水位与受影响清单
    恢复->>对账: 分批修复并提交差异
    alt 差异未归零或观察窗不稳
        对账-->>恢复: 继续查证，禁止宣告恢复
    else 业务验收通过
        对账->>复盘: 提交完整时间线和证据
        复盘-->>指挥: 更新门禁、目标和技术债
    end

数据演绎 12：可靠性提升必须看单位正确结果成本

方案甲每月基础成本 80,000 元，处理 2,000,000 次尝试，其中 1,990,000 次正确闭环，事故恢复与人工成本 20,000 元，单位正确结果成本为 (80,000 + 20,000) ÷ 1,990,000 ≈ 0.0503 元。方案乙基础成本 92,000 元，正确闭环 1,998,000 次，恢复与人工 4,000 元，单位成本约 96,000 ÷ 1,998,000 ≈ 0.0480 元。乙基础账单更高，却因差错更少而总成本更低。

热门面试题

1. 问题：事故复盘怎样避免停留在“加强监控”？
   • 考点：可验证改进。
   • 回答思路：每项改进绑定失效机制、所有者和验收演练。
   • 详细答案：先说明哪条不变量何时受损、为什么原门禁没阻止，再把改进落成条件更新、单主开关、独立配额、差异对账或自动停止线。每项都有负责人、截止日期、回归用例和故障演练；只有再次注入同类故障能被阻断或快速收敛，才算关闭。
   • 进阶追问：所有根因都要立即修吗？
   • 进阶回答：先修会再次造成重大损失的路径；低概率低影响项可登记技术债，但必须给适用边界和复审触发器。
2. 问题：错误预算能否允许少量重复支付？
   • 考点：SLO（服务等级目标）与硬不变量。
   • 回答思路：区分可用性预算和业务正确性红线。
   • 详细答案：不能。错误预算适合管理请求可用性、时延和变更节奏，不应把重复入账、库存超卖或高危控制误动作变成可消费额度。这些事件应设零容忍停止线，并通过幂等、对账和人工兜底治理。
   • 进阶追问：零容忍是否意味着宣称绝对不会发生？
   • 进阶回答：不是；它表示一旦发现立即停止扩量、进入事故流程并逐笔修复，而不是把发生比例解释为仍在目标内。
3. 问题：成本优化为什么要以正确闭环为分母？
   • 考点：成本转移与虚假降本。
   • 回答思路：把失败、重试、人工和恢复都纳入总成本。
   • 详细答案：按请求次数计算会把重复尝试当产出，也会忽略失败后对账、客服、补偿和声誉损失。以业务验收通过的唯一结果为分母，才能比较缓存、队列、供应商和存储方案是否真正降本，并防止通过少查单、少留证据或延迟修复制造账面节省。
   • 进阶追问：难以货币化的风险怎样处理？
   • 进阶回答：用风险等级、最大影响集合、监管或安全红线单列，不强行折成一个金额；先过硬门槛，再比较可货币化成本。

综合题使用说明

以下题库用于跨案例方案评审、事故应对、迁移演进和项目串讲训练，不属于上一知识小节的三道热门题。

13. 综合题库与项目评审训练

本题库共 45 题。每题口述答案按 3 至 5 分钟训练设计，数字均为可替换的演练输入；作答时先说明事实边界，再按约束、不变量、正常路径、失败路径、恢复、观测和取舍展开。题后链接指向 01—07 的真实纵向章节，用于继续深挖。

综合题 01：如何主持一次可落地的架构方案评审

1. 问题：如何主持一次可落地的架构方案评审？

   口述答案：我不会从架构图开始，而会先确认评审要决定什么，以及谁对业务结果、数据和运行负责。会前要求方案方提交目标与非目标、峰值区间、热点分布、增长周期、数据保留、外部配额、成本上限和真实证据来源；会上先逐项确认库存、资金、终态、权限或物理控制中哪些结果绝不能错，再画出权威源、正常路径和所有外部副作用。随后用失败矩阵追问请求未发出、远端已成功但响应丢失、消息重复、旧执行者恢复、回放压垮在线等场景，要求每种场景都有状态、查证、停止线和责任人。容量部分不仅看正常峰值，还计算突发、重试、积压和恢复放大；可观测部分必须从技术指标落到业务集合差异。结论会分为批准、带条件批准、只读试验和驳回，明确适用租户或渠道、补证期限、灰度单元、观察窗与回退动作。最后由实施、业务、数据和运行负责人共同复述门禁，确保不是主持人单方面理解。评审记录保留被淘汰方案及理由，后续量级或合同变化时可以重新打开，而不是把旧结论当永久真理。比如方案声称每秒支撑 5,000 次写，我会要求同时给出热点键占比、依赖稳定能力和故障恢复时的净消化率；若恢复只有每秒 4,000 次而实时新增为 3,800 次，20 万积压至少需要 1,000 秒，还未计失败回流。最后抽取一个超时、一个重复和一个回滚场景现场走查数据与动作，确保文档中的开关、查询和对账真的存在。评审结束后形成风险台账，下一次扩量必须引用本次证据和未决项，避免换一批人就重新争论同一个假设。

   • 回答思路：按评审目标、输入证据、硬约束、失败矩阵、实施门禁和责任签署六步组织。
   • 详细答案：主持人要把争论转成可验证决策，先确认权威事实与不可错结果，再用容量和故障演练淘汰方案，最后输出带范围、停止线、回退与补证期限的分级结论。
   • 进阶追问：评审会上意见无法统一时由谁拍板？
   • 进阶回答：业务所有者裁决价值与损失，技术和运行负责人对违反安全、不变量及不可恢复风险保留否决权，分歧与依据写入决策记录。
   • 案例事实卡与方案合同
   • 追问 1：会上出现关键量级缺失怎么办？
   • 直接回答 1：把该数字标为待核对，只允许不触碰危险写的影子或离线试验，并把日志采集、压测和补证日期写入结论。
   • 追问 2：谁有权触发停止线？
   • 直接回答 2：运行控制面应能自动触发，值班负责人可人工触发；业务负责人决定后续是否恢复承诺，但不能阻止已经定义的安全止血。
   • 追问 3：评审记录最重要的内容是什么？
   • 直接回答 3：不是会议纪要，而是输入证据、约束、决定、反例、适用范围、停止线、回退路径和每项未决风险的所有者。

综合题 02：业务只说高并发高可用时如何澄清约束

2. 问题：业务只说高并发、高可用时如何澄清约束？

   口述答案：我会把抽象口号翻译成可观察的业务场景。先问用户是谁、一次请求对应什么业务结果、峰值持续多久、热点是否集中、增长来自自然流量还是批量任务，再问失败一秒、十分钟和一天分别造成什么损失。高可用也要拆成读、写、查询、履约、通知和恢复，不同能力不能共享一个比例；支付确认不可猜测，搜索可以短时陈旧，导出可以排队，普通报警可以聚合，但高危报警不能静默。接着收集请求日志、业务键分布、依赖配额、数据库水位和历史事故，拿不到真实值就用区间演练并做敏感性分析。例如每秒 1,000 次请求、热点键占 40% 与均匀分布会导向完全不同的锁和分片方案。然后与业务共同定义硬约束、软目标、降级顺序、恢复时间和最大可接受影响集合，明确哪些场景宁可拒绝也不能错误成功。最终输出不是“支持高并发”，而是某类风险单元在给定峰值、突发倍数和依赖容量下，满足哪些不变量，越过什么水位时如何排队、降级、回退和补偿；未证实输入继续保留为门禁。我还会构造三个时间尺度：五分钟突发检验入口和队列，半小时依赖降速检验背压，一天级故障检验保留、回放和人工能力。假设峰值每秒 1,200 次、服务稳定能力 1,500 次，表面有 25% 余量；若一次请求平均产生两次下游写和 0.4 次重试，真实需求已达到每秒 2,880 次，原结论立即失效。澄清后的验收用业务键集合、最老年龄和错误分层，而不是只看机器负载。业务若无法接受排队，就必须在入口缩小承诺或购买更多依赖能力，不能把矛盾转移给无限队列。

   • 回答思路：把口号拆成业务结果、流量形状、失败时长、依赖上限和降级顺序。
   • 详细答案：澄清不是追问一个峰值，而是同时取得热点比例、事件放大、突发持续时间和恢复净吞吐，再为读、写、通知与恢复分别定义成功和可退让边界。
   • 进阶追问：历史流量无法代表大促怎么办？
   • 进阶回答：用业务计划给出区间和突发模型，压测关键热点与依赖配额，并把实际大促观测作为下一轮容量基线，首轮保留更高安全余量。
   • WMS（仓储管理系统）量级与容量输入
   • 追问 1：业务坚持要一个可用性数字怎么办？
   • 直接回答 1：可以给分链路目标，但同时附统计窗口、成功定义和排除项；不能用一个总比例覆盖资金正确性、查询时延和异步恢复。
   • 追问 2：热点比例为什么比平均吞吐更重要？
   • 直接回答 2：平均吞吐可能很低，但少数库存键、租户或渠道会形成锁竞争和配额耗尽，决定真实瓶颈与隔离方式。
   • 追问 3：需求澄清何时算结束？
   • 直接回答 3：当目标、硬约束、量级区间、失败成本、降级顺序、验收证据和待核对项都有明确所有者时，才可进入候选设计。

综合题 03：怎样把硬约束变成候选方案否决项

3. 问题：怎样把硬约束变成候选方案否决项？

   口述答案：我先把约束写成可以执行的断言，而不是“必须安全”“尽量一致”。例如库存是任一业务键的可售量不得为负且释放只能发生一次，支付是同一支付意图只能形成一组有效入账分录，报警控制是旧执行者和未审批动作不得生效。每条断言都补上权威证据、验证方法、故障注入和违反后的停止动作，再由业务与风险负责人确认是否允许任何比例的例外。候选比较分两阶段：第一阶段只检查硬约束，无法提供唯一键、状态机、资源端栅栏、对账或恢复证据的候选直接淘汰，不能用低成本和高吞吐补分；第二阶段才在合格候选中比较时延、交付速度、运维复杂度和单位正确结果成本。我还会检查约束之间是否冲突，例如既要求外部超时立即成功，又要求绝不重复建单，这实际上不可同时保证，应改为未知态查询和受控等待。评审结果要保留否决原因和重新进入条件，例如供应商补齐查单与幂等能力后可重评。这样否决项不是个人偏好，而是由失败损失、可逆性和证据共同形成的门槛。为了让门槛可测试，我会准备反例集：重复提交同一业务号、成功响应丢失、旧版本迟到写、权限撤销后读取和备份恢复后重放。候选必须给出每个反例的唯一最终状态和审计记录。假设某候选吞吐提高 50%，但十万次故障注入出现一笔重复入账，它仍不合格；另一候选吞吐较低但能排队并守住分录唯一，则可通过容量扩展继续优化。对于无法自动验证的外部合同，还要设人工抽检和供应商退出条件，防止硬约束只存在于协议文字中。

   • 回答思路：先把约束写成断言与反例，再先否决、后评分。
   • 详细答案：库存非负、分录唯一和旧控制代次不得生效都要绑定权威证据及故障用例；候选若无法证明，就不能让性能、成本等软优势抵消致命缺陷。
   • 进阶追问：硬约束是否可以按风险分阶段实现？
   • 进阶回答：可以分阶段建设能力，但未满足前只能运行不触碰该约束的只读或影子范围，不能提前承担对应生产主责。
   • 支付资金不变量与状态机
   • 追问 1：零重复是否能直接作为技术承诺？
   • 直接回答 1：应表达为业务有效副作用唯一，并设计重复尝试下的幂等与对账；不能声称网络和消息永不重复。
   • 追问 2：所有安全要求都是硬约束吗？
   • 直接回答 2：涉及越权、隐私泄露、资金和物理控制的核心要求是硬约束；安全日志保留时长等也可能受法规和合同决定，需逐项确认。
   • 追问 3：候选只差一个硬约束能否先上线再补？
   • 直接回答 3：不能承担该约束对应的生产主责；最多做隔离的只读或影子验证，并设置补齐证据后重新评审。

综合题 04：如何评审一套库存防超卖方案

4. 问题：如何评审一套库存防超卖方案？

   口述答案：我先确认库存对象和等式：实物、可售、预占、分配、拣货、复核与出库分别由谁维护，库存不超卖最终由哪个数据库条件更新和流水证明。随后检查请求幂等键、库存业务键、版本和状态机，重点演绎下单、支付成功、取消、预占过期同时发生时谁有资格迁移状态，不能让定时释放与支付确认都成功。性能层可以使用缓存削峰，但缓存只能提供准入线索，最终余额必须由权威事务裁决；缓存与数据库差异时宁可保守拒绝，也不能以缓存成功宣布库存成立。外仓调用要单独评审未知态：建仓单超时后复用原业务号查单，明确未执行才重试，成功则补本地事实。消息链要求权威事务和待发布记录同事务提交，消费端按业务副作用幂等；对账至少比较订单、预占流水、仓单和实物变化。容量要看热点商品锁等待、波次批量和恢复流量，批量任务与在线预占使用独立预算。灰度按低热点仓和商品切分，停止线包括可售为负、重复仓单、余额等式差异和未知态年龄上升。最后验证回滚不会释放已转为仓内责任的库存。数据演绎可以设某商品实物 1,000、预占 300、分配 200、不可售 50，则可售必须由固定等式复算，而不是由多个服务各存一个数字；并发 100 次每次申请 10 件时，只有满足余额条件的事务可提交。事故排查先按仓与商品冻结调整入口，核对期初、入库、释放、出库和人工调整流水，再恢复缓存。迁移到新库存服务时仍保持旧库单主裁决，新侧影子计算等式，连续跨过预占到期和波次周期无差异后才按商品单元切写。

   • 回答思路：围绕库存等式、竞态裁决、外仓未知态、消息补偿、热点容量和迁移停止线评审。
   • 详细答案：最终防超卖依赖权威条件更新与流水，缓存只削峰；支付、取消和到期任务竞争同一版本，仓单超时先查证，订单、库存、仓单与实物通过对账闭环。
   • 进阶追问：库存等式正确是否就能证明实物正确？
   • 进阶回答：不能，数据库内部可能自洽却共同偏离仓库现实，还要结合收货、拣货、复核、出库凭证和抽盘差异裁决。
   • WMS（仓储管理系统）库存完整方案
   • 追问 1：缓存预扣成功、数据库冻结失败怎么办？
   • 直接回答 1：数据库结果裁决失败，缓存按原业务键补回或由对账修复；订单不能进入已占库存终态。
   • 追问 2：预占过期任务和支付确认谁优先？
   • 直接回答 2：不靠时间先后猜测，而由同一状态版本和条件更新竞争；只有一个迁移成功，失败方读取新状态后停止或转补偿。
   • 追问 3：出现负库存先查什么？
   • 直接回答 3：先冻结危险写并按商品仓位查余额与流水，再定位条件更新、重复释放、批量任务和数据修复是否绕过统一入口。

综合题 05：如何评审支付资金正确性方案

5. 问题：如何评审支付资金正确性方案？

   口述答案：支付评审先把“支付成功”拆成支付意图、渠道受理、渠道确认、交易终态、账务分录和下游履约六个事实，明确哪个是外部凭证、哪个是本地权威。请求层用商户和业务单号防重复发起，渠道层保存渠道请求号与事件号，确认层只允许合法状态迁移，账务层以唯一业务来源生成借贷守恒分录；三层幂等不能合并成一个标志。调用渠道超时必须进入未知态，按原请求号查单，不能换号重付；回调要验签、防重放并允许重复，回调和主动查询同时到达时由状态版本裁决。支付成功事件在本地提交后传播，下游失败不能回滚已经确认的资金，只能重试和对账。退款、撤销、冲正与拒付分别建事实和金额上限，不覆盖原支付记录。容量不仅看发起量，还计算回调、查单、分录、对账和故障恢复放大，并按渠道隔离查询预算。灰度先选小额低风险渠道，实时检查重复入账、无分录成功和金额差异，完整跨过结算对账周期后再扩量。回滚时停新路由并逐笔查证在途，不能简单回档数据库。演练一万笔支付中若 80 笔超时，查单确认 50 笔成功、20 笔未执行、10 笔仍未知，就只允许 20 笔复用原号重试，10 笔进入升级清单；把 80 笔全部重付是不可接受的。日终还要按币种、渠道和结算批次复算金额，定位内部成功渠道无单、渠道成功内部无单和金额不符。恢复完成不是接口成功率回升，而是大额未知全部查清、分录差异归零、下游履约按同一支付号收敛，并在观察窗内没有重复入账反弹。

   • 回答思路：依次检查支付意图、渠道凭证、状态机、账务分录、未知态和结算对账。
   • 详细答案：支付、交易和账务各有状态与权威，三层幂等共同守住唯一结果；渠道超时按原号查单，已确认资金不因下游失败回滚，差异由凭证与分录修复。
   • 进阶追问：渠道成功但内部订单已取消如何处理？
   • 进阶回答：先补记真实支付与唯一分录，再按业务规则发起独立退款或恢复订单，不能删除渠道成功事实来迎合订单状态。
   • 支付资金正确性完整方案
   • 追问 1：收到成功回调但账务写失败怎么办？
   • 直接回答 1：保留渠道成功凭证和待入账事实，冻结重复支付，通过同一业务来源重试生成唯一分录，直到对账闭环。
   • 追问 2：为何支付状态和账务状态要分开？
   • 直接回答 2：渠道确认与本地分录可能在不同时间完成，两个状态各有权威和恢复动作；一列状态会覆盖中间证据并让补偿含糊。
   • 追问 3：支付降级能否直接返回处理中？
   • 直接回答 3：可以在证据未知时返回处理中并保留查询入口，但必须记录稳定支付号、最大处理时限和人工升级，不能后台无期限悬挂。

综合题 06：如何定义跨境履约的可验证成功

6. 问题：如何定义跨境履约的可验证成功？

   口述答案：跨境履约不能用“接口返回成功”作为终点，我会把成功拆为本地履约意图已提交、外仓唯一单号已确认、面单版本与文件摘要有效、承运商轨迹订阅建立、状态机合法前进以及异常可恢复。订单、履约单、外部仓单、面单和原始轨迹分别保存稳定身份，不把多个对象压成一列状态。调用外仓时使用业务幂等号，超时进入未知态并查单；面单拉取要校验文件大小、摘要和版本，避免拿到空文件也宣称成功。轨迹回调与轮询统一进入原始事件账，按承运商事件号或降级键去重，保留事件时间、接收时间和原文，再由标准化映射与单调版本更新查询状态。签收等终态不能被迟到的在途事件倒退，错误签收则通过订正事件表达。对账比较本地意图、外部单号、面单、轨迹和最终签收集合，不能只比订单数。容量评估包含外仓配额、轨迹放大、迟到重放和毒事件隔离，恢复流量与实时调用分开。灰度优先选择支持查单和幂等的渠道，停止线是重复外仓单、终态倒退、面单摘要异常和最老未知态持续上升。假设每秒 300 个新包裹，每个平均产生 12 条轨迹，则轨迹入口已是每秒 3,600 条；承运商补推三小时历史会再形成数量级放大，必须与实时分配独立预算。事故中先暂停高风险建单重试，保留查单和原始回调接入，把未知态按渠道与年龄排序。恢复时先确认外部单号唯一，再回放标准化投影，最后开放通知和查询。验收需要随机穿透一个正常包裹、一个重复回调、一个迟到订正和一个建单超时，证明每个对象都能从本地意图追到外部证据。

   • 回答思路：把成功拆为意图、外部单、面单、轨迹、终态和可恢复六类证据。
   • 详细答案：外部接口返回只是一条线索，必须保存稳定业务号、外部号、文件版本摘要和原始轨迹；未知先查单，乱序由版本与终态保护裁决，订正追加新事实。
   • 进阶追问：外部系统修改了原单字段但不升版本怎么办？
   • 进阶回答：保存每次查单原文与摘要，发现同一外部号内容变化就生成本地观察版本并进入差异审查，不能静默覆盖审计证据。
   • 跨境履约完整方案
   • 追问 1：承运商没有稳定事件号怎么办？
   • 直接回答 1：用运单、状态、事件时间、地点和载荷摘要构造降级键，同时保留碰撞记录；关键终态仍需结合原文和查单裁决。
   • 追问 2：回调和轮询结果冲突信谁？
   • 直接回答 2：两者都先入原始事件账，再按来源版本、事件时间、终态保护和订正规则裁决，不能按到达先后覆盖。
   • 追问 3：面单为什么需要版本？
   • 直接回答 3：地址、服务或承运商变化可能重新出单；版本和摘要能防止旧文件迟到覆盖新文件，也支持审计实际交付哪一版。

综合题 07：如何证明异步导出不是把风险延后

7. 问题：如何证明异步导出不是把风险延后？

   口述答案：我会从资源边界和结果可验证两方面证明。请求进入时先鉴权并冻结查询条件、租户范围和数据水位，同一用户与条件使用幂等键避免重复创建；任务状态只保存控制进度，真正完成要由稳定分片全部成功、行集校验通过、对象摘要确定且发布动作唯一共同证明。读取使用全序游标和固定水位，重试从检查点继续，不能用容易漂移的分页偏移；生成采用小批量读取和流式写，让内存峰值取决于批大小与并发而非总行数。导出执行器、队列、数据库连接和对象上传都与在线交易分域，在线水位越线时先暂停大任务与恢复回放。部分文件写入临时命名空间，完成校验后原子发布，不向用户暴露半成品；下载时按当前权限签发短期凭证，任务完成不等于永久下载授权。取消与完成通过条件状态竞争，失败方停止发布并留下清理清单。容量同时计算到达率、服务率、最坏工作集、对象保留和故障恢复，观测最老任务年龄、单批内存、连接占用、分片重试与孤儿对象。只有故障注入后在线主链稳定、任务可续跑、产物可复算，才证明异步化真正隔离了风险。具体演练可令每批 2,000 行、单行展开后平均 2 千字节、并发 8，则核心工作集约 32 兆字节，再加缓冲和编码余量仍应受控；若一次性加载 500 万行，异步只会把内存溢出移到后台。故障时暂停新大任务和失败回放，保留状态查询与已完成下载，按任务水位清理临时对象。恢复先从稳定检查点续跑少量分片，确认数据库连接、内存和对象错误稳定后逐档增加并发，并核对最终行集与创建时权限范围一致。

   • 回答思路：从冻结意图、稳定读取、流式工作集、资源隔离、唯一发布和权限交付证明。
   • 详细答案：异步只是调度方式，真正隔离依赖固定水位与游标、单批有界内存、独立执行预算、分片清单与对象摘要；完成和取消由条件状态选唯一胜者。
   • 进阶追问：导出源表在任务期间发生删除怎么办？
   • 进阶回答：按创建时固定快照或水位读取，删除后的权限在下载时重新判断；若合规要求立即不可导出，还要让撤销事件终止任务并清理产物。
   • 异步导出完整方案
   • 追问 1：进度达到 100% 为什么还不能发布？
   • 直接回答 1：进度可能只代表分片尝试结束，还需验证行数、分片集合、对象摘要和唯一发布状态，防止部分失败被百分比掩盖。
   • 追问 2：任务重试会不会重复行？
   • 直接回答 2：固定快照水位、稳定分片范围和全序游标，分片产物按身份幂等覆盖或去重，合并前再次校验边界。
   • 追问 3：对象已经生成但任务取消怎么办？
   • 直接回答 3：取消胜出后对象保持不可见并进入清理清单；若完成发布先胜出，则取消返回已完成或执行显式撤销，不能两边都声称成功。

综合题 08：如何识别缓存、消息和搜索造成的伪成功

8. 问题：如何识别缓存、消息和搜索造成的伪成功？

   口述答案：我会先要求每个组件说明它能证明什么、不能证明什么。缓存命中或预扣成功只能证明某个短期视图接受了操作，不能证明库存权威事务提交；消息发送或消费成功只能证明传播与处理尝试，不能证明外部副作用唯一完成；搜索索引出现文档只能证明派生投影可见，不能裁决支付、库存或权限。识别伪成功要为业务结果建立稳定键、权威状态、不可变流水和外部凭证，并把接口返回、消息位点、缓存版本和索引版本都关联到该业务键。线上监控不只统计组件成功率，还对账“缓存预扣成功但数据库无流水”“消费确认但无业务结果”“索引版本领先或落后权威”“已删除对象仍可搜索”等差集。故障演练主动注入数据库提交失败、消息确认丢失、索引写超时和缓存回滚失败，观察系统是否返回保守结果并能自动收敛。修复时始终由权威事实重建缓存和派生投影，不让多数副本投票。对用户暴露的状态也要区分已受理、处理中、已确认和可查询，避免一个绿色提示掩盖链路中间态。这样组件指标服务于定位，业务证据负责宣布成功。量化时把十万次组件成功与权威结果做集合差：若消息成功 99,950 次，但只有 99,920 个唯一业务结果，至少 30 次属于待查伪成功；若索引有 100,000 条而权威只有 99,990 个可见对象，还要检查删除与权限泄漏，而不能因数量接近放行。止血顺序是冻结危险命令、保留权威写和对账、暂停派生回放，再按版本修复缓存和索引。验收不仅要求差异归零，还要证明重新投递同一事件不会再次产生副作用，旧版本也不能覆盖新事实。

   • 回答思路：先声明组件证据边界，再用业务键把组件信号与权威结果做集合对账。
   • 详细答案：缓存成功、消息确认和索引可见都不等于业务成功；只有权威状态、流水及外部凭证能裁决，组件差异要从权威版本重建，而非多数投票。
   • 进阶追问：组件成功率是否完全没有价值？
   • 进阶回答：有定位和容量价值，可帮助判断故障在哪一段，但必须与业务成功率、差异集合和最老年龄联合使用，不能单独宣布恢复。
   • 多模型权威与派生合同
   • 追问 1：缓存比数据库更新时是否可以信缓存？
   • 直接回答 1：先检查缓存版本来源；若数据库事务未提交，缓存更新必须撤销或过期，不能以时间更新为由晋升权威。
   • 追问 2：消息已经确认但业务表没有记录怎么办？
   • 直接回答 2：按事件号和业务键查消费流水、事务日志与死信，重新驱动幂等处理；同时修正确认时机，避免先确认后提交。
   • 追问 3：搜索结果用于运营操作时如何降低风险？
   • 直接回答 3：搜索只提供候选集合，执行库存调整、退款或控制前回权威服务复核当前版本、权限和幂等条件。

综合题 09：如何为业务成功设计可重复的对账

9. 问题：如何为业务成功设计可重复的对账？

   口述答案：对账设计先固定对象、时间范围、业务键、口径版本和权威优先级，确保同一批次重复运行得到相同分类。库存对账从期初、入库、预占、释放、出库和调整复算期末，并与订单、仓单和实物抽盘关联；支付对账比较内部支付单、渠道凭证、账务分录与结算文件；物流比较履约意图、外部仓单、面单和轨迹终态；导出比较冻结条件对应的行集、分片清单与对象摘要；报警比较高危事件、报警实例、通知回执和控制动作。执行时先保留原始输入快照和摘要，再产出只左有、只右有、金额或数量不同、状态非法、版本落后和证据未知等差异，不直接自动抹平。每类差异绑定查证顺序、风险等级和补偿动作，补偿生成新流水与批次，原差异记录保持不可变。对账还要覆盖删除、权限和迟到修订，不能只比数量。恢复完成的标准是高风险差异清零、其余差异有明确归属、最老差异年龄下降且下一轮没有反弹。为防止对账自身出错，应使用独立实现复算关键公式，保留口径变更记录，并用小样本人工穿透验证。一次百万级对账可先按业务键分成 1,024 个桶计算数量和摘要，发现 6 个异常桶后再下钻，降低全量明细比较成本；但金额、库存负数、高危漏报和删除传播仍需全量规则校验。差异修复按风险排序：先冻结可能继续扩大的重复动作，再查外部凭证，随后补记权威事实，最后重建派生。每个补偿批次记录输入、审批、前后摘要和可撤销动作，下一轮对账要能识别它是合法订正而不是新异常。这样对账既是发现机制，也是恢复验收合同。

   • 回答思路：固定范围与口径，保留输入，分类差异，按风险查证，追加补偿，再复算验收。
   • 详细答案：对账要同时比较集合、字段、状态与业务守恒，产出只左有、只右有、版本不同和证据未知等类别；补偿有新批次与幂等键，不能覆盖原差异。
   • 进阶追问：对账口径升级后旧差异如何处理？
   • 进阶回答：保留旧口径批次和结论，以新口径另起批次重算并说明生效范围，不能用当前规则改写历史审计结果。
   • 支付对账与灾难恢复
   • 追问 1：对账发现差异后能否直接以渠道为准？
   • 直接回答 1：不能一概而论；资金结果通常要结合渠道凭证，但本地重复、伪造或结算差异仍需按合同和分录规则裁决。
   • 追问 2：对账任务本身重复执行怎么办？
   • 直接回答 2：批次有稳定范围和口径号，差异项按批次与业务键唯一；重复运行返回或更新同一调查对象，补偿动作另有幂等键。
   • 追问 3：差异率很低能否忽略？
   • 直接回答 3：先按失败成本分层；一笔重复资金或高危漏报也可能触发硬停止线，普通低风险差异才可按明确阈值和期限处理。

综合题 10：如何为共享系统划分失败域

10. 问题：如何为共享系统划分失败域？

口述答案：我不会按服务名称机械切分，而会先列出哪些流量会共同耗尽数据库连接、线程、内存、队列、外部渠道配额和人工处理能力，再按失败成本与恢复动作划域。库存可按仓、热点商品和批量波次分域，支付按渠道与资金键分域，导出和调度按任务类型与租户分域，报警同时按租户和严重等级分域，数据重建按模型与分区分域。每个域配置独立队列、并发上限、超时、重试预算、最老年龄和暂停开关，共享下游则给实时核心链保底，普通任务可借用空闲但必须能被收回。假设数据库稳定能力每秒 2,400 次，实时库存与支付保留 1,500，普通异步 500，恢复回放最多 400；事故后回放需求即使达到每秒 2,000 次也只能逐档使用 400，不能把总需求推到 4,000。故障注入要验证一个大租户、慢渠道或大导出失控时，其他域的业务成功率和最老年龄仍在门槛内。止血顺序优先暂停回放和低价值任务，再收缩普通并发，最后才限制核心入口。恢复时观察有效完成吞吐和失败回流，空闲配额只临时借出。若两个所谓独立域仍共享无法限额的关键资源，就继续下钻或做物理隔离，而不是在图上画两个框宣称隔离完成。 上线后每月复算各域峰值、借用时间和拒绝量，若普通域长期借满核心余量，说明容量基线已失效；若某域总是由人工兜底，说明运行能力也是共享瓶颈。迁移隔离资源时先做影子配额统计，再切队列和连接池，避免一次拆分改变消息顺序与业务主责。最终验收需同时证明故障被限制在域内、核心保底未被挤占、暂停后积压可追平且额外成本在预算内。

• 回答思路：先找共享耗尽点，再按失败成本、隔离键、预算、暂停和恢复动作划域。
• 详细答案：失败域以能否独立限流和恢复为准，分别配置队列、连接、并发与重试预算；实时核心有保底，普通与回放只借用可被及时收回的空闲份额。
• 进阶追问：两个域共享同一数据库是否一定不合格？
• 进阶回答：不一定，只要连接、查询、锁和恢复流量可被可靠配额并通过干扰演练；无法限制时才需要进一步拆库或物理隔离。
• 异步导出故障域设计
• 追问 1：逻辑配额与物理隔离怎样选择？
• 直接回答 1：先按损失和干扰强度使用独立队列、连接池与并发额度；无法可靠限制或涉及高风险安全边界时再拆集群或账户。
• 追问 2：空闲配额长期借给恢复有何风险？
• 直接回答 2：实时流量回升时无法及时收回会造成二次过载，因此借用要有租期、优先级和快速收缩开关。
• 追问 3：怎样证明域间没有相互拖累？
• 直接回答 3：对单域注入超时、重试与大任务，观察其他域的连接等待、时延、业务差异和最老年龄，并验证暂停动作不跨域扩散。

综合题 11：Runner（执行器）失去租约后为何仍可能产生副作用

11. 问题：Runner（执行器）失去租约后为何仍可能产生副作用？

口述答案：租约只说明某个执行者在一段时间内拥有尝试资格，不能中止已经发出的数据库写、外部请求或本地长计算。旧 Runner（执行器）可能发生长暂停、网络分区或心跳线程受阻，控制面判定租约过期后把任务交给新执行者；旧进程恢复时仍可能携带旧上下文继续提交，于是两个执行者都认为自己完成。我的设计会把任务定义、触发实例、执行尝试和业务结果分账，每次接管生成单调增加的代次，新旧执行都携带稳定业务幂等键和代次。任务库用条件更新拒绝旧代次推进检查点，真正危险的业务资源端也要保存已接受的最高代次，拒绝旧执行者迟到写；只在调度表校验不够，因为外部副作用可能绕过调度表。新执行者接管后先按业务键查证，已成功就补记任务终态，明确未执行才重试，仍未知则转人工。演练令旧代次 41 在暂停后恢复，新代次 42 已完成，资源端必须拒绝 41，最终只有一个有效业务结果。观测同时看租约过期、接管次数、旧代次拒绝、未知任务年龄和重复业务结果。恢复时先暂停产生危险副作用的任务类型，保留只读查证，再逐类放开。这个方案接受重复唤醒和重复尝试，但不接受重复有效副作用。 容量上还要区分调度吞吐和业务吞吐：每秒领取 500 个任务不代表完成 500 个结果，若 100 个因下游超时重入，净完成只有 400。发布时先灰度可查证的只读任务，故意让旧进程失去租约并恢复，确认任务库和业务资源都拒绝旧代次。事故复盘若只归因心跳超时仍不完整，还要检查租约长度、检查点粒度、外部幂等能力和接管策略是否共同放大了影响。

• 回答思路：区分租约资格、执行尝试和业务生效，以资源端单调代次封住迟到写。
• 详细答案：旧执行者失租后线程与外部请求不会自动停止，新执行者接管前要查证；任务库和业务资源共同拒绝旧代次，才能接受重复尝试而保持副作用唯一。
• 进阶追问：代次溢出或重置会怎样？
• 进阶回答：代次必须在任务或资源生命周期内严格单调且不可复用，迁移和恢复也保留最高值；容量设计使用足够宽整数并监控异常回退。
• Runner（执行器）租约与栅栏完整方案
• 追问 1：心跳正常能否证明任务还在推进？
• 直接回答 1：不能；心跳可能独立存活而业务线程卡住，还要观察检查点、业务结果和阶段最大年龄。
• 追问 2：资源端无法保存代次怎么办？
• 直接回答 2：至少用稳定业务键幂等、单执行串行和查证降低风险；无法约束的高风险副作用不应允许自动接管并发执行。
• 追问 3：任务完成后旧执行者还能更新日志吗？
• 直接回答 3：可以追加被拒绝的尝试审计，但不能改变任务终态、检查点或业务结果；审计记录要带旧代次和拒绝原因。

综合题 12：如何治理 IoT（物联网）报警风暴而不漏高危

12. 问题：如何治理 IoT（物联网）报警风暴而不漏高危？

口述答案：我会把原始事件、报警判断、通知尝试和控制动作拆成四本账，先保证可追溯，再做降噪。入口校验租户、设备、测点和协议，稳定事件号用于去重；设备自报等级只作线索，平台按固定规则版本重新判定。高危事件进入持久关键通道并独立对账，普通事件进入按租户公平调度的主通道，可以窗口聚合、抑制通知或延迟处理，但原始数量和降级决策必须保留。窗口按事件时间归属，水位和允许迟到处理乱序，聚合结果保存来源摘要、首末时间、设备数和修订代次；抑制不能删除报警，拓扑根因低置信时只能改变排序，不能静默高危。通知超时按外部请求号查证，自动控制仅开放白名单可逆动作并要求审批、冷却期和资源端单调代次。假设平时每秒 2,000 个事件，故障突发到 20,000，高危占 1%；系统至少为每秒 200 个高危和其查证链保底，普通流量按租户份额聚合。停止线包括高危事件与报警集合不一致、通知未知态持续上升、派生报警循环和旧控制代次被接受。恢复先冻结自动控制与历史回放，确保高危账闭环，再按净消化率恢复普通积压，最后复算异常规则版本产生的漏报和误报。 规则发布采用只读影子、展示、通知、受控动作四级推进，每一级都跨过迟到窗口并比较高危集合。成本不能只看通知条数下降，还要计入原始事件保留、窗口状态、查证、回放和人工改判，以正确闭环报警为分母。若压缩率很高但首次高危发现变慢或来源无法下钻，仍判定方案失败。

• 回答思路：按事件、报警、通知、控制四账展开，再讲高危旁路、窗口语义、公平背压与恢复。
• 详细答案：高危事实持久保底，普通流量可聚合延迟；规则版本、事件时间和修订代次保证可解释，通知未知先查证，控制由白名单和单调代次守护。
• 进阶追问：关键通道长期高负载是否应继续保底？
• 进阶回答：应先核对等级误判与设备异常，收缩普通和自动控制，同时扩充经验证的关键能力；不能通过降低高危等级来让指标变绿。
• IoT（物联网）报警风暴完整方案
• 追问 1：高危通道也出现积压怎么办？
• 直接回答 1：停止普通回放和低价值通知，进一步限制入口与自动控制，保留高危原始事实并启动人工接管，不能静默采样。
• 追问 2：抑制和去重有什么区别？
• 直接回答 2：去重判断是否同一事件贡献，抑制只暂停某个报警的通知或控制；被抑制报警仍要入账、可下钻和可解除。
• 追问 3：规则回滚后历史报警要删除吗？
• 直接回答 3：不能删除；停止异常版本的新判断，在隔离环境用稳定版本回放形成差异和修订，再决定补通知或订正。

综合题 13：外部建单超时后如何收敛未知态

13. 问题：外部建单超时后如何收敛未知态？

口述答案：请求发出前先在本地提交履约意图和稳定业务号，每次技术调用另有尝试号，保证多次重试仍指向同一外部业务对象。超时发生时不把状态改成失败，也不生成新业务号，而是记录请求摘要、渠道、发送时间、超时阶段和下一次查证时间进入未知态。查询任务使用独立配额按原业务号查单：查到外部单则校验关键字段和状态，补记本地外部单号并停止写重试；明确不存在才在重试预算内复用原号提交；渠道仍无法确定则按金额、仓单风险和年龄升级人工，同时冻结取消、释放或再次建单等冲突动作。假设 5,000 次建单有 100 次超时，第一次查单确认 65 次成功、25 次不存在、10 次仍未知，只重试 25 次；若全量重试，至少 65 次暴露在重复建单风险下。最老未知年龄、查证成功分布、重复外部号和人工积压是核心指标。渠道查单故障时，写入入口要按风险收缩，不能让未知集合无限增长。恢复后还要对账本地意图、外部单号、面单和取消状态，确认没有一单多号或本地已释放而外部继续履约。整个过程的目标不是让状态尽快变绿，而是用外部凭证把未知逐笔变成确定成功、确定未执行或明确人工责任。 为防止查询任务自身造成风暴，按渠道设置查证并发、退避间隔和最大年龄，实时新建与历史查证使用不同额度。灰度新适配器时专门注入“外部成功、响应丢失”，要求旧、新两条路径对同一业务号只得到一个外部单。复盘还要核对渠道是否真正承诺幂等，若合同与实测不符，应降低自动化等级或准备退出方案。

• 回答思路：用稳定业务号保存未知，再按查到成功、明确未执行、长期未知三路收敛。
• 详细答案：超时不改成失败，查单成功则补本地事实并停重试，不存在才复用原号重试，长期未知冻结冲突动作并升级人工；实时与查证配额分离。
• 进阶追问：渠道只支持按时间范围查单怎么办？
• 进阶回答：用业务号、金额、收件信息摘要和发送时间缩小候选，多个候选无法唯一裁决就进入人工，不允许自动挑一条绑定。
• 跨境履约失败矩阵
• 追问 1：外部查单返回多条记录怎么办？
• 直接回答 1：立即隔离并按业务号、请求摘要和时间线人工裁决，停止自动取消或重建，避免把重复外部单继续扩散到仓内。
• 追问 2：未知态多久后可以判失败？
• 直接回答 2：由渠道合同、查证能力和业务风险决定；超过最大年龄只能升级责任，不能在没有证据时把可能成功改成确定失败。
• 追问 3：取消请求也超时怎么办？
• 直接回答 3：取消拥有独立业务号和未知态，持续查证原单与取消结果；库存释放必须等待责任边界确定，不能提前假设取消成功。

综合题 14：支付结果未知时如何止血和恢复

14. 问题：支付结果未知时如何止血和恢复？

口述答案：我先区分单笔未知与渠道级未知风暴。单笔场景保存支付意图、渠道请求号、金额、币种、签名摘要和所有尝试，向用户返回处理中而不是成功或失败；查询任务复用渠道请求号查证，成功则幂等确认交易并生成唯一分录，明确失败才允许按原意图重新支付，长期未知升级人工。渠道级故障时立即停止自动重试和新流量扩张，保留查单、回调接收、账务补记与对账能力，必要时把新支付路由到经过评审的备用渠道，但同一支付意图不能同时在两个渠道活跃。假设一分钟新增 2,000 笔支付，渠道超时率从 0.1% 升到 20%，每分钟会新增 400 个未知；若每笔自动重试两次，写压力膨胀到 2,800 次且重复风险上升。止血后将新入口降到每分钟 800，查单稳定收敛每分钟 600，未知净变化为 200，仍在增长，必须继续限流或增加查询能力。恢复按大额、老龄和已收到回调优先，逐笔形成渠道凭证与分录。只有未知最老年龄下降、重复入账为零、渠道与内部金额差异清零并跨过结算观察窗，才恢复正常路由。代码回滚不能替代在途查证，因为渠道侧资金事实不会随版本回退。 恢复过程中每个操作都写入独立批次，人工补记也必须经过双人审批和金额上限校验，避免止血动作制造第二次资金差错。系统重新开放前，用一组已成功、明确失败、长期未知、重复回调和退款并发样本做穿透验证。对外状态更新与资金修复分开，先保证事实正确，再恢复通知和营销权益等非核心副作用。

• 回答思路：先阻断自动重试扩散，再保留回调查单，按金额与年龄逐笔形成资金证据。
• 详细答案：单笔返回处理中并保留原渠道号，渠道级风暴则收缩新入口与切换风险；只有成功凭证、明确失败或人工责任能关闭未知，恢复必须跨结算观察窗。
• 进阶追问：未知支付占用库存多久合适？
• 进阶回答：由商品稀缺、渠道最大确认时间和客户承诺共同决定；到期仍未知时进入保守释放加资金后置补偿流程，并保留竞态审计。
• 支付第三方未知态与降级
• 追问 1：备用渠道切换时如何防止双扣？
• 直接回答 1：原渠道意图必须有确定失败或可撤销证据，或业务明确接受人工裁决；同一支付意图保持唯一活跃渠道和全局幂等约束。
• 追问 2：回调在查单之后迟到怎么办？
• 直接回答 2：回调按渠道事件号和支付状态版本幂等处理，若与既有成功一致只补审计，冲突则进入差错调查而不覆盖终态。
• 追问 3：未知态是否计入可用性失败？
• 直接回答 3：应按对用户承诺计入处理中或未完成，并单列年龄；不能把接受请求就算成功，否则会掩盖资金长期悬挂。

综合题 15：发布回滚后如何处理已经扩散的业务事实

15. 问题：发布回滚后如何处理已经扩散的业务事实？

口述答案：回滚开始先冻结新版本写主责和继续扩量，记录开关生效水位，再分别盘点数据库新状态、已发布事件、正在执行任务、缓存与索引版本以及外部支付、仓单、通知或控制动作。无状态代码可以切回旧版，但旧版必须能读取新字段和新枚举；不兼容时先保持新读能力或启用兼容层，不能强行启动后破坏数据。对已经发生的业务事实按业务键建立受影响清单：外部成功但本地未记的要补记，主事实成功而派生失败的要重放，错误副作用需要通过退款、取消、订正等新动作补偿，证据不足的进入隔离和人工。假设新版本每分钟处理 4,000 次，其中 3% 触发外部动作，异常发现 3 分钟、开关传播 1 分钟，影响上界是 480 个外部动作；这 480 个必须逐笔查证，不能用数据库回档抹掉。消息消费者和 Runner（执行器）还要撤销新版本资格或提高代次，防止回滚后旧任务继续写。恢复旧主责后先小流量验证业务差异，随后按风险处理受影响集合，直到资金、库存、终态和权限差异归零。最后复盘监控发现时间、开关传播时间和事实扩散率，优化的是停止副作用的实际时间，而不仅是部署工具显示的回滚秒数。 数据库模式采用先扩展后收缩，至少在回退窗口内允许旧代码读取新数据；事件合同也要保留旧消费者可解析字段。若新版本改变了金额单位、状态含义或权限语义，即使结构兼容仍需单独订正。最终把受影响集合、修复批次和未能自动处理项交给业务签字，避免技术恢复后遗留无人负责的客户问题。

• 回答思路：先停新事实扩散，按数据、事件、任务和外部动作盘点，再分别继续、补偿或隔离。
• 详细答案：代码切旧只解决未来执行，已写状态和外部副作用必须按业务键查证；兼容读、单主开关、代次撤销与差异清单共同构成实际回滚。
• 进阶追问：回滚期间新旧消费者如何协调？
• 进阶回答：按事件合同版本和主责水位冻结新消费者，旧消费者只处理其兼容范围；无法解析的事件隔离，不能由两组消费者同时产生副作用。
• 多模型故障恢复与切换
• 追问 1：已经发布的消息要删除吗？
• 直接回答 1：通常不删除不可变事实；消费者按版本和动作语义处理，错误事实通过订正事件表达，未提交或纯唤醒消息可按清单隔离。
• 追问 2：旧版本无法读取新字段怎么办？
• 直接回答 2：保持前向兼容读、部署兼容适配或暂停切换；这正是数据库模式必须先扩展后收缩的原因。
• 追问 3：何时可以解除事故状态？
• 直接回答 3：旧主责稳定只是第一步，还需受影响业务键查证完成、关键差异归零、在途清空并跨过延迟副作用观察窗。

综合题 16：如何设计不破坏资金与库存的降级

16. 问题：如何设计不破坏资金与库存的降级？

口述答案：降级先按业务损失排序，而不是按组件是否方便关闭。资金和库存裁决必须保持保守：渠道结果未知就返回处理中并查证，库存权威不可用就拒绝新的危险扣减或限制为只读查询，绝不能用缓存或旧副本猜成功。可以牺牲的是搜索新鲜度、报表刷新、大导出、历史回放、普通通知和低优先任务；跨境建单可进入有界队列，高危报警保留关键通道，自动控制转人工。每个降级项写明触发阈值、用户可见状态、积压上限、最大持续时间、恢复顺序和补偿责任。演练数据库能力从每秒 2,000 降到 1,200，核心支付与库存需要 900，普通查询 500，导出与回放 600；总需求 2,000 超过能力，应先停 600 的导出回放，再把普通查询压到 300，核心仍保留 900，正好落在 1,200 内。若核心需求继续增长，则入口限流和排队，不能借用正确性预算。降级期间持续记录被拒绝、排队和延迟对象，用户界面区分未受理、处理中和已确认。恢复按权威写、查证对账、实时派生、普通异步、历史回放的顺序逐档开放，每档观察资源和业务差异。最大持续时间到达仍未恢复时升级业务决策，避免临时模式变成没有证据保留的长期架构。 降级演练要在发布前执行，验证入口确实能拒绝或排队、用户能看到真实状态、积压不会超过保留期、恢复脚本不会重复副作用。成本评估同时计算被拒业务损失和保住核心链的收益，不以“机器没挂”作为成功。若某项非核心能力每次事故都无法安全暂停，应补齐独立资源和持久任务账，而不是继续依赖人工杀进程。

• 回答思路：先锁定不可降级的资金库存裁决，再按价值暂停查询、导出、回放和普通通知。
• 详细答案：降级可以牺牲时效与体验，不能猜测权威结果；每项能力都有触发阈值、积压上限、用户状态、最大时长和阶梯恢复，核心容量始终保底。
• 进阶追问：降级期间缓存过期风暴怎么办？
• 进阶回答：限制回源并发、错开过期、保留热点保护，核心命令仍走权威校验；宁可返回处理中或限流，也不让缓存重建压垮数据库。
• WMS（仓储管理系统）热点容量与成本
• 追问 1：库存查询能否降级到缓存？
• 直接回答 1：可用于展示近似值并标明水位，但下单或调整前仍需权威条件校验；缓存不能承担最终扣减裁决。
• 追问 2：支付服务不可用时可否先收请求后补处理？
• 直接回答 2：只有能持久保存唯一意图、明确用户状态和最大处理时间时才可受理；不能返回支付成功，也不能无界积压。
• 追问 3：降级开关由谁关闭？
• 直接回答 3：按预定义恢复门禁由事故指挥或控制面逐档解除，每次解除都有观察窗，不能由单个业务请求临时绕过。

综合题 17：如何选择灰度单元而不是随机百分比

17. 问题：如何选择灰度单元而不是随机百分比？

口述答案：灰度单元要满足身份稳定、状态不跨主责、影响可隔离、结果可比较和回退可执行。库存适合按仓与商品集合，支付按渠道、币种和小额范围，物流按支持幂等查单的承运商，导出按租户和数据规模，调度按无危险副作用的任务类型，报警按租户与只读规则版本，多模型按索引或分区。若同一业务键在新旧路径间随机跳转，状态、缓存和外部幂等会被撕裂，即使总体错误率正常也无法归因。上线前从历史数据选择能覆盖正常、热点、取消、超时和迟到的代表单元，并建立旧路径基线；影子阶段新路径只计算不生效，双读差异达到门槛后才授予单元主责。假设灰度 5% 流量有 100,000 次请求，但都来自低风险查询，它不能证明支付回调或库存过期正确；应让小样本跨过完整业务周期。切写前冻结该单元新请求或用单调代次拒绝旧在途，记录切换水位。停止时路由整体回旧主责，新侧保持只读供差异调查。每次扩量只增加一个维度，例如先增加租户数量再增加热点强度，不同时改变代码、数据库和规则。这样灰度验证的是风险假设，而不是用随机用户承担未界定实验。 数据选择还要防止幸存者偏差：除了正常成功单元，主动纳入历史上出现过取消竞态、渠道超时、迟到事件和大对象的样本。每个单元记录进入与退出时间、代码版本、规则版本和数据水位，差异才能复现。若扩量后出现异常，可以精确收回该单元而不改变其他主责，并按相同样本回放修复版本验证根因已经消失。

• 回答思路：用稳定、可隔离、可比较、可回退的业务单元覆盖目标风险场景。
• 详细答案：库存按仓商品、支付按渠道小额、导出按租户规模、报警按只读规则切分；同一业务键固定主路径，先影子再切责，并跨过最慢业务周期。
• 进阶追问：灰度单元之间存在跨单元事务怎么办？
• 进阶回答：把关联对象提升为同一迁移单元，或在切换期间继续由旧主统一裁决；不能让一个原子业务横跨两个独立写主责。
• 异步导出灰度迁移与回滚
• 追问 1：首批灰度是否永远选最小客户？
• 直接回答 1：不一定；应选影响可控但能覆盖目标行为的单元，过小客户可能无法暴露热点、迟到和恢复问题。
• 追问 2：业务键哈希能否作为灰度单元？
• 直接回答 2：可以，只要同一键始终命中同一路径，相关联对象不被拆散，并有从哈希桶回退的稳定规则。
• 追问 3：灰度结束后为何还要保留旧链？
• 直接回答 3：需要跨过延迟故障和对账周期，并验证新链恢复能力；旧链在明确退出门禁满足前仍是回退证据和工具。

综合题 18：如何设置能自动执行的灰度停止线

18. 问题：如何设置能自动执行的灰度停止线？

口述答案：停止线从硬不变量、资源水位和恢复能力三层定义。第一层是不允许通过比例稀释的事件，例如重复入账、库存为负、重复外仓单、高危报警差异、旧执行代次生效和越权读取，发现一例就冻结扩量并切回既定主责；第二层是错误率、时延、连接等待、内存和队列年龄，采用分风险单元阈值和最小持续时间，防止瞬时噪声；第三层是净消化率、未知态最老年龄和差异积压，判断系统是否还具备恢复能力。每条停止线必须绑定数据来源、统计窗口、动作开关、影响范围、通知人和解除条件，不能只发告警等人判断。演练新路径每分钟处理 10,000 次，技术错误率从 0.05% 升到 0.08% 仍低于 0.1%，但出现一笔支付重复，硬停止线应立即触发；另一个场景错误率短时到 0.12% 持续十秒后恢复，可先冻结扩量并观察，而不一定全量回滚。自动动作先停新单元和历史回放，再根据业务差异决定切回。停止后系统生成受影响业务键、版本、水位与在途清单供查证。解除前要求根因已复现并修复、差异归零、回退演练通过和完整观察窗稳定。停止线本身也要定期故障演练，验证指标缺失或开关失败时有人工备用路径。 为避免恢复后立刻反弹，解除动作也按阶梯执行：先只读、再少量写、再恢复异步，最后才开历史回放；每档都重新计算影响集合和恢复余量。停止事件进入发布审计，记录谁定义、何时触发、开关多久生效和拦住多少危险动作。若实际生效时间超过设计值，就把传播延迟计入下一轮暴露上界，而不是修改报表掩盖。

• 回答思路：把硬不变量、统计水位和恢复能力分别转成自动动作与解除门禁。
• 详细答案：重复入账等硬事件一例即停，时延和错误率采用持续窗口，净消化率和最老年龄判断可恢复性；触发后冻结扩量并生成影响清单，解除也逐档进行。
• 进阶追问：停止线触发但旧链也异常怎么办？
• 进阶回答：进入双链故障预案，先冻结危险写并保留查证对账，按业务优先级启用人工或只读模式，不能机械切回已知不健康旧链。
• IoT（物联网）观测、SLO（服务等级目标）与回放
• 追问 1：停止线误报频繁怎么办？
• 直接回答 1：区分硬事件与统计信号，统计信号可用双指标、持续时间和风险单元降噪，但不能放宽资金或安全硬事件。
• 追问 2：指标系统故障时如何停止？
• 直接回答 2：关键门禁采用独立业务对账和本地保护，指标失联本身可触发保守冻结，并保留人工单主开关。
• 追问 3：停止扩量和全量回滚有何区别？
• 直接回答 3：停止扩量保持当前小范围以便查证；若不变量受损、影响继续扩大或无法隔离，才切回旧主责并处理已扩散事实。

综合题 19：如何设计单主裁决的迁移双写

19. 问题：如何设计单主裁决的迁移双写？

口述答案：迁移双写的第一原则是同一阶段只有一个系统决定业务成功。以旧系统为主时，业务状态和待传播变化在同一本地事务提交，发布器再把稳定业务键、聚合版本、事件号和载荷摘要传给新系统；新系统按键与版本幂等，重复事件返回既有结果，旧版本不能覆盖新版本。应用请求不能顺序调用新旧两边后把“都成功”当作提交，因为第一边成功、第二边失败或响应丢失都会形成半成功，补偿也未必能撤销外部副作用。假设迁移一百万次写，旧侧失败率万分之一、新侧失败率万分之五，独立近似下约有 600 次至少一边失败；单主传播把这些变成新侧可重放差异，而不是用户结果不确定。传播链记录提交位点、最老未应用年龄、版本跳跃和摘要冲突，超过保留期或净消化率不为正就停止扩量。新侧写成功不代表可切换，还要双读比较业务字段、权限、删除与状态机，并跨过延迟任务周期。切写按稳定业务单元进行，先冻结旧侧在途或提高主责代次，路由只把该单元交给新系统；旧侧转只读并继续接收新侧反向审计，而不是继续独立写。回退时恢复旧主责前先查清新侧已产生的事实，避免两个主系统同时生效。 迁移期间还要准备退出演练：暂停新侧消费一段时间，确认旧主不受影响；恢复消费后测量积压追平和业务差异；再模拟日志损坏，验证能否从快照与更早位点重建。告警按业务键版本跳跃、相同版本摘要冲突和最老传播年龄设置，不只看消费进程存活。只有旧系统退出后仍保留足够审计与回退证据，双写链路才算完成使命，而不是永久增加两套维护成本。

• 回答思路：旧主同事务提交事实与待传播记录，新侧按业务键版本幂等，切写前持续双读验收。
• 详细答案：双写只传播，不双重裁决；新侧失败形成可重放积压，版本冲突立即隔离。按业务单元切新主并收回旧写后，才结束双写责任。
• 进阶追问：待传播表自身膨胀如何治理？
• 进阶回答：按已确认消费水位分区归档和清理，保留期覆盖最坏恢复；清理前验证所有目标确认，不能仅按创建时间删除未传播事实。
• 多模型交易提交与传播
• 追问 1：新系统停机期间主业务要停吗？
• 直接回答 1：只要旧主和待传播日志安全，主业务可继续；但要监控日志保留和积压上界，超过可恢复窗口就收缩入口。
• 追问 2：新侧收到同版本不同内容怎么办？
• 直接回答 2：立即隔离为摘要冲突，停止该业务键推进并查权威日志；不能把后到内容当普通重复覆盖。
• 追问 3：何时把写主责交给新系统？
• 直接回答 3：新侧持续追平、业务差异通过、恢复演练完成、在途边界明确且旧侧可退后，才按单元切换。

综合题 20：双读校验发现新旧结果不同如何裁决

20. 问题：双读校验发现新旧结果不同如何裁决？

口述答案：双读阶段必须预先指定返回主结果和影子结果，不能差异出现时临时选看起来更合理的一边。旧系统仍是权威时，请求返回旧结果，新结果只写入差异账；切读后的单元返回新结果，但涉及支付、库存和权限的命令仍回权威事实复核。差异分类先看读取时间和版本水位，排除新侧允许的传播延迟，再分为键集合缺失、字段转换错误、状态版本落后、权限或删除不一致、口径预期差异和权威源自身缺陷。假设抽取 500,000 个业务键，1,000 个在五秒陈旧窗口内，200 个超过窗口，30 个权限不同，2 个金额不同；前 1,000 个不应立刻报故障，但其年龄要收敛，后 232 个必须阻断切换，其中金额与权限按硬风险优先查证。调查保留原始输入、旧结果、新结果、代码版本、规则版本和读取水位，修复后以同一批键重放，不能仅用最新随机样本证明。若确认旧权威有历史错误，应通过正式订正更新权威并传播，而不是让新侧影子结果直接夺权。为控制双读压力，可按业务键分层抽样并对高风险对象全量比较，查询预算与在线流量隔离。切换门禁同时要求差异率、差异最老年龄和不可接受类别都满足条件，避免平均比例掩盖少量资金错误。 差异口径本身也要版本化，例如旧系统按创建时间归属，新系统按支付完成时间归属，结果不同可能是预期语义变化，不能混入同步缺陷。预期差异必须由业务签署并能从原始事实同时复算两种口径。若差异只在某个租户、时区或历史版本集中，优先检查转换边界而不是全量重建。最终把差异率、硬风险数和最老差异年龄作为三条独立门禁，任何一条不合格都不切读。

• 回答思路：先按既定主责返回，再区分允许陈旧、同步缺陷、语义变化和权威错误。
• 详细答案：差异账保存两侧结果、版本、水位与口径，硬风险阻断切换；确认旧侧错误时也要正式订正权威，不能让影子结果临时夺权。
• 进阶追问：双读结果会泄露不同权限吗？
• 进阶回答：影子读取必须使用等价授权且结果只进受控差异系统，对权限字段做最小化和脱敏；任何越权差异均为硬停止线。
• 多模型数据质量排障与对账
• 追问 1：新结果响应更快可以优先返回吗？
• 直接回答 1：影子期不能按速度选结果；主责必须稳定，否则相同业务键会抖动，差异也无法归因。
• 追问 2：允许陈旧窗口怎样验证？
• 直接回答 2：记录权威提交时间、派生可见时间和版本，观察绝大多数及最老年龄，超过合同窗口即进入故障分类。
• 追问 3：双读压力太高怎么办？
• 直接回答 3：按风险全量与分桶抽样结合，离线回放历史查询，并给影子读取独立限额，不能挤占主查询。

综合题 21：切写时如何避免新旧系统同时成为主节点

21. 问题：切写时如何避免新旧系统同时成为主节点？

口述答案：我会把主责做成带版本的持久路由合同，而不是只改一个配置。切换前选定仓、租户、渠道或业务键分区，暂停该单元新请求，等待旧事务、消息和长任务排空；无法排空时给新主责分配更高单调代次，要求数据库或业务资源拒绝旧代次。路由变更包含单元标识、旧主、新主、切换水位、代次、生效时间和回退条件，所有写入口与补偿任务都读取同一合同，禁止旁路脚本继续写旧系统。演练旧任务在切换后恢复，若它携带旧代次提交，旧系统和外部资源都应拒绝；只在网关阻挡不够，因为任务可能早已越过网关。切换时先让新侧只读核对最新版本，再开放极小写流量，对账写入数、业务结果和副作用集合；旧侧保持只读镜像，记录任何残余写尝试。假设单元每分钟 3,000 次写，配置传播需要 30 秒，若不冻结就在窗口内暴露约 1,500 次双主竞争；通过入口冻结和资源端代次可把有效双主降为零。回退同样生成更高代次，不能把旧配置值简单改回，否则已经见过新代次的执行者可能乱序生效。最终以旧写尝试归零、业务差异清零、在途清单关闭和完整观察窗稳定作为切写成功证据。 旁路审计尤其重要：定时补偿、人工后台、数据修复脚本和旧消费者都可能绕过新路由，因此切换前扫描调用来源并给数据库旧写账户设置只读或条件拒绝。切换后的第一轮对账按单元比较写入键、状态版本和外部副作用，不等待日报。若发现旧写尝试，先定位来源并保持新主，不应为追求表面清零随意双向同步，否则会重新引入双主。

• 回答思路：把主责固化为带单元、水位和代次的合同，冻结在途并封堵所有旁路写。
• 详细答案：配置传播不足以阻止旧任务，必须由统一路由和资源端代次共同拒绝旧写；切换后审计脚本、人工后台与补偿任务的残余访问。
• 进阶追问：切写后发现一条旧侧合法晚到数据怎么办？
• 进阶回答：先判断它属于切换水位前的在途还是违规新写；前者按版本迁入新主，后者隔离来源，均不能重新开放旧侧双向写。
• Runner（执行器）栅栏与迟到写
• 追问 1：配置中心能否保证单主？
• 直接回答 1：只能传播意图，不能撤销已领取任务和在途请求；还需持久代次、入口冻结和资源端拒绝旧写。
• 追问 2：只读旧系统要保留多久？
• 直接回答 2：至少跨过延迟副作用、对账与回退窗口，并确认无旧写、证据已归档且新侧恢复演练通过。
• 追问 3：人工脚本如何纳入主责？
• 直接回答 3：脚本也必须通过统一服务或校验当前代次，记录审批和业务键；禁止直接绕过主责修改底表。

综合题 22：如何进行数据库模式的先扩展后收缩

22. 问题：如何进行数据库模式的先扩展后收缩？

口述答案：模式迁移分为扩展、回填、切读写、观察和收缩五步。扩展阶段只增加可空字段、新表或兼容索引，新旧代码都能运行；先发布能读取旧值、新值和未知枚举的代码，再开始写新字段，避免旧代码遇到新语义崩溃。回填使用稳定主键分片和固定水位，低速扫描并记录检查点，实时新增通过同一业务逻辑补齐；历史回填和在线写使用版本或条件更新，防止旧回填覆盖新值。切读前双读比较业务语义而非只比字符串，单位、默认值、时区和枚举含义都要纳入。假设一亿行数据按每秒 5,000 行回填，理论需 20,000 秒约 5.6 小时，但若数据库只允许每秒 2,000 行剩余能力，则至少 13.9 小时，还要预留失败重试和在线峰值，不能按最快速度承诺。切写后保留旧字段同步一段回退窗口，并监控仍读取旧字段的调用者；只有所有生产者、消费者、报表、脚本和备份恢复都不依赖旧结构，才停止旧写并删除。收缩是不可逆风险最高的一步，需要独立评审和备份验证。若变更涉及金额单位或状态语义，必须用新版本和订正记录表达，结构可兼容不代表业务兼容。 回退演练要在收缩前完成：切回旧代码读取一组已写新字段、未知枚举和历史空值的数据，确认不会误判；恢复备份到隔离环境，验证新旧模式和回填位点都存在。迁移指标包括回填最老主键、条件更新冲突、双读差异和旧字段读取量。只有旧读取量持续为零、回退窗口正式关闭、备份可恢复并获得数据所有者批准，才执行删除，且删除动作单独限速和审计。

• 回答思路：按扩展结构、兼容读取、在线回填、切换读写、观察依赖、最后收缩推进。
• 详细答案：先让旧新代码都能解析，再写新字段；回填使用稳定分片和条件版本，旧字段保留到读取归零、备份恢复和回退演练通过后才删除。
• 进阶追问：新增非空字段怎样避免长时间锁表？
• 进阶回答：先新增可空或有安全默认的字段，应用层逐步写入并分批回填，验证完整后再施加约束，具体动作需结合数据库能力压测。
• 多模型 Schema（模式）兼容与演进
• 追问 1：为什么先发布读兼容代码？
• 直接回答 1：生产者一旦写出新字段或枚举，旧消费者可能立即失败；先让读取方兼容才能安全扩大写入。
• 追问 2：回填能否直接覆盖空字段？
• 直接回答 2：要带版本或仅在仍为空且未被在线更新时写入，避免历史计算覆盖切换后的新事实。
• 追问 3：删除旧列前要查哪些旁路？
• 直接回答 3：除应用外还要查报表、导出、人工脚本、数据同步、备份恢复和审计工具，并验证回退已不依赖旧列。

综合题 23：快照加增量迁移如何确定无缝衔接点

23. 问题：快照加增量迁移如何确定无缝衔接点？

口述答案：核心是让快照与增量共享一个可证明的水位。开始快照前记录数据库一致性视图对应的事务或日志位点，快照读取该视图内的全部业务键，增量消费者从位点之后接收变化；不能先随意导表、结束后再找“差不多”的时间开始增量，否则快照期间的更新会漏失或重复。新系统写入同时携带业务键和来源版本，快照行是某一版本，后到增量只有版本更高才生效，重复或旧版本被幂等拒绝。快照分片用稳定全序主键，保存范围、行数和摘要；增量保存事件号、源位点和最老年龄。假设快照有 80,000,000 行，每秒处理 20,000 行需 4,000 秒；期间实时每秒新增 5,000 条变化，会积累 20,000,000 条增量。若追平消费者每秒 15,000 条，净消化率 10,000，额外需要 2,000 秒，总迁移至少约 100 分钟，还未计校验。快照完成后不能停增量做全量比较，应在持续消费下按分桶摘要和业务不变量校验，水位稳定接近源端后再双读。若日志保留不足以覆盖快照加追平时长，方案必须先延长保留、提高安全吞吐或分区迁移，不能开始后赌运气。回退时保留原位点和快照清单，确保可重建迁移过程。 迁移预算还要包含源库读取、目标写入、索引合并和对账扫描，任何一项都可能成为最小稳定吞吐。执行中若日志剩余保留时间小于预计追平时间加安全余量，应立即暂停新分区并扩展保留，而不是继续消耗窗口。校验时随机抽取更新频繁的热键，确认快照旧版本确实被后续增量推进；再删除一个测试对象，验证删除事件不会因快照重放而复活。

• 回答思路：用一致快照的日志位点连接全量和增量，再用版本拒绝快照迟到覆盖。
• 详细答案：快照按稳定主键保存分片清单，增量从精确下一位点消费；迁移预算必须覆盖快照期间新增、追平净吞吐和日志保留安全余量。
• 进阶追问：源库无法提供一致快照位点怎么办？
• 进阶回答：按可冻结分区短暂停写取得边界，或使用应用版本水位逐分区迁移；无法证明衔接就不能宣称无缝全量迁移。
• 多模型在线迁移与灰度
• 追问 1：快照中一行被更新多次怎么办？
• 直接回答 1：快照提供旧版本，位点后的增量按顺序或版本推进到最新；重复变化幂等，不能让快照迟到覆盖。
• 追问 2：日志出现缺口怎么办？
• 直接回答 2：停止切换，定位缺口范围并重新取对应分区快照或从更早可信点重建，不能用当前全量数字猜测补齐。
• 追问 3：何时说明已追平？
• 直接回答 3：源与目标位点差保持在合同窗口内、最老事件年龄稳定下降到门槛、业务差异可解释且恢复吞吐有余量。

综合题 24：恢复回放如何隔离真实副作用

24. 问题：恢复回放如何隔离真实副作用？

口述答案：回放默认只重建状态，不直接连接支付、外仓、通知、下载发布或设备控制等真实副作用。事件保留原业务键、事件号、来源版本和发生时间，回放批次另有身份，输出写入隔离表、影子索引或临时对象命名空间；所有副作用适配器在回放上下文中返回模拟结果或只读查证。先从可信快照和位点重建，再对账权威集合、派生集合与外部凭证，形成“应有但没有”“已有且正确”“存在冲突”“证据未知”四类。只有明确的应补差集才进入独立补偿流程，每一项重新校验当前状态、权限、金额上限和幂等键，并经风险审批执行。假设回放一百万个报警事件得到 5,000 个通知候选，其中 4,700 个历史已发送、200 个当时被合法抑制、80 个仍在允许延迟内、20 个确定漏发；真实补发集合只有 20，若直接让回放连接通知通道会重复 4,980 次。资源上历史回放与实时链分队列、线程和下游配额，实时水位越线时立即暂停。回放结果保存规则版本、输入摘要和输出摘要，修复后可重复运行得到同一差异。最终验收不仅看目标数据生成，还要证明副作用通道调用数为预期、旧业务键未重复生效、人工清单完整且在线链没有被回放拖慢。 回放环境也要复制权限与脱敏规则，防止历史敏感数据因调试被扩大暴露；输出对象设置独立保留期和访问账户。对包含随机算法、当前时间或外部配置的逻辑，固定种子、业务时间和配置快照，否则同一输入无法复现。若回放发现正式结果错误，先冻结相关规则或投影，发布订正版本并记录影响用户，再决定是否补发副作用，不能让数据工程师直接在生产表批量覆盖。

• 回答思路：影子重建状态，真实副作用默认关闭；对账形成明确差集后再走审批补偿。
• 详细答案：回放固定业务时间、规则版本与事件身份，输出到隔离空间；通知、支付、仓单和控制不直连，补发集合必须排除历史成功与合法抑制。
• 进阶追问：回放逻辑依赖当前外部汇率怎么办？
• 进阶回答：使用事件发生时的版本化汇率或原始凭证；拿不到就标记不可复现并限制结果用途，不能用当前汇率伪造历史一致。
• IoT（物联网）对账与规则回放
• 追问 1：回放时必须调用外部查单吗？
• 直接回答 1：高风险未知项可通过限额只读查证获取凭证，但不直接执行写动作，查单结果进入差异裁决。
• 追问 2：补发通知还用原请求号吗？
• 直接回答 2：应使用可追溯的补偿幂等键并关联原报警与回放批次，防止与历史尝试混淆或重复。
• 追问 3：影子结果何时可覆盖正式结果？
• 直接回答 3：不直接覆盖；通过版本化切换或订正批次发布，保留旧结果和切换水位，支持审计与回退。

综合题 25：迁移对账如何从数量比较升级到业务守恒

25. 问题：迁移对账如何从数量比较升级到业务守恒？

口述答案：我会建立由浅到深的五层门禁。第一层校验快照文件、分片清单和摘要，确认介质未损坏；第二层按稳定业务键比较集合，找只旧有、只新有与重复键；第三层比较来源版本、关键字段、权限、删除标记和状态机合法性；第四层复算业务守恒，例如库存期初加减流水等于期末、支付借贷平衡且一笔意图只有一组有效分录、导出行集等于冻结条件；第五层验证水位、最老年龄、查询时延和恢复净吞吐。总数相同不能跳过后面层级，一进一出会抵消，字段错和权限泄露也不改变行数。演练两边都是 2,000,000 行，集合差发现旧有新无 300、新有旧无 300，版本不同 1,200，权限不同 40，其中还有两笔支付金额差；表面数量差为零，实际至少 1,842 个对象需分类，金额与权限立即阻断切换。大规模比较先按业务键分桶计算数量与摘要，异常桶下钻明细，高风险不变量全量计算。差异单保留旧值、新值、来源证据、风险、责任人和修复批次，修复通过新版本传播而非直接改目标库。连续多轮对账还要观察同类差异是否反弹，确认根因在生产链而不是只修了存量。最终由业务所有者签署守恒结果，技术团队不能用“同步完成”代替业务验收。 修复审批按差异类型设置：派生索引落后可自动重放，库存余额或支付金额差异必须结合流水与外部凭证人工确认，高危控制记录缺失则先冻结设备动作。补偿前后都计算相同守恒公式并保存摘要，失败可重试但不能重复有效调整。若差异来源是口径变化，建立新口径批次和生效时间，不把历史合法数据批量改成当前样式。这样迁移验收既能发现漏数，也不会用修复脚本制造新事实。

• 回答思路：介质、集合、记录、业务守恒和运行能力五层逐级验收。
• 详细答案：行数与摘要只定位范围，最终要比较版本、权限、删除和库存资金公式；差异由权威与外部凭证裁决，修复追加新事实并防止反弹。
• 进阶追问：分桶摘要算法升级会影响历史比较吗？
• 进阶回答：会，因此摘要算法和字段集合必须版本化；升级时用同一数据并行计算新旧摘要，建立转换基线后再用于门禁。
• WMS（仓储管理系统）对账与补偿
• 追问 1：摘要相同能否跳过明细？
• 直接回答 1：高质量分桶摘要可降低下钻量，但业务守恒、权限和极高风险字段仍需独立校验，摘要算法也要版本化。
• 追问 2：差异修复应改哪一边？
• 直接回答 2：先由权威事实和外部凭证裁决，再修权威或重建派生；不能默认把旧覆盖新或新覆盖旧。
• 追问 3：连续几轮无差异才够？
• 直接回答 3：取决于业务周期，至少覆盖过期、回调、结算、迟到和清理等最慢机制，并通过一次故障恢复演练。

综合题 26：如何评估一项技术债的偿还优先级

26. 问题：如何评估一项技术债的偿还优先级？

口述答案：我先判断它是仍满足当前合同但持续付出成本的技术债，还是已经违反资金、库存、安全或用户承诺的缺陷；缺陷直接进入事故或修复，不能排在债务队列里。对真正债务记录本金，也就是一次性改造、迁移和培训投入；记录利息，包括每月适配、回归、值班、人工补偿、资源浪费和交付等待；再记录风险暴露、影响上界、适用边界、触发器和所有者。假设支付渠道硬编码每月花 8 人日接入、4 人日回归、3 人日故障处理，共 15 人日；平台化需 72 人日，之后每月降到 3 人日，月节省 12 人日，静态回收期 6 个月。若业务预计稳定运行两年且渠道继续增加，应优先；若产品四个月退出，可能只补测试和隔离。优先级还要乘以事故损失和触发概率，不能只按人日排序；无法查单导致重复资金风险通常高于报表代码重复。偿还计划只改一个主责，先补证据与门禁，再影子迁移，保留旧链回退。验收比较债务利息是否实际下降、事故影响是否收敛、新增运维复杂度是否可承担。关闭旧债时同步登记新架构带来的兼容、监控和供应商锁定债，避免“重构完成”成为新的盲区。 对风险还可用区间而不是伪精确概率：最坏影响多少业务键、多久能发现、多久能停止、能否逐笔恢复。若债务每月节省看似只有 5 人日，但一次事故会冻结渠道两小时且无法查单，它的优先级可能高于重复代码。每个季度复审实际利息和触发器，达到阈值自动进入方案评审；未达到则继续观察并保持缓解措施，避免技术债评估变成一次性的架构宣传。

• 回答思路：先区分缺陷与债务，再核算本金、月度利息、风险上界、偿还触发器和新债。
• 详细答案：债务优先级不能只按代码质量，需结合人工成本、事故损失和剩余业务周期；偿还采用可逆迁移并验证利息真实下降，而非重构完成即关闭。
• 进阶追问：业务一直推迟偿还高风险债务怎么办？
• 进阶回答：把最大影响、缓解成本和触发阈值正式升级到风险决策，关键安全与正确性缺陷不能作为普通债务无限延期。
• 案例事实卡与迁移路线
• 追问 1：没有历史工时数据怎么办？
• 直接回答 1：从工单、发布记录、事故和值班抽样建立区间，明确不确定性；先记录未来一个周期再重排，不编造精确数字。
• 追问 2：风险很高但改造巨大怎么办？
• 直接回答 2：先用限流、隔离、人工审批和对账降低暴露，再分阶段偿还；缓解措施不能替代最终所有者和期限。
• 追问 3：谁决定技术债优先级？
• 直接回答 3：技术提供成本与风险证据，业务确认损失和期限，运行确认可维护性，由共同决策而非单纯按研发偏好。

综合题 27：何时从模块化单体演进为服务化架构

27. 问题：何时从模块化单体演进为服务化架构？

口述答案：我不会把代码量或流行趋势当拆分理由，而看数据所有权、团队责任、资源曲线和失败域是否已经独立。库存与订单在早期共享本地事务，可以更简单地守住不超卖；当库存热点需要独立扩展、批量仓内任务持续干扰订单、团队发布节奏冲突且模块边界已经清晰，服务化才可能有收益。拆分前先在单体内禁止跨模块直接改表，通过明确接口、领域事件和契约测试证明边界；若连本地边界都守不住，网络化只会让耦合更隐蔽。迁移采用旧模块单主提交和待发布事件，新服务影子计算、双读对账，按仓或商品单元切换，不能同时拆数据库、改状态机、换消息和重组团队。容量上计算网络调用、序列化、重试和新运维成本，例如本地一次事务变为三次远程调用后，峰值每秒 1,000 个订单可能产生每秒 3,000 次调用和额外失败组合。故障演练要验证新服务不可用时订单能否保守拒绝或排队、旧服务如何回退、消息积压如何追平。成功标准不是服务数量增加，而是热点隔离、独立发布或团队交付得到可测改善，同时库存不变量、端到端时延和单位正确结果成本仍达标。如果收益没有覆盖一致性与值班成本，应继续保持模块化单体。 组织验收也要改变：新服务有明确所有者、值班、容量预算和事故权限，不能只是原团队多维护一个进程。契约变更通过版本与兼容测试，调用方不能依赖内部表结构。上线三个月后复盘独立发布次数、故障影响范围、锁等待、端到端时延和人均值班负担；若只有部署数量上升而业务交付没有改善，应停止继续拆分，并考虑重新合并过细边界。

• 回答思路：用数据所有权、团队责任、资源曲线和故障隔离收益判断，而非按代码量拆分。
• 详细答案：先在单体内建立模块与访问边界，再以单主传播和双读迁移；只有独立扩展、发布和故障范围的收益覆盖网络一致性和值班成本，服务化才成立。
• 进阶追问：拆分后出现分布式事务需求怎么办？
• 进阶回答：重新审视边界是否切断同一不变量；核心原子更新尽量留在同一聚合，边界外用已提交事件与补偿，必要时合并过细服务。
• WMS（仓储管理系统）迁移演进与取舍
• 追问 1：团队数量是否直接决定服务数量？
• 直接回答 1：不是；团队边界是输入之一，还需数据和失败责任可独立，避免一个业务事务被组织结构强行切碎。
• 追问 2：先拆数据库还是先拆代码？
• 直接回答 2：通常先建立代码与访问边界，禁止跨模块写，再通过事件和迁移逐步分离数据，降低一次性风险。
• 追问 3：拆分后性能变差怎么办？
• 直接回答 3：按调用链定位同步往返、序列化和重试，合并粗粒度接口或异步副作用；若根本收益不足，应按回退合同合并责任。

综合题 28：遗留系统没有幂等和对账时如何分阶段改造

28. 问题：遗留系统没有幂等和对账时如何分阶段改造？

口述答案：我不会先拆服务或替换数据库，而会先补事实与观测。第一阶段梳理订单、库存、支付或任务的稳定业务键，建立不可变操作流水和状态变更审计，对当前重复和差异做只读扫描，确认真实影响；入口暂时无法全量改造时，可在高风险命令前加幂等登记和唯一约束。第二阶段把外部调用的业务号、请求摘要、尝试号与结果凭证落账，超时显式进入未知态，先查证再重试。第三阶段将业务状态和待发布变化放入同一本地事务，消费者按业务副作用幂等，补上死信与人工工作台。第四阶段建设独立对账，从集合差、字段差下钻到库存等式或资金分录守恒，补偿用新流水而非直接改最终状态。假设历史一百万订单中发现 800 个重复请求、120 个状态与流水不符、20 个外部结果未知，先冻结这 20 个高风险对象，再处理状态差异，最后清理可证明无副作用的重复。第五阶段才通过影子流量迁移新实现，旧系统继续单主裁决，跨过完整业务周期后按单元切换。每阶段都有独立收益和回退：即使服务化延期，事实账、幂等和对账也已经降低事故风险。改造过程避免全量历史一次修复，先保护新流量，再按风险和年龄治理存量，防止修复脚本绕过新入口制造第二套事实。 对无法立刻建立唯一键的历史数据，保留冲突组和人工映射，不强行合并；对新增数据则从生效水位开始严格执行。指标从重复登记、未知年龄、对账差异和补偿成功率逐步建立，只有数据证明风险下降才进入下一阶段。最终目标是让每个成功、失败和订正都能被重新计算，而不是让旧系统在一次大改后看起来更现代。

• 回答思路：先补业务身份和事实账，再补未知态、可靠传播、对账补偿，最后迁移实现。
• 详细答案：遗留改造优先保护新流量并冻结高风险历史冲突，每阶段都能独立降低重复与不可恢复风险；不把拆服务作为第一步，也不全量覆盖旧数据。
• 进阶追问：遗留代码无法同事务写待发布记录怎么办？
• 进阶回答：先用数据库变更日志或事务后扫描补传播，并对缺口对账；关键路径逐步改为同事务模式，过渡方案标明丢失窗口和退出期限。
• 案例索引与迁移路线
• 追问 1：唯一约束上线时已有重复数据怎么办？
• 直接回答 1：先按业务键形成冲突组，冻结高风险对象并人工裁决；从新水位启用约束，历史逐批治理，不能直接删除重复行。
• 追问 2：先做对账还是先做补偿？
• 直接回答 2：先有可重复对账和差异分类，再定义补偿；否则脚本不知道权威依据，也无法证明修复是否正确。
• 追问 3：如何避免改造长期没有业务收益？
• 直接回答 3：每阶段绑定可测指标，如未知态年龄、重复副作用、人工工单和恢复时间，阶段完成即可减少具体风险。

综合题 29：多模型数据架构如何控制技术债和成本

29. 问题：多模型数据架构如何控制技术债和成本？

口述答案：我先要求每新增一种存储模型都写清唯一用途、数据所有者、来源、陈旧窗口、删除语义、重建输入、退出路径和单位正确结果成本。交易数据库守住订单、库存和资金权威，搜索只承担全文与组合过滤，分析库承担大范围聚合，时序模型承担事件时间窗口与降采样，对象存储承担冷证据；如果两个模型解决同一查询且没有独立失败需求，应优先合并。成本不能只看节点账单，还要算每笔交易产生的写放大、网络、索引合并、冷热保留、备份、回填、重建、对账、值班和隐私删除。演练一笔交易在权威库写 3 个单元，在搜索、分析、时序和归档再写 5 个单元，逻辑写放大为 8；日增一千万笔就是八千万个写单元，每个模型都增加恢复与删除责任。技术债台账记录模式兼容、分片倾斜、历史回填、供应商锁定和无人负责的派生表，达到水位或人工利息阈值就进入偿还评审。控制措施包括统一事件身份与版本、快照加增量重建合同、按风险分层保留、自动生命周期、查询路由和定期退出演练。搜索或分析不可用时可降级到有限回源或展示水位，但不能反向改交易事实。 每季度淘汰没有活跃查询、无法说明所有者或无法重建的派生数据，删除前验证依赖和合规保留。若一个新模型每月节省 20 人日分析开发，却增加 8 人日运维和 5 人日删除治理，净收益仍为 7 人日；若查询量下降，结论应重评。架构价值不是模型越多越先进，而是每个模型的边界、成本和退出都可证明。

• 回答思路：每个模型先证明独特用途，再核算写放大、保留、重建、删除、值班和退出全成本。
• 详细答案：交易源唯一权威，搜索分析时序各守有限读职责；统一事件和重建合同降低债务，定期淘汰无所有者、无查询收益或无法删除恢复的派生。
• 进阶追问：多个团队都想保留自己的派生副本怎么办？
• 进阶回答：要求每个副本提交查询收益、所有者、质量目标、删除和恢复成本；无法证明独立价值的合并为共享数据产品或停止写入。
• 多模型容量成本与分片治理
• 追问 1：搜索索引能否长期不重建？
• 直接回答 1：不能把未演练当能力；应定期从快照和增量重建影子索引，记录耗时、差异和切换证据。
• 追问 2：冷热分层最容易遗漏什么成本？
• 直接回答 2：冷数据取回、校验、解密、出口流量和恢复人时；便宜存储若无法在目标时间恢复并不便宜。
• 追问 3：如何判断某个派生库该退出？
• 直接回答 3：用途被替代、查询收益低于维护利息、所有者缺失或无法满足删除恢复合同时，应先影子停写、验证依赖后退出。

综合题 30：迁移完成后如何安全退出旧链路

30. 问题：迁移完成后如何安全退出旧链路？

口述答案：退出旧链不是停止服务器，而是证明旧链不再承担写、读、恢复和审计责任。先从统一路由、数据库账户、消息订阅、定时任务、人工后台和脚本六类入口确认旧写为零，任何残余写都追到所有者；再观察旧读量，区分用户查询、报表、审计与回退探测，逐一迁移。旧系统保留只读期间持续与新系统对账，至少跨过支付结算、库存过期、物流迟到、对象清理或规则窗口等最慢业务周期，并执行一次新系统故障恢复，证明没有旧链也能从备份、日志和外部凭证重建。数据归档前固定模式、字典、权限、摘要、位点和保留策略，不能只存一份无人能读的表文件。假设旧链每月仍有 0.02% 读流量，千万请求中就是 2,000 次；直接关停会变成用户故障，应先定位调用方而不是以比例低忽略。退出分为停新写、停普通读、停回退读、归档证据、撤销账户和释放资源，每步有回退点。安全与合规负责人确认密钥、个人数据和备份删除责任，财务确认供应商账单和合同退出。最终更新值班手册和事故路由，避免故障时人员仍操作旧控制台。 退出后保留一段独立监控，任何访问旧地址或旧队列都触发告警而不是静默失败。资源释放前做成本基线，确认账单下降与新链额外成本，防止只是把成本转移。最后关闭技术债台账中的旧链条目，同时登记新系统的兼容和恢复债务，保证演进有完整生命周期。 正式关停前再保留一周拒绝探针：旧入口不处理业务，只记录调用身份并返回可识别错误，确认没有隐蔽客户端后才撤销域名和账户。归档恢复抽取一个分区在隔离环境读取，证明字典、密钥和口径齐全。

• 回答思路：依次退出旧写、旧读、回退责任、在线数据和资源，同时验证新链独立恢复。
• 详细答案：通过账户、网络、队列、脚本和拒绝探针证明旧依赖归零，跨最慢业务周期对账并完成新链恢复演练；归档保留模式、密钥、位点和口径。
• 进阶追问：旧链合同尚未到期但技术已退出怎么办？
• 进阶回答：停止业务依赖但保留最小合规与安全维护，核算提前解约和闲置成本；不能因账单存在就继续双写制造技术风险。
• 多模型在线迁移与退出
• 追问 1：旧数据库可以直接只读保留吗？
• 直接回答 1：可在明确期限内只读，但需限制账户、继续补丁与备份，并计划归档；永久保留会形成安全和成本债。
• 追问 2：新系统恢复演练失败怎么办？
• 直接回答 2：停止退出，修复备份、位点和回放能力；旧链仍作为受控回退，不能因项目期限强行下线。
• 追问 3：如何发现无人登记的旧依赖？
• 直接回答 3：结合访问日志、账户审计、网络流量、消息订阅和逐步拒绝演练，不能只依赖服务目录。

综合题 31：完整串讲 WMS（仓储管理系统）库存预占到出库

31. 问题：完整串讲 WMS（仓储管理系统）库存预占到出库方案。

口述答案：我会从库存承诺与实物责任一致这个目标开始。客户请求带幂等键进入订单域，库存服务按仓、商品和批次定位权威余额，通过条件更新同时写预占记录与流水，确保可售不为负；缓存只做热点准入和削峰，数据库事务才裁决成功。预占有明确到期时间和状态版本，支付确认、取消与到期释放竞争同一条件迁移，只有一方成功，失败方读取新状态后停止。进入仓内后，履约单、仓单、波次、分配、拣货、复核和出库分别保存身份与责任转移，少货和复核差异进入异常单，不直接改余额掩盖。外仓建单携带稳定业务号，超时进入未知态先查单，确认成功才绑定外部单号。权威事务和待发布事件同事务提交，消息允许重复，消费端按仓单或业务动作幂等。对账从期初、入库、预占、释放、出库和调整复算期末，并穿透订单、仓单与实物。容量关注热点锁、波次批量和恢复流量，在线预占有保底，批量任务可暂停。事故出现负库存时先冻结该仓商品危险写，核对流水与旁路脚本，再修权威并重建缓存。 迁移新服务采用旧库单主裁决、新侧影子等式与双读，对低热点仓灰度，跨过预占到期和波次周期后按仓商品切写。停止线是可售为负、重复释放、重复仓单和对账差异。取舍上接受缓存短时不一致、消息重复和批量延迟，但不接受库存权威被缓存替代或实物责任无法追溯。 复盘结果还要与实物抽盘交叉验证，因为数据库等式自洽也可能共同偏离仓内现实；抽盘差异生成调整审批和新流水，不回写历史。成本按正确出库单计入锁等待、补偿和人工。

• WMS（仓储管理系统）库存与仓内作业方案
• 追问 1：支付成功后发现预占已释放怎么办？
• 直接回答 1：状态条件裁决若释放先成功，不能直接恢复旧预占；进入重新占用或退款补偿流程，保留两条事实。
• 追问 2：波次任务为何不能长事务锁住全部库存？
• 直接回答 2：会扩大锁范围和失败回滚，阻塞在线预占；应稳定分片、短事务提交、保存检查点并支持异常单恢复。
• 追问 3：人工库存调整怎样控制？
• 直接回答 3：最小权限、双人审批、原因码、前后余额与流水审计，并走统一条件更新，禁止直接改最终余额。

综合题 32：完整串讲支付确认、账务与对账恢复

32. 问题：完整串讲支付确认、账务与对账恢复方案。

口述答案：我先声明资金正确性高于表面可用性。支付发起以商户、业务单号和支付意图形成请求幂等，创建本地支付单和渠道请求号后调用渠道；超时只进入未知态，复用原号查单，绝不换号盲重试。渠道同步返回、异步回调和主动查询都先验签、防重放并保存原始凭证，再由支付状态版本裁决合法迁移。确认成功的本地事务同时记录支付事实、待入账或待发布事实，账务服务按唯一业务来源生成借贷守恒分录；支付状态、交易状态和账务状态分开，因为它们可能在不同时间收敛。下游订单、库存和通知消费已提交事件，允许重复投递但副作用按支付号唯一。退款、撤销、冲正和拒付各有独立状态与流水，共享可退金额上限，不覆盖原支付成功。日内增量对账快速发现内部成功渠道无单、渠道成功内部无单、金额不同和分录缺失，日终再结合结算文件确认资金。渠道故障时停自动写重试、保留查单回调和账务补记，按金额与年龄处理未知。 容量计算发起、回调、查单、分录和对账放大，按渠道隔离配额。灰度从小额、可查单渠道开始，跨完整结算周期，重复入账和无分录成功为硬停止线。恢复完成要求未知大额清零、借贷守恒、渠道金额差异清零且延迟回调不再改变终态；代码回滚不能代替在途资金查证。 数据演练可取十万笔确认、200 笔超时，经查单 130 成功、50 未执行、20 未知，只重试 50；若全部重试，至少 130 笔暴露重复扣款风险。月末再从结算总额、手续费和退款净额复算，避免日内状态正确但结算口径错误。成本以正确闭环交易为分母，纳入渠道查询、对账与人工差错处理。

• 支付资金正确性与恢复方案
• 追问 1：账务分录写成功但事件发送失败怎么办？
• 直接回答 1：分录与待发布事实同事务提交，发布器按事件号重试；不能回滚已生效分录，也不能重新生成另一组分录。
• 追问 2：退款和冲正为何要分开？
• 直接回答 2：退款是正常反向业务，冲正纠正异常记账，触发者、凭证和状态不同；混合会破坏审计与金额上限。
• 追问 3：渠道账单晚到如何对账？
• 直接回答 3：先用实时凭证做临时收敛，账单到达后按批次重算并生成迟到差异，原对账批次不覆盖。

综合题 33：完整串讲跨境订单、面单、轨迹与异常恢复

33. 问题：完整串讲跨境订单、面单、轨迹与异常恢复方案。

口述答案：跨境履约的核心是承认外部慢、重复、乱序和结果未知是常态。订单确认后先提交本地履约意图，编排层只管理下单、建仓单、面单、出库和轨迹阶段，适配层吸收不同海外仓和承运商协议；订单、履约单、外部仓单、面单和轨迹事件各有稳定身份。外仓建单使用业务幂等号，超时进入未知态并查单，查到成功补记外部号，明确不存在才复用原号重试。面单文件记录版本、大小和摘要，重新出单生成新版本，旧文件迟到不能覆盖。回调与轮询都保存原始事件、事件时间、接收时间、来源版本和原文，标准化后按运单与版本更新查询投影；重复不再贡献，迟到在途不能倒退签收终态，错误签收通过订正事件表达。失败按可重试、不可重试、未知和毒事件分类，重试有退避、次数和最大年龄，毒事件隔离后不阻塞分区。容量从订单峰值乘以面单和轨迹放大，渠道配额、实时与历史回放分域。 排障从业务键穿透本地意图、外部请求、原始轨迹和投影，先保留接入再停危险建单重试。对账比较本地订单、外部号、面单、轨迹和终态集合。迁移新适配器先影子请求转换与双读，不真正建单，随后按支持查单的低风险渠道切换；重复外仓单、终态倒退和面单摘要异常立即停止。 演练每秒 400 个包裹、平均 15 条轨迹，事件入口为每秒 6,000 条；补推历史时若恢复每秒 9,000、实时仍为 6,000，净消化仅 3,000。验收还要穿透错误签收订正、面单重拉和取消未知三个样本，证明原始事实不丢、投影能修订、外部副作用不重复。

• 跨境履约、面单与轨迹方案
• 追问 1：轨迹状态标准化会不会丢信息？
• 直接回答 1：标准状态服务查询，原始事件和承运商原文永久关联保留；无法映射的状态进入未知分类而不是强行归并。
• 追问 2：毒事件如何恢复？
• 直接回答 2：保存原文、错误、模式版本和业务键到隔离队列，修复转换后按原事件号回放，避免阻塞正常分区。
• 追问 3：签收后迟到一个揽收事件怎么办？
• 直接回答 3：原始事件照常入账，但查询终态不倒退；若承运商明确订正签收，则用更高订正版本处理。

综合题 34：完整串讲异步导出快照、分片与交付

34. 问题：完整串讲异步导出快照、分片与交付方案。

口述答案：异步导出首先冻结用户意图，而不是直接把查询丢进队列。入口校验当前权限、租户和条件，保存规范化条件、数据水位、格式和幂等键；相同请求可返回已有任务。任务状态机区分待执行、运行、取消中、成功、失败和过期，完成由分片集合、行数、对象摘要和唯一发布共同证明。数据读取使用固定水位与全序游标，按稳定主键范围分片，检查点记录最后成功边界；重试不会因新增数据或分页漂移漏行重行。文件生成采用有界批次、流式编码和分段上传，内存峰值由批大小乘并发决定，执行器、线程、数据库连接和对象上传与在线交易隔离。临时分片写入不可见命名空间，全部校验后合并或生成清单，再原子发布不可变对象。用户下载时重新校验权限并签发短期凭证，对象到期与任务审计分开保留。取消和完成通过条件状态竞争，取消胜出则禁止发布并登记孤儿对象清理。 观测任务最老年龄、分片失败、数据库水位、单批内存和对象错误；线上内存异常先停大任务与回放，保护在线链，再从检查点小批恢复。容量计算到达率、服务率、最坏工作集、对象保留和恢复余量。灰度从小数据租户开始，对比冻结行集与摘要，回滚只切交付主责，不删除已生成证据。 数据演练设单批 2,000 行、展开后每行 2 千字节、并发 8，核心数据约 32 兆字节，叠加编码与上传缓冲后仍要低于资源水位。恢复不仅验证文件可下载，还要扫描临时命名空间和清理队列，确保取消、失败与过期任务没有长期孤儿对象，权限撤销也能阻止旧凭证继续使用。

• 异步导出快照与隔离方案
• 追问 1：为什么不使用偏移分页？
• 直接回答 1：并发新增删除会让偏移漂移，深分页成本也上升；固定水位加全序游标更易续跑和证明边界。
• 追问 2：分片都成功为何合并仍可能失败？
• 直接回答 2：可能缺分片、边界重叠、摘要损坏或对象发布失败，合并前后都要校验清单与最终摘要。
• 追问 3：任务成功后用户权限被撤销怎么办？
• 直接回答 3：下载时按当前权限重新授权，不因任务历史成功永久开放；必要时立即撤销凭证并审计访问。

综合题 35：完整串讲 Runner（执行器）调度、接管与恢复

35. 问题：完整串讲 Runner（执行器）调度、接管与恢复方案。

口述答案：调度系统只保证生成和驱动执行意图，不承诺业务天然只执行一次。任务定义保存计划版本、资源组、超时、重试预算和暂停策略；触发实例用任务与计划时间形成唯一键，补扫重复创建会返回既有实例。调度器提交触发事实后发送唤醒，Runner（执行器）通过条件更新领取租约并获得单调代次，执行尝试、检查点和业务结果分别记录。心跳只能续资格，不能证明业务推进；检查点必须对应稳定业务边界。租约过期后新执行者接管，先按业务幂等键查证原结果，已成功就补任务终态，明确未执行才重试，未知则人工。旧执行者恢复时，任务库拒绝旧代次推进，业务资源也拒绝旧代次副作用，避免只锁调度表却让迟到写生效。不同任务类型和租户使用独立队列、线程、并发与下游预算，慢任务、重试和历史恢复不能吃光核心任务。 重试按错误分类、退避、次数和最大年龄，补偿生成新事实而不删除失败。暂停是持久控制状态，停止新领取并等待或撤销在途；恢复生成新代次从检查点继续。观测有效完成、最老年龄、租约过期、旧代次拒绝和未知任务。灰度先选只读任务，故意注入长暂停与重启；重复业务结果或旧代次生效为停止线。方案接受重复唤醒，拒绝重复有效副作用。 容量用有效完成而非领取数：每秒领取 600、成功 500、失败重入 80、实时新增 450，则净消化只有 50。事故恢复先处理高风险老任务，验证取消与完成竞态只有一个胜者，检查点之后的副作用可安全重入；人工接管也生成更高代次和审计，不能直接改成功状态。

• Runner（执行器）调度与恢复方案
• 追问 1：任务状态成功但业务结果不存在怎么办？
• 直接回答 1：任务成功属于伪成功，按业务键查证并回退到待恢复或异常态；完成必须由业务权威结果证明。
• 追问 2：检查点越细越好吗？
• 直接回答 2：不是；过细会增加持久化成本且可能落在不可幂等中间态，应选择可重复进入的业务边界。
• 追问 3：暂停时正在执行的任务怎么办？
• 直接回答 3：按任务合同选择等待安全点、协作取消或让租约过期；危险副作用需撤销资格并由资源端拒绝旧代次。

综合题 36：完整串讲 IoT（物联网）报警聚合、背压与恢复

36. 问题：完整串讲 IoT（物联网）报警聚合、背压与恢复方案。

口述答案：我把目标定义为风暴下高危不漏、普通可降级、通知可查证、控制可撤销。设备事件先校验租户、设备、测点和协议，保存稳定事件号、事件时间、接收时间与原始摘要；平台按明确规则版本判断等级，设备自报高危不能无条件占用关键通道。高危进入持久旁路并独立对账，普通事件按租户公平配额进入窗口处理。去重只让同一事件贡献一次，聚合键由租户、拓扑、规则版本和故障族构成，窗口保存首末时间、数量、不同设备、代表样本和修订代次；迟到在允许期内产生修订，超过期限进入侧账。抑制只暂停通知或控制，不删除报警，关联边保留拓扑版本和证据，低置信根因不能隐藏高危。通知尝试有通道幂等号，超时先查证；自动控制限定白名单、审批、冷却期和资源端单调代次，旧控制者迟到会被拒绝。 容量按风暴峰值、窗口状态、通知配额和恢复净吞吐推导，入口、实时、历史回放和通知重试分域。事故先冻结自动控制和历史回放，保住高危接入与查证，再回滚异常规则，隔离回放差异。验收比较高危事件、报警、通知与控制集合，观察最老年龄和人工积压。灰度从只读影子到展示、通知、受控动作逐级开放，每级跨过迟到窗口。 数据演练从每秒 3,000 突发到 30,000，高危占 0.5%，关键通道至少保障每秒 150 条及其查证；普通流量即使压缩 95%，也要抽样核对来源覆盖和误合并。恢复后回放一组拓扑过期、维护抑制和派生循环样本，确认高危从未被静默，解除抑制不会重复通知或控制。

• IoT（物联网）报警治理方案
• 追问 1：设备时钟严重漂移怎么办？
• 直接回答 1：结合网关时间、设备序列和历史偏移隔离该设备，不能让它拖住全局水位；原始时间仍保留供审计。
• 追问 2：普通报警可以丢弃吗？
• 直接回答 2：可按明确策略不做实时通知或只保留摘要，但原始计数、降级版本和恢复责任必须可解释，不能静默消失。
• 追问 3：根因报警关闭是否自动关闭子报警？
• 直接回答 3：不能；要根据各子对象恢复事件和抑制解除条件裁决，根因关闭只是一条证据变化。

综合题 37：完整串讲多模型存储、搜索、分析与时序方案

37. 问题：完整串讲多模型存储、搜索、分析与时序方案。

口述答案：我先明确同一业务事实只有一个权威裁决者，多模型是为不同读取形状建立可删除重建的派生。交易数据库保存订单、库存、支付、设备和规则的当前状态与不可变流水，本地事务同时写待发布事实；发布器或变更日志把事件号、业务键、来源版本、事件时间和提交时间传播出去。搜索模型按查询聚合文档，支持全文、过滤和排序，但关键命令执行前回权威服务复核；分析模型保留原始明细和口径版本，迟到修订先形成候选批次；时序模型区分原始点、最新值、降采样和冷归档，对象存储保存带清单、摘要和保留策略的证据。每个模型都有数据所有者、陈旧窗口、幂等规则、删除传播、对账和重建合同。事件重复按事件号去重，同一业务键用来源版本拒绝倒退，模式演进先扩展后收缩。故障时先判断权威事实是否正确，再沿提交位点、消费水位、版本和业务键定位派生差异；搜索可降级到有限精确回源，分析展示截止水位，不能反向覆盖交易。 容量同时计算写放大、复制、合并、回填和重建，恢复流量与实时增量隔离。迁移新模型使用一致快照加增量追平，影子空间分层校验后按分区切读。假设每秒 2,000 笔交易平均产生 1.5 个事件，四倍突发为每秒 12,000 条；恢复每秒 18,000、实时 12,000，60 万积压需约 100 秒追平。验收还要覆盖权限、删除和一次真实重建。 删除传播也要作为主链测试：撤销一个用户权限并删除一条权威记录，验证搜索、分析、时序和归档索引在合同窗口内收敛，备份保留则按合规策略隔离而非继续对外可见。

• 多模型存储搜索分析时序方案
• 追问 1：分析结果能否直接触发补货？
• 直接回答 1：可生成候选建议，但执行前必须由库存领域校验当前余额、权限、版本和幂等，分析库不直接改权威。
• 追问 2：派生模型都落后时如何判断源头？
• 直接回答 2：从权威提交版本和待发布记录开始，检查发布位点、分区水位和各消费者版本，找到第一个出现缺口的边界。
• 追问 3：对象存储归档是否等于可恢复？
• 直接回答 3：不等于；还需模式、字典、密钥、位点、读取演练和业务校验，证明归档能在目标时间重建。

综合题 38：如何比较七个案例的共同失败模式与不同取舍

38. 问题：如何比较七个案例的共同失败模式与不同取舍？

口述答案：七个案例共同面对重复、乱序、超时未知、资源耗尽、旧版本迟到、派生差异和恢复流量反噬，因此都需要稳定业务键、权威事实、状态版本、幂等、失败分类、对账、回放和停止线。但取舍由失败成本决定。库存接受缓存短时不一致和请求拒绝，不接受余额为负；支付接受用户短时处理中，不接受重复入账和分录不守恒；物流接受外部状态延迟，不接受重复建单和终态被旧轨迹倒退；导出接受排队与取消，不接受拖垮在线和交付半成品；Runner（执行器）接受重复唤醒和重复尝试，不接受旧代次副作用；IoT（物联网）报警接受普通事件聚合与延迟，不接受高危静默和误控制；多模型接受派生陈旧，不接受派生反写权威或无法删除重建。评审时我会用同一张矩阵比较权威源、硬不变量、未知态、降级对象、恢复起点和单位正确结果成本，再回到各自纵向数据模型。 例如同样是超时，支付和外仓建单都必须查单，搜索写超时则可从权威版本重放；同样是旧执行者，调度和自动控制需要资源端单调代次，普通分析任务可能只需幂等覆盖。容量也不能统一：支付按渠道配额与金额风险，报警按风暴和高危份额，导出按工作集和对象保留。跨案例抽象用于检查遗漏，不用于抹平领域差异；最终每个方案都要回答“错一次损失什么、怎样证明、何时停止、从哪里恢复”。 对比时还要保持证据等级一致，不能拿某案例的生产指标与另一个案例的演练数字直接排名。若真实材料不足，就统一使用区间、公式和故障注入结论，明确哪些判断需要日志、账单或复盘升级。

• 七个案例事实卡
• 追问 1：哪个机制最具通用性？
• 直接回答 1：稳定业务身份加权威事实最通用，它让重复、查询、对账和恢复都能围绕同一对象展开。
• 追问 2：哪个取舍不能跨项目照搬？
• 直接回答 2：降级容忍度；搜索允许陈旧不代表支付可猜结果，普通报警可延迟也不代表高危控制可延迟查证。
• 追问 3：统一平台是否能消除领域差异？
• 直接回答 3：平台可提供消息、幂等、配额和观测能力，但业务不变量、状态机和补偿仍由领域所有者定义。

综合题 39：库存出现负数事故如何从止血到复盘

39. 问题：库存出现负数事故如何从止血到复盘？

口述答案：发现负库存先按仓、商品和批次冻结新的扣减、释放与人工调整，保留只读查询和流水采集，避免修复期间继续扩大。建立受影响业务键集合，记录首次异常时间、当前余额、预占、分配、出库和所有调整流水；不要先把余额改回零。用期初加收入减支出的固定等式复算，分别检查条件更新是否缺余额判断、支付确认与到期释放是否都成功、消息重复是否导致重复扣减、波次批量是否绕过统一入口、数据脚本是否直改余额以及缓存补偿是否反向覆盖。假设某商品期初 1,000，入库 200，预占净增 700，出库 450，调整减 60，理论期末为负 10；继续下钻发现同一释放事件重复执行 20 件，则正确期末应为 10。修复不是删除重复流水，而是确认权威与实物后追加订正流水，重建余额与缓存，并逐单检查已承诺订单是否需要补货、拆单或退款。 恢复先开放低风险查询，再小流量条件扣减，跨过预占到期和波次周期后全量；停止线仍是任一负数或等式差异。复盘时间线要区分触发缺陷、潜伏条件和放大器，例如缺唯一约束是缺陷，批量重试和告警只看总库存是放大器。改进落到唯一键、状态版本、旁路账户禁写、实时守恒抽检和故障演练，最后用相同重复事件证明不再产生负数。 影响评估还要按客户承诺分层，负数十件可能对应一个热点大客户，也可能分散在十个订单，处理顺序不同。复盘前保存数据库日志、缓存版本、任务尝试和人工操作审计，避免恢复动作覆盖现场。成本不仅算补货，还算仓内返工、客服和后续对账。改进关闭前在隔离环境重放当时业务键与并发顺序，确认条件更新只能产生一个合法状态。

• WMS（仓储管理系统）线上排障与迁移
• 追问 1：为何不能立即把负数改为零？
• 直接回答 1：会抹掉差异来源，且可能与实物和订单承诺不符；应先冻结、复算和裁决，再用新流水订正。
• 追问 2：缓存为正、数据库为负信谁？
• 直接回答 2：数据库权威流水和实物证据裁决，缓存停止扣减并从修复后的权威版本重建。
• 追问 3：技术恢复后还有什么业务动作？
• 直接回答 3：核对受影响订单、仓单和客户承诺，决定补货、拆单、取消或赔付，并把处理结果纳入事故验收。

综合题 40：支付重复入账事故如何复盘并防止再发

40. 问题：支付重复入账事故如何复盘并防止再发？

口述答案：止血先按支付意图、渠道和时间范围冻结重复确认与自动补单，保留回调接收、只读查单和账务对账；若渠道仍在重发，入口验签后只记录原始事件，不再次产生分录。影响集合从渠道请求号、渠道事件号、内部支付号和账务来源号四个维度取并集，逐笔比较外部扣款次数、内部支付终态、有效分录组和下游履约。假设 50,000 笔支付中发现 12 个内部重复分录，其中 8 笔外部只扣一次、4 笔外部也扣两次；前 8 笔需要冲正内部重复分录，后 4 笔还要按渠道规则退款或争议处理，不能用同一脚本。根因分析沿时间线检查回调与主动查询并发、唯一约束是否落在错误字段、事务提交失败后重试是否换业务来源号、人工补单是否绕过入口，以及消费者确认时机。修复通过新冲正或退款事实表达，原分录和凭证不可删除。 恢复前对同一支付号重复回调、响应丢失、查询与回调并发、账务提交后进程崩溃做故障注入，确保最终只有一组有效分录。灰度恢复小额渠道，重复入账为零容忍停止线，并跨过结算周期。长期改进包括三层幂等、状态版本、账务来源唯一、人工双人审批和实时渠道至分录差异。复盘不把责任停在“消息重复”，因为消息重复可预期，真正缺陷是业务副作用没有唯一约束。 对客户通知要晚于资金裁决，不能在差异未查清时群发错误结论。大额和已触发履约的重复项优先，退款前检查是否已有拒付或冲正，避免反向动作叠加。恢复完成后将渠道、内部支付、分录和结算四个集合重新对账，并由财务确认净额。每项长期改进绑定故障用例、负责人和期限，下一次发布自动运行重复回调与响应丢失测试。

• 支付对账、差错与灾难恢复
• 追问 1：内部重复分录能直接删除一组吗？
• 直接回答 1：不能；应追加冲正并关联原来源，保留完整审计和借贷守恒，删除会破坏历史凭证。
• 追问 2：外部也重复扣款谁裁决退款？
• 直接回答 2：结合渠道凭证、合同和内部支付意图确认重复，使用独立退款业务号执行并持续对账。
• 追问 3：为什么消息去重仍不够？
• 直接回答 3：回调、查询和人工可能走不同消息或无消息路径，最终账务来源和状态迁移本身必须唯一。

综合题 41：消息积压时如何计算恢复时间并避免二次事故

41. 问题：消息积压时如何计算恢复时间并避免二次事故？

口述答案：先确认积压是什么业务对象、最老年龄和失败成本，不只看消息条数。按主题、分区、租户、渠道和错误类型分桶，识别实时新增率、有效成功吞吐、失败重入、重复空转与下游稳定能力；净消化率等于有效成功减实时新增减失败回流。假设积压 900,000 条，消费者每秒拉取 2,000，实际成功 1,500，实时新增 900，失败回流 200，净消化只有每秒 400，理论清理需 2,250 秒约 37.5 分钟；若只用拉取数计算会误报 7.5 分钟。止血先限制生产端非核心流量，隔离毒消息和无限重试，给支付确认、高危报警等核心分区保底，暂停历史回放和大任务。增加消费者前检查数据库连接、外部渠道配额、锁竞争和幂等能力，否则并发会把下游打垮并提高失败回流。恢复按 10%、25%、50% 等档位增加，每档观察最老年龄是否下降、业务差异是否扩大和资源是否越线。 消息成功处理不等于业务完成，必须用订单、分录、仓单、通知或投影水位验收。积压清零后继续观察迟到重试和死信，回放毒消息使用原事件号并隔离副作用。复盘要问为什么入口没有背压、失败分类为何无效、保留期是否覆盖恢复、容量为何只测正常流量，并更新队列预算与停止线。 若积压涉及顺序业务，不能为了吞吐随意跨业务键并行；同一订单、支付或设备保持局部顺序，不同键再扩并发。恢复期间记录每档并发对应的成功、重入和下游水位，形成下一次容量基线。对超过业务最大年龄的消息不直接丢弃，而是转差错或人工并保留原因。最终用业务对账确认积压期间没有漏订单、漏分录或漏高危通知。

• Runner（执行器）积压容量与渐进恢复
• 追问 1：直接增加分区一定能提速吗？
• 直接回答 1：不一定；顺序键、下游容量和热点可能限制并行，重新分区还会改变顺序与迁移成本。
• 追问 2：最老年龄下降但总量上升说明什么？
• 直接回答 2：可能旧消息在清理但新流量增长更快，要同时看新增、完成、年龄分布和业务优先级，不能单指标判断。
• 追问 3：毒消息应如何处理？
• 直接回答 3：保存原载荷、错误、版本和业务键到隔离区，修复后按原身份回放；不能无限阻塞主分区或静默丢弃。

综合题 42：如何在成本与 SLO（服务等级目标）之间做可解释取舍

42. 问题：如何在成本与 SLO（服务等级目标）之间做可解释取舍？

口述答案：我会先把 SLO（服务等级目标）按业务结果拆开，而不是为整个系统设一个可用率。支付确认、库存裁决和高危控制有硬正确性红线；搜索新鲜度、普通报警通知、导出完成时间和分析报表可以定义不同延迟目标与降级。然后建立每档目标对应的容量、冗余、保留、恢复和人工成本，并以正确闭环结果为分母。假设方案甲基础成本每月 80,000 元，正确闭环 1,990,000 次，事故与人工 20,000 元，单位成本约 0.0503 元；方案乙基础 92,000 元，正确闭环 1,998,000 次，事故与人工 4,000 元，单位成本约 0.0480 元。乙账单更高但总成本更低，说明不能只砍基础资源。错误预算用于管理时延和可用性变更速度，不能允许少量重复入账、超卖或高危误控制。成本优化优先清理无用副本、过度保留、低价值查询和失败空转，再评估降低冗余；任何削减都用故障演练验证恢复目标。 对业务展示边际成本，例如搜索新鲜度从五秒降到一秒需要多少写入与节点，导出从两小时降到十分钟需要多少并发且会否影响在线，由业务选择价值。预算越线时按预先定义顺序暂停历史回放、普通异步和低价值查询，保住核心事实。季度复审目标与真实使用，避免为已消失场景永久付费，也避免降本把事故成本转给客服和人工。 还要做目标降档演练，例如把普通搜索新鲜度从一秒放宽到十秒，确认节省了多少写入与节点、用户是否能看到截止水位、关键命令是否仍回源。若节省只占总成本 2%，却增加权限陈旧风险，就不值得实施。反过来，延长关键原始事件保留虽增加存储，却可能显著降低事故无法回放的损失。

• 多模型容量、成本与冷热分层
• 追问 1：可用率更高为什么成本可能更低？
• 直接回答 1：更少差错、重试、人工和赔付可能抵消冗余资源，必须看全成本和正确结果分母。
• 追问 2：错误预算耗尽后做什么？
• 直接回答 2：冻结高风险变更，优先可靠性改进和容量修复；硬不变量事件无论预算是否耗尽都立即止血。
• 追问 3：如何防止业务无限提高目标？
• 直接回答 3：展示每档目标的边际成本、失败损失和实现证据，由业务与技术共同签署，目标定期按真实价值复审。

综合题 43：如何制定并验证恢复时间和恢复点目标

43. 问题：如何制定并验证恢复时间和恢复点目标？

口述答案：我会从业务损失反推，而不是照抄统一数字。恢复时间目标回答从故障到核心业务重新可用允许多久，恢复点目标回答最多允许丢失到哪个时间点；支付分录、库存流水等已确认事实通常要求通过同步日志或可重放记录把数据丢失降到极低，搜索索引则可接受从权威源重建。先列每类数据的权威、备份频率、事务日志保留、外部凭证、依赖恢复顺序和人工能力，再计算备份恢复、日志重放、差异对账、服务启动和灰度开放的总时间。假设数据库恢复备份 25 分钟、日志重放 15 分钟、业务对账 20 分钟、灰度观察 10 分钟，端到端至少 70 分钟，不能只报数据库 25 分钟；若目标是 45 分钟，就要并行对账、缩小数据集或改进备份，而不是改文档数字。恢复点也要用故障切断验证：随机抽取故障前后的支付、库存和删除事件，确认已承诺事实没有丢失，允许重建的派生能从明确位点追平。 演练同时切断一个依赖，避免所有系统完好时的表演式恢复；记录人员发现、授权和操作时间，因为人工等待也属于目标。恢复后业务差异归零和观察窗稳定才算完成，服务端口打开不是终点。目标每季度按数据增长和人员变化复测，超时项进入技术债和容量计划。 对多区域或多渠道系统还要明确故障切换会不会产生双主，恢复时间不能以牺牲事实唯一为代价。演练时记录从最后一个正常业务键到第一个恢复业务键的连续性，并抽查故障窗口内所有大额、负库存和删除动作。若恢复后需要三小时人工对账，这三小时也属于完整业务恢复，不应从报告中剔除。改进完成后用相同数据规模重演，证明目标来自实测而非资源估算。

• 支付对账与灾难恢复
• 追问 1：备份每天一次是否意味着恢复点为一天？
• 直接回答 1：不一定；若有完整事务日志和外部凭证可重放，恢复点可更近，但必须演练证明日志连续、可读且能对账。
• 追问 2：搜索索引恢复点可以为零吗？
• 直接回答 2：索引本身可丢弃重建，但权威快照与事件流不能有缺口；目标应描述可见陈旧和重建时间，而非索引持久性。
• 追问 3：恢复演练为何要包含人工时间？
• 直接回答 3：真实事故需要发现、授权、取密钥和决策，忽略这些只得到工具执行时间，无法兑现业务恢复承诺。

综合题 44：如何回答方案中最重要的架构取舍

44. 问题：如何回答方案中最重要的架构取舍？

口述答案：我会用“保什么、放弃什么、为什么、如何验证”回答，而不是罗列组件。跨案例最重要的取舍是接受传输和执行层的重复、延迟与局部不可用，换取业务事实唯一、可查证和可恢复。库存允许缓存短时不准与请求保守失败，但由数据库条件更新守住余额；支付允许未知态等待，但不猜渠道结果；物流允许轨迹迟到，但保留原始事件和终态保护；导出允许排队，但隔离在线资源；Runner（执行器）允许重复领取，但资源端拒绝旧代次；报警允许普通流量聚合，但高危有关键通道；多模型允许派生陈旧，但只能从权威单向重建。这样做的代价是需要业务键、流水、状态机、对账、回放、人工工作台和更多存储，不是免费一致性。 我还会说明为什么没选另一条路。例如不追求跨所有系统强同步事务，因为外部渠道和长任务无法可靠参与，会扩大阻塞与耦合；也不选择“全部最终一致”口号，因为资金与库存仍需本地强不变量和明确时限。验证通过故障注入：重复、超时、乱序、旧执行者、回放和回滚都应得到唯一可解释结果。容量与成本用演练公式展示，真实数字不足就明确待核对。最后给出边界：若业务不能接受处理中、人工或短时降级，就必须增加同步能力、冗余和预算，不能靠架构术语消除物理约束。 面试表达还会补一组反例：若追求同步成功而把外部调用放进长事务，锁与未知态会互相放大；若只追求可用而异步一切，用户可能看到成功却没有资金或库存事实。我的选择是在本地权威边界内强约束，边界外用可查证状态和补偿收敛。取舍不是固定答案，依赖外部幂等、损失上界和业务等待容忍度，条件变化就重新评审。

• 案例事实卡与方案合同
• 追问 1：最终一致是不是降低正确性？
• 直接回答 1：不是；权威本地不变量仍强保证，派生在明确窗口内收敛，超时进入故障与恢复，不是无限等待。
• 追问 2：为什么不用更多缓存提升可用性？
• 直接回答 2：缓存可提升读取和削峰，但不能在权威不可用时猜资金库存结果；增加缓存也增加版本和恢复成本。
• 追问 3：取舍如何获得业务认可？
• 直接回答 3：把每种降级的用户影响、持续时间、成本和失败上界量化，由业务签署优先级并在演练中验证。

综合题 45：如何用五分钟完成架构案例库总述

45. 问题：如何用五分钟完成架构案例库总述？

口述答案：我会先用一句话定主线：这些方案都在不可靠网络、外部系统和异步执行下，用权威事实、稳定身份和可恢复流程保证关键业务结果。第一分钟讲评审方法，先确认目标、量级、硬不变量、权威源和失败成本，缺证据只做可逆试验；结论带范围、停止线和回退。第二分钟串订单主链：WMS（仓储管理系统）用条件更新与流水守住库存，支付用渠道凭证和分录守住资金，跨境履约用稳定业务号、查单和原始轨迹吸收未知与乱序。第三分钟讲异步与突发：导出以快照、稳定分片和流式生成隔离在线，Runner（执行器）以任务账、租约与单调代次阻止旧执行者，IoT（物联网）报警以四本账、关键通道和规则回放保证高危不漏。第四分钟讲数据与迁移：交易源唯一裁决，搜索、分析和时序按版本派生；迁移用快照加增量、单主传播、双读对账和按风险单元切换，回放默认隔离真实副作用。第五分钟讲事故与取舍：超时进入未知，回滚代码不抹业务事实，恢复看净消化率和业务差异，成本按正确闭环结果计算。 我会主动说明哪些是直接经历、哪些是已有材料映射、哪些数字仅为演练，避免把候选架构包装成生产成果。收尾给出共同边界：接受消息重复、查询陈旧、普通任务延迟和人工接管，不接受资金重复、库存超卖、高危静默、旧代次生效和派生反写权威。若面试官选一个点追问，就立即进入对应纵向章节的数据模型、失败矩阵、演绎和恢复证据，而不是继续背总述。

• 架构案例库总索引
• 追问 1：五分钟里最不该省略什么？
• 直接回答 1：硬不变量、最难失败和恢复证据；只讲正常架构和技术栈无法体现高级方案能力。
• 追问 2：面试官质疑数字真实性怎么办？
• 直接回答 2：明确演练边界，给出公式、所需生产日志和验证门禁；没有证据就不把推导数字说成线上结果。
• 追问 3：如何根据岗位调整总述？
• 直接回答 3：支付岗位加深资金与对账，物流岗位加深未知态与轨迹，平台岗位加深调度、隔离和迁移，但共同方法保持不变。

14. 本章复习与验收清单

• 能在没有架构图的情况下先讲清目标、约束、权威事实和否决项。
• 能区分确定失败、结果未知、确定成功和主成功但派生失败。
• 能解释失败域、核心保底、恢复净消化率和停止线。
• 能说明代码回滚、业务补偿、数据订正和派生重建的不同。
• 能画出影子、双读、单主切写、快照加增量和旧链退出路线。
• 能分别串讲库存、支付、物流、异步导出、Runner（执行器）、IoT（物联网）报警和多模型数据。
• 能用业务集合差异验收恢复，而不是只看服务与队列指标。
• 能用单位正确结果成本解释 SLO（服务等级目标）与预算取舍。
• 能做一场包含影响、时间线、放大器、止血、恢复和长期改进的事故复盘。
• 能在五分钟总述后，沿真实相对链接回到任一纵向案例深挖。