一致性、可用性、容量与成本权衡高频追问

本册训练架构师把“一致性还是可用性、同步还是异步、扩容还是降级”从偏好题改成约束题：先守业务不变量，再识别分区与失败语义，随后用容量和成本数据计算，最后通过降级、补偿、预算和分治形成可验证方案。架构原则承接质量属性权衡、失败成本与风险，容量口径承接容量排队与资源模型，项目事实以项目串讲事实卡为边界。

PlantUML（开源建模工具）图解读： 决策起点不是技术名词，而是业务不变量和失败成本。资金、库存、不可逆履约优先查证与收敛；可延迟工作则可排队和降级。随后把故障后有效容量、恢复净速度、建设运行成本与失败损失放在同一模型中，任何一项越界都回到目标和边界重新裁剪。

一、CAP（一致性、可用性、分区容错）的真实裁决

1. 分区发生时按业务动作选择一致性或可用性

热门面试题

1. 问题（基础题）：CAP（一致性、可用性、分区容错）为什么不是“三选二”的静态标签？

   • 考点：网络分区、读写动作、业务语义与局部决策。
   • 回答思路：先说明分区是分布式系统必须处理的故障，再按具体操作裁决拒绝、降级或接受旧值。
   • 详细答案：正常网络下系统可以同时提供较好的一致性和可用性，真正冲突发生在节点之间无法确认彼此状态时。此时不是给整个系统贴标签，而是对每个业务动作选择：库存扣减和支付确认若无法确认权威状态，应拒绝或进入未知态；商品说明和历史轨迹可返回带版本与时间戳的旧值。架构师要写明分区识别信号、请求结果、恢复后的冲突处理和用户可见语义。
   • 进阶追问：超时就能证明发生了网络分区吗？
   • 进阶回答：不能。超时只能说明在期限内没有结果，可能来自排队、停顿、依赖变慢或请求已成功但响应丢失；涉及副作用时必须先查证，不能把超时直接当失败重做。

2. 问题（原理题）：为什么支付确认通常偏向一致性，而商品查询可以偏向可用性？

   • 考点：不可逆副作用、陈旧读取、损失不对称。
   • 回答思路：比较“错误回答”和“暂时不回答”的失败成本。
   • 详细答案：支付确认若在未知状态下再次扣款，会造成双扣、错账和对账压力，错误成功的成本远高于短暂等待，因此需要稳定业务键、渠道查单、状态机和账务核对。商品查询返回几秒前的数据通常只影响体验，可通过版本、更新时间和兜底文案控制风险。选择依据不是技术先进程度，而是每个动作在错、慢、停三种情况下的损失。
   • 进阶追问：库存查询是否也能返回旧值？
   • 进阶回答：展示库存可近似，但下单承诺必须回到权威预占；读路径可用性不能越过写路径的不超卖不变量。

3. 问题（项目题）：WMS（仓储管理系统）仓库网络中断时怎样裁决出库动作？

   • 考点：边缘可用、库存权威、离线额度与恢复对账。
   • 回答思路：按不可逆程度分层，核心扣减保守，扫描与草稿可离线。
   • 详细答案：仓内扫描、称重和装箱草稿可以在本地记录稳定业务键、设备时间与操作人，恢复后按序上送；真正改变跨渠道可售量或确认出库的动作必须依赖可验证授权。若业务确需离线作业，可下发有上限、可过期、按仓隔离的离线额度，并保留消耗流水。网络恢复后先合并事件、检查重复和越界，再更新中心状态，不能简单以最后一次写入覆盖。
   • 进阶追问：离线额度如何避免被多个设备重复消费？
   • 进阶回答：按仓、设备或作业单切分不可重叠额度，使用单调序号和一次性凭证；发现缺口立即冻结剩余额度并进入人工核对。

flowchart LR
    A[业务请求] --> B{节点间状态能否确认}
    B -- 能 --> C[按正常一致性协议处理]
    B -- 不能 --> D{错误结果是否不可逆}
    D -- 是 --> E[拒绝或进入未知态]
    E --> F[查证 对账 补偿]
    D -- 否 --> G[返回有版本的旧值或降级结果]
    F --> H[恢复后收敛]
    G --> H

Mermaid（图表语法）图解读： 分区只触发裁决，不自动给出答案。不可逆动作走拒绝、未知态和查证；可容忍陈旧的数据走版本化降级。两条路径都必须在恢复后收敛，不能把临时可用变成永久分叉。

数据演绎 1：分区期间的库存损失边界。 E3（演练证据）设单仓某货品可售 1,000 件，中心与仓内终端中断 20 分钟，线上每分钟平均下单 30 件，仓内每分钟平均出库 20 件。若两边都无约束继续扣减，理论竞争量为 1,000 件，任何波动都可能超卖；若提前给仓内 200 件独立离线额度，线上权威侧只暴露 800 件，则两侧最大承诺仍为 1,000 件。恢复时核对额度消耗序号、线上预占流水和取消释放，差异未清零前不回补可售量。

二、BASE（基本可用、软状态、最终一致）与收敛证明

2. 最终一致必须回答状态如何、何时、由谁收敛

热门面试题

1. 问题（基础题）：BASE（基本可用、软状态、最终一致）是不是允许数据长期不一致？

   • 考点：软状态、收敛窗口、补偿责任与证据。
   • 回答思路：区分允许暂时不同与允许无人负责。
   • 详细答案：最终一致允许状态在传播和处理期间暂时不同，但必须定义稳定业务键、状态偏序、最大收敛窗口、重试与补偿方式、对账频率和人工接管条件。软状态意味着中间态会随消息、查单或补偿变化，不意味着结果可以猜测。没有收敛期限、观测指标和责任人的“最终一致”只是把错误推迟暴露。
   • 进阶追问：如何证明已经最终一致？
   • 进阶回答：用权威事实与各投影按业务键核对，验证差异数量、最长年龄和终态摘要均在门禁内，并保留重放水位与修复记录。

2. 问题（原理题）：状态机为什么比“失败后重试”更重要？

   • 考点：状态偏序、重复乱序、未知态和非法跃迁。
   • 回答思路：说明重试只是传输动作，状态机才决定业务能否接受该结果。
   • 详细答案：消息可能重复、乱序、延迟，外部调用也可能成功但响应丢失。若只做重试，旧消息可能覆盖终态，重复调用可能再次产生副作用。状态机为每个状态定义允许的前驱、版本和副作用条件，例如支付从处理中进入成功后不得被迟到的失败通知回退；履约取消到达时若已出库，则必须转售后流程。重试必须受状态机、幂等键和查证结果约束。
   • 进阶追问：状态越多越好吗？
   • 进阶回答：不是。只保留业务裁决需要区分的状态；纯技术细节进入事件与指标，避免状态爆炸造成无法维护的迁移规则。

3. 问题（项目题）：异步导出如何实现可验证的最终一致？

   • 考点：任务状态、快照、分片、结果交付与过期。
   • 回答思路：从提交、执行、合并、交付、过期五段说明。
   • 详细答案：提交时固化筛选条件、权限摘要和快照时点，生成稳定任务键；执行器按分片处理并记录水位、摘要和重试次数；所有分片完成后才合并文件，文件校验成功后再把任务切到可下载。通知失败不回退文件状态，用户可从任务中心查取；超过收敛窗口的任务进入补偿或人工清单。删除文件前先改变可见状态并等待安全窗口，避免状态显示成功但对象已不存在。
   • 进阶追问：某个分片永久失败怎么办？
   • 进阶回答：达到重试上限后冻结任务，展示失败范围和可重跑入口；若允许部分结果，必须在需求阶段明确并在文件中标注缺失分片，不能默认悄悄交付。

stateDiagram-v2
    [*] --> 已提交
    已提交 --> 执行中
    执行中 --> 合并中: 全部分片完成
    执行中 --> 待补偿: 超时或重试耗尽
    待补偿 --> 执行中: 修复后重放
    合并中 --> 可交付: 摘要校验通过
    合并中 --> 待补偿: 校验失败
    可交付 --> 已过期: 超过保留窗口
    已过期 --> [*]

Mermaid（图表语法）图解读： 最终一致通过状态偏序落地。正常路径从提交推进到可交付，任何超时和校验失败都进入可观测补偿态；只有修复证据充分才允许重放，终态不会被旧事件随意覆盖。

数据演绎 2：用差异年龄验证收敛。 E3（演练证据）设每日 60,000 个导出分片，首次成功率 99.5%，即约 300 个需重试；二次修复 90%，剩 30 个进入补偿。若补偿处理能力每分钟 10 个，且没有新增失败，3 分钟可清空；若高峰每分钟新增 15 个失败，则队列每分钟净增 5 个，系统永远无法“最终”收敛。容量评审因此必须同时比较失败产生率和补偿完成率，并对最老差异超过 15 分钟告警。

三、强一致与最终一致的分层组合

3. 以业务不变量划定强一致核心与异步投影

热门面试题

1. 问题（基础题）：强一致和最终一致如何在同一业务中组合？

   • 考点：权威写模型、派生读模型、事务边界和异步传播。
   • 回答思路：把不能错的最小事实放在强一致边界，把可重建投影放到异步链路。
   • 详细答案：订单受理、库存预占流水和账务分录等决定承诺的事实应在最小事务边界内原子落库；搜索索引、统计报表、通知和轨迹视图是可由权威事实重建的投影，可以异步更新。这样既保护业务不变量，又避免把所有依赖拉进长事务。投影必须携带业务键、版本和事件时间，并提供延迟指标、重放与对账能力。
   • 进阶追问：为什么不把所有系统都做强一致？
   • 进阶回答：跨网络长事务会放大锁持有、超时、协调故障和不可用范围；很多派生结果并不值得支付同等成本，关键是证明它可重建且陈旧窗口可接受。

2. 问题（原理题）：怎样判断某个字段是权威事实还是派生投影？

   • 考点：数据所有权、重建能力、冲突裁决。
   • 回答思路：问谁能创建和更改、丢失后能否从其他事实重算、冲突时听谁。
   • 详细答案：权威事实有唯一拥有者和明确变更命令，冲突时它提供最终裁决；派生投影由一个或多个事实计算，允许删除后重建。比如支付渠道回执与账务分录是关键证据，支付成功统计是投影；库存流水是权威变化记录，可售查询缓存是投影。若多个系统都能直接改同一字段，就不是高可用，而是数据所有权缺失。
   • 进阶追问：权威源故障时可以临时改投影吗？
   • 进阶回答：不能把投影提升为权威写源；可进入只读、排队或有界离线模式，恢复后仍由权威命令和流水裁决。

3. 问题（项目题）：支付、履约、通知三段链路如何分配一致性等级？

   • 考点：资金正确性、履约幂等、通知可重试。
   • 回答思路：按副作用不可逆程度逐层放宽。
   • 详细答案：支付意图、渠道结果和账务分录必须可查证、可对账，不能因超时猜成功；履约创建允许异步，但同一订单只能产生一个有效履约意图，调用外部仓前要有稳定业务键和状态机；通知属于派生体验，可多次重试并在耗尽后转人工或任务中心查询。三段都关联同一业务键，但拥有各自状态与恢复责任，不能用一个全局事务锁住所有步骤。
   • 进阶追问：通知没发出，订单算成功吗？
   • 进阶回答：业务核心可成功，但交付体验未完成；应分开记录业务成功率和通知成功率，并给用户可查询结果，不把通知失败回滚资金或履约。

flowchart LR
    A[业务命令] --> B[最小强一致事务]
    B --> C[权威事实与流水]
    C --> D[异步事件]
    D --> E[履约投影]
    D --> F[查询投影]
    D --> G[通知投影]
    E --> H[对账与重建]
    F --> H
    G --> H
    H --> C

Mermaid（图表语法）图解读： 强一致只覆盖决定承诺的最小事实，异步事件驱动多个可重建投影。对账链路从投影回看权威事实，发现差异后重建而不是双向随意覆盖。

数据演绎 3：缩小强一致边界的吞吐收益。 E3（演练证据）设支付核心事务平均 40 毫秒，若同步等待履约 180 毫秒和通知 80 毫秒，单线程理论每秒只能完成约 3 次，并长时间占用连接；把核心事务收敛到 40 毫秒后，单线程理论上限约 25 次，履约和通知分别由有界消费者处理。若履约峰值每秒 200 次、消费者有效能力每秒 240 次，则有恢复余量；任何阶段能力低于到达率都必须限流或扩容，不能靠异步名称掩盖积压。

四、同步、异步与背压裁决

4. 用时效、结果依赖和失败语义选择调用方式

热门面试题

1. 问题（基础题）：同步和异步的选择标准是什么？

   • 考点：用户时效、结果依赖、可排队性和恢复责任。
   • 回答思路：先问调用方是否必须立即依据结果继续，再判断工作能否排队与补偿。
   • 详细答案：登录校验、库存承诺等后续动作依赖即时结论，通常同步返回明确成功、拒绝或处理中；报表生成、轨迹刷新和批量通知耗时长且可延迟，适合异步。异步不是性能开关，它引入任务状态、幂等、顺序、积压、重试、取消和结果交付责任；同步也必须有超时预算、并发上限和未知态处理。最终选择由业务时限与失败语义决定。
   • 进阶追问：把接口改成返回任务编号就算异步化完成吗？
   • 进阶回答：不算。还需任务权威状态、队列容量、消费者隔离、重试与死信、查询与通知、取消和过期、对账与人工接管。

2. 问题（原理题）：异步系统为什么必须有背压？

   • 考点：到达率、完成率、有界队列与过载扩散。
   • 回答思路：说明队列只能平滑短峰，无法消除长期能力缺口。
   • 详细答案：当到达率持续高于完成率，积压按两者差值线性增长，随后占满磁盘、内存或保留期，并把过期任务和重试压力反灌上游。背压通过入口限额、租户配额、任务大小限制、优先级、拒绝和预约，把负载控制在可恢复范围。消费者扩容前还要核对数据库连接、外部限额和写入能力，避免只把瓶颈向后移动。
   • 进阶追问：队列很长但业务没投诉，可以不处理吗？
   • 进阶回答：要看最老任务年龄和业务截止时间；深度本身缺少量纲，年龄越界说明承诺已失败，即使投诉尚未到达也要降载或扩容。

3. 问题（项目题）：IoT（物联网）报警风暴为什么不能全部同步推送？

   • 考点：窗口聚合、优先级、背压和安全告警保护。
   • 回答思路：区分原始事件留存、告警判定和通知交付三条链路。
   • 详细答案：设备抖动可能在短时间产生大量重复事件，若每条都同步推送，通知通道先饱和，真正高危告警反而延迟。入口应快速记录原始事件和设备序号，按设备、规则与时间窗聚合去重；告警引擎依据严重级别进入不同优先队列，高危事件保留独立容量，普通事件可合并或延迟。通知失败不丢原始证据，恢复后按最新有效状态补发并抑制过期重复。
   • 进阶追问：聚合会不会漏掉瞬时高危事件？
   • 进阶回答：高危规则走旁路立即判定，聚合只减少重复通知；原始事件仍保留，规则版本和窗口结果必须可审计。

flowchart LR
    A[请求或事件] --> B{是否必须即时依赖结果}
    B -- 是 --> C[同步调用]
    C --> D[超时预算与并发上限]
    B -- 否 --> E[异步队列]
    E --> F[配额 优先级 有界积压]
    F --> G{完成率是否高于到达率}
    G -- 否 --> H[背压 降级 扩容]
    G -- 是 --> I[按时交付]

Mermaid（图表语法）图解读： 是否依赖即时结果决定第一层选择；进入异步后还要持续验证完成率。只要净消化能力为负，就必须通过背压、降级或扩容恢复，而不是继续无限接收。

数据演绎 4：异步队列只能吸收短峰。 E3（演练证据）设报警入口峰值每秒 5,000 条，窗口聚合后进入处理队列每秒 800 条，消费者能力每秒 1,000 条，峰值持续 10 分钟，则每秒净消化 200 条，峰值期无新增积压。若聚合失效导致每秒 1,400 条进入队列，则每秒积压 400 条，10 分钟新增 240,000 条；峰值结束后入口降到每秒 300 条，净消化每秒 700 条，约 343 秒清空。告警要同时看积压年龄、高危队列隔离和恢复时间。

五、容量估算与故障后恢复能力

5. 从业务峰值推导实例、存储、队列与安全余量

热门面试题

1. 问题（基础题）：容量估算为什么不能只看日均请求量？

   • 考点：峰值窗口、热点、写放大、故障余量和增长。
   • 回答思路：从业务事件换算峰值到达率，再逐层计算放大和有效能力。
   • 详细答案：日均会掩盖活动、截单、盘点和设备风暴。容量模型至少需要典型峰值、极端峰值、持续时间、单请求读写次数、对象大小、热点比例、重试率和未来增长；有效能力要以满足时延和正确性目标的成功完成量计算。最后扣除一个故障域，确认关键流量仍可完成，非关键流量有明确降级。
   • 进阶追问：没有历史峰值数据怎么办？
   • 进阶回答：用订单计划、设备规模、上游限额和日志区间建立低中高三档假设，标明证据等级，再用回放和压测逐步校准。

2. 问题（原理题）：为什么恢复能力必须进入容量模型？

   • 考点：积压斜率、净消化能力与恢复时间。
   • 回答思路：正常能扛住不代表故障后能清债。
   • 详细答案：故障或限速期间会积累任务，恢复后如果完成率只等于新到达率，历史积压永远不会下降。模型应计算积压量除以“恢复完成率减正常到达率”，得到理论清空时间，再考虑重试、热点和依赖限额。对于支付查单、履约创建和报警处理，恢复窗口本身就是业务承诺，必须预留额外吞吐或分时降载。
   • 进阶追问：恢复时把消费者全部拉满可以吗？
   • 进阶回答：必须受数据库、外部通道和下游写入上限约束；盲目拉满会触发新一轮超时和重试，应阶梯提速并监测成功完成率。

3. 问题（项目题）：百万行异步导出怎样做容量估算？

   • 考点：行宽、快照读取、分片、文件膨胀与并发隔离。
   • 回答思路：分别估算读取量、内存上限、临时磁盘、网络和交付时限。
   • 详细答案：先用平均与高分位行宽估算原始数据，再乘编码、转义和压缩系数；按数据库允许的扫描速度和业务交付时限确定分片数，单分片采用流式读取和有界缓冲，不能把整表装入内存。并发任务要乘总连接、临时磁盘和出口带宽，在线交易保留独立资源池。最终以文件摘要、行数和快照水位验收。
   • 进阶追问：分片越多是否越快？
   • 进阶回答：不是。分片增加调度、连接、合并和热点竞争；应在数据库与存储可承受范围内压测寻找有效并行度。

flowchart TB
    A[业务峰值与持续时间] --> B[请求放大与对象大小]
    B --> C[应用有效完成率]
    B --> D[数据库与外部依赖上限]
    B --> E[存储 网络 队列需求]
    C --> F[扣除一个故障域]
    D --> F
    E --> F
    F --> G{关键流量仍可完成}
    G -- 否 --> H[扩容 限流 分片 降级]
    G -- 是 --> I[压测和恢复演练]

Mermaid（图表语法）图解读： 容量由业务峰值向每一层放大，并由最弱依赖决定上限。扣除故障域后仍能完成关键流量只是设计门槛，最终还需压测与恢复演练校准。

数据演绎 5：导出容量从行宽开始。 E3（演练证据）设单任务 1,000,000 行，平均原始行宽 600 字节，格式化后膨胀 1.4 倍，压缩比 50%，最终文件约 420,000,000 字节；生成期间原始分片、合并文件和安全余量按最终文件 3 倍估算，单任务临时空间约 1.26 吉字节。若并发 20 个任务，至少需要约 25.2 吉字节临时空间，尚未计失败残片。读取能力每秒 25,000 行时单任务纯读取约 40 秒，但数据库只允许 5 个并发扫描，因此调度必须分批而不是同时开 20 路。

六、成本模型、预算与失败成本

6. 把建设、运行、变更、失败和退出放进同一账本

热门面试题

1. 问题（基础题）：架构成本为什么不能只看机器账单？

   • 考点：全生命周期成本、人力、风险、退出与机会成本。
   • 回答思路：统一时间窗口，列出显性费用和隐性损失。
   • 详细答案：机器只是运行成本的一部分。完整模型还应包含研发与迁移、许可证、网络和备份、值班与升级、合规审计、故障恢复、客诉赔付、供应商锁定、数据迁出和退役。对于低频高损的支付错账或库存超卖，失败成本可能远高于常态资源费；对于可延迟导出，过度冗余又会长期浪费。模型要给出基准、乐观、悲观区间与敏感变量。
   • 进阶追问：概率无法准确估计，失败成本还能算吗？
   • 进阶回答：可以用影响上下界和情景频次做敏感性分析，目标是识别结论在哪个阈值反转，而不是伪造精确概率。

2. 问题（原理题）：预算如何影响一致性和可用性设计？

   • 考点：资源冗余、工程复杂度、风险容忍与目标裁剪。
   • 回答思路：预算不足时重排业务优先级，不能平均削减所有保护。
   • 详细答案：强一致、多地冗余、实时对账和全天值守都需要资源与工程投入。预算有限时先保护不可逆、高损失不变量，把非关键查询改为陈旧可读，把报表和导出改为预约或排队，把低价值数据缩短保留期；同时明确被放宽的时效和可用性承诺。不能在不修改承诺的情况下静默减少容量或恢复能力，否则只是把成本转成事故债务。
   • 进阶追问：如何向业务说明“更便宜”的代价？
   • 进阶回答：把每个降本动作映射到可见结果、最大影响窗口、恢复方式和预计节省，要求业务对新边界确认并设置回滚阈值。

3. 问题（项目题）：IoT（物联网）原始事件保留多久怎样决策？

   • 考点：存储成本、审计价值、聚合层级和删除风险。
   • 回答思路：按事件价值和查询概率分层保留，而不是统一无限保存。
   • 详细答案：高危安全事件和事故证据需要更长保留并防篡改，普通心跳可在短期原始保留后转为分钟或小时聚合；设备配置变更要与告警关联保留。模型输入包括每日事件量、压缩比、冷热存储单价、查询频次、法规和事故回溯窗口。删除前验证聚合完整性、保留策略和恢复例外，避免降本破坏调查证据。
   • 进阶追问：冷热分层一定更便宜吗？
   • 进阶回答：要计入迁移、检索、取回流量和运维成本；若频繁回查，低存储单价可能被取回费用抵消。

flowchart LR
    A[候选方案] --> B[建设与迁移成本]
    B --> C[运行与人力成本]
    C --> D[变更与合规成本]
    D --> E[失败损失区间]
    E --> F[退出与退役成本]
    F --> G{预算和风险均可接受}
    G -- 否 --> H[裁剪目标或更换方案]
    G -- 是 --> I[设单位成本与重审阈值]

Mermaid（图表语法）图解读： 成本评审沿生命周期推进，失败和退出不能藏在脚注。若预算或风险任一不可接受，就应裁剪目标或更换方案；通过后仍需用单位业务成本和阈值持续重审。

数据演绎 6：预算削减不能只砍冗余。 E3（演练证据）设当前月运行费 60 万元，其中核心交易 30 万元、查询与报表 18 万元、长期存储 12 万元，目标节省 10 万元。若直接减少核心交易三分之一容量，单故障域后有效能力将从峰值的 1.25 倍降到 0.83 倍；更合理的组合是报表预约和错峰节省 4 万元、普通事件分层保留节省 3 万元、低命中缓存缩容节省 2 万元、闲置测试环境定时回收节省 1 万元，同时保持资金和库存故障余量。

七、降级、错误预算与失败止损

7. 降级必须保护核心不变量并提供恢复路径

热门面试题

1. 问题（基础题）：什么是合格的降级方案？

   • 考点：核心路径、触发条件、用户语义、恢复与补偿。
   • 回答思路：说明降级不是统一返回成功，而是主动收缩能力边界。
   • 详细答案：合格降级先声明保什么、停什么、谁触发、何时恢复。支付渠道不可用时可暂停新支付并允许查单，不能伪造成功；WMS（仓储管理系统）高峰可关闭低优先报表、限制大批量导出，保留库存扣减和出库指令。每项降级要有入口开关、容量收益估算、用户提示、数据补偿和恢复验收，且定期演练权限与依赖。
   • 进阶追问：降级开关越多越好吗？
   • 进阶回答：不是。开关过多会组合爆炸和误操作，应按业务能力分层、默认安全、可审计，并通过预案和演练证明实际有效。

2. 问题（原理题）：错误预算如何连接可用性与研发节奏？

   • 考点：目标窗口、允许失败量、发布门禁和风险消费。
   • 回答思路：把可用性目标转成窗口内可消费的失败额度。
   • 详细答案：先按用户可感知结果定义目标，例如订单受理成功而非单个接口健康；再计算统计窗口内允许失败的请求或分钟数。预算充足时可进行受控变更和试验，消耗过快时冻结高风险发布、优先修复和演练。错误预算不是故意制造故障的额度，也不能覆盖资金错账等正确性红线；后者即使请求比例很小也可能零容忍。
   • 进阶追问：低流量系统怎样使用错误预算？
   • 进阶回答：结合事件次数、影响时长和关键业务样本，不机械套百分比；小样本下应使用更长窗口并保留正确性门禁。

3. 问题（项目题）：跨境履约外部承运商限速时如何降级？

   • 考点：入口配额、优先级、预约、状态透明和恢复追赶。
   • 回答思路：保护截单和高价值订单，非紧急请求排队并给出可查询状态。
   • 详细答案：先按承运商、服务等级和截单时间分队列，给临近截单和高优先订单保留独立配额；批量轨迹刷新、历史补录和低优先面单延后。入口按下游明确限额接收，超出部分预约而非无界重试。恢复后按截止时间和积压年龄追赶，核对同一履约意图只创建一个有效面单，并向运营展示受影响订单与预计恢复时间。
   • 进阶追问：承运商完全不可用时是否自动切换？
   • 进阶回答：只有业务规则、价格、线路、标签和幂等语义都预先验证的订单才能切换；否则进入待决策队列，避免自动产生错误履约和额外费用。

flowchart LR
    A[业务与技术信号] --> B{是否越过降级门槛}
    B -- 否 --> C[正常服务]
    B -- 是 --> D[冻结非关键变更]
    D --> E[保留资金 库存 高危告警]
    D --> F[限流 排队 关闭低优先能力]
    E --> G[监测不变量与容量]
    F --> G
    G --> H{恢复门槛满足}
    H -- 否 --> D
    H -- 是 --> I[分批恢复 补偿 对账]

Mermaid（图表语法）图解读： 降级从越界信号触发，先冻结额外风险，再按优先级保留核心能力。恢复不是直接全开，而是分批恢复、补偿和对账，直到不变量与容量同时稳定。

数据演绎 7：降级收益必须可计算。 E3（演练证据）设履约系统峰值每秒 600 个请求，其中面单创建 180、轨迹查询 300、历史补录 120；外部承运商限额降到每秒 220。若全部公平竞争，关键面单会大量超时。降级后为面单保留每秒 190 的配额，轨迹查询限制到每秒 20 并优先缓存，历史补录暂停，总量降到每秒 210，留出每秒 10 的抖动余量。恢复后历史补录以不超过剩余能力的一半追赶，避免再次挤压在线请求。

八、分治思想与组合权衡

8. 按业务不变量、故障域和成本归属拆解复杂系统

热门面试题

1. 问题（基础题）：分治思想在架构权衡中解决什么问题？

   • 考点：问题分解、局部自治、全局不变量与组合验收。
   • 回答思路：先按独立决策和恢复边界拆分，再用契约和预算重新组合。
   • 详细答案：复杂系统若用一个一致性等级、一个容量池和一个成本目标，会让最严格需求拖累所有能力。分治把资金、库存、履约、导出和报警按不变量、数据所有权、故障域、时效与成本归属拆开：每块有自己的状态、配额和恢复手册；跨边界通过稳定业务键、版本化契约和端到端对账协作。局部可自治，但不能破坏少量全局不变量。
   • 进阶追问：分得越细越好吗？
   • 进阶回答：不是。边界增加会带来消息一致性、观测、部署和组织成本；只有独立扩容、隔离故障或变化频率的收益持续超过协作成本才值得物理拆分。

2. 问题（原理题）：如何避免分治后的局部最优？

   • 考点：端到端目标、预算分配、契约与联合演练。
   • 回答思路：局部指标服从端到端业务结果，并设置跨域门禁。
   • 详细答案：每个领域可优化自身吞吐和成本，但共同承担订单、资金、库存和履约完整性。需要定义端到端成功口径、跨域时限、差异对账和升级责任；容量预算按关键链路而不是平均分配，变更要用真实业务键贯穿联合演练。若某服务通过快速返回成功把工作丢给无容量下游，本地可用性变好却让整体交付变差，应由端到端指标否决。
   • 进阶追问：共享平台的成本怎样归属？
   • 进阶回答：拆成基线保障和按量消耗，基线由平台预算承担，增量按租户或业务量展示；归属用于决策透明，不应诱导业务规避必要观测和安全能力。

3. 问题（项目题）：怎样为 WMS（仓储管理系统）、支付、导出和 IoT（物联网）建立不同策略？

   • 考点：差异化不变量、容量池、降级和成本。
   • 回答思路：给四类工作负载分别定义一致性、时效、失败成本和资源隔离。
   • 详细答案：WMS（仓储管理系统）库存承诺保护不超卖和流水可对账，支付保护资金守恒和唯一确认，两者拥有高优先容量与保守未知态；异步导出强调快照、交付时限和资源隔离，可排队、预约和取消；IoT（物联网）报警强调原始证据、高危旁路和风暴聚合。四类系统共享观测、身份和审计基座，但不能共享无上限线程池、队列和降级开关，避免一个低价值洪峰拖垮核心交易。
   • 进阶追问：统一平台是否会破坏隔离？
   • 进阶回答：平台可统一能力接口和治理规则，但租户配额、优先级、故障域与数据权限必须隔离；统一不等于共享同一资源上限。

flowchart TB
    A[端到端业务目标] --> B[资金域]
    A --> C[库存与履约域]
    A --> D[异步任务域]
    A --> E[报警事件域]
    B --> F[全局不变量与对账]
    C --> F
    D --> F
    E --> F
    F --> G[容量预算 成本归属 联合演练]
    G --> A

Mermaid（图表语法）图解读： 四类领域按自身失败语义自治，但最终回到全局不变量与对账。容量、成本和演练是重新组合的控制面，防止局部成功掩盖端到端失败。

数据演绎 8：统一资源池为何会造成局部最优。 E3（演练证据）设共享执行池每秒能力 1,000 个任务，常态支付查单 150、库存补偿 200、导出分片 250、报警处理 200，总量 800。报警风暴新增每秒 600 后，总到达变为 1,400，若公平排队，四类任务都延迟。分治后为支付和库存固定保留每秒 450，报警高危保留 150，剩余 400 由普通报警和导出按配额竞争；低优先任务被背压，核心不变量仍有容量。恢复后再按最老任务年龄调整剩余配额。

九、综合题库：一致性、可用性、容量与成本现场权衡

1. 问题（综合题）：设计一个跨机房订单系统时，你如何解释 CAP（一致性、可用性、分区容错）并做选择？

   • 考点：分区裁决、业务动作分级、未知态、恢复收敛与证据。
   • 回答思路：先定义不变量，再按读写动作比较错误回答与暂时不回答的成本，最后补容量与恢复。
   • 详细答案：先列订单唯一受理、库存不超卖、支付不重复确认等不变量；再按动作裁决，订单详情可返回带版本旧值，库存承诺和资金确认在无法验证权威状态时拒绝或进入处理中。分区恢复后按业务键、版本和流水对账，冲突不能依赖最后写入覆盖。方案还要扣除一个机房后的有效容量，并定义非关键查询的降级和关键写入的排队上限。
   • 进阶追问：如果业务要求分区时所有接口都必须成功怎么办？
   • 进阶回答：要求业务明确“成功”的语义和错误成功的赔付边界；对不可逆动作不能伪造成功，可返回已受理或处理中，并提供查询与恢复承诺。
   • 口述答案：我不会先把系统简单归类成一致型或可用型，而会从业务动作和不变量开始。跨机房意味着网络分区无法被架构消灭，只能提前定义分区时每类请求怎样裁决。订单详情、商品说明这类读取，即使短时间陈旧，失败成本通常是体验下降，可以返回带版本号和更新时间的旧值；库存预占、支付确认、履约创建会产生不可逆承诺，错误成功可能导致超卖、双扣或重复发货，因此无法确认权威状态时应拒绝、排队或进入处理中，不能猜测成功。写入侧要使用稳定业务键、单一事实所有者和单调版本，超时后先查证，不直接换业务号重试。恢复阶段按订单键核对订单、库存、支付和履约流水，发现冲突依据状态偏序和权威证据处理，而不是用最后写入覆盖。容量上我还会模拟失去一个机房：计算剩余实例、数据库连接、队列和外部配额能否承担关键写入；若不足，就提前限制低优先查询、关闭报表与大导出，为资金和库存保留资源。验收不只看接口存活，还看端到端订单成功率、未知态数量、最老差异年龄、恢复清空时间和人工接管量。这样表达的重点是，CAP（一致性、可用性、分区容错）不是选产品时的标签，而是分区发生时针对不同业务动作做出的、可验证且可恢复的裁决。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 超时等于分区吗？/不等于，只能证明期限内未得到结果；② 旧值能用于下单吗？/旧值可展示，承诺必须回权威预占；③ 双机房都写可以吗？/可以设计，但必须有冲突裁决、唯一键和容量证据；④ 如何验收恢复？/看差异数量、最长年龄、流水摘要和积压清空时间。
   • 延伸：质量属性权衡与失败成本

2. 问题（综合题）：面试官说“最终一致就是靠重试”，你如何纠正并给出完整方案？

   • 考点：BASE（基本可用、软状态、最终一致）、状态机、幂等、查证、对账与补偿容量。
   • 回答思路：说明重试只是传输手段，收敛需要业务裁决和证据闭环。
   • 详细答案：完整方案要定义稳定业务键、权威事实、合法状态迁移、最大收敛窗口和责任人。重复由幂等处理，乱序由版本与状态偏序拒绝，超时副作用先查证，长期差异由对账、补偿和人工接管处理。补偿队列的完成率必须高于差异产生率，否则不会最终收敛。
   • 进阶追问：对账发现两边都自称成功，以谁为准？
   • 进阶回答：依据预先定义的数据所有权和外部不可逆证据裁决；无法自动判断时冻结对象并人工核对，不能用更新时间覆盖。
   • 口述答案：我会先指出，重试只能提高消息或调用再次到达的概率，不能决定业务状态是否允许再次执行。最终一致至少要有五层机制。第一层是稳定业务键，同一支付意图、履约意图或导出任务无论重试多少次都关联同一个对象。第二层是状态机和单调版本，明确哪些状态可以迁移，终态不能被迟到旧消息覆盖，取消与成功冲突时按业务偏序处理。第三层是幂等与副作用查证，数据库内部可以用唯一约束和流水去重，外部支付或仓库调用超时则先查单，因为请求可能已经成功而响应丢失。第四层是对账与补偿，把权威事实和派生投影按业务键核对，记录差异类型、年龄、金额或数量，再执行补记、冲正、释放或重放。第五层是容量和责任，补偿完成率必须长期高于差异产生率，最老差异超过窗口要升级人工，不能让队列无限增长。以跨境履约为例，订单已受理后异步创建面单，调用超时先按履约意图查承运商；确认未创建才重试，确认已创建则补录本地结果，无法确认就保持待查状态。验收指标包括重复副作用为零、非法状态迁移为零、差异数量和年龄受控、补偿清空时间达标。BASE（基本可用、软状态、最终一致）的“软状态”允许中间状态变化，但每个变化都必须有证据、有期限、有负责人，绝不是把失败丢进队列后期待它自行消失。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 幂等能替代状态机吗？/不能，幂等防重复，状态机裁决合法顺序；② 重试间隔怎么设？/按依赖恢复特征退避并设总截止时间；③ 补偿失败怎么办？/冻结对象、保留证据并升级人工；④ 如何证明最终一致？/权威源与投影对账，差异量、年龄和摘要都过门禁。
   • 延伸：微服务一致性治理与演进追问

3. 问题（综合题）：请设计 WMS（仓储管理系统）库存防超卖，并说明强一致、可用性和容量如何权衡。

   • 考点：库存口径、热点预占、事务流水、读写分层、降级与对账。
   • 回答思路：先定义库存状态与不变量，再缩小强一致核心，最后计算热点容量和故障余量。
   • 详细答案：权威侧以仓库、货品和批次定义可售，预占、实扣、释放都写不可变流水并受唯一业务键约束；查询缓存和报表异步更新。热点时入口限购、按键串行或分段额度，无法确认权威状态则排队或售罄。扣除一个故障域后关键预占仍要有有效能力，非关键查询与导出可降级。
   • 进阶追问：安全库存是否意味着可以接受超卖？
   • 进阶回答：安全库存是业务缓冲，不是技术错误许可证；是否允许超承诺、最大数量和赔付策略必须由业务明确，流水仍需可对账。
   • 口述答案：我会先把“库存”拆成实物、账面、可售、预占、实扣、释放和在途，明确真正的不变量是同一口径下可售不能被承诺成负数，订单、库存流水和仓内结果最终可核对。写路径只把决定承诺的最小事实放进强一致边界：以订单行作为稳定业务键，在权威库存库中原子检查可售、写预占流水并扣减可售，唯一约束防止重复预占。支付成功后转实扣，取消或超时按状态机释放，未知支付状态不得提前回补。商品页库存、运营报表和搜索结果属于可重建投影，可以异步更新并显示时间戳，不能反过来作为扣减依据。热点货品不能只靠加线程，我会在入口限购、按仓库与货品分区、对极热点采用有序处理或预分配不重叠额度，同时监控锁等待、成功完成率和最老排队时间。容量估算从活动峰值、热点占比、单次写放大和事务时间出发，扣除一个故障域后验证关键预占能力；如果不足，优先关闭大导出和实时报表，对低优先渠道限流，为库存写入保留连接和执行线程。仓库断网时只允许扫描草稿或使用有上限的离线额度，恢复后按额度序号和中心流水对账。最终验收包括负库存为零、重复预占为零、订单库存差异在窗口内清零、故障后积压可在目标时间清空。这个方案不是追求所有读取都强一致，而是保护承诺事实，把可延迟部分异步化，并用容量隔离保证高峰和故障下仍守住不变量。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 缓存扣库存可行吗？/可作前置削峰，但最终承诺要与权威流水核对；② 热点锁严重怎么办？/限购、分区、有序处理并缩短事务；③ 支付超时能释放吗？/不能，先查证支付状态；④ 仓库离线怎么做？/使用隔离额度和单调序号，恢复后对账。
   • 延伸：WMS（仓储管理系统）库存预占与对账补偿方案

4. 问题（综合题）：支付回调超时、重复、乱序时，如何保证资金一致性又不牺牲过多可用性？

   • 考点：支付意图、渠道查单、账务分录、状态偏序、对账与用户语义。
   • 回答思路：资金事实保守裁决，接入可用性通过处理中和查证链路提供。
   • 详细答案：创建稳定支付意图并保证同一意图唯一，渠道请求携带稳定业务键；超时进入未知态并主动查单，重复通知按事件标识和状态机去重，成功终态不被迟到失败覆盖。账务分录采用可审计流水，渠道账单与本地账务定期对账，差异补记或冲正。
   • 进阶追问：查单接口也不可用怎么办？
   • 进阶回答：保持处理中并限制重复副作用，按退避策略继续查证，超过业务窗口进入人工清单；不能因追求可用而猜测成功或失败。
   • 口述答案：支付场景里我会把“可用”定义成用户始终得到可理解、可查询、可恢复的结果，而不是每次都返回支付成功。首先创建唯一支付意图，客户端重试、服务重试和渠道调用都复用同一业务键；本地状态机区分已创建、处理中、成功、失败、待查和已冲正，只有合法前驱才能迁移。调用渠道超时不能直接判失败，因为渠道可能已经扣款但响应丢失，此时进入待查状态，通过主动查单、异步回调和渠道账单三个证据源收敛。重复回调按渠道事件标识和支付意图去重，乱序失败通知不能覆盖已确认成功。资金落账采用不可变分录和借贷平衡校验，业务状态与账务结果分开记录，避免修改余额掩盖历史。可用性方面，前台立即展示处理中和查询入口，订单保留合理支付窗口；查单消费者有独立容量、限速和重试截止时间，不与新支付争抢全部资源。系统还要按日或更短窗口核对渠道金额、支付意图和账务分录，差异按漏单、重复、金额不符分类，自动补记或冲正，高风险项人工复核。容量评审会模拟渠道变慢带来的待查增长，确保恢复完成率高于新增待查率。验收看双扣和错账为零、未知态最长年龄、对账差异金额、自动修复率和人工单量。这样是在资金正确性上保守，在交互和恢复路径上提供可用，而不是用错误成功换表面成功率。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 回调和查单冲突听谁？/按渠道权威证据、事件时间和状态偏序裁决；② 能否换支付单号重试？/同一意图不能盲目换号，先查证旧单；③ 账务能直接改余额吗？/不能，应追加分录并保留审计；④ 用户一直处理中怎么办？/超过窗口升级人工并提供明确状态。
   • 延伸：支付资金正确性与对账恢复方案

5. 问题（综合题）：把百万行导出从同步改成异步，你会怎样设计并证明不是“转移超时”？

   • 考点：快照语义、任务状态、分片容量、资源隔离、背压和交付。
   • 回答思路：先定义交付承诺，再设计有界任务系统并量化数据库、内存、磁盘和队列。
   • 详细答案：提交时固化条件、权限和快照，返回稳定任务编号；执行按分片流式读取并记录水位，合并后校验行数与摘要再交付。限制单任务大小、租户并发和全局扫描连接，交易与导出资源隔离。队列看最老任务年龄和净消化能力，过载时预约或拒绝。
   • 进阶追问：业务坚持所有导出十分钟完成怎么办？
   • 进阶回答：用行宽、并发、数据库可用扫描能力和成本反推可行范围；若预算不变，就必须限制字段、时间范围、并发或改离线数据源。
   • 口述答案：我会先把“异步导出”定义成有交付承诺的任务系统，而不是接口返回一个编号就结束。提交阶段固化筛选条件、租户权限、字段版本和快照时点，生成稳定任务键，重复提交可以复用或明确创建新版本。执行阶段按主键范围或稳定分片切分，使用流式读取和有界缓冲，记录每个分片的水位、行数、摘要和重试次数，不能把百万行一次装入内存。所有分片完成后再合并，校验总行数、文件摘要和快照边界，通过后把任务切为可下载；通知失败不回退文件状态，用户可以从任务中心查询。容量上从高分位行宽计算读取量、格式膨胀、临时磁盘、出口带宽和保留期，并把并发任务数乘到数据库连接与扫描量上。导出使用独立连接池、线程池和存储配额，不与在线订单和库存写入争抢。队列必须有租户并发、单任务大小、优先级和截止时间，监控最老任务年龄、完成率和到达率；若长期完成率低于到达率，就预约、限流或拒绝，而不是无限堆积。失败分片达到上限后进入可见补偿态，可重跑且保留已完成证据；取消要停止未开始分片并安全清理临时文件。验收除十分钟交付率外，还包括交易延迟不退化、内存无无界增长、失败残片可回收、文件行数与摘要正确。这样才能证明异步化真正隔离资源、吸收短峰并可恢复，而不是把前台超时搬到后台队列。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 分片越多越好吗？/不是，受数据库连接、合并和调度开销约束；② 源数据变化怎么办？/以固化快照或明确弱快照语义处理；③ 通知失败算任务失败吗？/文件成功与通知失败分开记录；④ 队列满怎么办？/按租户配额预约、限流或拒绝。
   • 延伸：异步导出快照、分片与隔离方案

6. 问题（综合题）：业务只给日订单量，如何完成可评审的容量估算？

   • 考点：峰值区间、请求放大、热点、故障余量、恢复能力与证据等级。
   • 回答思路：把日量转换为分时峰值，再逐层推导应用、数据库、队列和存储，并用压测校准。
   • 详细答案：日量只能给出总规模，必须补峰值系数、持续时间、热点占比、每订单读写和重试。单实例能力以满足时延和正确性的成功完成率为准，实例数还要扣除一个故障域。队列按到达率减完成率算积压，恢复能力必须高于正常到达率。
   • 进阶追问：历史数据不可信怎么办？
   • 进阶回答：用日志、账单、活动计划和上游限额交叉验证，给低中高三档区间与证据等级，并把最大未知列为压测门禁。
   • 口述答案：拿到日订单量后，我不会直接除以八万多秒，因为业务流量通常集中在活动、截单、盘点和结算窗口。第一步是还原业务节奏，用小时和分钟分布得到典型峰值、极端峰值及持续时间；没有历史时，就从营销计划、上游限额、仓库作业能力和设备规模建立低中高三档假设。第二步做请求放大，一笔订单会触发库存查询与预占、支付、履约、消息、日志和报表写入，要分别估算每层次数、对象大小、重试率和热点货品比例。第三步测有效能力，单实例能力不是实验室最高吞吐，而是在目标尾部时延、错误率和正确性约束下的稳定成功完成率；数据库还要看连接、锁等待、热点与磁盘写入。第四步计算故障余量，模拟失去一个实例组、一个分区或一个外部通道后，剩余能力能否保住支付、库存和履约关键流量，报表和导出可否降级。第五步计算积压与恢复，故障期间的积压量除以恢复完成率减正常到达率，得到清空时间；若差值不为正，就不存在恢复。第六步把数据存储、消息保留、文件临时空间和未来增长纳入周期预算。最后通过分层压测、真实流量回放和故障演练校准假设，记录瓶颈迁移。评审输出应包含输入来源、计算公式、三档结果、降级边界和重审阈值。这样即使初始数据不完整，结论也可复算、可证伪，而不是用一个看似精确的实例数掩盖未知。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 峰值系数怎么定？/优先用分时日志，缺失时做区间假设；② 单实例能力取最高值吗？/取满足目标的稳定完成率；③ 为什么扣故障域？/验证高峰故障时仍能保核心；④ 如何算恢复时间？/积压除以恢复完成率与正常到达率之差。
   • 延伸：容量排队与资源模型

7. 问题（综合题）：系统平时利用率只有 50%，为什么仍可能扛不住单节点故障？

   • 考点：平均值陷阱、故障域、热点分片、共享依赖与有效能力。
   • 回答思路：把集群平均拆成分片与依赖水位，并在同一峰值窗口扣除故障域重算。
   • 详细答案：平均利用率会掩盖热点、不可迁移状态和共享数据库上限。失去节点后流量重分配、缓存冷启动和重试会降低单节点有效能力，剩余实例即使理论容量足够，也可能因连接与锁竞争过载。应按关键分片和依赖计算故障后利用率。
   • 进阶追问：保留多少冗余才合理？
   • 进阶回答：由最大故障域、扩容与预热时间、可降级比例、峰值持续时间和失败成本共同反推，不存在统一百分比。
   • 口述答案：50% 只是某个统计窗口和聚合口径下的平均值，不能直接等价为一半故障余量。我会先拆四类原因。第一，流量可能不均，某个热点货品、租户或分片已经接近饱和，其他节点空闲也接不走它。第二，节点故障后会发生连接重建、缓存冷启动、分区迁移和超时重试，剩余节点的有效完成率通常低于正常值，不能按理论线性叠加。第三，应用节点虽然有余量，共享数据库、消息分区、外部支付通道或网络出口可能已经接近上限，应用扩容无法创造下游能力。第四，故障域可能不是单节点，而是一整个机房、可用区或同批次依赖，实际损失比例大于实例数量显示。验证时我会选真实峰值窗口，按分片统计到达率、成功完成率、尾部时延、队列年龄和依赖水位，再扣除最大可信故障域，重新计算关键流量是否仍能完成。还要注入缓存冷、实例重启和依赖变慢，观察重试是否放大。若故障后能力不足，不一定只加机器，可以对报表、轨迹刷新和导出降级，为库存与支付保留连接；也可以拆热点、提前预热或缩短恢复时间。冗余目标由业务失败成本决定，资金和库存需要更保守，可延迟任务可以用队列吸收。验收标准应是故障期间核心业务结果、积压上界和恢复时间达标，而不是平均中央处理器数值仍然好看。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 平均值何时有用？/适合趋势观察，不适合证明故障余量；② 热点如何识别？/按业务键、分片和租户拆分吞吐与等待；③ 加节点一定有效吗？/不一定，共享依赖可能先饱和；④ 怎样验收？/峰值下注入故障，看核心成功、积压和恢复。
   • 延伸：成本容量治理与故障余量

8. 问题（综合题）：公司要求年度技术预算降低 20%，你如何降本但不破坏核心稳定性？

   • 考点：单位成本、业务分级、故障余量、失败成本、退出成本和重审门槛。
   • 回答思路：先建立成本账本和保护红线，再按价值移除浪费、调整非关键承诺，最后灰度验证。
   • 详细答案：成本按建设、运行、变更、失败与退出分类，并按业务量归一。支付、库存和高危告警的正确性与故障余量作为红线；优先清理闲置环境、低价值日志、低命中缓存和无边界导出，再对报表时效、数据保留与非关键冗余做业务确认。
   • 进阶追问：业务不同意降低任何服务承诺怎么办？
   • 进阶回答：展示每项承诺对应的资源、风险与可选成本区间；若范围、质量和预算都不可变，应升级决策而不是技术团队暗中承担风险。
   • 口述答案：我会把降本当成一次质量属性重排，而不是统一砍机器。先建立过去十二个月的成本账本，按计算、存储、网络、许可证、人力和值班拆分，并除以订单、任务或设备事件得到单位业务成本；同时把故障赔付、人工修复、合规和迁出成本补进模型。第二步明确红线：支付资金守恒、库存不超卖、高危告警不漏和必要审计不能因为预算下降而放宽，单故障域后的关键容量也不能未经验证直接删除。第三步按风险从低到高处理浪费，先回收闲置测试环境和长期空闲实例，压缩重复日志与失败残片，淘汰低命中缓存，限制无边界查询和大导出；再通过预约、错峰和租户配额降低峰值。第四步调整数据生命周期，普通设备心跳短期保留原始数据后转聚合，事故证据继续长期保存；冷热分层要计入取回和运维费用。第五步检查架构复杂度，低价值多套中间件、重复平台和过度拆分可能增加值班和升级成本，能合并时先验证故障域。第六步把每个动作写成节省金额、用户影响、风险上界、回滚信号和负责人，按小批灰度实施。过程中持续看核心成功率、尾部时延、积压年龄、故障余量和单位成本，任何不变量或恢复时间越界立即回滚。若 20% 无法在不改变承诺的情况下实现，我会给出保守、均衡、激进三档方案，请业务和财务共同确认新的时效、保留期或风险边界，而不是把事故成本藏到未来。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 先砍冗余可行吗？/先验证故障域，核心余量不能盲砍；② 冷存储一定省钱吗？/要计迁移、取回与运维；③ 如何量化收益？/看年度节省和单位业务成本；④ 何时回滚？/不变量、尾时延或恢复时间越界时。
   • 延伸：成本、退出路径与迁移决策

9. 问题（综合题）：如何设计一套“可执行而不是写在文档里”的降级体系？

   • 考点：业务分级、触发与恢复门槛、资源收益、用户语义、演练和权限。
   • 回答思路：逐项定义保留能力、暂停能力、操作入口、预期收益、补偿与恢复。
   • 详细答案：降级项按业务能力而非技术组件定义，每项要有触发信号、审批和自动边界、容量收益、用户提示、数据副作用与恢复步骤。默认安全、权限隔离、操作审计，并在峰值前演练。恢复需分批开放、清理积压和对账，不能指标一回落就全量开启。
   • 进阶追问：自动降级还是人工降级更好？
   • 进阶回答：可逆、边界清楚且已演练的动作可自动；涉及资金、库存写入或大范围用户影响的动作保留人工确认和快速回滚。
   • 口述答案：我会从业务能力清单开始，而不是从几个开关开始。先把系统分成必须保留、可延迟、可关闭和必须人工裁决四层，例如支付查证、库存保护和高危报警必须保留，轨迹刷新、实时报表和大导出可以延迟，营销推荐可以关闭，资金冲正与离线额度放开需要人工确认。每个降级项都写清触发信号、连续窗口、操作者、影响租户、预计释放的线程、连接或下游配额、用户看到的状态、产生的数据债务和最大持续时间。开关必须默认安全、权限最小化、操作留痕，并能按租户、地区和业务类型逐级生效，避免一次误操作影响全局。自动化只处理可逆且反复演练过的动作，如限制报表并发；涉及不可逆副作用时由值班负责人确认。触发后监控的不只是中央处理器和错误率，还包括核心业务成功率、最老积压、未知态和外部限额，确认降级确实释放了目标资源。恢复阶段先验证依赖稳定和剩余容量，再小批开放入口；对积压设置追赶速度，防止瞬间回放造成二次过载；随后执行通知补发、报表重算、状态查证和端到端对账。最后复盘实际释放容量、误触发、用户影响和人工操作时长，删除无收益开关。演练要包含权限是否可用、配置传播是否及时、用户文案是否正确以及恢复能否完成。只有从触发到补偿都被验证，降级才是稳定性能力；只写“必要时关闭非核心功能”并不能在事故中可靠执行。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
   • 追问/直答：① 开关越多越好吗？/不是，会造成组合爆炸；② 自动化边界是什么？/可逆、可观测且演练充分；③ 降级后看什么？/核心结果、资源收益和数据债务；④ 如何恢复？/依赖稳定后分批开放并补偿对账。
   • 延伸：稳定性事故、容量排障与综合题库

10. 问题（综合题）：IoT（物联网）设备告警风暴下，如何兼顾高危不漏、系统可用和存储成本？

• 考点：原始证据、高危旁路、窗口聚合、优先队列、背压和分层保留。
• 回答思路：把接入、判定、通知和存储解耦，分别定义不变量与容量策略。
• 详细答案：接入快速持久化设备、序号、事件时间和规则版本；高危规则旁路实时判定，普通事件按设备与窗口聚合。不同严重级别进入隔离队列，通知通道配额保护高危。原始数据按风险分层保留，聚合结果长期保存，过载时背压低优先事件但不丢审计证据。
• 进阶追问：窗口聚合会不会改变事件真相？
• 进阶回答：聚合只改变告警投影和通知频次，原始事件仍以不可变记录保存；高危规则不依赖普通聚合路径。
• 口述答案：我会把告警系统拆成原始事件接入、规则判定、告警状态、通知交付和数据保留五层。接入层的首要目标是保留证据，记录设备标识、单调序号、事件发生时间、接收时间和规则版本，快速写入有界日志；重复和乱序不能直接覆盖。规则层把高危事件放到独立旁路，满足条件立即判定，普通抖动按设备、指标和时间窗聚合去重，减少相同故障反复生成通知。告警状态机区分新建、持续、恢复和确认，迟到事件依据事件时间和偏序处理。通知层按严重等级使用隔离队列和配额，高危拥有保留容量，普通告警可合并、延迟或只更新任务中心；外部短信通道限速时不能让重试占满全部线程。容量模型从设备数、上报频率、风暴倍数和持续时间计算入口与队列，验证聚合失效时最大积压、磁盘保留和恢复清空时间；若完成率低于到达率，入口对低优先遥测采样或背压，但安全事件继续接收。成本上，高危事故证据和配置变化长期保留，普通心跳短期原始保存后转分钟、小时聚合，删除前验证法规和调查窗口。验收包括高危漏报为零、通知延迟、重复通知压缩率、最老积压、原始事件可追溯和单位设备存储成本。这样既不靠丢事件维持表面可用，也不为每次抖动支付无限通知与长期存储费用。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 高危如何保护？/独立判定路径、队列和配额；② 普通事件能丢吗？/按契约采样或聚合，原始证据边界要明确；③ 乱序怎么处理？/用事件时间、序号和状态偏序；④ 如何降存储成本？/按风险分层保留并保存聚合。
• 延伸：IoT（物联网）报警风暴治理项目串讲

11. 问题（综合题）：Runner（执行器）调度系统如何处理重复执行、节点失联和积压恢复？

• 考点：租约、栅栏、幂等、任务状态、分区裁决、优先级和恢复容量。
• 回答思路：调度权与业务副作用分开保护，节点失联后通过租约和栅栏转移，副作用靠幂等与查证。
• 详细答案：任务有稳定业务键和单调代次，执行节点持有带期限租约；接管者获得更高栅栏号，存储和下游拒绝旧代次写入。失联不等于任务失败，外部副作用先查证。队列按任务类型隔离，恢复时保证完成率高于新到达率并限制重试风暴。
• 进阶追问：租约到期后旧节点继续运行怎么办？
• 进阶回答：仅靠租约不够，关键写入必须携带栅栏号并由权威存储拒绝旧代次；无法校验的外部动作需稳定业务键和查单。
• 口述答案：Runner（执行器）调度我会分成任务事实、调度所有权和业务副作用三层。任务事实记录稳定业务键、状态、计划时间、尝试次数、截止时间和单调代次；调度器给节点发放有期限租约，心跳中断只说明所有权可能过期，不直接证明任务未执行。新节点接管时获得更高栅栏号，所有关键数据库写入都携带该编号，权威存储拒绝旧节点的迟到写入，从而避免网络恢复后的双主提交。对于支付、履约等外部副作用，即使栅栏无法传到第三方，也要使用稳定业务键，超时先查单再决定重试。执行状态机区分待执行、运行中、待查、成功、可重试失败和终止，重试受状态与截止时间约束，不允许无限循环。容量上按短任务、长任务、查证任务和补偿任务隔离队列与线程池，设置租户配额和优先级；节点故障后先保护新到关键任务，再用剩余能力追赶积压。恢复时间按积压除以恢复完成率减正常到达率计算，差值不为正就需要扩容或降载。缩容时先停止领取新任务，等待租约与在途副作用安全结束。观测包括重复副作用、租约冲突、旧栅栏拒绝数、最老任务年龄、重试放大和各队列净消化能力。故障演练要覆盖节点暂停、网络隔离、数据库变慢和外部结果未知。这样才能证明系统即使至少执行，也不会把技术重复变成业务重复，同时在节点失联后可在明确窗口内恢复。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 心跳断了能立即重跑吗？/不能，先看租约、栅栏和副作用证据；② 栅栏保护什么？/阻止旧所有者迟到写入；③ 外部系统不认栅栏怎么办？/稳定业务键加查单；④ 积压怎么清？/隔离优先级并保证恢复净能力为正。
• 延伸：Runner（执行器）调度租约与恢复方案

12. 问题（综合题）：跨境履约依赖多个承运商，如何权衡可用性、费用和一致性？

• 考点：供应商路由、履约意图、外部幂等、限额、自动切换边界和对账。
• 回答思路：先统一业务意图和状态，再把承运商差异封装为可验证策略，自动切换必须受业务规则约束。
• 详细答案：同一订单建立唯一履约意图，调用承运商携带稳定键并保存原始请求回执。路由综合线路、截单、价格、服务能力和限额；超时先查单，不能直接切换造成双面单。只有标签、费用和取消规则兼容时才自动切换，结果通过账单和轨迹对账。
• 进阶追问：最低价承运商是否应优先？
• 进阶回答：不能只看面单价，要计妥投、时效违约、取消、人工处理和切换失败成本，使用单位成功履约成本比较。
• 口述答案：我会先把承运商选择从一次接口调用提升为履约意图管理。每个订单和包裹生成唯一履约意图，记录目的地、服务等级、截单时间、商品限制、预算和候选承运商；任何重试或切换都围绕同一意图，不新造无法关联的单据。路由层先用硬约束淘汰不支持线路、标签、清关或危险品规则的候选，再比较价格、历史妥投、时效、取消能力、当前限额和故障状态。调用外部承运商时携带稳定业务键并保存请求、响应和回执；超时进入待查，优先查单，确认未创建才可重试或切换，确认已创建则补录本地面单。自动切换必须有边界：标签格式、报价、服务等级、取消语义和用户承诺都兼容才可执行，否则进入运营待决策队列，避免生成双面单或额外费用。可用性通过多候选、独立配额、预约队列和状态透明实现，不通过猜测成功实现。容量上按承运商限额和截单时间分优先队列，临近截单订单保留资源，轨迹刷新和历史补录可降级。成本模型使用单位成功履约成本，除了面单价，还计失败重试、改派、客服、赔付和账单差异。恢复后按履约意图核对本地状态、承运商面单、轨迹终态和账单金额。验收看重复面单、超时待查年龄、截单前完成率、自动切换成功率、账单差异和单位成功履约成本。这样才能同时管理一致性、可用性和费用，而不是把多供应商简单理解成多写几个接口。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 超时能立即换承运商吗？/不能，先查旧承运商是否已建单；② 如何防双面单？/唯一履约意图、稳定键和查单；③ 路由只看价格吗？/还看时效、成功、取消和失败成本；④ 完全不可用怎么办？/高优先订单人工改派，其他预约排队。
• 延伸：跨境订单履约与异常恢复方案

13. 问题（综合题）：什么情况下必须强一致，什么情况下最终一致更合理？

• 考点：业务不变量、可逆性、陈旧窗口、协调成本和可重建投影。
• 回答思路：用错误结果的不可逆性和数据能否重建判断，不按技术组件一刀切。
• 详细答案：决定资金、库存和唯一外部承诺的最小事实需要强约束；搜索、报表、通知与派生视图可最终一致。跨系统副作用无法放进同库事务时，采用本地事实、异步传播、幂等、查证和对账。关键是定义收敛窗口和失败责任。
• 进阶追问：强一致是否一定低性能？
• 进阶回答：强协调会增加延迟和故障耦合，但缩小事务边界、减少热点和合理分区可改善；不能把性能问题当成放弃正确性的理由。
• 口述答案：我的判断顺序是业务不变量、错误可逆性、用户时效和实现成本。若某个事实一旦错误就会形成不可逆承诺，例如同一支付意图只能确认一次、可售库存不能被扣成负数、同一包裹只能有一个有效履约单，那么决定该承诺的最小写入边界需要强约束，通常通过单一权威源、事务、唯一约束和状态机完成。这里强调“最小”，因为没有必要把通知、搜索和报表一起锁进事务。若数据是由权威事实计算出的查询投影，丢失后可以重建，用户也能容忍秒级或分钟级陈旧，例如订单列表、轨迹视图、统计报表和通知状态，更适合最终一致，通过版本化事件异步更新。跨外部系统的支付和履约无法真正做同库原子提交时，也不能假装强一致，而是先持久化本地意图，再调用外部，超时查证，重复幂等，最后用对账和补偿收敛。最终一致必须定义最大差异窗口、最老差异告警、补偿责任和人工接管，不能只说会重试。选择时还要比较协调带来的锁时间、网络依赖、故障范围和容量成本；若所有读取都追求最新，会降低分区期可用性并增加资源费。验收则分两类：强一致核心看不变量是否始终成立，异步投影看差异量、年龄和重建结果。好的方案不是选择一个口号，而是形成“强一致事实、最终一致传播、可验证收敛”的分层组合。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 报表能强一致吗？/能但通常不值得，需看时效与成本；② 外部支付怎么强一致？/不能跨域假装原子，要查证和对账；③ 缓存属于权威吗？/通常是可重建投影；④ 最终一致多久算最终？/由业务窗口定义并监控最老差异。
• 延伸：支付履约与外部依赖追问

14. 问题（综合题）：如何用错误预算决定“继续发版还是先治理稳定性”？

• 考点：用户结果、服务目标、预算消耗速率、正确性红线和发布门禁。
• 回答思路：先定义可感知成功，再按窗口计算允许失败量，以消耗速率触发不同治理动作。
• 详细答案：错误预算基于端到端用户结果而非单服务存活。预算健康时可做受控变更，消耗加快时降低发布频率并修复，接近耗尽时冻结高风险变更。资金错账、隐私泄露等正确性事件不应因比例小而被预算豁免。
• 进阶追问：业务增长导致请求更多，允许失败数也更多合理吗？
• 进阶回答：百分比预算需配合绝对影响、关键用户和损失上限；高风险场景要设置绝对护栏，不能只看比例。
• 口述答案：我会先确保错误预算绑定的是用户可感知结果，例如订单能否受理并在承诺时间进入履约，而不是某个接口返回码。然后选择统计窗口和目标，把允许失败的比例换算成请求数、订单数或不可用分钟，并同时设置绝对影响上限。日常决策不只看剩余多少，还看消耗速率：预算充足且消耗稳定时，可以继续小批发布和故障演练；短窗口消耗显著加快时，减少并发变更、提高灰度门槛并优先修复；预算接近耗尽时，冻结高风险功能发布，只允许稳定性修复和必要安全变更。对于支付错账、库存超卖、隐私泄露和高危告警漏报，我会设独立正确性红线，它们即使占请求比例很小也不能用错误预算合理化。每次发布前评估变更影响的故障域、可逆性、回滚时间和当前积压，发布后观察端到端成功、尾部时延、差异年龄和人工单量，而不是只看应用错误率。若事故由外部依赖造成，也应计入用户结果预算，再通过合同和架构治理分摊责任，不能从看板中删除。低流量系统则使用事件次数、影响时长和关键样本，避免百分比失真。复盘要区分发布、容量、依赖和操作消耗，推动最主要来源治理。错误预算的价值是把“稳定还是迭代”的争论变成共同规则，但前提是指标可信、红线清楚、触发动作预先约定。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 预算耗尽还能发安全修复吗？/可以，按必要变更流程小批验证；② 外部故障算吗？/用户受影响就算；③ 正确性事故算百分比吗？/设独立绝对红线；④ 低流量怎么做？/结合事件次数、时长和关键样本。
• 延伸：SLI（服务等级指标）、SLO（服务等级目标）与错误预算

15. 问题（综合题）：自建还是采购一项关键能力，你如何把成本与失败风险放在同一模型？

• 考点：全生命周期成本、能力边界、供应商风险、退出路径、敏感性与试验。
• 回答思路：先用硬约束淘汰，再在统一周期比较建设、运行、失败与退出，并用试验证据校准。
• 详细答案：比较相同工作负载与服务承诺，纳入研发、迁移、订阅、网络、值班、合规、停机损失、涨价和迁出。对概率不确定的失败做上下界和敏感性分析，明确结论在哪些业务量、价格或故障频率下反转。采购也要验证数据导出和替代方案。
• 进阶追问：团队熟悉自建技术能否直接决定？
• 进阶回答：熟悉度影响交付与恢复成本，是重要变量但不是唯一结论；还需比较长期能力、合规、规模和退出风险。
• 口述答案：我会先统一比较边界，确保自建和采购承担相同业务量、峰值、正确性、恢复时间和数据保留，否则价格没有可比性。第一步用硬约束淘汰，例如资金审计、数据地域、接口幂等、峰值限额和可导出能力不满足就不进入打分。第二步以三年为周期建立成本账本：自建包括研发、迁移、基础设施、值班、升级、培训和关键人员风险；采购包括接入、订阅、按量费用、跨区网络、供应商支持、合同涨价和定制限制。两边都要计故障损失、合规审计、双轨迁移和退役成本。第三步量化失败风险，用发生频次区间乘影响区间，不确定时做乐观、基准和悲观情景，重点找出业务量、订阅涨幅、人工投入或事故频率达到什么阈值时结论反转。第四步评估控制边界，供应商不可用时能否降级、数据能否完整导出、稳定业务键是否贯穿、故障证据是否可取；自建则看团队能否全天恢复和持续升级。第五步做小范围试验，使用真实数据分布和故障注入验证吞吐、尾部时延、限流、恢复与账单。第六步把退出写进合同和技术设计，定期演练导出样本与替代路径。最终决策记录假设、证据等级、异议、有效期和重审触发器。这样成本不是一张采购报价表，失败风险也不是模糊恐惧，而是能与业务收益、控制能力和退出代价一起比较的决策模型。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 采购价低就选采购吗？/还要计运行、失败和退出；② 风险概率未知怎么办？/做区间与敏感性分析；③ 如何验证退出？/实际导出数据并演练替代接入；④ 熟悉度如何计？/折算交付、值班和恢复人力。
• 延伸：自建、采购与供应商控制边界

16. 问题（综合题）：分治思想如何用于支付、库存、履约三个领域，又不造成局部最优？

• 考点：领域边界、数据所有权、契约、端到端不变量、容量预算和联合验收。
• 回答思路：按独立事实和恢复责任拆分，用稳定键、契约、对账与共同目标重新组合。
• 详细答案：支付拥有支付意图与渠道证据，库存拥有预占、实扣和释放，履约拥有外部建单与仓内状态；禁止跨域直接写库。跨域事件携带稳定业务键、版本和语义，端到端以订单、资金、库存、履约不变量联合验收。资源与故障域隔离，但预算按关键链路统筹。
• 进阶追问：领域独立后谁对最终订单负责？
• 进阶回答：各领域负责自身事实，订单业务负责人对端到端结果负责；跨域异常有明确升级时限和联合对账机制。
• 口述答案：分治不是把三个模块拆成服务就结束，而是让每个边界拥有可独立裁决的事实和恢复责任。支付域拥有支付意图、渠道回执和账务分录，库存域拥有可售、预占、实扣与释放流水，履约域拥有履约意图、外部面单和仓内状态；任何领域都不能为了方便直接修改他域数据库。三域用同一订单业务键关联，事件契约明确版本、事件时间、状态语义和重复处理规则。局部强一致只保护各自最小不变量，跨域通过异步传播、查证、对账与补偿收敛。为了避免局部最优，我会定义少量端到端门禁：已确认支付的订单必须能找到对应资金分录，已承诺库存必须有预占流水，同一履约意图最多一个有效面单，最终订单、库存、支付和履约可按键核对。容量上各域线程、连接和队列隔离，支付查证与库存补偿保留高优先资源，履约和通知按外部限额排队；但整体容量评审要模拟某一域变慢时是否把积压和重试传给其他域。指标也不能只看本地接口绿色，要看订单端到端时效、未知态、差异年龄和人工接管。发布时用真实订单样本做联合灰度与回滚，事故时由订单业务负责人协调，各领域负责人提供证据和修复动作。成本归属可以按基线与增量展示，但不能诱导团队关闭必要审计。这样分治带来独立扩容、故障隔离和清晰所有权，又通过共同不变量、契约和联合验收防止每个团队只优化自己的看板。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 能共享数据库吗？/早期可同库但要模块与所有权隔离；② 谁维护契约？/生产者负责语义，双方共同评审版本；③ 本地成功算整体成功吗？/不算，要看端到端不变量；④ 如何隔离容量？/分池、配额、优先级并联合压测。
• 延伸：分治、边界与技术债治理

17. 问题（综合题）：把单体库存系统迁到分布式架构时，如何控制一致性风险和迁移成本？

• 考点：先扩展后收缩、双轨、数据水位、影子校验、回切、失败成本与批次。
• 回答思路：先稳定语义和业务键，再做兼容扩展、回填、双轨校验和小批切换，删除旧路径最后进行。
• 详细答案：冻结库存口径和状态偏序，建立不可变流水；新模型先回填历史并追平增量，影子处理不产生外部承诺。按仓库或货品灰度读取，比较数量、摘要和差异年龄，越界停批回切。双写不能当权威，原始命令与流水用于重建。
• 进阶追问：双轨运行时间越长越安全吗？
• 进阶回答：不一定，时间越长成本和分叉机会越大；应由覆盖业务周期、差异稳定窗口和回切验证决定，并设明确退出门槛。
• 口述答案：迁移库存系统时，我会先控制语义，再控制流量。第一步冻结可售、预占、实扣和释放的定义，确认仓库、货品、批次粒度以及稳定订单行键；若旧系统没有完整流水，先补变更事件和对账基线，否则迁移后无法解释差异。第二步采用先扩展后收缩，新旧模型都能识别新增字段和状态，避免代码回滚后误读数据。第三步历史回填按仓库或主键分片，记录开始水位、完成水位、行数和摘要；实时增量同时进入新模型，新链路先做影子计算，不对外扣减或释放。第四步持续比较新旧可售、预占汇总、流水摘要和订单关联，差异按重复、丢失、乱序和口径不一致分类，不能直接用新值覆盖旧值。第五步选择低风险仓库灰度读取，写入权威仍保持单一；观察一个完整业务周期后逐步扩大。任何负库存、差异年龄、尾部时延或数据库水位越过门禁，立即停批并回切读取，新链路保留证据用于修复。第六步全量切换后继续双读校验和恢复演练，确认旧系统不再接收命令且回切窗口结束，才删除旧字段和任务。成本模型要计双轨资源、人工核对、延期和回退窗口，批次大小由失败影响和恢复时间决定。最终验收是业务不变量持续成立、差异可解释并清零、故障下可回切，而不是新服务已部署。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 双写能保证一致吗？/不能，仍可能部分成功，要靠流水与对账；② 先切读还是写？/通常先影子与读灰度，权威写最后迁移；③ 如何选批次？/按故障域和可恢复时间控制；④ 何时删旧系统？/观察窗、回切和对账均通过后。
• 延伸：架构决策、可逆性与技术债

18. 问题（综合题）：发生数据库故障并积压大量支付查单时，恢复顺序如何设计？

• 考点：证据保全、止损、优先级、净消化能力、重试风暴、对账与恢复门禁。
• 回答思路：先阻断新增风险并固定水位，再恢复最小查证能力，阶梯追赶积压，最后对账和开放全部流量。
• 详细答案：故障期暂停高风险新写入或转处理中，保留支付意图与渠道证据，禁止无界重试。数据库恢复后先检查一致性与容量，再按金额、年龄和业务截止时间处理待查；限制并发不越过渠道和数据库上限。积压清空后仍需账务对账和抽样。
• 进阶追问：为什么不先把所有消费者开到最大？
• 进阶回答：恢复初期缓存、连接和存储都不稳定，满速回放会再次打垮依赖并制造更多未知态，应按成功完成率阶梯提速。
• 口述答案：恢复的第一原则不是尽快把流量全开，而是保护证据并避免二次伤害。故障发生时先确认影响边界，冻结不必要发布，支付入口对无法可靠落库的请求返回处理中或暂停新支付，已创建支付意图、渠道请求和回调原始证据要保留；同时关闭无界重试，记录故障开始水位和最老未知态。数据库恢复后先验证复制、事务日志、表约束和读写一致性，再开放最小查证能力，不立即恢复全部新交易。待查队列按高金额、临近订单截止时间和最老年龄排序，但设置单租户和单渠道上限，防止局部热点。消费者采用阶梯提速，每一档观察数据库连接、锁等待、渠道限额、成功查证率和新未知态产生率；只有恢复完成率持续高于正常到达率，历史积压才会下降。理论清空时间是积压量除以恢复完成率减正常到达率，还要给重试和人工项留余量。查证结果按状态机落库，已扣款补记成功，明确失败释放订单，仍未知继续退避并进入人工清单，不能用批量更新强行清零。积压回落后逐步恢复新支付，最后执行渠道账单、支付意图和账务分录对账，抽查金额与订单状态。复盘记录恢复峰值、二次失败、人工量和实际清空时间，校准预留容量。这样恢复顺序从证据、最小能力、受控追赶到对账开放，目标是恢复资金不变量，而不是让队列数字最快归零。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 先恢复新流量还是旧积压？/保留最小新流量，按业务优先级分配；② 积压清空公式是什么？/积压除以恢复率减新到达率；③ 未知态怎么清？/查证、退避、人工，不能猜；④ 何时全开？/依赖稳定、积压受控且对账通过后。
• 延伸：故障模型与容灾恢复

19. 问题（综合题）：架构评审时如何同时审查一致性、可用性、容量和成本，而不是各说各话？

• 考点：质量场景、统一工作负载、候选对比、失败注入、预算与决策记录。
• 回答思路：用同一业务场景和数据口径贯穿四类属性，先硬约束淘汰，再比较可逆性和总成本。
• 详细答案：评审输入包括业务不变量、峰值与故障窗口、依赖限额、预算和失败损失。每个候选都回答分区裁决、降级、故障后有效容量、恢复时间、建设运行与退出成本。通过场景演练和试验验证，结论记录假设、证据、异议、负责人和重审条件。
• 进阶追问：多个指标无法统一成一个分数怎么办？
• 进阶回答：不强行加权求和；先用红线淘汰，再展示关键属性的取舍边界与敏感性，由有权承担结果的人裁决。
• 口述答案：我会用一组统一质量场景组织评审，避免数据库团队谈一致性、运维团队谈可用性、财务只谈账单。场景写成：在某峰值和某故障下，哪个业务动作必须在多长时间内完成，允许什么结果，失败损失和预算上限是多少。例如促销峰值中失去一个故障域，库存预占不得超卖，支付未知态十五分钟内收敛，报表允许延迟两小时。对每个候选方案先检查硬约束，包括资金、库存、合规和数据所有权，不满足直接淘汰。剩余方案逐项回答：网络分区时哪些请求拒绝、处理中或陈旧可读；强一致边界有多大，异步投影怎样对账；单实例有效能力、热点、依赖限额和故障后余量是多少；降级能释放多少资源，恢复积压多久清空；三年建设、运行、变更、失败和退出成本是多少。关键假设必须用真实数据分布、压测、故障注入和迁出样本验证，不能只引用功能清单。对于不可统一的属性，不伪造一个总分，而是先红线淘汰，再展示保守、均衡、激进三档以及结论反转阈值，请业务、技术和财务共同确认。决策记录保留被否方案、异议、证据等级、负责人、有效期和重审触发器。上线门禁使用与评审相同的业务指标和故障场景。这样四类属性共享一套输入、场景和验收证据，权衡是显式选择，不会在实施阶段各自偷偷改变承诺。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 能用综合评分吗？/可辅助排序，硬约束不能被高分抵消；② 谁做最终裁决？/由有权承担业务、技术和预算结果的负责人；③ 试验测什么？/最不确定且失败成本高的假设；④ 何时重审？/量级、价格、故障或约束越过阈值时。
• 延伸：解决方案评审、实施与验收

20. 问题（综合题）：请用一套统一方法串讲 WMS（仓储管理系统）、支付、履约、异步导出和 IoT（物联网）的架构权衡。

• 考点：不变量、失败成本、差异化一致性、容量隔离、降级、成本和分治。
• 回答思路：先给统一决策框架，再说明五类业务为何选择不同策略，最后给共同验收口径。
• 详细答案：统一框架是目标与不变量、失败语义、工作负载、候选权衡、恢复与成本。库存和支付保护强约束，履约外部副作用靠意图、查证与对账，导出用有界异步任务，报警用原始证据、高危旁路与聚合。五类工作负载资源隔离，共享观测和审计。
• 进阶追问：这些系统最大的共同反模式是什么？
• 进阶回答：把超时等同失败、把重试等同一致、把加机器等同容量、把降级等同伪造成功，以及只看局部指标不看端到端结果。
• 口述答案：我会用“目标、不变量、失败语义、容量、成本、恢复”六步统一串讲。WMS（仓储管理系统）的核心不变量是不超卖和库存流水可对账，因此预占、实扣、释放在最小权威边界内强约束，查询和报表异步，热点时限购、排队并保留故障余量。支付的核心是资金守恒和同一意图唯一确认，渠道超时进入待查，通过回调、查单、账单和账务分录收敛，绝不以错误成功换可用。跨境履约面对外部副作用，为每个包裹建立唯一履约意图，承运商超时先查单，只有业务规则兼容才自动切换，轨迹和账单最终对账。异步导出强调快照、分片、流式处理和交付状态，用租户配额、有界队列及独立连接池隔离在线交易，过载时预约或拒绝。IoT（物联网）报警保存原始事件和规则版本，高危旁路实时处理，普通抖动窗口聚合，通知队列按优先级隔离，数据按风险冷热分层。五类系统不能共用无上限线程池和队列，但可以共享身份、审计、观测、任务契约和对账框架。容量都从峰值、持续时间、放大和热点计算，扣除故障域后验证核心流量，并保证恢复完成率高于正常到达率。成本都同时看建设、运行、失败与退出，预算不足时先裁剪低价值时效和保留期，不破坏资金、库存和高危告警红线。最终验收看端到端业务结果、未知态与差异年龄、积压恢复、人工量和单位业务成本。这套方法体现分治：每类工作负载按自己的失败成本自治，再由共同不变量和证据闭环组合起来。 口述收尾时，我还会主动说明假设来源、负责人、停止条件和复核日期，并用灰度、故障注入及业务对账逐项验证；一旦流量、依赖限额或失败损失越过阈值，就重开评审并回算容量与成本，避免把阶段性判断当成永久结论。现场回答时我还会补充证据边界和停止线：先说明哪些数字来自真实监控，哪些只是 E3（演练设计）；任何方案只要破坏资金、库存、履约或高危告警不变量，就先停止扩量并回到权威事实查证。
• 追问/直答：① 哪两类最偏强约束？/支付与库存承诺；② 哪类最适合排队？/导出和低优先履约任务；③ 报警如何兼顾不漏与降本？/高危旁路、普通聚合和分层保留；④ 共同验收是什么？/业务结果、收敛年龄、恢复时间和单位成本。
• 延伸：项目组合与综合追问树