候选矩阵、淘汰条件与多模型边界

本册定位：把工作负载卡转成可复算但不迷信分数的选择过程。WMS（仓储管理系统）、支付、跨境物流、Runner（执行器）和 IoT（物联网）仅作为 E2（已有材料映射）的面试方案；所有权重、评分、流量、容量、延迟与成本数字均为 E3（演练证据），不是生产事实。实际版本、账单、团队熟练度与线上指标没有可追溯材料时记为 E0（待核对）。产品底层机制与故障细节链接到存储、搜索与时序入口，本册只负责选型方法。

1. 从问题空间生成候选，而不是从产品清单挑赢家

1.1 候选生成：能力类别、替代路径与基线方案

候选生成先回答“需要哪类能力”，再列产品。每组至少包含现状基线、同类替代和“不引入新组件”三个方向；否则矩阵只是为预设答案背书。交易候选关注不变量与审计，缓存关注可重建与回源，消息关注解耦与恢复，搜索关注全文和复杂过滤，分析关注扫描聚合，时序关注追加写、时间窗和迟到修正。一个产品可以进入多组候选，但必须按不同角色重新评分。

flowchart LR
    A["业务不变量与工作负载"] --> B["能力类别"]
    B --> C["现状基线"]
    B --> D["同类替代"]
    B --> E["架构替代"]
    B --> F["不新增组件"]
    C --> G["候选池"]
    D --> G
    E --> G
    F --> G
    G --> H["硬约束门禁"]

图解读：节点从业务问题展开到四种候选来源；箭头表示候选必须回溯到能力而不是品牌。前提是工作负载和不变量已在第 00 章登记。正常路径生成含基线的候选池；失败路径是遗漏“不做”方案后把新增复杂度当成免费；结论是候选完整性先于评分精度。

数据演绎 1：候选覆盖率不等于候选数量

E3（演练证据）：某物流查询评审列出 Elasticsearch（搜索引擎）、ClickHouse（列式数据库）、MongoDB（文档数据库）三个产品，看似有 3 个候选，但现状数据库查询、增加只读投影和不新增组件均未列入，四类来源只覆盖 1 / 4 = 25%。补齐基线、同类、架构替代和不做选项后，即使仍只保留 4 个方向，覆盖率也为 4 / 4 = 100%。该比例只检查讨论空间，不证明任何候选可用。

热门面试题

1. 问题：为什么候选池必须包含现状方案？
   • 考点：基线比较。
   • 回答思路：新方案的收益必须覆盖迁移和运行成本。
   • 详细答案：没有现状基线，团队只能比较新产品之间的相对优劣，无法证明“保持现状并优化”是否更便宜、更可逆。基线还提供真实故障、技能和成本证据，是后续 POC（概念验证）的对照组。
   • 进阶追问：现状明显很差还要保留吗？
   • 进阶回答：要保留为对照，但若违反硬约束可在门禁阶段淘汰，并记录违反项而非给低分。
2. 问题：产品候选与架构候选有什么区别？
   • 考点：问题分解。
   • 回答思路：前者换实现，后者重分职责。
   • 详细答案：把 MySQL（关系型数据库）换成另一交易库属于产品替代；保留交易库并增加可重建搜索投影属于架构替代。后者改变数据流、一致性和恢复责任，不能与单产品分数混成同一行。
   • 进阶追问：什么时候优先架构替代？
   • 进阶回答：当同一模型同时承担互相冲突的交易、全文检索和聚合负载时，先拆职责通常比寻找万能产品更可验证。
3. 问题：如何避免候选生成被个人偏好控制？
   • 考点：评审治理。
   • 回答思路：按能力来源枚举并要求反例。
   • 详细答案：先冻结需求、候选生成规则和证据等级，再由不同角色补充现状、替代、分层与不做选项。每个提名人同时写不适用条件，评审人才能发现“只提熟悉产品”的选择偏差。
   • 进阶追问：候选越多越好吗？
   • 进阶回答：不是。覆盖主要机制后应合并同质候选，把验证预算留给结论可能翻转的差异。

1.2 硬约束淘汰：不可补偿条件先于权重

硬约束是违反后不能用其他优点抵消的资格条件。支付账务无法审计、库存无法原子保护不变量、敏感数据地域不合规、故障后没有可执行恢复路径，都应直接淘汰或降为派生角色。未知不是自动通过：高失败成本条件若为 E0（待核对），候选进入“暂停验证”，不得带着乐观分数参加排名。

sequenceDiagram
    participant 评 as 评审组
    participant 候 as 候选方案
    participant 证 as 证据库
    participant 分 as 加权评分
    评->>候: 逐项提交门禁证明
    候->>证: 正确性 合规 恢复 责任
    alt 全部门禁通过
        证-->>评: 可比较
        评->>分: 进入评分
    else 高风险证据未知
        证-->>评: 暂停并安排验证
    else 明确违反硬约束
        证-->>评: 淘汰或降为派生角色
    end

图解读：评审组、候选、证据库和评分阶段构成资格链。正常路径是全部硬约束有证据后才打分；失败路径分为未知暂停和明确淘汰；前提是门禁在看到总分前冻结；结论是高性能不能抵消不可恢复或不合规。

数据演绎 2：门禁不允许用总分抵消

E3（演练证据）：候选甲在性能、成本、易用性三项各得 5 分，权重分别为 40%、30%、30%，加权分为 5.00；但它不能提供支付审计链，正确性门禁为 0。候选乙三项各为 3 分，加权分只有 3.00，但通过门禁。结论必须是甲淘汰、乙继续比较，而不是甲凭 5.00 > 3.00 胜出。

热门面试题

1. 问题：什么条件应该直接淘汰而不打分？
   • 考点：不可补偿决策。
   • 回答思路：从不变量、法律和恢复底线判断。
   • 详细答案：只要违反后会造成不可接受且无法由其他收益补偿的结果，例如资金不可审计、库存约束无法守住、数据地域违法或关键事实不可恢复，就应直接淘汰。低成本和高吞吐只属于偏好，不能交换这些底线。
   • 进阶追问：团队不熟悉算硬约束吗？
   • 进阶回答：关键链路无人值守且期限内无法补齐能力时可成为门禁；若有培训、托管或缩小范围的可信计划，则作为风险评分。
2. 问题：硬约束未知时为什么不能先给中间分？
   • 考点：证据边界。
   • 回答思路：未知不是满足，也不是普通偏好。
   • 详细答案：给中间分会让其他高分掩盖关键证据缺口。正确动作是标 E0（待核对）、指定取证人和期限，验证前保持暂停；只有低失败成本且有明确回退的试点才可带条件前进。
   • 进阶追问：期限很紧怎么办？
   • 进阶回答：缩小数据和流量范围、保留旧路径并优先验证最高损失门禁，不能把时间压力改写成通过证据。
3. 问题：淘汰与降为派生角色有什么区别？
   • 考点：多模型边界。
   • 回答思路：按责任而非产品做结论。
   • 详细答案：某候选不适合承载交易主事实，不代表它不能做搜索或分析副本。降级角色要求权威源仍能守住不变量，派生数据可校验、可回放、可重建，且故障不会反向污染主事实。
   • 进阶追问：派生层也要过门禁吗？
   • 进阶回答：要，但门禁不同，重点转为权限、删除传播、可重建、延迟边界和降级能力。

2. 加权矩阵、敏感性分析与结论翻转

2.1 加权决策矩阵：公式、责任人与可复算记录

通过门禁后，矩阵将偏好显式化。设第 i 项权重为 w_i、候选在该项得分为 s_i，总分 S = Σ(w_i × s_i)，且 Σw_i = 100%。权重由承担失败成本的业务、运行、安全和技术角色共同确认；评分由能解释证据的人填写。矩阵必须保留版本、日期、输入和未决项，不能只贴最终排名。

评分采用 E3（演练证据）的 1 至 5 级离散标尺：1 表示明显不适配但尚未触碰门禁，3 表示经验证可接受，5 表示对当前工作负载有显著优势。每个分数同时记录理由与 E0（待核对）至 E3（演练证据）的证据等级；适配度回答“好不好”，证据等级回答“信不信”，二者不得混成一个分数。高分但证据弱的分项优先进入 POC（概念验证）。

flowchart LR
    A["已通过门禁的候选"] --> B["冻结指标定义"]
    B --> C["确认权重总和百分之百"]
    C --> D["逐项评分与证据"]
    D --> E["计算加权总分"]
    E --> F["执行敏感性分析"]
    F --> G["记录选择与不选理由"]

图解读：节点给出矩阵从输入到决策记录的完整链路。正常路径在计算后继续做敏感性分析；失败路径是权重无人负责或分数没有证据时暂停；前提是候选已过门禁；结论是总分只是中间产物，不是自动决策器。

数据演绎 3：手工复算加权分

E3（演练证据）：某候选在正确性适配、查询适配、运行复杂度、成本四项得分为 5、4、3、2，权重为 35%、30%、20%、15%。总分为 5×0.35 + 4×0.30 + 3×0.20 + 2×0.15 = 3.85。若表格显示 4.05，即使排序不变也必须纠错，因为不可复算的矩阵无法进入决策记录。

热门面试题

1. 问题：权重应由架构师一个人决定吗？
   • 考点：决策责任。
   • 回答思路：权重代表失败成本与业务偏好。
   • 详细答案：架构师负责组织和检查独立性，但支付正确性、恢复时限、运行负担和预算分别由业务、财务、运行与安全角色承担。让单人定权重会把个人技术偏好伪装成组织取舍。
   • 进阶追问：多人意见无法统一怎么办？
   • 进阶回答：展示不同权重情景下的排名和损失，由有授权的责任人决策，并记录少数意见与复审条件。
2. 问题：为什么总分最高不等于必须选择？
   • 考点：模型边界。
   • 回答思路：矩阵压缩了不确定性和不可逆后果。
   • 详细答案：总分可能对权重轻微变化敏感，也可能由弱证据高分驱动，还无法表达候选组合、迁移窗口与不可逆成本。决策人必须结合分差、敏感性、证据、反例和退出路径解释最终选择。
   • 进阶追问：何时可以直接按排名？
   • 进阶回答：候选都过门禁、分差稳定、关键分数证据充分、迁移风险相近且责任人认可时，排名可作为强输入。
3. 问题：如何避免重复指标放大偏好？
   • 考点：指标独立性。
   • 回答思路：检查因果重叠。
   • 详细答案：若“吞吐”“性能”“响应速度”都来自同一能力，就会重复加权。应回到工作负载拆成可区分的写入、查询长尾或恢复吞吐，并说明每项对应不同失败后果。
   • 进阶追问：指标越少越好吗？
   • 进阶回答：不是，以覆盖关键偏好且彼此可解释为准；遗漏恢复和团队能力同样会让矩阵失真。

2.2 敏感性分析：找到翻转阈值而不是只报排名

敏感性分析回答“结论依赖哪个假设”。常用方法是单因素改权重、情景组合和临界点求解：保持其他输入不变，逐步提高一个有争议权重，观察第一名何时变化；再用高峰、故障、团队缩编等组合情景重算。若很小变化就翻转，应把结论写成“条件性选择”，并优先验证造成翻转的分项。

sequenceDiagram
    participant 评 as 评审人
    participant 基 as 基准矩阵
    participant 情 as 情景矩阵
    participant 验 as 验证计划
    评->>基: 读取基准权重与分数
    loop 改变争议输入
        基->>情: 重算排名与分差
        情-->>评: 是否翻转
    end
    alt 小幅变化即翻转
        评->>验: 验证敏感分项并保留双方案
    else 大幅变化仍稳定
        评->>验: 验证关键门禁与退出
    end

图解读：基准矩阵被多个情景重复计算。正常路径输出翻转阈值；失败路径是把单一权重当成永恒事实；前提是评分标尺不随情景偷偷变化；结论是稳定性比分数的小数位更有决策价值。

数据演绎 4：权重变化导致结论翻转

E3（演练证据）：候选甲在查询能力得 5 分、运行简洁得 2 分，候选乙分别得 3 分和 5 分。若查询权重为 60%、运行权重为 40%，甲为 3.8，乙为 3.8；查询权重升到 70% 时，甲为 4.1、乙为 3.6；降到 50% 时，甲为 3.5、乙为 4.0。翻转点正是 60%，因此应先确认查询收益是否真的值得超过六成偏好。

热门面试题

1. 问题：为什么必须写结论翻转条件？
   • 考点：决策适用边界。
   • 回答思路：选择只在一组假设下成立。
   • 详细答案：业务规模、团队和合规会变化。写明哪个权重、分数或门禁变化会让第二名胜出，才能在条件发生时复审，也能防止团队把一次评分当成永久技术标准。
   • 进阶追问：所有权重都要扫描吗？
   • 进阶回答：优先扫描分差大、证据弱、争议高和失败成本高的项，其余做合理区间检查即可。
2. 问题：两候选分差很小应怎么处理？
   • 考点：不确定性决策。
   • 回答思路：比较可逆性并验证敏感项。
   • 详细答案：小分差意味着模型不足以给强结论。应保留两者，验证最能造成翻转的假设，并优先选择迁移更小、团队更熟或退出更容易的方案，而不是继续调整小数制造赢家。
   • 进阶追问：可以并行使用两个吗？
   • 进阶回答：只有职责天然可拆且同步、校验、运行成本被证明值得时可以，不能为逃避决策制造重复主事实。
3. 问题：敏感性分析与压力测试有什么不同？
   • 考点：模型与实验边界。
   • 回答思路：前者重算判断，后者观测系统。
   • 详细答案：敏感性分析在决策模型内改变权重或输入，发现结论依赖；压力测试对实现施加载荷，产生可复现运行证据。前者指导测什么，后者可修正评分，二者不能相互替代。
   • 进阶追问：先做哪个？
   • 进阶回答：先用敏感性定位高价值未知，再把有限实验预算投入可能翻转结论的项。

3. 六类场景可复算矩阵

3.1 交易场景：主事实、事务、审计与恢复

交易候选首先通过不变量、审计和恢复门禁。下面比较 MySQL（关系型数据库）、PostgreSQL（关系型数据库）与 MongoDB（文档数据库）的演练适配度，不代表产品绝对能力。场景假设是 WMS（仓储管理系统）库存和支付状态以结构化主事实、条件更新、唯一约束和对账为核心；文档灵活性属于偏好，不能抵消跨记录不变量。

以上权重、分数与总分均为 E3（演练证据）。同分时不继续制造小数：若现有团队 MySQL（关系型数据库）运行证据为 E1（源码与可复现证据）而 PostgreSQL（关系型数据库）经验为 E0（待核对），基准方案优先 MySQL（关系型数据库）；若复杂查询与标准能力权重提高且团队能力补齐，结论可翻转。

sequenceDiagram
    participant 命 as 业务命令
    participant 门 as 交易门禁
    participant 矩 as 候选矩阵
    participant 主 as 权威交易库
    participant 对 as 对账恢复
    命->>门: 不变量 审计 恢复要求
    门->>矩: 仅放行合格候选
    矩->>主: 选择结构化主事实
    主->>对: 提交日志与业务流水
    alt 校验一致
        对-->>命: 交易闭环
    else 差异或未知态
        对->>主: 查证 补偿 人工接管
    end

图解读：命令先过交易门禁，再由矩阵选择权威库。正常路径提交后进入对账；失败路径由差异和未知态触发查证；前提是搜索和缓存不参与最终裁决；结论是交易选型的核心是守住并证明不变量。

数据演绎 5：交易矩阵的翻转情景

E3（演练证据）：基准权重下 MySQL（关系型数据库）与 PostgreSQL（关系型数据库）均为 4.60。若团队运行权重从 20% 降至 10%，查询适配从 15% 升至 25%，其他不变，则 MySQL（关系型数据库）为 4.50，PostgreSQL（关系型数据库）为 4.80，结论翻转。若跨记录约束门禁不通过，则 MongoDB（文档数据库）不参与该轮计算，而不是保留 3.15 竞争。

热门面试题

1. 问题：交易主库为什么不能只按吞吐选？
   • 考点：主事实责任。
   • 回答思路：先保证可证明的正确性与恢复。
   • 详细答案：支付和库存错误的失败成本不是响应慢，而是错账、重复扣减或无法追溯。吞吐属于通过正确性、审计、恢复门禁后的偏好，还要结合热点、事务范围和对账路径验证。
   • 进阶追问：高吞吐候选一定淘汰吗？
   • 进阶回答：不一定，可作为派生写模型或特定边界内的主事实，但必须缩小不变量范围并证明恢复。
2. 问题：MySQL（关系型数据库）与 PostgreSQL（关系型数据库）同分怎么选？
   • 考点：同分决策。
   • 回答思路：回到证据、迁移和敏感项。
   • 详细答案：比较现有数据、团队值守、查询需求、迁移窗口和退出成本。若当前 MySQL（关系型数据库）已经有可复现运行证据，且新能力不是硬需求，保持基线更可逆；若查询能力权重提高并完成运行验证，PostgreSQL（关系型数据库）可胜出。
   • 进阶追问：能双主并存吗？
   • 进阶回答：不能仅因同分就双主，重复权威源会引入冲突；迁移双写也必须有唯一裁决和结束日期。
3. 问题：文档数据库何时能承载交易事实？
   • 考点：聚合边界。
   • 回答思路：不按标签否定，检查不变量范围。
   • 详细答案：当业务不变量能封闭在单一聚合、确认语义和唯一约束满足、审计恢复可验证、团队能处理分片与副本故障时可以进入候选。跨聚合资金守恒仍需额外账务和对账设计。
   • 进阶追问：模式灵活是决定性优势吗？
   • 进阶回答：只有字段演进是主要失败成本时才可能成为高权重优势，不能抵消事务和恢复缺口。

3.2 缓存场景：可重建、失效、热点与回源

缓存不是更快的主库，而是可以丢弃并从权威源恢复的读模型或计算结果。候选包括 Redis（远程字典服务）、进程内缓存和不设缓存直接优化主库。门禁是权威源仍可用、缓存值有版本或失效语义、不可用时回源受控；若丢缓存就无法恢复库存或支付状态，应先纠正数据责任，不进入评分。

以上为 E3（演练证据）。多实例热点查询下 Redis（远程字典服务）胜出；单实例只读字典若把延迟和运行简洁合计权重提高到 70%，进程内缓存可能翻转；低流量支付状态查询若一致性和回源权重提高，不设缓存可能更优。

sequenceDiagram
    participant 用 as 调用方
    participant 缓 as 缓存候选
    participant 主 as 权威源
    participant 护 as 回源保护
    用->>缓: 按业务键读取
    alt 命中且版本有效
        缓-->>用: 返回派生值
    else 未命中或失效
        缓->>护: 合并 限流 排队
        护->>主: 读取权威事实
        主-->>护: 值与版本
        护->>缓: 回填并设置失效语义
        护-->>用: 返回权威结果
    end
    alt 缓存不可用
        用->>护: 受控降级而非无限回源
    end

图解读：缓存命中是正常快路径，未命中经回源保护访问权威源。失败路径是缓存不可用时限流降级；前提是缓存可丢弃、可重建；结论是回源上限和版本语义与延迟同等重要。

数据演绎 6：缓存矩阵与击穿容量

E3（演练证据）：热点读取输入为每秒 2,000 次，命中率从 99% 降到 70%，回源从 2,000×1%=20 次/秒升至 2,000×30%=600 次/秒。若主库安全回源上限演练为 150 次/秒，缺口是 600-150=450 次/秒，必须合并、排队或拒绝。该失败直接影响“回源降级”评分，不证明 Redis（远程字典服务）本身错误。

热门面试题

1. 问题：什么情况下 Redis（远程字典服务）应直接退出候选？
   • 考点：缓存边界。
   • 回答思路：看它是否被迫承担不可重建主事实。
   • 详细答案：若业务要求以缓存中的支付或库存值作最终裁决，且缓存丢失后没有权威流水、版本和对账恢复，就违反主事实门禁。应先补权威源或改变职责，而不是用持久化参数掩盖边界错误。
   • 进阶追问：开启持久化就能变主库吗？
   • 进阶回答：不能自动成立，还要证明事务、不变量、审计、复制故障语义、备份恢复和团队能力。
2. 问题：进程内缓存为何可能在敏感性分析中胜出？
   • 考点：工作负载适配。
   • 回答思路：单实例、只读、小数据时共享能力价值下降。
   • 详细答案：若数据很小、变化少、每个实例可独立加载且不要求跨实例一致，进程内缓存延迟和运行简洁优势更重要。实例增多、热点变化或失效需要统一后，权重会转向 Redis（远程字典服务）。
   • 进阶追问：如何处理更新？
   • 进阶回答：使用版本化配置、通知失效或短生命周期，并保留回源；无法证明传播时延时不缓存关键状态。
3. 问题：缓存事故后应该换产品还是改设计？
   • 考点：故障归因。
   • 回答思路：先查责任边界、热点和回源链。
   • 详细答案：先取证命中率、热点键、失效时间、回源并发、版本差异和主库水位。若是同时过期、无限重试或缺少请求合并，应修设计；只有候选机制长期无法满足共享、容量或恢复边界时才重开选型。
   • 进阶追问：止血动作是什么？
   • 进阶回答：保护主库优先，限制热点、合并回源、延长非关键旧值并对关键事实回退权威查询。

3.3 消息场景：解耦、顺序、回放与恢复吞吐

消息候选需要先证明事件有权威出处、生产与本地事实不会静默分叉、消费可幂等、积压可恢复。下面比较 Kafka（分布式日志消息系统）、RocketMQ（分布式消息队列）和 RabbitMQ（消息队列）。若支付成功只写消息而没有本地事实或 Outbox（发件箱）记录，任何中间件都直接违反门禁；矩阵只比较通过可靠生产边界后的路由、回放、顺序、运行和恢复偏好。

以上均为 E3（演练证据）。支付后通知库存、物流和积分且重视顺序与业务语义时，RocketMQ（分布式消息队列）在本情景胜出；日志与轨迹长期回放权重提高时 Kafka（分布式日志消息系统）翻转；复杂路由、小规模任务分发且回放权重降低时 RabbitMQ（消息队列）可能胜出。

sequenceDiagram
    participant 交 as 交易服务
    participant 本 as 本地事实与发件箱
    participant 消 as 消息候选
    participant 库 as 库存消费者
    participant 物 as 物流消费者
    participant 对 as 差异校验
    交->>本: 同事务提交业务与事件
    本->>消: 发布稳定业务键和版本
    par 独立消费
        消->>库: 幂等更新库存流程
        消->>物: 幂等创建履约流程
    end
    库-->>对: 消费水位与结果
    物-->>对: 消费水位与结果
    alt 差异存在
        对->>消: 从检查点回放
    end

图解读：交易先把业务事实与 Outbox（发件箱）同事务提交，再发布给多个消费者。正常路径各自幂等并上报水位；失败路径从检查点回放；前提是消息不是唯一事实；结论是产品分数不能替代生产一致性和消费收敛设计。

数据演绎 7：消息积压恢复与矩阵翻转

E3（演练证据）：故障期间生产每秒 1,200 条、消费为 0，持续 600 秒，积压为 720,000 条。恢复后生产仍为每秒 1,200 条，消费者总吞吐为每秒 3,000 条，净清理为每秒 1,800 条，理论清理时间 720,000 / 1,800 = 400 秒。若恢复目标是 300 秒，候选即使总分最高也需扩容或淘汰；若回放吞吐权重从 25% 升至 45%、业务路由降至 10%、顺序延迟降至 10%，Kafka（分布式日志消息系统）为 4.20，RocketMQ（分布式消息队列）为 4.10，排名翻转。

热门面试题

1. 问题：Kafka（分布式日志消息系统）和 RocketMQ（分布式消息队列）怎么选？
   • 考点：工作负载与恢复。
   • 回答思路：比较回放、顺序、路由、延迟和团队。
   • 详细答案：持续事件流、长保留和高回放价值会提高 Kafka（分布式日志消息系统）的权重；交易事件、顺序、延迟和业务语义治理可能提高 RocketMQ（分布式消息队列）的权重。两者都必须先证明可靠生产、幂等消费、积压恢复和运维能力。
   • 进阶追问：吞吐更高就选 Kafka（分布式日志消息系统）吗？
   • 进阶回答：不能，若业务主要损失来自顺序、延迟或运维复杂度，吞吐优势未必能改变总决策。
2. 问题：什么时候消息方案应直接淘汰？
   • 考点：可靠性门禁。
   • 回答思路：看事实、幂等和恢复是否闭环。
   • 详细答案：本地提交与发布可能静默分叉且无扫描补发、消费者副作用不能幂等、原始事件无法保留或积压无法在目标内恢复时，应直接淘汰当前设计。换产品不能修复缺少业务键和对账。
   • 进阶追问：允许消息重复吗？
   • 进阶回答：传输可重复，但业务效果必须通过唯一键、状态检查或幂等记录收敛。
3. 问题：消息积压一定说明选型错误吗？
   • 考点：故障归因。
   • 回答思路：区分实现退化、容量不足和机制边界。
   • 详细答案：先看生产、消费、分区热点、下游延迟、死信和重试放大。代码退化或临时资源不足可修复；长期无法扩展、不可回放或恢复时间持续越界才触发重新选型。
   • 进阶追问：积压清零算恢复吗？
   • 进阶回答：不算，还要核对重复副作用、死信、业务状态和主副本差异是否归零。

3.4 搜索场景：全文、过滤、相关性与可重建索引

搜索层服务跨字段过滤、全文召回、相关性和排序，不拥有订单、资金或库存最终状态。候选比较 Elasticsearch（搜索引擎）、PostgreSQL（关系型数据库）内置检索和 MySQL（关系型数据库）有限查询。门禁是搜索索引可从权威源或事件重建、删除与权限能传播、延迟有边界、索引不可用时有降级；若搜索结果反向修改主状态，直接淘汰该职责设计。

以上为 E3（演练证据）。跨境物流全文和多条件查询下 Elasticsearch（搜索引擎）仅领先 0.10，结论敏感；若运行简洁从 20% 升到 30%、全文相关性从 30% 降到 20%，PostgreSQL（关系型数据库）以 3.90 超过 Elasticsearch（搜索引擎）的 3.70。

sequenceDiagram
    participant 主 as 订单与轨迹权威源
    participant 事 as 已提交事件
    participant 索 as 搜索索引
    participant 查 as 查询服务
    participant 校 as 校验任务
    主->>事: 输出业务键 版本 删除标记
    事->>索: 幂等建立文档
    查->>索: 全文 过滤 排序
    索-->>查: 结果与索引版本
    索-->>校: 数量 版本 权限摘要
    alt 延迟或差异越界
        校->>事: 从水位回放或全量重建
        查->>主: 降级到有限精确查询
    end

图解读：权威源通过已提交事件构建搜索索引，查询服务只读取派生结果。正常路径持续校验；失败路径回放、重建并降级主库有限查询；前提是业务键、版本和删除标记完整；结论是搜索能力越强，越需要证明可重建和权限一致。

数据演绎 8：索引重建窗口决定候选资格

E3（演练证据）：物流索引有 120,000,000 条文档，演练重建吞吐每秒 20,000 条，全量基础时间为 120,000,000 / 20,000 = 6,000 秒，即 100 分钟；期间增量每秒 2,000 条，产生 12,000,000 条，按同吞吐追平需 600 秒。忽略切换校验的理论下界为 110 分钟。若业务恢复上限为 90 分钟，该候选不通过恢复门禁，不能靠相关性 5 分补偿。

热门面试题

1. 问题：为什么订单主数据不建议直接放 Elasticsearch（搜索引擎）？
   • 考点：权威源边界。
   • 回答思路：搜索可见不等于业务提交。
   • 详细答案：搜索系统擅长倒排、过滤与相关性，但刷新可见、分片恢复和更新语义不等同于交易事务、唯一约束和账务审计。订单主事实应由能守住状态机和恢复的系统负责，Elasticsearch（搜索引擎）作为可重建读模型。
   • 进阶追问：索引延迟时怎么办？
   • 进阶回答：展示更新时间，关键精确查询降级权威源，并从事件水位回放，不伪造最新状态。
2. 问题：何时不需要独立搜索引擎？
   • 考点：复杂度控制。
   • 回答思路：查询简单、规模可控、团队有限时保留基线。
   • 详细答案：若主要是主键、少量组合条件和小规模文本匹配，现有关系库通过索引即可满足，独立搜索的同步、权限、重建和运行成本可能超过收益。敏感性分析中运行简洁权重会推动关系库胜出。
   • 进阶追问：未来增长怎么办？
   • 进阶回答：保留事件和投影接口，达到查询或资源阈值后再引入，而不是提前承担永久复杂度。
3. 问题：搜索切换为什么要保留旧索引？
   • 考点：可逆迁移。
   • 回答思路：新索引需要差异观察窗口。
   • 详细答案：新旧索引在映射、分词、权限和删除传播上可能产生非预期差异。小流量切读并保留旧索引，才能在差异越界时快速回退，而不把重建失败扩散到所有用户。
   • 进阶追问：什么时候下线旧索引？
   • 进阶回答：新索引通过总量、字段、权限、查询和删除校验，且覆盖约定观察与回放窗口后。

3.5 分析场景：扫描聚合、资源隔离与口径重算

分析层消费已确认事实，承担宽表扫描、维度聚合和历史重算，不得阻塞交易写入或反向成为资金裁决。候选比较 ClickHouse（列式数据库）、PostgreSQL（关系型数据库）分析副本和 Elasticsearch（搜索引擎）聚合。门禁是口径可版本化、原始事实可回放、资源与交易隔离、权限可审计；只有聚合结果而没有明细或口径定义时直接淘汰。

以上为 E3（演练证据）。大规模明细扫描时 ClickHouse（列式数据库）胜出；若数据量小、查询固定且团队运行权重从 15% 提高到 35%，扫描聚合从 35% 降到 20%，批量写入从 20% 降到 15%，PostgreSQL（关系型数据库）可从 3.70 升到 4.10，ClickHouse（列式数据库）降到 3.65，结论翻转。

sequenceDiagram
    participant 事 as 权威业务事件
    participant 明 as 分析明细
    participant 聚 as 聚合模型
    participant 报 as 报表查询
    participant 核 as 口径核对
    事->>明: 批量写业务键 时间 金额
    明->>聚: 按版本口径计算
    报->>聚: 查询维度与周期
    聚-->>报: 结果与口径版本
    聚-->>核: 明细数 金额和 水位
    alt 口径变化或差异
        核->>明: 冻结版本并重算窗口
        明->>聚: 覆盖新版本结果
    end

图解读：权威事件先沉淀分析明细，再按口径版本聚合。正常路径报表携带口径；失败路径从明细重算而非手工改结果；前提是交易与分析资源隔离；结论是列式性能必须与重算、口径和退出能力一起比较。

数据演绎 9：分析重算窗口与资源预算

E3（演练证据）：需要重算 30 天，每天 80,000,000 行，共 2,400,000,000 行。演练读取和聚合吞吐每秒 400,000 行，理论时间为 2,400,000,000 / 400,000 = 6,000 秒，即 100 分钟；若为保护在线查询只允许使用 50% 资源，时间近似放大为 200 分钟。若业务要求 120 分钟内完成，当前隔离策略下不合格，必须提高重算资源、缩小窗口或改变方案。

热门面试题

1. 问题：ClickHouse（列式数据库）为什么适合报表但不自动适合交易？
   • 考点：存储模型与负载。
   • 回答思路：列式扫描与事务点写是不同目标。
   • 详细答案：列式存储、排序和批量处理能减少宽表聚合的读取，但交易需要细粒度更新、约束、低延迟确认和审计恢复。分析优势不能直接推导为支付或库存主库优势。
   • 进阶追问：能存分析明细事实吗？
   • 进阶回答：可以承载可回放的分析明细，但交易权威和业务不变量仍由来源系统负责。
2. 问题：小数据量为何可能选 PostgreSQL（关系型数据库）分析副本？
   • 考点：总成本。
   • 回答思路：性能收益不足以覆盖新系统复杂度。
   • 详细答案：查询量和数据规模可控、团队已熟悉关系库、重算时间满足目标时，PostgreSQL（关系型数据库）的运行简洁、事务能力和工具复用可能更有价值。只有扫描瓶颈成为主要失败成本时才提高列式权重。
   • 进阶追问：如何保留演进空间？
   • 进阶回答：保留原始事件、口径版本和批量导出边界，使后续可重建新分析副本。
3. 问题：分析结果与账务不一致先信谁？
   • 考点：权威性与对账。
   • 回答思路：先按数据责任定位差异。
   • 详细答案：资金最终状态以账务权威源为准，分析结果用于发现异常。应比较事件水位、过滤口径、迟到、重复和版本，修正派生模型；不能用报表覆盖账务事实。
   • 进阶追问：差异归零就结束吗？
   • 进阶回答：还要记录根因、受影响窗口、重算版本和防复发校验，避免下一批再次偏离。

3.6 时序场景：摄入、时间窗、高基数与迟到修正

时序场景以时间戳、标签、数值、追加写、窗口查询和保留策略为核心。候选比较 ClickHouse（列式数据库）、PostgreSQL（关系型数据库）分区表与 Elasticsearch（搜索引擎）。IoT（物联网）报警事实必须保留稳定事件标识和来源；聚合、降采样与最新值都是派生模型。无法处理乱序、迟到修正或高基数导致不可控资源风险的候选应暂停或淘汰。

以上为 E3（演练证据）。高频设备事件和大窗口聚合使 ClickHouse（列式数据库）胜出；若设备规模小、需要事务关联且团队运行权重提高，PostgreSQL（关系型数据库）可能翻转。Elasticsearch（搜索引擎）只有在日志搜索与时序检索共同占主导、并证明高基数和恢复边界时才保持候选资格。

sequenceDiagram
    participant 设 as 设备事件
    participant 原 as 原始时序事实
    participant 窗 as 窗口聚合
    participant 告 as 告警规则
    participant 修 as 迟到修正
    设->>原: 事件标识 事件时间 标签 数值
    原->>窗: 按事件时间聚合
    窗->>告: 输出窗口统计与版本
    alt 关键阈值越界
        告-->>设: 记录告警事实并通知
    end
    alt 迟到或乱序到达
        原->>修: 定位受影响窗口
        修->>窗: 重算并递增版本
        窗->>告: 更正状态并保留历史
    end

图解读：原始事件先落权威时序事实，再生成窗口聚合和告警。正常路径按事件时间计算；失败路径由迟到乱序触发重算和版本更正；前提是原始事件可追溯；结论是最新值和告警不能只靠覆盖写。

数据演绎 10：时序摄入、保留与高基数放大

E3（演练证据）：50,000 台设备每 10 秒上报 8 个指标，摄入为 50,000×8/10=40,000 点/秒；每点压缩后演练按 24 字节，单日约 40,000×86,400×24=82,944,000,000 字节，约 82.94 GB（十亿字节），保留 30 天约 2.49 TB（万亿字节），尚未计副本和索引。若把请求标识作为标签导致每天新增数百万序列，高基数门禁可能直接失败，不应靠总分掩盖。

热门面试题

1. 问题：时序数据为什么要区分事件时间和到达时间？
   • 考点：乱序与窗口。
   • 回答思路：业务发生顺序与系统接收顺序不同。
   • 详细答案：网络、设备离线和批量补传会让到达顺序偏离真实发生顺序。窗口聚合若只用到达时间会把迟到事件放错区间，因此要保存事件时间、到达时间和版本，并定义可修正窗口。
   • 进阶追问：修正会重复告警吗？
   • 进阶回答：告警使用稳定业务键和状态版本，区分首次触发、更正与恢复，通知侧幂等并保留历史。
2. 问题：高基数为什么可能成为直接淘汰条件？
   • 考点：资源上界。
   • 回答思路：标签组合会放大索引和内存。
   • 详细答案：若用户、请求或随机标识进入标签，每个组合都可能形成新序列，资源增长与事件数不同阶。候选无法给出基数上限、拒绝策略和迁移路径时，生产风险不可控，应暂停验证或淘汰。
   • 进阶追问：明细还要保留吗？
   • 进阶回答：关键原始事件按审计和恢复要求保留，查询用低基数标签、降采样和冷热分层，不把随机字段设为索引维度。
3. 问题：IoT（物联网）报警风暴如何影响选型权重？
   • 考点：突发负载与优先级。
   • 回答思路：提高摄入、背压、聚合和恢复权重。
   • 详细答案：风暴时关键不是平均写入，而是突发摄入、窗口聚合、优先级、通知背压和事件追溯。若候选日常查询优秀但峰值时丢原始事实或无法恢复，就不能通过门禁。
   • 进阶追问：聚合会掩盖高危事件吗？
   • 进阶回答：高危规则走独立保留和通知路径，低危重复才允许窗口聚合，二者分别验收。

4. 多模型权威边界、重建策略与反例

4.1 权威源与派生模型：唯一裁决、版本和一致性

多模型不是多份主数据。交易库拥有订单、库存、支付和账务的最终裁决；Redis（远程字典服务）保存可失效缓存；MQ（消息队列）承载已提交事件；Elasticsearch（搜索引擎）承载检索投影；ClickHouse（列式数据库）承载分析和时序投影。跨模型一致性依靠稳定业务键、单调版本、幂等写、事件水位、删除传播和差异校验，不追求把所有系统绑进一个全局事务。

sequenceDiagram
    participant 命 as 业务命令
    participant 权 as 交易权威源
    participant 事 as 已提交事件
    participant 缓 as 缓存投影
    participant 搜 as 搜索投影
    participant 分 as 分析时序投影
    participant 校 as 一致性校验
    命->>权: 条件更新并提交版本
    权-->>命: 返回权威结果
    权->>事: 发布已提交变化
    par 构建派生模型
        事->>缓: 失效或更新版本
        事->>搜: 幂等索引
        事->>分: 批量写明细与窗口
    end
    缓-->>校: 版本与抽样值
    搜-->>校: 水位与删除摘要
    分-->>校: 明细和聚合摘要
    alt 差异越界
        校->>事: 回放指定范围
        命->>权: 降级读取权威事实
    end

图解读：交易权威源先提交，再由事件并行构建三类派生模型。正常路径用版本和摘要校验；失败路径回放并降级权威读取；前提是唯一裁决不变；结论是最终一致性必须有可测水位和恢复动作，不是“等一会儿就好”。

数据演绎 11：版本水位与差异收敛

E3（演练证据）：权威源某批次版本区间为 1 至 1,000,000，搜索水位为 998,000，差距 2,000；消费净追平每秒 500 个版本，理论追平 2,000/500=4 秒。抽样 10,000 个业务键发现 25 个字段差异，差异率 25/10,000=0.25%。即使水位追平，字段差异未低于演练阈值 0.05% 也不能切读，需定位映射或删除传播问题。

热门面试题

1. 问题：多模型系统如何定义唯一权威源？
   • 考点：数据所有权。
   • 回答思路：按业务不变量指定唯一裁决者。
   • 详细答案：对每个事实写清谁接受命令、谁校验状态、谁产生版本、冲突时信谁。库存可售、支付入账和订单状态各自有领域权威；搜索、缓存和分析只能消费已提交变化，不能反向改写裁决。
   • 进阶追问：多个领域能有不同权威源吗？
   • 进阶回答：可以，但每个事实只能有明确所有者，跨领域通过契约和事件协作，不能共享一张无人负责的主表。
2. 问题：最终一致性怎样证明而不是口头承诺？
   • 考点：可观测收敛。
   • 回答思路：定义水位、版本、差异与恢复时限。
   • 详细答案：记录来源提交版本、派生消费水位、端到端延迟、重复和死信；按业务键比较数量、字段、金额和删除状态。越界后能回放指定范围并再次校验，才构成可证明收敛。
   • 进阶追问：全量行数相等够吗？
   • 进阶回答：不够，重复和遗漏可能互相抵消，还需字段摘要、关键聚合、版本与删除校验。
3. 问题：为什么不建议跨所有模型做全局事务？
   • 考点：耦合与可用性。
   • 回答思路：派生职责允许有界延迟并可重建。
   • 详细答案：把缓存、搜索和分析都纳入同步提交会放大延迟、故障域和恢复复杂度。主事实本地守住不变量，派生通过事件、幂等和校验收敛，更符合各模型的责任和失败成本。
   • 进阶追问：用户要求立刻搜到怎么办？
   • 进阶回答：关键写后读可临时查询权威源或合并本次结果，同时显示索引状态，不改变全局责任边界。

4.2 重建策略：全量快照、增量回放、校验与切换

可重建不是“理论上能重跑”，而是明确输入、顺序、吞吐、检查点、校验、切流和回退。缓存可直接失效回源；搜索通常用全量快照建立新索引，再追增量并灰度切读；分析和时序按事实明细与口径版本重算；消息消费者从保留期内检查点回放。若源数据保留期短于重建窗口，候选不具备退出资格。

sequenceDiagram
    participant 权 as 权威源
    participant 快 as 全量快照
    participant 事 as 增量事件
    participant 新 as 新派生模型
    participant 校 as 校验器
    participant 读 as 读流量
    权->>快: 导出冻结水位前数据
    快->>新: 限速全量构建
    事->>新: 从冻结水位后幂等追平
    新-->>校: 数量 字段 权限 删除 水位
    alt 校验通过
        读->>新: 小流量切读
        新-->>校: 新旧结果与长尾
    else 校验失败
        校->>新: 清理或从检查点重放
    end
    alt 灰度越界
        读->>权: 切回旧路径
    end

图解读：全量快照与增量事件在冻结水位汇合。正常路径校验后灰度切读；失败路径回放或切回旧路径；前提是输入保留期覆盖全过程；结论是重建、迁移和退出共用同一套可验证能力。

数据演绎 12：重建期间增量追平是否收敛

E3（演练证据）：全量 300,000,000 条，构建吞吐每秒 50,000 条，基础时间 6,000 秒；期间增量每秒 8,000 条，产生 48,000,000 条。增量回放能力每秒 20,000 条，但新流量仍为每秒 8,000 条，净追平每秒 12,000 条，追平时间 48,000,000/12,000=4,000 秒，总理论下界 10,000 秒。若事件只保留 7,200 秒，重建未结束增量已过期，恢复门禁直接失败。

热门面试题

1. 问题：搜索索引重建为什么要全量加增量？
   • 考点：在线重建。
   • 回答思路：全量期间业务仍在变化。
   • 详细答案：只做全量会在结束时落后整个构建窗口；只回放增量又缺少历史基线。记录冻结水位，全量构建其前数据，再从水位后幂等追平，才能在不中断写入时得到完整新副本。
   • 进阶追问：水位记错怎么办？
   • 进阶回答：以稳定业务键和版本做重叠回放，允许重复但不能遗漏，并用摘要发现边界错误。
2. 问题：如何判断重建真正完成？
   • 考点：验收闭环。
   • 回答思路：水位追平只是一个条件。
   • 详细答案：还要核对总量、字段、关键聚合、权限、删除、查询结果和长尾，并在灰度窗口观察新旧差异。任何不可解释差异都应停止切流。
   • 进阶追问：何时可删除旧副本？
   • 进阶回答：新副本通过验收、回退窗口结束、源数据与回放路径仍可用、审计保留满足后。
3. 问题：事件保留期为什么是选型门禁？
   • 考点：恢复可行性。
   • 回答思路：重建必须拿到全过程输入。
   • 详细答案：若全量构建和追平需要的时间超过事件保留期，早期增量会在消费前消失，新副本永远无法收敛。必须延长保留、提高吞吐或提供另一份可重复输入。
   • 进阶追问：备份能替代事件吗？
   • 进阶回答：备份可提供某时点基线，但之后变化仍需日志或事件连接，并验证顺序和删除语义。

4.3 反例、线上复审与可直接复述的话术

矩阵最危险的反例包括：先定产品再调权重、让高分抵消硬约束、把 E0（待核对）写成 3 分、只展示赢家不写第二名、不做翻转分析、把缓存和索引设为主事实、声称“支持备份”却未演练恢复。线上问题先按实现、容量、工作负载漂移和责任边界分层取证，只有原决策前提长期失效才重新选型。

flowchart TD
    A["线上异常"] --> B["冻结时间线与证据"]
    B --> C{"硬约束是否受损"}
    C -->|是| D["止损 回退 对账"]
    C -->|否| E{"实现或容量可修复"}
    E -->|是| F["修复并同口径复测"]
    E -->|否| G["重算工作负载与矩阵"]
    G --> H["检查权重翻转与边界"]
    H --> I["保留基线 灰度迁移"]

图解读：异常先冻结证据，再判断硬约束是否受损。正常修复路径不重开选型；失败路径在前提长期失效时重算矩阵并灰度迁移；前提是不以事故情绪替代证据；结论是选型复审是一种受控变更，不是换产品冲动。

数据演绎 13：三类信号触发复审而非一次告警

E3（演练证据）：演练定义连续 3 个观察窗满足任意两项才进入复审：查询 P99（99 分位响应时间）超过目标 30%、恢复时间超过目标 20%、月度资源成本超过基线 25%。某次发布后只有 P99（99 分位响应时间）单窗升高 40%，先回滚实现；若后续 3 窗同时出现 P99（99 分位响应时间）高 35% 和恢复时间高 28%，才重开工作负载、门禁和矩阵。阈值是演练治理规则，不是线上事实。

热门面试题

1. 问题：如何识别“为了选某产品而做矩阵”？
   • 考点：决策偏差。
   • 回答思路：检查候选、权重和证据的时间顺序。
   • 详细答案：若候选不含现状和不做选项、指标专门描述某产品、权重在看到分数后调整、弱项被拆小而强项重复计权，就是结果导向矩阵。应冻结输入、保留修订历史并让失败成本承担者确认。
   • 进阶追问：发现后如何纠正？
   • 进阶回答：撤回排名，从工作负载重新生成能力指标和候选，再由不同角色独立评分。
2. 问题：线上变慢就应该重新选型吗？
   • 考点：复审触发。
   • 回答思路：先排实现和容量，再看前提是否长期失效。
   • 详细答案：发布、索引、热点、重试和资源饱和都可能造成短期变慢。只有查询形态、规模、恢复、安全、团队或成本前提持续变化，且现方案无法在可接受代价内修复，才需要重新选型。
   • 进阶追问：如何避免修复后反复？
   • 进阶回答：用同一负载和口径复测，将新阈值、根因和复审条件写回决策记录。
3. 问题：面试中如何一句话解释矩阵的边界？
   • 考点：架构表达。
   • 回答思路：分数显式化偏好，不替代底线和证据。
   • 详细答案：我会说：“先用硬约束淘汰不可用方案，再用加权矩阵公开剩余偏好，用敏感性分析说明结论何时翻转；分数帮助讨论，最终选择仍要由证据、失败成本、权威边界和退出路径共同负责。”
   • 进阶追问：怎样体现项目经验？
   • 进阶回答：用库存、支付、物流、报警的不同失败成本解释权重，并明确哪些是 E2（已有材料映射）、哪些只是 E3（演练证据）。

综合题分隔（非知识小节）

5. 综合题库

综合题 01：完整讲一次候选矩阵方法

1. 问题：请完整说明从工作负载到技术选择的过程。
   • 口述答案：我不会先报产品名，而是先确认业务目标、不变量、失败成本和工作负载：交易要守住金额、库存和状态，搜索、分析、缓存允许在明确窗口内延迟，但必须可重建。然后按现状基线、同类替代、架构替代和不新增组件四类生成候选，防止矩阵只是给预设答案背书。下一步先做硬约束门禁；正确性、合规、恢复或责任人不满足时直接淘汰或降为派生角色，高风险项为 E0（待核对）时暂停验证，不能给中间分蒙混。剩余候选使用统一的一至五分标尺，把权重、分数、理由、证据等级和责任人写入可复算矩阵。总分只用于显式化偏好，我还会改变争议权重、计算翻转点并比较高峰、故障和团队缩编情景；小幅变化即翻转时，结论只能写成条件性选择。最后明确唯一权威源、事件版本、幂等投影、差异校验、重建、灰度切换和回退，并在决策记录中写未选择理由与复审触发器。这样选型不是一次排名，而是可以被证据推翻、被故障验证、也能安全撤销的工程决策。 实施前我会把最不确定、失败损失最高的分项转成最小实验，固定数据、版本、资源和停止条件；实施中只扩大通过门禁和差异校验的流量；实施后按原权重口径复测长尾、恢复、人工处理量和成本。任何数字若没有生产记录就保留 E3（演练证据）标签，团队变化、业务峰值或合规边界越过记录阈值时，重新从工作负载开始，而不是只在旧表上改一格分数。 决策会议还必须留下第二名、明确反例与不选理由，避免半年后只剩一个无法解释的赢家名称。
   • 追问 1：核心顺序是什么？直答：先问题与门禁，再矩阵与敏感性，最后权威边界和退出。
   • 追问 2：总分最高必须选吗？直答：不必须，还要看分差稳定性、证据、迁移和不可逆后果。
   • 追问 3：未知项怎么办？直答：标 E0（待核对），指定取证动作和期限，高风险项验证前暂停。
   • 详情：工作负载与选型路线

综合题 02：如何证明候选没有被刻意遗漏

2. 问题：评审人质疑候选池偏向某个产品，你如何回应？
   • 口述答案：我先展示候选生成规则，而不是为某个产品辩护。每项能力都必须从四个方向展开：当前方案能否通过优化继续使用，同类机制有哪些替代，能否通过读写分离、派生模型或冷热分层改变职责，以及限流、延期或人工是否比新增组件更合适。候选提名时不先打分，每个提名人同时写适用工作负载、主要代价和明确反例，避免只提交自己熟悉的强项。随后把候选映射回同一组业务输入，删除只是品牌不同但机制和风险相同的同质项，把验证预算留给可能改变结论的差异。如果现状方案已违反硬约束，也保留在清单中并标明淘汰原因，使迁移收益有对照，而不是悄悄消失。对于 E0（待核对）的版本、团队能力和价格，我只记录缺口，不按乐观假设填分。最后让业务、运行、安全和开发分别复核候选覆盖，保存新增、合并和淘汰历史。这样可以证明讨论空间完整，但我不会声称候选数量越多越客观；完整性来自机制与替代路径覆盖，不来自堆产品名。 我还会做一次反向审查：先隐藏产品名，只看每行机制、责任和失败路径，判断评审者是否仍能解释入选理由；再把第二名放入最坏情景，看它是否因被低估的恢复或退出能力而翻转。如果某个候选只能用“行业常用”解释，或指标刚好重复它的卖点，就退回候选生成。最终记录提名人、删除原因和证据来源，保证后续人员能复现而不是相信会议记忆。 若新的业务约束出现，先重新运行四类来源检查，再决定是补候选还是修改旧候选边界。
   • 追问 1：至少要几个候选？直答：没有固定数量，但必须有现状、不做和关键机制替代。
   • 追问 2：同质候选怎么处理？直答：先按机制合并，只有支持、成本或退出差异可能翻转时才分别保留。
   • 追问 3：谁来补候选？直答：由承担业务、运行和安全后果的不同角色独立补充。
   • 详情：架构需求与约束

综合题 03：硬约束与高总分冲突

3. 问题：一个候选性能、成本都最高，但无法证明资金审计，怎么决策？
   • 口述答案：我会直接把它从支付主事实候选中淘汰，而不是给审计项低分后让性能和成本抵消。支付不变量要求一笔外部交易、支付单、账务分录和最终状态可追溯，审计缺失的后果是错账无法定位、重复入账无法证明、恢复后也不知道是否收敛，这属于不可补偿失败。首先把门禁判定、缺失证据和责任人写入记录；若只是材料尚未取得，则标 E0（待核对）并暂停，不把“应该支持”当通过。其次评估它能否降为可重建的查询、风控或分析副本，前提是权威账务仍在通过门禁的交易系统中，派生故障不能反向污染主事实。如果候选方能通过最小实验补齐审计、备份恢复和差异校验，再重新进入门禁，而不是保留原高分。对外说明时我会强调，矩阵只比较合格候选的偏好，不负责交易底线。最终选择可能是总分较低但正确性、恢复和团队责任清晰的方案，并把性能缺口转成容量优化或后续验证任务。这不是保守，而是让失败成本与决策权重一致。 验证时我会注入回调重复、数据库提交后响应丢失、节点恢复和备份回放，按支付业务键核对金额守恒、唯一入账、状态版本与人工待办；只恢复服务可用而无法证明账务一致，仍判门禁失败。若降为派生角色，还要限制写权限、定义删除传播和失效窗口，确保该候选的高性能只改善读取，绝不获得改变资金事实的通道。 评审结论由资金责任人与恢复责任人共同确认，架构师不能用个人偏好替他们接受错账风险。 该确认与门禁证据一并归档。
   • 追问 1：审计能后补吗？直答：关键链路上线前必须通过门禁，后补计划不能替代当前证据。
   • 追问 2：能做小流量试点吗？直答：仅限不承载真实资金裁决、可完整回退的隔离范围。
   • 追问 3：高分还有价值吗？直答：可提示其在派生角色或补齐门禁后的潜力，但不改变当前淘汰。
   • 详情：支付资金一致性

综合题 04：高风险未知项如何进入决策

4. 问题：团队没有候选产品的恢复记录，是否可以先给三分？
   • 口述答案：不能把未知自动写成中间分，因为三分的语义是“经验证可接受”，而没有恢复记录只能标 E0（待核对）。我会先判断这项是否是硬约束：如果候选要承载库存、支付或唯一事件事实，恢复能力未知意味着资格暂停；如果只是可丢弃缓存，可以在权威源和回源保护完整的前提下做有限试点。取证计划要具体到备份输入、故障注入、恢复步骤、数据校验、恢复时间、责任人和停止条件，不接受“看官方文档支持恢复”这种替代。实验数字全部标 E3（演练证据），保存版本、配置、数据规模和结果，成功后才可升级为 E1（源码与可复现证据）并重新评分。如果期限不足，我会缩小职责、保留旧路径和人工接管，优先验证失败损失最大的未知，而不是一次验证所有功能。决策记录还要说明未知项对排名的影响：把可能分数在合理上下界重算，若结论会翻转，必须先验证；若不翻转，也不能跳过硬门禁。这样既不把不确定性伪装成确定，也能让验证预算服务真正可能改变选择的问题。 我会把未知项建立成有截止时间的风险条目，写清缺什么原始材料、由谁获取、失败后缩小到什么角色。实验不仅测“能恢复”，还测操作是否依赖个人经验、权限是否临时放大、恢复期间新写入怎样衔接、校验差异能否归零。若第一次演练只能靠手工改数据才完成，证据仍不足；只有步骤可重复、结果可比较、失败可回退，才允许更新门禁结论。 验证记录必须保存原始输入和失败样本，不能只留一张成功截图作为通过依据。
   • 追问 1：官方文档算什么证据？直答：可说明机制候选，但不能替代本工作负载下的可恢复记录。
   • 追问 2：期限紧如何止损？直答：缩小角色、数据和流量，保留旧路径与人工接管。
   • 追问 3：何时能从 E0（待核对）升级？直答：有可追溯输入、步骤、结果和复跑条件后。
   • 详情：存储恢复与迁移

综合题 05：权重由谁决定

5. 问题：技术、业务和运维对权重争议很大，你如何收敛？
   • 口述答案：我先把争议从“喜欢哪个产品”改写成“谁承担哪种失败”。业务负责人确认库存超卖、支付错账、查询延迟和报表延期的相对损失；运行负责人确认值守、升级、恢复和告警负担；安全负责人确认地域、权限和审计底线；技术人员解释机制和验证成本。硬约束先冻结，不能进入权重谈判。偏好项使用一致的定义和计量方向，检查吞吐、性能、响应速度是否重复计权，再要求权重总和为百分之百。无法统一时不偷偷平均，而是保留两到三个有业务含义的情景，例如增长优先、稳定优先和团队缩编，分别重算排名、分差和最坏损失。若不同情景赢家不同，就把选择写成条件性决策，由有授权的人确认当前情景，并记录少数意见、复审日期和翻转阈值。若赢家始终不变，争议对决策不敏感，可以停止无效讨论。评分人和权重确认人也要分开，避免同一人既定义重要性又给自己熟悉的候选高分。最终会议产物不是一个神秘总分，而是一份可以解释谁为何接受什么代价的决策记录。 收敛前我会让每个角色分别描述最坏可接受后果，再把描述对应到同一指标，避免运行人员说“难维护”、业务说“必须实时”却没有可比较含义。会议只确认权重和风险授权，不现场随意改分；分数变化必须带新证据。上线后按角色观察正确性、恢复、值守工时与业务延迟，某项持续越界就触发原责任人复审，防止权重确认只停留在签字。 若某角色拒绝确认相应失败成本，该维度保持未决，方案不能借默认平均值绕过授权。
   • 追问 1：可以把所有权重设相等吗？直答：只有失败成本确实相近时，不能用相等掩盖未决策。
   • 追问 2：谁有最终决定权？直答：由承担业务结果并获授权的责任人决定，架构师提供证据与边界。
   • 追问 3：争议多久复审？直答：在工作负载、团队或合规触发器越界时复审，不只按日历。
   • 详情：质量属性与权衡

综合题 06：权重变化导致结论翻转

6. 问题：如何向面试官演示敏感性分析而不是只报最终分？
   • 口述答案：我会选最有争议且候选分差最大的两项做可复算演示。假设候选甲查询能力得五分、运行简洁得二分，候选乙分别得三分和五分；当查询权重为百分之六十时两者同为三点八，查询权重升到百分之七十时甲为四点一、乙为三点六，降到百分之五十时甲为三点五、乙为四点零，因此百分之六十是翻转点。这个结果说明“甲更好”并不完整，正确结论是“当查询收益在总偏好中超过六成时选甲，否则选乙”。接着我会检查评分本身的区间：如果甲的查询五分只有 E3（演练证据），降为四分是否也会翻转；若会，就优先做查询和运行实验。然后构造高峰、故障和团队缩编情景，避免单因素扫描遗漏相关变化。对于小幅变化就翻转的方案，我会保留第二名、选择更可逆的迁移路径并设置复审触发器；对于大幅变化仍稳定的结论，仍需验证门禁和退出。敏感性分析不是预测未来概率，而是暴露决策最依赖的假设，让验证、灰度和回退都有明确优先级。 我还会绘制权重区间而非只给三个点，标出同分线、当前位置和业务可接受范围；如果当前位置紧贴同分线，就不把微弱领先写成强结论。多变量情景中，团队缩编常同时降低运行能力分并提高简洁权重，峰值增长则同时改变吞吐与恢复分，必须成组重算。最终把翻转条件写进决策记录和监控触发器，让线上事实能自动提醒团队重开评审。 对无法量化概率的情景，我只比较后果与可逆性，不把主观概率伪造成精确期望值。
   • 追问 1：翻转点有什么用？直答：它把“更重要”变成可讨论边界，并指导优先取证。
   • 追问 2：结论很敏感还能上线吗？直答：可以，但应选可逆路径、保留备选并缩小灰度。
   • 追问 3：敏感性分析能替代压测吗？直答：不能，它只说明测什么，压测才产生运行证据。
   • 详情：选型路线与证据

综合题 07：交易数据库候选矩阵

7. 问题：WMS（仓储管理系统）库存和支付交易主库怎么选？
   • 口述答案：我先写共同门禁：条件更新必须守住可售量不为负，支付金额和状态可审计，重复请求可返回既有结果，备份恢复后能用流水和对账证明没有多扣、少扣、重复入账或遗漏。未通过这些条件的候选直接退出主事实竞争。通过后再比较事务与约束、审计恢复、查询适配和团队运行，基准情景可给 MySQL（关系型数据库）与 PostgreSQL（关系型数据库）相同的高分，而 MongoDB（文档数据库）是否保留取决于不变量能否封闭在单一聚合。若现有团队对 MySQL（关系型数据库）有 E1（源码与可复现证据）的运行和恢复记录，迁移没有新增硬需求，我会优先保持基线；若复杂查询、标准能力和扩展特性权重提高，且 PostgreSQL（关系型数据库）运维能力完成验证，敏感性分析可能翻转。缓存、搜索和分析不参与最终库存或资金裁决，只消费已提交版本。迁移若必要，必须定义唯一权威、增量同步、双写差异、灰度读、停止阈值和回退，不能因矩阵同分就长期双主。项目表达中我会明确这些数字是 E3（演练证据），真实版本、规模和团队能力仍需现场核对。 POC（概念验证）不会只跑正常写入，而会覆盖两个并发请求争抢最后库存、支付回调重复、提交成功后响应丢失、长事务锁等待和备份恢复。验收同时看拒绝是否可解释、业务流水是否闭合、恢复后金额与状态是否对得上。即使新候选查询更强，只要迁移期间无法确定唯一写入裁决或回退会丢新数据，就保持现状并先补迁移能力，不为高分冒险。
   • 追问 1：为什么不先比吞吐？直答：交易错误的首要损失是错误事实和不可恢复，吞吐在门禁后比较。
   • 追问 2：同分怎么破？直答：看证据强度、迁移成本、团队能力和翻转项。
   • 追问 3：MongoDB（文档数据库）一定不能做交易吗？直答：不绝对，需证明聚合内不变量、确认语义、审计和恢复。
   • 详情：MySQL（关系型数据库）与分库分表

综合题 08：缓存矩阵与击穿反例

8. 问题：库存热点查询应该选 Redis（远程字典服务）、进程内缓存还是不缓存？
   • 口述答案：我先确认缓存角色：库存最终可售和扣减仍由交易权威源裁决，缓存可以失效、丢弃和重建；如果丢缓存就无法还原库存，当前设计直接违反门禁。多实例共享热点、统一失效和受控回源权重较高时，Redis（远程字典服务）通常更适配；单实例、只读、小字典且变化极少时，进程内缓存的低延迟和运行简洁可能在敏感性分析中胜出；低流量支付状态查询若一致性、审计和简洁权重更高，不缓存并优化主库可能是最佳方案。矩阵要写分布式共享、延迟、一致性治理、运行成本和回源降级，而不是只写“快”。我还会演练命中率从百分之九十九降到百分之七十后的回源放大，验证请求合并、限流、旧值策略和主库安全上限。击穿事故发生时先保护主库、冻结热点和失效证据，不立即判定 Redis（远程字典服务）选错；同时过期、无限重试或版本缺失属于设计问题。只有共享、容量或恢复机制长期不满足工作负载，才重开选型，并保留权威读取回退。 上线前还要验证缓存值携带的业务版本、删除和权限语义，避免旧值在交易已取消后继续展示。灰度时同时观察命中率、回源并发、主库锁等待、P99（99 分位响应时间）和差异样本，任何不变量风险先关缓存而不是扩大节点。成本要包含内存、副本、跨区流量和值守，不能只比较一次查询延迟；若不缓存也满足目标，它就是复杂度最低的真实赢家。 灰度结束后仍定期演练整片缓存失效，确认回源保护没有因业务增长而失去安全余量。
   • 追问 1：持久化能让缓存变主库吗？直答：不能自动满足事务、不变量、审计和恢复门禁。
   • 追问 2：进程内缓存怎样更新？直答：版本化加载、通知失效或短生命周期，并保留权威回源。
   • 追问 3：击穿先扩容吗？直答：先限制回源和重试放大，确认瓶颈后再扩。
   • 详情：Redis（远程字典服务）缓存一致性

综合题 09：消息中间件候选矩阵

9. 问题：支付成功后通知库存、物流和积分，Kafka（分布式日志消息系统）、RocketMQ（分布式消息队列）与 RabbitMQ（消息队列）怎么选？
   • 口述答案：产品比较前先守住可靠生产门禁：支付业务事实和 Outbox（发件箱）事件同事务提交，消息包含稳定业务键与版本，发布失败可扫描补发，消费者对库存、物流和积分副作用分别幂等，积压、死信和差异都能回放校验。缺少这些条件时换任何中间件都不能解决“数据库成功、消息丢失”或重复消费。通过门禁后，我按回放吞吐、业务路由、顺序与延迟、团队运行和恢复工具加权。交易事件强调顺序、延迟和业务语义时 RocketMQ（分布式消息队列）可能领先；长期轨迹流、保留和大规模回放权重升高时 Kafka（分布式日志消息系统）会翻转；规模较小、复杂路由占主导且长期回放价值低时 RabbitMQ（消息队列）可以胜出。然后用生产速率、故障时长、消费能力和下游上限计算净清理速度，恢复时间越过硬目标则候选直接失败，不能以路由高分抵消。上线按消费者分批灰度，保留事件事实、检查点和旧消费路径；积压清零后还要核对死信、重复副作用和业务状态，才能宣布恢复。 我会额外注入分区热点、消费者重启、下游限流和毒事件，确认扩并发不会破坏业务键顺序，也不会把积压转移成数据库故障。保留期必须大于故障发现、修复和回放总窗口，权限和敏感载荷也需通过门禁。选择后记录何时因回放增长、交易延迟或团队变化而翻转，并定期用同一批事件复演恢复，不把某次清零曲线当作永久能力。 消费者升级还要验证新旧事件模式兼容，避免回放历史事件时因字段变化再次形成积压。
   • 追问 1：为什么消息不能是唯一事实？直答：业务提交、审计和补发需要本地可追溯来源。
   • 追问 2：积压如何计算？直答：先算故障累积，再用恢复消费减持续生产得到净清理速率。
   • 追问 3：重复消息允许吗？直答：传输可重复，业务效果必须幂等收敛。
   • 详情：MQ（消息队列）可靠性

综合题 10：物流搜索选型

10. 问题：跨境物流轨迹查询什么时候引入 Elasticsearch（搜索引擎）？

• 口述答案：我先区分轨迹权威事实与搜索投影。承运商事件、合法状态转移、来源和版本保存在可追溯权威源中，Elasticsearch（搜索引擎）只承担全文、复杂过滤、排序和相关性；搜索不可用或延迟时不能伪造送达，而应显示更新时间并降级到有限精确查询。候选可包含 Elasticsearch（搜索引擎）、PostgreSQL（关系型数据库）内置检索、MySQL（关系型数据库）有限查询和维持现状。门禁是索引可从快照与事件重建，权限和删除能传播，延迟有目标，重建期间有回退。矩阵比较全文相关性、复杂过滤、重建、运行简洁和交易降级；若主要是单号点查和少量条件，运行简洁权重提高后关系库可能胜出，不应为了“以后也许需要”提前承担分片、映射和同步成本。若全文、多语言、多条件和排序已成为主要失败成本，Elasticsearch（搜索引擎）才有稳定优势。实施时用新索引全量加增量追平，比较数量、字段、权限、删除和真实查询，小流量切读；差异或长尾越界立即切回旧索引或权威查询。 评审还要把相关性质量与系统性能分开：典型查询需要人工标注或业务规则判断召回和排序，不能只用响应时间宣布成功。映射变更、分片恢复和删除传播都要做失败演练，重建吞吐必须在事件保留期内追平。若客服查询允许稍后展示但权限泄露不可接受，权限门禁优先于相关性高分；最终索引别名、旧索引保留期和降级提示都写入上线清单。
• 追问 1：搜索结果能改订单状态吗？直答：不能，它是派生读取，状态变更回到领域权威源。
• 追问 2：何时无需搜索引擎？直答：点查和简单过滤已满足目标，新增运行成本高于查询收益时。
• 追问 3：重建完成看什么？直答：水位、总量、字段、权限、删除、查询差异和长尾共同通过。
• 详情：Elasticsearch（搜索引擎）机制

综合题 11：分析平台选型

11. 问题：业务报表应该选 ClickHouse（列式数据库）还是关系型数据库分析副本？

• 口述答案：我先把分析从交易链路隔离，明确报表消费已确认事实，允许按口径窗口最终一致，但不能阻塞订单、库存或支付写入，也不能用聚合结果覆盖账务。候选至少包含 ClickHouse（列式数据库）、PostgreSQL（关系型数据库）分析副本、现有数据库优化和不新增平台。门禁是原始明细或事件可回放，指标口径可版本化，权限可审计，重算有资源隔离和完成时限。通过后比较扫描聚合、批量写入、重算恢复、运行简洁和口径治理。数据量大、宽表扫描和历史重算是核心工作负载时，ClickHouse（列式数据库）的列式与排序能力权重更高；数据规模小、查询固定、团队已熟悉关系库时，PostgreSQL（关系型数据库）的简洁和工具复用可能在权重变化后翻转。验证不能只跑一个最快查询，而要包含典型查询集、并发、后台合并、失败重算、权限和冷热保留。上线先写分析明细，再按版本聚合；发现差异时从明细重算并保留旧口径。成本没有账单时标 E0（待核对），容量和重算数字全部按 E3（演练证据）表达。 我会用订单数、金额和退款三个可独立核验的聚合做对账，防止某个口径恰好抵消重复与遗漏；迟到数据进入明确修正窗口，报表展示口径版本和更新时间。资源隔离演练要证明重算不会挤压在线查询，失败后能从明细断点继续。成本模型同时计写入、存储、扫描、网络、运维和退出，若增长假设变化导致排名翻转，就先做归档或限额，再决定是否迁移。
• 追问 1：为什么不用交易库直接跑报表？直答：扫描与聚合会争抢交易资源，失败边界和恢复目标也不同。
• 追问 2：小数据一定选关系库吗？直答：不一定，但必须证明新平台收益覆盖运行和迁移成本。
• 追问 3：报表错了先改结果吗？直答：先定位明细、水位和口径，从来源重算，不手工覆盖事实。
• 详情：ClickHouse（列式数据库）机制

综合题 12：IoT（物联网）时序选型

12. 问题：设备指标和报警事件如何选择时序存储？

• 口述答案：我会先区分原始报警事实、指标明细、窗口聚合、最新值和通知状态。原始事件保存稳定事件标识、设备、事件时间、到达时间、来源和版本，是迟到修正与事故追溯的依据；聚合、降采样和最新值都可重建。工作负载卡要计算设备数、指标数、采样频率、点大小、保留期、突发倍数、标签基数和查询窗口。门禁包括高基数上界、乱序迟到处理、原始事实保留、重算、冷热迁移和故障恢复。候选比较 ClickHouse（列式数据库）、PostgreSQL（关系型数据库）分区表与 Elasticsearch（搜索引擎）时，持续高摄入和大窗口聚合会提高 ClickHouse（列式数据库）得分；设备少、需要事务关联且团队运行简洁更重要时，PostgreSQL（关系型数据库）可翻转；日志搜索占主导才提高 Elasticsearch（搜索引擎）权重。报警风暴还要验证优先级、窗口聚合、通知背压和恢复，不以平均写入代替峰值。随机请求标识若作为标签导致序列爆炸，应直接违反基数门禁，而不是给成本低分。 验证数据要包含正常采样、设备离线后批量补传、时钟偏差、重复事件和单租户突发，分别观察摄入拒绝、窗口版本、查询长尾和磁盘增长。高危告警从原始事实直接建立独立状态，低危重复才做聚合，通知失败不得阻塞原始写入。冷热迁移后仍需抽样回查和重算，删除策略要符合审计；真实标签分布未知时标 E0（待核对），先采样再决定分片与保留。
• 追问 1：事件时间为何重要？直答：设备离线补传会让到达顺序偏离真实发生顺序。
• 追问 2：聚合会漏高危告警吗？直答：高危事件独立保留和通知，低危重复才窗口聚合。
• 追问 3：容量怎么估？直答：设备数乘指标数除采样间隔，再乘点大小、保留期和副本放大。
• 详情：时序模型与冷热治理

综合题 13：多模型唯一权威边界

13. 问题：交易、缓存、消息、搜索、分析和时序如何保证一致性？

• 口述答案：我不会把目标定义成六个系统每一毫秒完全相同，而是先为每个业务事实指定唯一裁决者。订单状态、库存可售、支付入账由交易权威源在本地事务中守住不变量并产生单调版本；Redis（远程字典服务）只加速读取，MQ（消息队列）传播已提交变化，Elasticsearch（搜索引擎）负责检索，ClickHouse（列式数据库）负责分析和时序投影。权威提交与 Outbox（发件箱）事件同事务，事件携带稳定业务键、版本和删除语义，派生侧按键幂等并拒绝旧版本。系统持续记录来源版本、消费水位、端到端延迟、死信和重试，按业务键比较数量、字段、金额、权限与删除；行数相等不能证明一致，因为重复与遗漏可能抵消。差异越界时停止扩散，从检查点回放或全量重建，关键读取降级权威源；派生系统永远不能反向覆盖主事实。恢复完成必须同时满足水位追平、差异阈值、业务聚合和观察窗口。这样的一致性是可测、可恢复的收敛承诺，而不是一句“最终会一致”。 我还会为每个模型写清最大可接受滞后和用户可见语义：缓存旧值能否展示、搜索是否标更新时间、报表何时冻结口径、告警修正如何通知。校验按风险分层，资金与库存做业务键和金额全量核对，低风险搜索可用摘要加抽样，但删除与权限必须强校验。事件模式变化采用向后兼容和分阶段消费，旧消费者未升级前不删除字段；任何无法回放的变化都要先停发布。
• 追问 1：为何不用全局事务？直答：派生职责可接受有界延迟，全局同步会放大延迟和故障域。
• 追问 2：行数相等够吗？直答：不够，还要字段、金额、版本、权限和删除校验。
• 追问 3：冲突时信谁？直答：信业务事实的唯一权威源，修正或重建派生模型。
• 详情：权威数据与派生边界

综合题 14：派生模型重建与切流

14. 问题：如何证明搜索或分析副本真的可重建？

• 口述答案：我会把“可重建”拆成输入、时间、校验和回退四类证据。先冻结模式、口径、权限和来源水位，从权威源导出水位前的全量快照；新副本限速构建，同时保留水位后的已提交事件。全量结束后从冻结水位幂等回放增量，消费能力必须大于持续新增，净追平速度才能为正；还要确认事件保留期覆盖全量与追平总窗口，否则早期增量会在消费前过期，候选直接不满足恢复门禁。水位追平后不立即切换，而是比较总量、关键字段、金额或状态聚合、权限、删除传播和典型查询，并记录不可解释差异。切流从小比例只读请求开始，同时观察新旧结果、P99（99 分位响应时间）、错误和资源水位；任一停止阈值越界就切回旧索引或权威有限查询。旧副本保留到观察窗口、回放演练和审计保留都通过，再下线。所有吞吐和窗口没有运行记录时标 E3（演练证据）。只有这套流程实际可执行、可复跑，才能说派生模型可重建，而不是因为产品文档有导入导出功能就下结论。 我还会在重建前测算全量基础时间、构建期间新增量和净追平时间，任何一段超过源数据或事件保留期都先判失败。断点恢复要注入进程退出和部分分片失败，证明不会从头重复造成资源风暴；校验器本身也保留版本和抽样依据。切换后继续双读对比一段约定窗口，确保权限、删除与迟到事件没有在灰度结束后才暴露。 下线旧副本前再做一次从零重建抽演，防止首次成功依赖已经丢失的临时脚本或个人权限。
• 追问 1：全量和增量为何都要？直答：全量补历史，增量补构建期间变化，两者以冻结水位衔接。
• 追问 2：水位追平就能切吗？直答：不能，还要字段、权限、删除、查询和长尾校验。
• 追问 3：旧副本何时删？直答：新副本稳定越过回退窗口且重建演练通过后。
• 详情：备份恢复与在线迁移

综合题 15：WMS（仓储管理系统）库存防超卖的多模型组合

15. 问题：库存防超卖为什么不能只选一个高分缓存方案？

• 口述答案：防超卖首先是交易不变量，不是缓存命中率问题。我会让交易权威源用条件更新、唯一请求标识和库存流水保证已确认扣减不超过可售量，重复请求返回既有结果；Redis（远程字典服务）可以承担可售查询、热点保护或预约令牌，但任何预扣都要有版本、失效和对账，缓存丢失后必须能从库存事实重建。消息用于把已提交变化传播给履约、补货和搜索，消费者按库存单与版本幂等；搜索和分析只展示或统计，不参与扣减裁决。选型时交易候选先过正确性与恢复门禁，缓存候选先过可重建与回源门禁，消息候选先过可靠生产与恢复门禁，不能把三者放在一张总分表里互相抵消。演练会覆盖并发扣减、缓存击穿、消息重复、延迟和权威库恢复，并按业务键对账库存余额、流水和派生版本。若 Redis（远程字典服务）不可用，系统应限流、排队或回退权威条件更新，而不是放开无保护写入。面试中我会明确这是 E2（已有材料映射）的方案表达，具体峰值与收益无证据时只按 E3（演练证据）估算。 容量演练会从仓库、商品和活动热点分布计算并发，而不是只看总 QPS（每秒查询率）；最后一件库存、重复扫描、取消释放和超时重试都必须纳入同一状态机。上线以非热点只读流量开始，再逐步开放热点缓存，监控条件更新失败、缓存版本差、回源并发和流水差异。任何已确认量超过权威可售量的样本都立即停灰度、切回交易库并启动对账。 取消与释放同样使用唯一请求标识，防止补偿重复把库存加回两次。
• 追问 1：缓存预扣能当最终结果吗？直答：不能，最终确认由权威库存事实和流水裁决。
• 追问 2：消息延迟会超卖吗？直答：不应，消息只传播已提交变化，不参与同一库存不变量裁决。
• 追问 3：缓存故障如何止损？直答：限流、请求合并、排队并回退权威条件更新。
• 详情：库存项目案例

综合题 16：支付成功后的事件通知

16. 问题：支付成功后异步通知下游，如何避免选型掩盖资金风险？

• 口述答案：我先把支付成功定义在支付单与账务权威源，而不是定义成消息发送成功。渠道回调经过验签、幂等和状态机校验后，在本地事务中写支付状态、账务或待记账事实以及 Outbox（发件箱）事件；提交后发布器才能把稳定业务键、金额、币种和版本发送到 MQ（消息队列）。这样即使中间件暂时不可用，扫描任务仍可补发，资金事实不会因为消息丢失而消失。下游库存、物流、积分分别维护幂等记录和可重试状态，不以消费确认替代业务完成；毒事件进入隔离并保留人工路径。产品矩阵只比较回放、顺序、路由、延迟、运行和恢复，任何候选若无法在保留期内清理积压或团队无人恢复，直接退出关键事件角色。支付通知还需主动查单与对账处理未知态，避免超时后重复发起支付。恢复时不仅看积压清零，还按支付业务键核对消息、下游效果和账务结果。真实中间件版本和线上吞吐没有证据时标 E0（待核对），矩阵数字标 E3（演练证据），不把方案演练包装成生产收益。 我会把“发布成功、消费成功、业务完成”设为三个独立状态，分别有时间、重试次数和责任人，避免某个确认覆盖全链路。故障演练包括渠道重复回调、发布超时但实际成功、消费者处理后确认丢失和下游限流；每种情况都应依靠幂等与查证收敛。安全门禁还要求载荷最小化、敏感字段脱敏和访问审计，不能因异步链路而降低支付数据控制。 对账批次要能反查原支付、事件与下游结果，差异未清零时不得因通知重试成功就关闭事故。
• 追问 1：数据库成功消息失败怎么办？直答：Outbox（发件箱）记录与业务同事务，发布器扫描补发。
• 追问 2：消费成功等于业务成功吗？直答：不等于，要核对下游幂等副作用和最终状态。
• 追问 3：如何处理未知支付态？直答：主动查单、状态机收敛和对账，不能直接重付。
• 详情：支付渠道与幂等

综合题 17：跨境物流轨迹的多模型边界

17. 问题：跨境物流轨迹既要写入、搜索又要分析，如何设计选型边界？

• 口述答案：我会把承运商原始事件和合法状态转移放在可追溯权威源，保存业务单号、承运商事件标识、来源、事件时间、到达时间、状态版本和原始摘要。接入层先去重并校验状态机，旧版本不能覆盖新状态；成功提交后再通过 MQ（消息队列）传播。Elasticsearch（搜索引擎）投影面向客服和运营的全文、多条件过滤与排序，ClickHouse（列式数据库）投影面向时效、异常和承运商分析，缓存只加速热点单号查询。三个派生模型分别有水位、幂等键、删除和权限规则，任何一个故障都不反向改写轨迹权威状态。候选矩阵也分开：事件流比较回放与恢复，搜索比较相关性与重建，分析比较扫描与重算，不能把产品跨角色的分数相加。客服要求实时可见时，索引未追平就显示来源时间并降级权威精确查询，不伪造送达。迁移采用全量快照加增量回放，新旧查询按业务单号抽样校验；异常状态、删除、权限和多语言查询都通过后才扩大流量。这样多模型增加的是明确读能力，而不是三份互相争夺真相的数据。 对承运商差异，我会通过防腐层统一事件语义，但保留原始码和映射版本，映射错误时可重新解释历史，而不是手工改索引。校验除总量外还比较每单最新合法状态、事件数量和时间范围，分析口径按承运商与时区版本化。索引或分析故障期间，接入仍持续保存权威事件；恢复后按水位补齐，使客服降级与后台重算互不阻塞。 删除与隐私请求也从权威流程产生版本事件，确保搜索和分析副本都能被追踪清除。
• 追问 1：轨迹乱序怎么处理？直答：按事件时间、来源版本和合法状态转移判断，保留迟到事实。
• 追问 2：搜索延迟怎么办？直答：显示更新时间，关键查询降级权威源并回放差异范围。
• 追问 3：分析结果能改轨迹吗？直答：不能，它用于发现异常，修正必须回到权威接入流程。
• 详情：跨境物流项目选型

综合题 18：IoT（物联网）报警风暴的候选淘汰

18. 问题：报警风暴场景中，什么候选应该不打分直接淘汰？

• 口述答案：我先定义不能接受的结果：高危原始事件不可静默丢失，设备和规则来源可追溯，重复通知可聚合但不能吞掉首次高危告警，积压后必须在目标窗口恢复。任何候选若遇到高基数标签就无上界增长、峰值摄入时只能随机丢弃、原始事件保留短于恢复窗口、迟到事件无法修正或团队没有可执行恢复责任，就不进入加权排名。通过门禁后再比较摄入、窗口聚合、迟到重算、高基数治理、通知背压、运行和成本。数据流上，原始事件先按稳定事件标识落地，窗口层对低危重复聚合，高危事件走独立优先级；通知系统有配额、静默、升级和人工确认，不能让短信或第三方接口反压到原始摄入。演练用设备数、指标数、采样频率和突发倍数计算峰值，用暂停消费者后的净清理速率计算恢复，并注入乱序和重复验证告警版本。若某产品日常查询得分很高但恢复和基数门禁失败，我会明确淘汰，而不是用平均性能掩盖风暴风险。真实设备规模无证据时只给 E3（演练证据）区间。 评审还要区分拒绝、降采样和聚合：拒绝必须有明确低优先级范围与计数，降采样不能作用于高危原始事件，聚合结果要能追溯被合并的时间窗和数量。灰度时按租户和设备组隔离，观察标签基数、摄入延迟、积压、通知成功率与人工确认。若一个异常租户能拖垮全局，说明隔离门禁未通过，应先加配额和故障域边界。 恢复后按事件标识核对高危首次通知和最终确认，不能只看总通知数接近输入数。
• 追问 1：低危事件可以丢吗？直答：要由业务明确降级策略并保留聚合计数，不能技术侧默认丢弃。
• 追问 2：高基数如何止损？直答：限制标签集合、拒绝随机标识入标签并隔离异常租户。
• 追问 3：通知失败影响原始写入吗？直答：不应，通知异步背压并可重试，原始事实独立保留。
• 详情：时序报警项目

综合题 19：Runner（执行器）调度的存储与消息选择

19. 问题：Runner（执行器）调度如何用候选矩阵避免重复副作用？

• 口述答案：调度选型先写不变量：同一任务可以被重复投递和重试，但同一业务副作用只能由有效执行租约提交一次，旧执行者恢复后不能越权写结果。任务定义、状态、尝试次数、租约版本和最终结果放在可审计权威源；MQ（消息队列）只分发可重复任务，缓存只加速待执行视图。候选门禁包括条件领取、租约或栅栏版本、幂等结果、超时恢复、死信和人工接管；如果系统只能依赖“消息不会重复”或本地内存锁，应直接淘汰关键调度角色。通过后，数据库队列、消息中间件和混合方案分别按吞吐、延迟、顺序、可见性、恢复、运维和成本评分。任务量不大且状态查询、条件领取是主需求时，数据库基线可能优于新增消息；突发任务、下游隔离和独立扩展权重提高时，混合方案可能翻转。故障演练要暂停执行者、制造心跳延迟、重复投递和旧执行者复活，核对栅栏版本是否阻止旧提交。恢复完成还需按任务业务键核对副作用，而不是只看队列为空。这样中间件选择服务调度语义，不替代调度语义。 我会把任务分成可安全重试、需查证后重试和只能人工处理三类，矩阵中的恢复分必须覆盖三种语义。执行记录保留输入摘要、领取者、栅栏版本、开始结束和结果标识，方便旧执行者提交时被权威源拒绝。容量估算同时看任务到达、平均执行时长、下游配额和失败重试放大；扩消费者前先确认下游承受能力，避免把队列积压转成外部接口风暴。 人工接管也要写入同一执行记录并校验栅栏，避免人工与自动恢复同时提交副作用。
• 追问 1：租约过期就能换执行者吗？直答：可以接管，但提交副作用还要校验更高栅栏版本。
• 追问 2：消息重复怎么办？直答：按任务和副作用幂等，返回既有执行结果。
• 追问 3：何时不用 MQ（消息队列）？直答：任务量小、数据库领取满足目标且新增运维成本不值得时。
• 详情：分布式幂等与补偿

综合题 20：评审人评分分歧

20. 问题：两个专家对同一候选分别打二分和五分，怎么处理？

• 口述答案：我不会先取平均值，因为巨大分歧通常意味着标尺、事实或工作负载理解不一致。先让双方分别写出对应输入、依赖机制、补偿动作、反例和证据等级，再检查是否一个人在评日常查询、另一个在评故障恢复，或者一个引用 E1（源码与可复现证据）、另一个只是 E3（演练证据）推断。若指标定义混入两个目标，就拆成独立项并重新确认权重；若事实冲突，就设计最小 POC（概念验证）复现决定性场景；若只是风险偏好不同，则保留两个权重情景，让有授权且承担后果的人选择。评审记录应保存原分数和修改原因，不能只留下收敛后的数字。还要把二分与五分分别代入矩阵做区间敏感性分析：若赢家不变，分歧对当前决策不敏感，可带风险项前进；若赢家翻转，就必须先补证据或选择更可逆方案。平均为三点五会伪造一个无人真正认可的判断，也无法告诉团队下一步测什么。最终目标不是让每个人意见一致，而是让差异来源可解释、决策责任清楚、未来能按同一证据复审。 收敛会议前我会交换双方的评分理由而隐藏姓名，减少职位和熟悉度带来的锚定；会议只讨论差异项，不重开已稳定门禁。实验若仍不能区分，就把不确定区间和最坏损失写入选择，优先保留旧路径。上线后分别验证双方最担心的信号，并约定哪一个观测结果支持改分，使分歧转成可证伪假设而不是长期争论。 若新增证据只影响一个分项，禁止顺手重写其他分数，保持矩阵版本差异可审计。
• 追问 1：什么时候可以平均？直答：同一标尺、同一事实且只是小幅独立判断误差时才可汇总。
• 追问 2：谁设计实验？直答：由双方共同确认能区分主张的输入、输出和停止条件。
• 追问 3：分歧不影响赢家还要记录吗？直答：要，它可能在未来权重变化后成为翻转因素。
• 详情：ADR（架构决策记录）与评审

综合题 21：候选同分如何决策

21. 问题：两个候选加权总分完全相同，你会怎么选？

• 口述答案：同分说明当前矩阵无法提供唯一强结论，不应继续添加没有证据的小数位。我会先比较单项分布：一个可能在性能领先但恢复较弱，另一个可能运行简单但扩展一般，总分相同不代表风险相同。然后检查关键分数的证据等级和敏感性，改变有争议权重、评分区间和高峰故障情景，找出哪个假设会让结果翻转。若仍同分，我优先选择可逆性更高、迁移范围更小、现有团队有 E1（源码与可复现证据）、数据导出更开放、回退更快的方案；这些不是隐藏加分，而是把遗漏的退出和证据维度显式补回矩阵。也会考虑不选择新产品，若现状经优化能满足目标，零迁移是一个真实候选。只有职责天然不同且同步、校验、成本都可证明时才组合使用两个，不能因为不敢决策就建立双主。决策记录写清“在当前权重下等价，因可逆性选择甲”，并保存乙作为翻转后的备选，定义规模、团队或合规变化后的复审条件。这样同分不会阻塞行动，也不会被包装成某个产品客观更优。 我还会比较错误选择的后悔成本：导出是否开放、调用是否可兼容、历史数据能否重建、旧方案需要保留多久，以及团队从故障到恢复要依赖多少人工步骤。若这些内容此前没有指标，就正式新增“退出与可逆性”维度并让所有候选重算，而不是只给偏好的候选加分。最终采用最小可行范围验证，第二名保留文档和脚本，不保留长期双运行成本。 复审触发后先重放原矩阵和证据，确认是真翻转而不是评分口径已被悄悄改变。
• 追问 1：可逆性为什么重要？直答：输入不确定时，它限制错误选择的迁移和恢复损失。
• 追问 2：能投票决定吗？直答：投票可表达偏好，但不能替代失败责任、证据和授权。
• 追问 3：同分可长期双用吗？直答：不能默认双用，额外同步和运行成本必须有独立收益。
• 详情：架构决策可逆性

综合题 22：供应商跑分与真实工作负载冲突

22. 问题：供应商 Benchmark Test（基准测试）显示性能第一，为什么仍不能直接选？

• 口述答案：我会先确认跑分的版本、硬件、数据分布、读写比例、并发模型、查询集、缓存状态、复制确认、持续时间和失败注入，这些任何一项不同都可能让结果无法迁移到本项目。供应商数据可以作为 E3（演练证据）的候选机制线索，除非输入、脚本和环境能在本地复跑，否则不能写成 E1（源码与可复现证据）。更重要的是，性能只是一项偏好，无法证明交易不变量、数据地域、权限审计、备份恢复、团队值守、价格增长和退出可行。我的做法是从工作负载卡抽取典型与最坏场景，在同一数据、同一确认语义和同一资源预算下比较候选；同时注入节点故障、积压、重建和迁移，记录 P99（99 分位响应时间）、正确性差异、恢复时间和人工步骤。再把可复现结果填回矩阵并做敏感性分析，看性能优势是否足以改变选择。若候选在硬约束上失败，即使跑分领先也直接淘汰；若优势只在供应商特定条件出现，则记录适用边界。这样既尊重实验，也避免把营销数字变成架构结论。 我还会要求测试包含预热与冷启动、稳定运行与突发、读写混合与热点倾斜，报告错误和资源曲线而非只取最佳窗口。托管服务要核对限额、跨区网络、升级窗口、数据导出和合同退出，价格没有真实报价时标 E0（待核对）。若无法获得可复现脚本，就把跑分只用来决定是否进入 POC（概念验证），不进入最终评分证据。 同一测试至少重复多轮并保留离散程度，避免把一次偶然峰值当成稳定能力。
• 追问 1：供应商数据完全没用吗？直答：有用，可生成假设和实验范围，但不能替代本地证据。
• 追问 2：先复现哪个指标？直答：优先复现会导致矩阵翻转且失败成本高的分项。
• 追问 3：平均延迟够吗？直答：不够，还要长尾、错误、正确性、恢复和资源水位。
• 详情：证据与 POC（概念验证）边界

综合题 23：事故后是否重新选型

23. 问题：缓存击穿、消息积压或搜索差异发生后，如何判断要不要换技术？

• 口述答案：事故中先保护业务不变量并冻结时间线，不在压力下直接宣布产品选错。缓存击穿先限制热点和回源，保住交易库；消息积压先保证原始事件、暂停非关键生产并保护下游；搜索差异先切回旧索引或权威有限查询。随后收集发布、配置、热点、命中率、生产消费速率、死信、水位、版本、权限、删除和资源证据，把原因分成实现缺陷、容量不足、工作负载漂移和责任边界错误。若是同时过期、无限重试、消费代码退化或映射错误，修复后用同一输入和时间窗复测，不能把可修实现问题升级为迁移工程。若原工作负载长期变化，现方案无法在可接受成本内满足恢复、基数、查询或团队门禁，才重新生成候选、重算权重和敏感性。若缓存或索引被错误设为主事实，则先恢复权威边界并对账，换产品不是根治。复审必须保留现状作为基线，写迁移、校验、灰度和回退；一次告警或平均指标异常不足以触发不可逆切换。事故给选型提供新证据，但证据需要回写决策模型，而不是替代模型。 复盘时我会把每个原决策假设与事故证据逐条对照：峰值是否低估、恢复是否从未演练、团队是否变化、成本是否漏算、门禁是否被绕过。只有连续观察窗显示同类越界并且优化、隔离或扩容仍不能恢复目标，才批准新选型。迁移前先验证旧系统可导出和可回退，避免在事故余波中同时承担新旧两套未知风险。 事故修复与新方案验证使用同一业务样本，才能比较换技术是否真正降低原失败成本。
• 追问 1：事故后先扩容吗？直答：先确认瓶颈和放大链，扩容只处理已知容量缺口。
• 追问 2：何时确定是边界错误？直答：派生丢失后无法恢复主事实，或派生能反向覆盖权威状态时。
• 追问 3：修复后如何验收？直答：同口径复测正常与失败路径，并核对业务差异归零。
• 详情：存储线上排障

综合题 24：多模型在线迁移的一致性

24. 问题：从旧搜索或分析平台迁移到新平台，如何避免双写分叉？

• 口述答案：我会坚持唯一权威源不变，新旧平台都只是派生读模型。准备阶段冻结字段、口径、权限、删除语义和来源水位，先从权威快照构建新平台，再从冻结水位后的已提交事件幂等追平；尽量不让业务服务分别调用新旧平台双写，因为网络超时会产生无法判断的部分成功。若必须临时双写，也以权威事件为裁决，记录每侧结果并有扫描补偿，设置明确结束日期。校验分为总量、业务键、字段摘要、关键金额或状态聚合、权限、删除和典型查询，避免重复与遗漏在行数上互相抵消。新平台只接小比例读流量，观察差异、P99（99 分位响应时间）、错误和资源水位，停止阈值越界立即切回旧读；迁移期间任何写命令仍回权威源。旧平台保留到新平台越过观察、事件保留和回放演练窗口，完整导出和目标重建都通过后再下线。迁移吞吐、追平时间和成本没有真实记录时标 E3（演练证据），合同与账单未知标 E0（待核对）。这样双系统并存是受控迁移状态，不会演变成永久双主。 我会把迁移状态按业务分片记录，明确每片的全量水位、增量水位、校验结果和当前读路径，失败只回退受影响范围。模式变更采用兼容读取，旧新平台都能理解过渡字段，删除和权限变更优先级高于普通更新。切换后继续从权威源抽样反查，直到新平台经历一次实际增量高峰和恢复演练，才允许关闭旧同步与告警。 迁移结束还要撤销临时写权限与补偿任务，避免过渡机制成为长期隐性双写。
• 追问 1：为何避免业务双写？直答：部分成功和超时未知会造成两侧分叉，恢复责任不清。
• 追问 2：谁裁决差异？直答：权威源的业务事实和版本裁决，新旧派生都按其修正。
• 追问 3：旧平台何时下线？直答：新平台验收、回退窗口和重建演练全部通过后。
• 详情：在线迁移与回滚

综合题 25：矩阵反例审查

25. 问题：你会如何审查一份看起来很完整的技术选型矩阵？

• 口述答案：我先不看赢家，先看输入和过程。检查业务目标、不变量、失败成本和工作负载是否明确，候选是否包含现状、同类替代、架构替代和不新增组件；若指标名称恰好对应某产品特性，可能是先定答案。然后检查硬约束是否独立于评分，正确性、合规、恢复和责任未知时有没有标 E0（待核对）并暂停，还是被填成三分。再检查评分标尺是否统一，吞吐、性能、速度是否重复计权，每个分数是否有理由、反例和证据等级，权重是否由承担后果的人确认且总和为百分之百。接着手工复算公式，查看第二名和单项差异，改变争议权重与弱证据分数，看小幅变化是否翻转；只给一个总分、不展示敏感性通常是假精确。最后审查权威源、消息生产、幂等、校验、重建、迁移和退出，确认缓存、搜索和分析没有被偷偷设为主事实。若矩阵在看到结果后改权重、删除候选或追加小数，我会要求回到冻结版本重做。合格矩阵不一定给唯一答案，但必须让选择依据、未知、代价和撤销条件都能被下一位评审复现。 我还会随机抽一行要求评分人从原始证据重新计算，检查链接、版本和公式是否真的存在；再把一个硬约束设为失败，确认流程会淘汰而非只扣分。随后删除产品名称，让评审只凭机制和边界判断，识别品牌偏见。最后检查决策记录是否写第二名、不选理由、责任人、复审触发器和退出步骤；缺少任一项都只能算讨论草稿，不能作为上线批准依据。 审查结论也要注明矩阵适用的工作负载版本，防止被其他项目直接复制后误用。
• 追问 1：最常见伪精确是什么？直答：弱证据输入却给多位小数，并把总分当客观真理。
• 追问 2：先看赢家有什么风险？直答：会被锚定，忽略候选遗漏、门禁失效和权重操纵。
• 追问 3：矩阵没有唯一赢家算失败吗？直答：不算，它可能诚实暴露需要验证或授权决策的边界。
• 详情：架构评审与风险

综合题 26：完整项目口述与结论边界

26. 问题：请用项目化语言完整讲一次六类技术选型与多模型设计。

• 口述答案：我会以跨境订单为主线：订单、库存和支付先在交易权威源中守住状态、金额与可售不变量，候选先过事务、审计、恢复和团队门禁，再比较 MySQL（关系型数据库）与 PostgreSQL（关系型数据库）的查询、运行和迁移；Redis（远程字典服务）只做热点订单与可售查询，丢失后从权威源重建，命中、失效和回源保护单独评分。支付提交与 Outbox（发件箱）事件同事务，Kafka（分布式日志消息系统）、RocketMQ（分布式消息队列）和 RabbitMQ（消息队列）按回放、顺序、路由、积压恢复和团队能力比较，消息不替代本地事实。物流轨迹进入 Elasticsearch（搜索引擎）检索投影，经营指标进入 ClickHouse（列式数据库）分析投影，设备报警按原始时序、窗口聚合和迟到修正分层；三个派生层都携带业务键、版本和水位，可校验、回放和降级。每张矩阵公布 E3（演练证据）的权重、分数和公式，并扫描权重变化导致的翻转；硬约束失败不打分。上线采用全量加增量重建、小流量切读和旧路径回退，差异越界立即停止。最后明确哪些是 E2（已有材料映射）的项目方案、哪些为 E0（待核对），不虚构版本、吞吐和收益。 项目落地时我会为六类角色分别设验收：交易看不变量与对账，缓存看版本和回源，消息看净恢复与幂等，搜索看权限和查询差异，分析看口径重算，时序看迟到与高基数。事故时先降级派生、保护权威，再按水位重建；复盘把新证据写回权重和门禁。退出时保证权威数据可导出、事件可回放、调用可兼容、旧读可回退，使任何单个产品都不是不可撤销前提。
• 追问 1：六类系统谁是主？直答：按事实所有权只有交易领域权威，其他按职责是可重建模型或传递通道。
• 追问 2：如何证明选型可撤销？直答：保留权威输入、事件水位、校验、旧读和明确下线窗口。
• 追问 3：什么时候重开选型？直答：门禁、工作负载、团队、成本或合规前提持续越界时。
• 追问 4：分数的定位是什么？直答：公开偏好并发现敏感项，不替代证据、底线和责任。
• 详情：存储搜索时序完整项目题库

6. 图形资产、项目话术与审计清单

• PlantUML（开源建模工具）源文件：selection-candidate-matrix.puml；同名 PNG（便携式网络图形）是渲染产物，源文件为唯一可编辑版本。

图解读：正式图从工作负载进入候选池，硬约束把候选分为淘汰、暂停和可评分三路；通过者进入加权矩阵与敏感性分析，再选择交易权威与缓存、消息、搜索、分析、时序派生角色。正常路径以版本、校验和重建闭环；失败路径由门禁失败、结论翻转或差异越界返回验证和工作负载；前提是分数不替代证据；结论是多模型只有在唯一权威和可重建成立时才是能力分工。

项目话术：我会先把库存、支付和订单的错误事实列为硬约束，再让缓存、消息、搜索、分析和时序分别证明可重建、可回放与可降级。候选通过门禁后才按工作负载加权；我会主动展示权重变化导致的结论翻转，不把总分说成客观真理。最终方案保留唯一权威、版本水位、差异校验、灰度和回退，并按 E0（待核对）至 E3（演练证据）说明事实边界。

• 能从四类来源生成候选，并说明为什么必须保留现状和不做选项。

• 能区分直接淘汰、暂停验证、降为派生角色和进入评分。

• 能手工复算加权分，并解释分数与证据置信度的区别。

• 能计算权重翻转点，并用交易、缓存、消息、搜索、分析、时序各举一例。

• 能说明唯一权威、版本、水位、幂等、校验、重建、灰度与回退。

• 能识别先定产品、重复计权、未知给中分和高分抵消门禁等反例。

• 知识小节与章节题：13 / 39，每个知识 ### 有标记和三道六字段题。

• Mermaid（图表语法）：13 张，其中 10 张为时序图，全部真实渲染。

• 表格与数据演绎：13 / 13，六类矩阵可复算，数字标 E3（演练证据）。

• 综合题：26 道，每题口述答案有效字符 560—1000，含 3—5 组追问直答和真实链接。

• 正式图：1 组，PlantUML（开源建模工具）源与同名 PNG（便携式网络图形）真实渲染并目视检查。