Spring（Java 应用框架）项目排障、事故复盘与综合面试题库

知识图谱编号：2.3.8。本篇不复制 2.3.1 至 2.3.7 的机制正文，而是把容器、代理、事务、请求、安全与持久层串成生产证据链。所有数量和指标均为面试演绎样例，真实面试时应替换为本人项目中可核对的数据。

1. 排障总原则：先证明事实，再解释机制

线上问题不能以“加注解、重启、扩容”结束。统一顺序是：确认影响面，执行可回滚止血，保存制品与现场，建立多个可证伪假设，用日志、指标、链路、线程、连接和数据库最终状态收敛根因，再完成修复、故障注入验证和组织复盘。框架日志只说明某个技术阶段，订单、资金、库存和任务状态才是业务结论。

flowchart LR
    A["告警与用户现象"] --> B["确认业务影响和时间窗"]
    B --> C["可回滚止血"]
    C --> D["冻结制品、配置和现场证据"]
    D --> E["提出可证伪假设"]
    E --> F["容器、代理、事务、请求、安全、持久层逐层验证"]
    F --> G{"证据能解释业务最终状态?"}
    G -->|"否"| E
    G -->|"是"| H["根因与修复"]
    H --> I["回归、灰度和故障注入"]
    I --> J["复盘、守门和知识沉淀"]

图解：节点是一次事故必须留下的证据阶段；箭头是从现象到可验证结论的推进顺序；前提是止血动作可回滚且不销毁现场；正常路径以数据库和外部渠道最终状态闭环；失败路径返回假设而不是继续猜；业务结论是“服务恢复”不等于“业务数据恢复”。

2. 十二类项目与事故实战

2.1 Bean（对象实例）创建、启动失败与就绪门禁

事故展开：现象是新版本实例反复重启且未进入就绪；影响是发布容量下降，旧实例退出后支付回调积压。证据包括制品摘要、配置版本、完整最内层异常、条件评估报告、容器刷新阶段耗时和已创建线程。假设依次为配置绑定失败、候选冲突、初始化远程调用超时和端口占用。止血是暂停滚动发布并保留旧实例，不把坏实例强行加入流量。根因若是渠道客户端在初始化回调中无界探测外部地址，应改成启动期只校验本地配置与密钥格式，就绪后有界预热；核心依赖失败保持不就绪，可选渠道按能力降级。验证要覆盖缺配置、外部超时、部分渠道失败和关闭，确认完成事件未发布时不会接流量。机制详见容器与 Bean（对象实例）生命周期和启动与自动配置。

flowchart TD
    A["启动失败"] --> B["固定制品、配置和启动参数"]
    B --> C["读取最内层异常"]
    C --> D{"失败阶段"}
    D -->|"定义"| E["扫描、导入、条件和覆盖"]
    D -->|"实例化"| F["构造器、工厂方法和候选"]
    D -->|"初始化"| G["回调、外部探测和线程"]
    D -->|"网页服务器"| H["端口、权限和连接器"]
    E --> I["最小配置复现"]
    F --> I
    G --> I
    H --> I
    I --> J{"修复后完成刷新且就绪?"}
    J -->|"否"| C
    J -->|"是"| K["灰度并验证资源释放"]

证据	能证明什么	不能证明什么	处置
最内层异常	首个失败阶段和直接原因	业务数据已经安全	保留完整异常链
条件评估报告	自动配置为何命中或后退	对象运行一定正确	与依赖树和配置交叉验证
完成与就绪事件	容器阶段已经完成	所有外部渠道可用	核心/可选能力分级
线程和连接差值	失败清理是否泄漏资源	后续请求语义正确	注入失败并观察归零

数据演绎 1：10:00:00 发布 v42，首个实例在 18s 时因渠道探测超时失败；五个实例连续重试使启动线程从 5 增至 47，旧池容量从 20 降至 12，回调积压从 0 升至 860。暂停发布后保留 16 个旧实例；把探测改成 800ms 超时、两次重试并移到就绪后，单实例刷新降到 6.2s。故障注入一个非核心渠道超时，新实例仍就绪但该渠道路由关闭；核心账务库不可达时实例保持不就绪。灰度 30 分钟后积压归零、线程回到基线且无未知支付。

2.2 循环依赖、早期代理与对象身份事故

事故展开：现象是应用升级后出现循环依赖错误，临时打开兼容开关虽能启动，但部分库存方法没有事务和审计。影响是同一业务对象存在原对象与代理两个身份，条件扣减在异常时未回滚。证据要包括依赖创建链、注入方式、作用域、容器最终引用类型、被依赖方持有的引用类型和通知器链。假设是构造器双向依赖、原型对象参与、初始化中泄露 this 或早期代理与最终代理不一致。止血应回滚版本或关闭危险入口，而不是永久允许循环。根因修复是抽取上层编排、领域事件或第三服务形成单向依赖；必须保留同步返回语义时，由编排器显式组织调用。验证比较引用身份并执行回滚、权限和审计测试。机制详见三级缓存、早期代理与重构边界和代理调用链。

sequenceDiagram
    participant C as "容器"
    participant A as "库存服务 A"
    participant B as "履约服务 B"
    participant P as "最终代理"
    C->>A: "实例化 A"
    C->>C: "登记 A 的早期引用工厂"
    C->>B: "A 依赖 B，开始创建 B"
    B->>C: "B 请求 A"
    C-->>B: "返回 A 的早期代理引用"
    C->>A: "完成填充和初始化"
    C->>P: "形成最终代理并校验身份"
    alt "早期代理与最终代理一致"
        P-->>C: "发布同一身份"
    else "原对象泄漏或重复包装"
        C-->>C: "启动失败或行为不一致"
    end

场景	能否依靠早期引用	主要风险	首选方案
单例属性循环	某些条件下可兼容	半初始化、身份不一致	重构依赖方向
构造器循环	不可	双方都没有原始实例	抽取编排器
原型循环	不可稳定缓存	每次创建链不同	消除循环
跨线程初始化	不应依赖	可见性、等待和死锁	生命周期内不启动业务线程

数据演绎 2：版本 v17 中 InventoryService 与 FulfillmentService 改为构造器互相依赖，12 个实例全部启动失败。临时改回属性注入后实例启动，但压测 10,000 次失败扣减有 37 次库存未回滚。身份采样显示履约服务持有原对象，而容器导出的是事务代理。回滚止血后抽取 AllocationCoordinator 统一编排，两个领域服务只暴露单向端口；再次压测 100,000 次，异常回滚率 100%，审计切面命中率 100%，依赖图不再成环。

2.3 AOP（面向切面编程）、事务失效与连接池耗尽

事故展开：现象是批量出库偶发部分提交，同时连接池等待持续升高。影响是订单状态、库存流水和消息记录不一致。证据必须同时证明实际引用是否为代理、调用是否从代理外部进入、事务管理器与数据源是否匹配、线程是否切换、连接何时获取与归还、异常是否传播、数据库最终行状态。假设包括同类自调用、非公开方法、异常被捕获、错误回滚规则、事务内远程调用、REQUIRES_NEW（新建事务传播）嵌套和异步线程越界。止血是关闭批量入口、降低并发并补偿未决记录。根因若是外层事务持有连接等待渠道，再由内层新事务申请第二连接，会形成容量乘法；应缩短本地事务，把远程交互移到状态机和可靠消息，按调用链设计池容量。详见代理拦截边界和事务传播与一致性。

flowchart TD
    A["事务失效或连接等待"] --> B["确认调用引用是否为代理"]
    B --> C{"是否从外部进入可拦截方法?"}
    C -->|"否"| D["定位自调用、私有方法或原对象"]
    C -->|"是"| E["确认事务管理器与数据源"]
    E --> F["跟踪连接获取、绑定和归还"]
    F --> G["确认异常传播与回滚标记"]
    G --> H["核对数据库最终状态"]
    H --> I{"存在远程等待或嵌套新事务?"}
    I -->|"是"| J["缩短事务并改状态机/消息"]
    I -->|"否"| K["修复代理、规则或资源绑定"]

证据层	关键问题	常见误判	验证
代理	调用是否经过拦截器	看到注解就认为生效	记录代理类型和调用入口
事务	管理器、传播和回滚标记	只看开始日志	跟踪事务标识与挂起恢复
连接	获取、绑定、等待、归还	只扩池不改长事务	对齐池指标和线程栈
数据	最终提交了哪些行	日志报错等于已回滚	独立连接核对最终状态

数据演绎 3：连接池上限 30，批量入口并发 20。每个外层事务先占一条连接，再调用平均 1.8s 的远程运价接口，其中 40% 请求进入 REQUIRES_NEW（新建事务传播）审计并申请第二条连接；峰值需求约 28 至 40，等待 p99 达 4.6s，超时率 7.3%。止血把并发降至 8。修复后远程调用移到事务外，本地更新和 Outbox（发件箱）写入控制在 45ms 内，审计合并同一事务；等待 p99 降至 12ms，连接使用峰值 14，注入渠道超时也不会占用数据库连接。

2.4 支付回调重复、本地事务消息与资金一致性

项目话术：背景是支付渠道会重复通知、乱序通知和超时重试，且本地订单、资金流水、余额和下游履约不能共享一个数据库事务。约束是回调响应要快、验签必须在状态变更前、金额币种不可相信请求体、渠道超时可能已成功。设计上以渠道、商户、渠道事件号建立唯一幂等键，保存原始报文摘要和验签版本；在同一本地事务中锁定支付单、校验合法状态迁移、写不可变资金流水与 Outbox（发件箱），提交后快速应答。发布器将事件投递 MQ（消息队列），消费方以业务事件号幂等；未知支付由查单，对账按渠道账单、支付单和资金流水三方核对。取舍是接受跨系统最终一致而不伪造全局原子性。事故时先暂停自动履约、保留收款入口和对账证据，再按状态补发或人工闭环。机制链接事务与 Outbox（发件箱）和请求绑定与异常处理。

sequenceDiagram
    participant P as "支付渠道"
    participant W as "回调入口"
    participant D as "本地数据库"
    participant O as "Outbox 发布器"
    participant M as "MQ（消息队列）"
    participant F as "履约服务"
    P->>W: "重复或乱序回调"
    W->>W: "验签、商户、金额、币种校验"
    W->>D: "唯一事件号 + 锁定支付单"
    D->>D: "状态迁移 + 资金流水 + Outbox 同事务"
    D-->>W: "提交成功"
    W-->>P: "快速成功响应"
    O->>D: "扫描未发布事件"
    O->>M: "至少一次投递"
    M->>F: "可能重复消费"
    F->>F: "业务事件号幂等履约"

stateDiagram-v2
    [*] --> CREATED
    CREATED --> PROCESSING: "发起渠道"
    PROCESSING --> SUCCEEDED: "明确成功或查单成功"
    PROCESSING --> FAILED: "明确失败"
    PROCESSING --> UNKNOWN: "超时或响应不可判定"
    UNKNOWN --> SUCCEEDED: "查单/对账确认成功"
    UNKNOWN --> FAILED: "查单确认失败"
    SUCCEEDED --> REFUNDING: "退款申请"
    REFUNDING --> REFUNDED: "退款确认"

控制点	唯一键/状态	失败窗口	恢复方式
回调接收	渠道+商户+事件号	验签后进程崩溃	渠道重试或主动查单
本地提交	支付单版本+流水号	提交结果未知	按唯一键查询，不盲重做
事件发布	Outbox（发件箱）事件号	提交后未投递	发布器重试
履约消费	业务事件号	消费成功但确认失败	幂等重放

数据演绎 4：渠道在 3s 内发送同一事件 E9001 三次，并在 30s 后补发一次。第一请求验签通过，将支付单 P77 从 PROCESSING 改为 SUCCEEDED，写流水 L88 与事件 O99；第二请求命中唯一键直接返回已处理，第三请求发现状态已终态且金额一致，也返回成功。发布器首次投递后在确认前崩溃，消息被再次投递；履约以 O99 唯一键只创建一个出库单。最终统计回调四次、本地状态变更一次、资金流水一条、消息投递两次、履约一次，金额守恒。

2.5 WMS（仓储管理系统）库存并发、防超卖与事务边界

项目话术：背景是多仓、多货主库存同时被下单、取消、波次和人工调整，热点商品峰值并发高。约束是不能只依赖应用锁，多实例、重试和消息重复都存在；也不能在数据库事务中调用仓外系统。设计以库存台账为权威事实，条件更新 available >= quantity 保证不为负，受影响行数决定成功；请求号和业务类型建立唯一流水，预占、确认、释放使用状态机，重复命令返回既有结果。批量分配按稳定顺序锁定库存行，缩短事务并避免死锁；跨服务通过可靠事件推进，超时订单由扫描与对账释放。取舍是热点行吞吐有限，必要时分仓、分桶或排队，但守恒不下放给缓存。详见事务边界和MyBatis（持久层框架）条件更新。

flowchart LR
    A["预占命令和请求号"] --> B["幂等流水唯一检查"]
    B --> C["条件扣减可用库存"]
    C --> D{"受影响行数为 1?"}
    D -->|"是"| E["写预占明细和 Outbox（发件箱）"]
    D -->|"否"| F["库存不足或并发冲突"]
    E --> G["事务提交"]
    G --> H["异步通知订单/履约"]
    H --> I{"后续成功?"}
    I -->|"成功"| J["确认预占"]
    I -->|"取消/超时"| K["幂等释放"]

方案	一致性依据	优点	风险与边界
应用内锁	单进程对象	简单	多实例无效
分布式锁	外部租约	收敛热点	锁过期、脑裂，仍需数据约束
条件更新	数据库原子行更新	直接守住不为负	热点行竞争
串行队列	分区顺序	平滑峰值	分区热点、积压和恢复

数据演绎 5：商品 S1 可用量 10，同时收到请求 R1=7、R2=6、R1 重试。R1 首次条件更新成功，可用变 3 并写预占流水；R2 因 3<6 影响行数为 0，返回不足；R1 重试命中唯一流水，返回第一次结果而不再扣减。订单随后取消，释放命令以原预占号只执行一次，可用恢复 10。压测 50,000 个含 20% 重复的命令，最终可用、预占、已占用之和始终等于期初加调整量。

2.6 跨境物流轨迹、面单接口与上下游同步

项目话术：背景是面单和轨迹接入多个承运商，不同字段、状态码、时区和重试语义不一致。约束是外部接口有配额、超时可能成功、轨迹会乱序补传且部分节点缺失。设计把供应商协议隔离在适配器，内部统一运单、节点和原始载荷摘要；创建面单使用业务请求号与供应商单号双向映射，超时进入未知状态并主动查询，不立即重建。轨迹以承运商、运单号、节点标识或规范化指纹幂等，保存原始发生时间、接收时间和时区，状态机只允许合法推进，迟到明细保留但不倒退主状态。同步采用游标或水位、分页检查点、限流、熔断和退避；失败进入可重放队列。请求机制详见Spring（Java 应用框架） MVC（网页模型视图控制器）请求链，持久化详见MyBatis（持久层框架）映射与批处理。

sequenceDiagram
    participant J as "上游订单"
    participant L as "物流应用服务"
    participant A as "承运商适配器"
    participant C as "承运商"
    participant D as "轨迹存储"
    J->>L: "创建面单，携带业务请求号"
    L->>D: "登记请求和 PROCESSING"
    L->>A: "转换内部模型"
    A->>C: "供应商协议请求"
    alt "明确成功"
        C-->>A: "供应商单号和面单"
        A-->>L: "规范化结果"
        L->>D: "保存映射并置成功"
    else "超时未知"
        L->>D: "置 UNKNOWN"
        L->>C: "按业务号主动查询"
    end

边界	内部统一模型	外部差异	防错措施
面单创建	请求号、运单、标签版本	同步/异步、返回格式	未知状态后查单
轨迹节点	代码、发生时间、地点	时区、状态码、补传	原始值+规范化值
批量同步	游标、水位、检查点	分页、配额、窗口	重叠窗口+幂等
下游通知	内部事件号	订阅方能力差异	至少一次+消费幂等

数据演绎 6：同步任务水位为 12:00，以五分钟重叠窗口拉取 11:55—12:10 共 1,200 条。去重后新增 980，重复 210，无法映射 10 条进入隔离表。运单 T9 先收到 DELIVERED，后补传两小时前的 IN_TRANSIT；明细都保存，但主状态不从已签收倒退。面单创建超时后查单发现供应商已生成单号，因此绑定原请求，不再次购买。下一水位只在所有分页落库成功后推进到 12:10。

2.7 Spring（Java 应用框架） MVC（网页模型视图控制器）异步导出与 OOM（内存溢出）

事故展开：现象是大客户导出百万行订单时进程频繁 Full GC（完全垃圾回收）并最终 OOM（内存溢出），接口线程和异步线程都堆积。影响是同实例其他查询超时，导出文件有时半成品。证据包括请求参数、任务号、堆使用趋势、堆转储、对象直方图、线程池队列、数据库游标、响应是否仍持有、文件写入字节和任务状态。假设包括一次性加载全量列表、工作簿对象保留所有单元格、无界线程池、请求上下文被闭包捕获和失败后临时文件未清理。止血是关闭同步大导出、限制行数和并发，保留小查询。修复为任务化导出：请求只校验并创建任务，执行器按主键游标分页读取、流式写临时对象存储，周期更新检查点，成功后原子发布下载地址；失败可幂等续跑并清理。详见异步请求与文件传输和JVM（Java 虚拟机）排障。

flowchart LR
    A["导出请求"] --> B["参数、权限和额度校验"]
    B --> C["创建唯一任务"]
    C --> D["有界队列调度"]
    D --> E["按主键游标分页读取"]
    E --> F["流式写临时文件"]
    F --> G["更新检查点和统计"]
    G --> H{"还有数据?"}
    H -->|"是"| E
    H -->|"否"| I["校验行数与摘要"]
    I --> J["原子发布下载地址"]
    J --> K["通知用户并设置过期清理"]

风险	证据	错误方案	正确控制
全量驻留	堆中列表和单元格对象	增大堆掩盖增长	游标分页、流式写
并发失控	活跃线程和队列无界	每请求新线程	有界池、租户配额
半文件	字节数与任务状态不一致	直接写正式地址	临时对象+原子发布
上下文丢失	异步线程无租户/用户	复制整个请求对象	显式最小上下文快照

数据演绎 7：旧方案导出 1,200,000 行，查询列表占 1.4GB，工作簿对象增至 2.8GB，4GB 堆在 11 分钟后 OOM（内存溢出）；队列中另有 17 个任务。止血限制单租户一个任务。新方案每页 2,000 行，内存稳定在 620—780MB，每 20,000 行保存检查点，写入临时对象 tmp/T88。第 360,000 行进程强杀后，新实例从已提交检查点恢复，最终行数与查询快照同为 1,200,000，摘要一致后才发布正式地址。

2.8 Spring Security（安全框架）越权、令牌与异步上下文事故

事故展开：现象是普通仓库账号可通过修改路径参数读取其他仓库订单，另有一批刷新后的令牌被旧实例拒绝。影响是数据越权与集中登录失败。证据包括脱敏主体标识、租户与仓库声明、请求路径、过滤器链、认证结果、方法授权决策、资源归属查询、密钥版本、签发与校验时间、时钟偏差和发布实例。假设是只校验登录未校验资源归属、方法安全被自调用绕过、租户上下文在异步线程丢失、密钥轮换不同步或时钟漂移。止血是关闭高风险批量接口、按租户网关限流、撤销受影响令牌并保留审计。修复采用入口认证、方法级权限和数据行归属三层校验；令牌按密钥标识支持新旧密钥短暂并存，敏感操作使用服务端会话版本或撤销表。异步任务只携带签名后的最小主体快照并在执行前重新授权。详见认证授权与过滤器链和请求入口。

flowchart LR
    A["请求到达"] --> B["过滤器认证主体"]
    B --> C{"令牌签名、时间和会话版本有效?"}
    C -->|"否"| D["拒绝并记录脱敏原因"]
    C -->|"是"| E["方法权限判断"]
    E --> F{"角色/能力允许?"}
    F -->|"否"| D
    F -->|"是"| G["查询资源租户和仓库归属"]
    G --> H{"主体可访问该资源?"}
    H -->|"否"| D
    H -->|"是"| I["执行业务并写审计"]

防线	解决问题	典型失败	验证
入口认证	你是谁	伪造、过期、错误密钥	签名、时间、发行者和受众
方法授权	能做什么	角色扩大、自调用旁路	外部代理入口和拒绝测试
数据授权	能操作哪条数据	改路径参数越权	查询强制租户/仓条件
审计与撤销	事后追踪和紧急失效	日志泄密、令牌长期有效	脱敏标识、会话版本

数据演绎 8：租户 A 的用户持有仓库 W1 权限，请求路径改为 W2。旧接口只检查 ROLE_OPERATOR，返回 200 和 37 条其他仓数据。止血关闭批量查询并在网关阻断跨仓参数。修复后仓库归属进入查询条件，方法权限仍作为第一层；回归矩阵覆盖 A/W1 成功、A/W2 拒绝、租户 B/W2 成功、管理员受审计。密钥轮换期间新密钥 K2 签发，校验端同时保留 K1 到旧令牌最长寿命结束，拒绝率从 18% 恢复到基线。

2.9 MyBatis（持久层框架）慢 SQL（结构化查询语言）、批处理与缓存事故

事故展开：现象是轨迹批量入库后数据库负载升高，接口 p99 从 180ms 升至 3.2s，部分页面读到旧状态。影响是同步积压和履约延迟。证据包括映射语句标识、脱敏参数形态、执行计划、扫描行数、返回行数、锁等待、批次大小、提交频率、会话范围、缓存命中与清理时点。假设是动态条件漏索引、循环单条写、批量执行未刷新、一级缓存返回旧对象、二级缓存跨事务失真或插件改写漏租户条件。止血是降低批次和并发、关闭高风险缓存、暂停异常计划。根因修复以真实选择性建联合索引，批次按参数和事务容量控制，写后清理正确命名空间；核心库存和资金不依赖二级缓存判定。验证比较执行计划、逻辑读、锁时间和最终行数，并用多会话交错测试缓存。详见MyBatis（持久层框架）执行与缓存。

flowchart TD
    A["慢 SQL（结构化查询语言）或脏读"] --> B["定位映射语句和参数形态"]
    B --> C["获取实际执行计划"]
    C --> D["核对扫描行、返回行和索引选择性"]
    D --> E["核对锁等待和事务时长"]
    E --> F["核对批次、刷新和提交"]
    F --> G["核对一级/二级缓存作用域与清理"]
    G --> H{"插件是否改写租户、分页或权限条件?"}
    H -->|"是"| I["审计改写前后语句和参数"]
    H -->|"否"| J["索引、语句或批次修复"]
    I --> J

问题	关键证据	常见根因	修复验证
慢查询	实际计划、扫描/返回比	索引不匹配、隐式转换	生产分布参数回放
批处理慢	每批行数、刷新、提交	伪批量、事务过大	吞吐与锁时间共同观察
旧数据	会话和命名空间清理	一级缓存复用、二级缓存滞后	双会话交错测试
租户泄漏	改写前后语句	插件漏条件或别名误判	越权用例和语法树审计

数据演绎 9：轨迹表 80,000,000 行，查询按 tenant_id + tracking_no，旧索引只有 tracking_no，某公共单号前缀扫描 240,000 行返回 12 行。增加以租户开头的联合索引后扫描 14 行。入库原来循环 5,000 次单条提交耗时 18s；改为每批 500、每 2,000 行提交后为 2.6s，锁等待未显著增加。二级缓存曾使另一会话在更新后 30s 仍读旧轨迹，核心查询关闭该缓存并以版本事件刷新页面投影。

2.10 Runner（执行器）调度、租约、重复执行与优雅停机

项目话术：背景是 Runner（执行器）处理报表、同步和补偿任务，多实例部署且会滚动发布。约束是进程可能强杀、任务时长不确定、数据库与 MQ（消息队列）只能提供各自边界。设计以任务状态机和租约领取：使用条件更新把待执行任务变为运行中，记录执行实例、租约截止和尝试次数；执行期间周期续租并保存检查点，副作用使用任务号加步骤号幂等。停机先从就绪和调度器摘除，停止领取新任务，给在途任务有界时间完成；超时则保存检查点、停止续租，让新实例在租约过期后恢复。取舍是至少一次执行而非假装恰好一次，业务副作用必须可重入。机制详见启动、就绪与优雅停机和事务边界。

stateDiagram-v2
    [*] --> PENDING
    PENDING --> RUNNING: "条件领取 + 租约"
    RUNNING --> RUNNING: "续租 + 检查点"
    RUNNING --> SUCCEEDED: "全部步骤完成"
    RUNNING --> RETRY: "可恢复失败"
    RETRY --> PENDING: "退避到期"
    RUNNING --> DEAD: "超过重试或不可恢复"
    RUNNING --> PENDING: "租约过期后接管"

阶段	必须动作	失败风险	恢复依据
领取	条件更新状态和租约	多实例重复领取	受影响行数和版本
执行	步骤幂等、续租、检查点	强杀、长暂停	任务号+步骤号
停机	摘流、停领、有界等待	强杀前未完成	检查点和租约过期
接管	校验旧租约和状态	双执行窗口	栅栏版本与幂等副作用

数据演绎 10：任务 J100 租约 60s，每 20s 续租，每 10,000 行保存检查点。实例 A 执行到 35,000 行时收到停机信号，停止领取并在 25s 宽限内提交到 40,000 行后退出；若第 15s 被强杀，租约到期后实例 B 以更高栅栏版本接管，从已提交 30,000 行恢复。第 30,001—35,000 行可能重做，但步骤幂等键阻止重复通知和重复扣费。最终任务成功一次，执行尝试两次。

sequenceDiagram
    participant R as "注册与流量入口"
    participant S as "调度器"
    participant W as "工作线程"
    participant D as "任务存储"
    R->>S: "停机通知"
    S->>R: "置为不就绪"
    S->>S: "停止领取新任务"
    S->>W: "通知在途任务收口"
    W->>D: "保存检查点与最终状态"
    alt "宽限内完成"
        W-->>S: "完成"
    else "宽限到期"
        S->>W: "中断可中断步骤并停止续租"
        D-->>S: "租约到期后允许新实例接管"
    end

2.11 IoT（物联网）报警风暴、背压与隔离

项目话术：背景是设备断网或阈值配置错误时，成千上万设备同时上报告警，通知、规则和工单链路被放大。约束是关键安全告警不能丢，重复心跳类告警不应淹没系统；单租户异常不能拖垮其他租户。设计在入口只做认证、格式校验和持久化接收，按租户与设备分区；以设备、规则、时间窗形成去重键，采用抑制、聚合、迟滞和恢复事件降低抖动。消费者有界并发，队列水位触发背压和分级降级：先暂停报表和低级通知，关键告警保留独立容量。规则版本写入事件，重放时按原版本解释；通知使用幂等键，工单状态机防重复创建。事故证据覆盖入口速率、分区倾斜、队列年龄、拒绝数、规则版本、通知成功和数据库池。请求边界详见Spring（Java 应用框架） MVC（网页模型视图控制器），持久化边界详见MyBatis（持久层框架）。

flowchart LR
    A["设备事件"] --> B["认证与格式校验"]
    B --> C["按租户/设备分区"]
    C --> D["原始事件持久化"]
    D --> E["规则判断和版本记录"]
    E --> F["时间窗去重、抑制和聚合"]
    F --> G{"队列水位"}
    G -->|"正常"| H["通知与工单"]
    G -->|"高"| I["背压并暂停低优先级"]
    I --> H
    H --> J["幂等副作用和恢复事件"]

层次	守护指标	风暴策略	不能牺牲的事实
入口	每租户速率、拒绝率	配额与背压	原始关键事件可追溯
规则	命中率、版本分布	去重、迟滞、聚合	解释使用的规则版本
队列	深度、最老年龄、倾斜	分区扩容和优先级	关键告警独立容量
副作用	通知、工单成功率	幂等、重试、死信	同一告警不重复建单

数据演绎 11：正常入口 2,000/s，错误规则发布后升至 45,000/s，租户 T7 占 82%，最老消息年龄 160s，数据库连接使用 95%。止血回滚规则并限制 T7 为 8,000/s，暂停低级短信。去重窗口将 15 分钟内同设备同规则的 1,800,000 条事件聚合为 62,000 个告警，关键安全类单独通道无丢失；恢复事件逐一关闭工单。修复加入规则灰度、命中倍数守门和租户隔离，演练 60,000/s 时关键队列年龄低于 5s。

2.12 统一事故指挥、证据矩阵与复盘守门

一次成熟事故处理要把“谁在什么时候基于什么证据做了什么”记录清楚。现象负责描述用户可见结果，影响负责量化订单、资金、库存、时延和租户范围；假设必须可由某项证据证伪。止血和根因修复分开：前者追求快速、可回滚和减少损失，后者改变机制并通过故障注入。证据分为发布事实、运行事实、调用事实、资源事实和业务事实；任何单层证据都不足以结束事故。复盘不追责个人，而是寻找为什么错误能进入生产、为什么监控未早发现、为什么恢复依赖人工记忆，并转化为配置校验、发布门禁、容量守门、演练和所有者。综合机制入口见路线与版本边界。

flowchart TD
    A["事故指挥"] --> B["影响与优先级负责人"]
    A --> C["止血执行负责人"]
    A --> D["证据与时间线记录"]
    A --> E["业务数据核对负责人"]
    B --> F["订单、资金、库存、租户影响"]
    C --> G["回滚、限流、降级、隔离"]
    D --> H["制品、配置、日志、指标、链路"]
    E --> I["最终状态、对账和人工闭环"]
    F --> J["统一事实表"]
    G --> J
    H --> J
    I --> J

flowchart LR
    A["复盘根因"] --> B{"哪道防线缺失?"}
    B --> C["设计：边界和不变量"]
    B --> D["实现：幂等、事务和资源"]
    B --> E["发布：配置、灰度和回滚"]
    B --> F["观测：指标、日志和业务对账"]
    C --> G["自动化守门"]
    D --> G
    E --> G
    F --> G
    G --> H["演练并验证防再发"]

证据域	关键字段	用途	保留原则
发布事实	制品摘要、配置版本、实例批次	关联变更	不记录明文密钥
调用事实	请求号、链路号、主体、代理路径	还原执行链	标识脱敏且可关联
资源事实	线程、连接、队列、堆、锁	解释容量与等待	与同时间业务量对齐
业务事实	状态历史、流水、事件、对账	判断最终正确性	不可变、可审计

数据演绎 12：14:03 告警显示支付回调错误率 22%；14:06 确认仅 v58 新实例受影响，覆盖 3 个商户、1,240 次回调。14:08 回滚并停止自动履约，14:12 错误率恢复。证据表发现配置中心密钥版本已更新，但新制品缓存旧公钥；86 笔已成功验签并入账，273 笔渠道成功但本地未知，其余明确失败。主动查单和对账在 15:10 收敛未知项，无重复入账。防再发加入密钥标识兼容窗口、发布前双版本验证、未知支付告警和季度演练，所有行动项均有所有者和截止日。

2.13 章节收口与题库使用说明

上面的十二个知识小节到此结束。下面的综合题库跨分册复述，不再计入章节级六字段题；每道题只保留一个权威口述答案，并链接到对应机制分册。

3. 跨章节综合口述题库

以下题目用于三至五分钟完整复述。每道题按结论、约束、机制链、失败边界、项目证据和验证闭环组织；追问给出直接答案，避免只留下关键词。

问题（综合题）：Bean（对象实例）的实例化和初始化有什么区别，完整创建链路如何影响线上排障？
考点：容器生命周期、失败阶段、代理和资源清理。
口述答案：结论是实例化只解决“原始对象怎样出现”，初始化解决“对象怎样变成满足框架契约、可被代理并可对外工作的成品”，二者之间还有依赖填充和感知回调，不能混为一个 new。容器先从 BeanDefinition（Bean 定义）选择构造器、工厂方法或 FactoryBean（工厂对象）产品并创建原始实例；随后按候选规则填充依赖，执行 Aware（感知接口）回调，再依次经过初始化前对象后置处理器、初始化回调、初始化后对象后置处理器，事务、安全或审计代理通常在后处理阶段形成。约束是构造器和初始化都不应进行无界远程调用或启动失控线程，因为上下文尚未完成刷新；初始化失败会取消关键单例创建，并要求清理本轮已建立的连接和线程。失败边界还包括原型对象销毁不由容器自动兜底、懒加载把错误推迟到首请求、初始化中泄露 this 导致原对象绕过代理。支付项目中，渠道客户端构造阶段只接收不可变配置，初始化阶段校验密钥格式和路由唯一性，远程能力放到有界预热；核心账务客户端失败时实例不就绪，非核心渠道可按能力降级。排障时我会先由最内层异常定位定义、实例化、填充、初始化还是代理阶段，再比较容器最终引用、资源差值和就绪事件。验证覆盖缺候选、错误密钥、远端超时、代理命中及关闭，证明失败实例不接流量且资源归零。
进一步验收时，我会固定制品、配置和依赖小版本，记录基线吞吐、延迟、线程、连接与业务状态，再分别注入重复、超时、部分失败和强杀。修复只有在技术指标恢复、业务不变量成立、失败可重放且回滚路径经过演练后才算完成；若仍依赖人工临时改数据，就继续保留风险项和所有者。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：构造器执行完对象就能被业务使用吗？直接回答：不能，依赖填充、初始化回调和代理可能尚未完成，此时暴露会得到半成品。
- 追问 2：初始化回调有哪几类？直接回答：常见有注解回调、初始化接口和定义中的初始化方法，具体顺序与版本应以机制分册和项目验证为准。
- 追问 3：为什么要区分失败阶段？直接回答：不同阶段证据和修复完全不同，候选冲突不能用延长超时解决，初始化阻塞也不能靠调整扫描范围解决。
- 关联专题：Bean（对象实例）完整生命周期

问题（综合题）：singleton（单例作用域）是否线程安全，怎样设计支付、库存类避免共享状态事故？
考点：作用域、共享可变状态、线程上下文和并发边界。
口述答案：结论是 singleton（单例作用域）只保证一个容器和名称下通常复用同一实例，不提供任何线程安全承诺。网页请求、消息消费、调度任务和异步回调会同时调用这个对象；若字段保存当前订单、租户、临时列表、非线程安全格式化器或可变渠道选择结果，就会发生覆盖、串租户和可见性问题。正确设计是让应用服务保持无状态：请求数据放方法参数和局部变量，不可变配置在构造后安全发布；确需共享的统计或缓存使用有明确并发语义的组件，并把原子范围、失效和容量写清。ThreadLocal（线程本地变量）只能表达线程绑定上下文，线程池会复用线程，必须在统一入口设置并在 finally 清理，而且异步切换不能假设自动传播。支付路由表在启动时由渠道集合构建成不可变映射，交易状态只进数据库；WMS（仓储管理系统）库存扣减依靠数据库条件更新和幂等流水，不能把数量缓存在单例字段。排障时会用并发请求携带不同租户和请求号，检查日志关联、字段快照、线程本地变量残留和最终数据；再通过线程安全检测与压力测试观察错误是否随并发出现。边界是“无状态”不等于没有依赖，连接池、缓存和客户端本身也是共享资源，需有界容量、线程安全说明和关闭协议。验证不仅看无异常，还要证明租户隔离、金额守恒、库存守恒以及滚动发布后上下文不串用。
为了让结论可复核，我会把主体、业务键、时间、线程、事务、连接和最终数据放到同一时间线，并明确每项证据能证明什么、不能证明什么。灰度期间设置停止条件和可回滚开关，结束后用独立查询或对账确认结果，避免把一条成功日志、一次无异常请求或短时指标下降误当成根因已经消失。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：给方法加同步锁能让单例设计正确吗？直接回答：只能串行化该实例上的部分访问，不能解决多实例、旁路调用和持久化不变量，还会压低吞吐。
- 追问 2：不可变对象为何更容易线程安全？直接回答：构造后状态不再变化，正确发布后各线程不必协调读写，推理范围更小。
- 追问 3：请求作用域能代替无状态设计吗？直接回答：它隔离一次请求，但消息、调度和异步场景仍需显式上下文，也会增加对象和代理管理成本。
- 关联专题：作用域与线程安全

问题（综合题）：BeanFactoryPostProcessor（Bean 工厂后置处理器）和 BeanPostProcessor（Bean 后置处理器）有什么区别，误用会造成什么事故？
考点：定义阶段、实例阶段、过早创建和代理生成。
口述答案：结论是前者修改“对象配方”，后者参与“每个对象从原始实例到最终引用”的过程。BeanFactoryPostProcessor（Bean 工厂后置处理器）在普通单例创建前读取或修改 BeanDefinition（Bean 定义），适合占位符解析、定义校验和程序化注册；它不应为了业务逻辑主动获取普通对象，否则会在对象后置处理器链尚未完整时造成过早实例化。BeanPostProcessor（Bean 后置处理器）围绕实例初始化前后工作，依赖注入、生命周期注解、事务和其他代理能力都可能通过它或其扩展完成，因此顺序和适用范围直接影响最终对象身份。失败边界包括定义处理器偷偷访问数据库导致启动阻塞、对象处理器自身依赖普通业务对象造成链不完整、多个代理处理器重复包装、返回不同实例却未保持早期引用一致。项目中，支付渠道配置的重复标识和必填属性应在定义或启动校验阶段失败，而交易规则不应由定义处理器调用远端加载；审计代理只包围带明确标记的应用服务，不对所有对象盲目拦截。排障时先导出处理器名称与顺序，确认目标对象创建时间是否早于完整链注册，再比较原始类型、最终代理类型和通知器；若只有部分方法缺事务，要同时检查对象是否从静态注册、监听器或初始化回调中逃逸。验证用最小上下文断言定义修改结果、代理链、失败清理和多处理器顺序，不能只凭启动成功判断扩展点正确。
容量层面还会用接近生产的租户分布、热点比例和失败延迟进行阶梯压测，同时观察队列最老年龄、资源等待、拒绝、重试和下游承载。达到阈值时系统应先背压或降级非核心能力，而不是无限堆积；恢复后资源要自动回到基线，积压有明确清理速度，核心交易不因批处理或外部抖动被拖垮。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：为什么定义处理器不能随意调用 getBean？直接回答：这可能提前创建普通对象，使其漏过尚未注册完整的对象后置处理器和代理链。
- 追问 2：对象后置处理器能替代领域服务吗？直接回答：不能，它适合通用生命周期和横切能力，复杂业务状态机放进去会隐藏调用和事务边界。
- 追问 3：怎样处理多个代理能力的顺序？直接回答：明确安全、事务、重试、审计等先后语义，记录通知器链并以失败场景验证，不能只依赖偶然注册顺序。
- 关联专题：容器扩展点与对象后置处理器

问题（综合题）：Spring（Java 应用框架） Transaction（事务）的异常回滚规则是什么，为什么线上仍会出现“报错但已提交”？
考点：代理、异常传播、回滚标记、提交时点和数据库最终状态。
口述答案：结论是回滚不是由“日志里出现异常”触发，而是事务拦截器在代理调用边界观察到异常，并按配置决定提交或回滚；最终还要看物理事务是否成功提交。常见默认规则会对未检查异常回滚，对检查异常需显式配置，但项目不能死记默认值，应按实际版本和注解核对。出现“报错但已提交”通常有五类原因：调用根本没经过代理，例如同类自调用或原对象逃逸；方法使用了错误事务管理器或数据源；异常在事务方法内部被捕获并正常返回；异常类型不命中回滚规则；异步线程在原事务之外失败。还有一种相反情况是内层参与事务后标记仅回滚，外层捕获异常继续提交，最终在提交时得到意外回滚。排查必须记录实际代理、事务标识、传播行为、连接绑定、异常离开代理的形态、回滚标记和提交日志，再用独立连接查询最终行状态。支付回调中，验签和参数错误应在事务前拒绝；状态更新、资金流水和 Outbox（发件箱）同一事务，任何不变量失败都抛出明确业务异常并命中回滚。修复不能只“再加注解”，而要调整调用入口、异常契约或事务边界。回归覆盖正常、检查异常、未检查异常、提交阶段失败、同类自调用和异步切换，并核对支付单、流水和事件三者同成同败。
安全与可靠性验收会同时覆盖正常、越权、伪造、重复、乱序和过期输入，所有拒绝都要有脱敏审计，所有重试都要由持久业务键吸收。关键结论不能依赖单机内存或线程上下文，进程重启、实例扩容和消息重放后仍应得到同一业务终态；无法自动确定的结果必须进入未知状态、查证和人工闭环。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：捕获异常后手工标记回滚可以吗？直接回答：技术上可以，但会增加隐藏控制流；优先让异常契约清晰地穿过事务边界，确需转换时保留原因并显式测试。
- 追问 2：日志打印“回滚”就证明数据没提交吗？直接回答：不能，可能是另一事务或提交前日志，必须用事务外独立查询和流水对账确认。
- 追问 3：检查异常为什么常被误用？直接回答：开发者以为所有异常默认回滚，实际规则可能不同；应按业务原子性显式配置并测试，而非按异常继承体系猜。
- 关联专题：事务代理、回滚规则与最终状态

问题（综合题）：AOP（面向切面编程）适合解决什么问题，为什么不能承载复杂领域流程？
考点：横切关注点、代理边界、顺序和可观测性。
口述答案：结论是 AOP（面向切面编程）适合把多个明确调用点都需要、且不改变核心领域语义的横切能力集中起来，例如事务入口、授权、审计、指标和受控重试；它不适合隐藏支付状态迁移、库存补偿或履约编排。代理式实现只拦截通过代理引用进入的可拦截方法，同类自调用、私有路径、构造阶段、原对象引用和异步线程都可能绕过；多个通知还存在顺序问题，例如重试包在事务外会每次建立新事务，包在事务内可能在同一已失败事务里重复。若把复杂业务放切面，调用者看不到副作用和失败契约，测试与事故还原都会困难。项目中我会让审计切面记录脱敏主体、请求号、方法结果类别和耗时，但支付金额校验、状态机和对账由显式应用服务完成；安全切面负责能力判断，资源归属仍进入查询条件。排障先确认目标对象代理类型、通知器链和真实调用入口，再比较成功与失败路径是否都经过切面，检查通知内部是否发起远程调用、吞异常或记录敏感数据。设计评审要求切面幂等、快速、有界并可关闭，明确顺序和失败策略。验证包含代理命中、自调用旁路、通知异常、多个通知顺序、异步切换和性能开销，业务最终状态仍由领域数据证明，不能用“切面日志存在”代替正确性。
设计复盘时我会说明曾考虑的替代方案、没有采用的原因以及剩余边界，把临时止血、永久修复和长期治理分开。行动项必须转化为启动校验、唯一约束、容量门禁、告警或演练，并绑定负责人和期限；下一次相同故障应由系统提前拒绝、快速降级或自动恢复，而不是再次依赖个人经验排查。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：日志切面失败应不应该阻断业务？直接回答：普通观测通常降级并告警，强审计按合规要求可能阻断；策略必须显式且有容量隔离。
- 追问 2：怎样解决同类自调用？直接回答：优先把事务或授权边界提升到另一个协作对象的公开入口，不建议到处从容器取自身代理。
- 追问 3：AOP（面向切面编程）和过滤器有什么边界？直接回答：过滤器位于网页请求入口，代理围绕容器方法；消息和调度没有网页过滤器，核心能力应放正确边界而非重复实现。
- 关联专题：代理链、通知顺序与适用边界

问题（综合题）：三级缓存解决循环依赖需要哪些前提，为什么仍可能出现代理身份不一致？
考点：单例属性循环、早期引用、代理时点与不可解边界。
口述答案：结论是所谓三级缓存不是通用循环依赖算法，而是单例创建流程中管理完整对象、早期引用和早期引用工厂的协作机制。它要求至少先产生某一方原始实例，所以构造器双方互相依赖时无对象可暴露；原型对象没有稳定的单例缓存生命周期，也不能依赖该机制。属性循环中，容器实例化 A 后登记早期引用工厂，填充 A 时创建 B，B 再请求 A 才触发工厂返回早期引用；若 A 将来需要代理，工厂要尽量返回与最终发布一致的早期代理。身份不一致通常来自自定义后置处理器重复包装、初始化中把原始 this 注册到外部、处理器过早创建对象，或早期代理与最终代理使用不同通知链。即使容器允许循环，B 看到的 A 也可能尚未完成全部初始化，所以调用其业务方法存在半成品风险。WMS（仓储管理系统）项目中库存与履约双向依赖应抽取分配协调者；若旧系统短期兼容，必须比较依赖方引用与容器最终引用的代理类别和匿名身份，执行事务、安全、审计三类命中测试，并设置移除期限。排障保留最深创建链，确认注入方式、作用域、版本开关和自定义处理器，再查静态集合、监听器与线程是否泄露原对象。最终验收是依赖方向单向、代理身份唯一、异常回滚和关闭资源正确，而不是仅把应用启动起来。
进一步验收时，我会固定制品、配置和依赖小版本，记录基线吞吐、延迟、线程、连接与业务状态，再分别注入重复、超时、部分失败和强杀。修复只有在技术指标恢复、业务不变量成立、失败可重放且回滚路径经过演练后才算完成；若仍依赖人工临时改数据，就继续保留风险项和所有者。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：二级缓存为什么不能直接存原对象？直接回答：目标对象若需要代理，直接暴露原对象会让依赖方绕过横切能力；延迟工厂允许在真正需要时生成早期代理。
- 追问 2：属性循环一定能解决吗？直接回答：不一定，还受作用域、版本策略、异步创建和自定义代理处理器影响，不能写成绝对能力。
- 追问 3：打开循环引用配置是不是修复？直接回答：通常只是兼容止血，必须补身份验证、监控和明确重构计划。
- 关联专题：三级缓存、早期代理和不可解边界

问题（综合题）：自动配置如何提供默认实现，又如何被业务安全覆盖？
考点：候选导入、条件评估、后退规则、配置绑定和版本边界。
口述答案：结论是自动配置是“在明确条件成立且业务未提供替代对象时注册默认能力”，不是启动后神秘修改对象。启动阶段先根据版本对应的注册元数据导入候选配置，再评估类路径、配置属性、已有对象、网页应用类型等条件；条件成立后注册 BeanDefinition（Bean 定义），常见后退条件让用户定义对象优先。安全覆盖要求类型、限定标识和注入点语义一致，多个候选要明确主候选或集合路由，不能依赖名称碰巧覆盖。失败边界包括把另一主版本的注册方式和配置键套入项目、业务对象创建得太晚导致后退条件已命中、配置绑定成功但账号语义错误、同名覆盖掩盖两个来源，以及测试环境类路径与生产不同。支付项目中默认渠道路由器只在不存在自定义路由器时注册；业务提供多渠道路由时，以渠道标识建立不可变映射，重复标识启动失败。排障从依赖树锁定 Spring Boot（快速开发框架）小版本，查看条件评估报告、候选配置来源、已注册对象名称、绑定结果和最终注入引用，不以“加排除注解”作为第一反应。验证用最小上下文覆盖依赖存在/缺失、属性启用/禁用、用户对象存在、多个候选和错误配置，确认默认实现恰好在预期条件下出现，升级时重新核对官方稳定文档和运行结果。
为了让结论可复核，我会把主体、业务键、时间、线程、事务、连接和最终数据放到同一时间线，并明确每项证据能证明什么、不能证明什么。灰度期间设置停止条件和可回滚开关，结束后用独立查询或对账确认结果，避免把一条成功日志、一次无异常请求或短时指标下降误当成根因已经消失。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：业务对象为什么可能没有让默认实现后退？直接回答：其定义注册时机、类型或条件不匹配，条件评估时看不到符合要求的候选；应查报告和定义来源。
- 追问 2：直接排除整个自动配置有什么风险？直接回答：可能连同必要基础设施一起移除，升级时还会失去默认修复；优先在最小范围提供替代对象或调整条件。
- 追问 3：怎样避免版本知识混用？直接回答：先读项目依赖树锁定小版本，再核对对应官方文档、配置键和条件报告，用运行证据落地。
- 关联专题：启动、自动配置和条件评估

问题（综合题）：为什么不建议在数据库事务中调用支付、物流等远程系统，正确设计是什么？
考点：长事务、未知结果、状态机、可靠事件和补偿。
口述答案：结论是本地数据库事务只能原子控制绑定的本地资源，无法把第三方支付或承运商接口纳入同一提交；把远程调用塞进事务既没有获得全局原子性，反而延长连接和锁持有，并制造超时未知结果。典型失败是请求已被渠道执行但响应丢失，本地因超时回滚；若随后盲目重试，可能重复扣款或购买面单。正确做法先定义状态机和业务唯一键：在短本地事务中保存操作意图、请求号和待发事件，提交后调用远端；明确成功、明确失败和未知结果分别推进状态。未知状态优先主动查询，长期未决进入对账与人工闭环；远端若支持幂等键必须传稳定业务号。下游通知通过 Outbox（发件箱）和 MQ（消息队列）至少一次投递，消费者以事件号幂等。支付项目中支付单从创建、处理中、未知到成功或失败，资金流水只在确认成功时生成且唯一；物流面单超时后按业务号查单，不再次购买。排障要对齐本地事务时间、连接占用、远程请求号、渠道流水、状态历史和消息轨迹，不能看到本地回滚就假定渠道失败。验证注入远端超时、响应丢失、重复回调、发布确认丢失和消费者重启，证明金额、订单和履约最终一致且连接池不被远程延迟拖垮。
容量层面还会用接近生产的租户分布、热点比例和失败延迟进行阶梯压测，同时观察队列最老年龄、资源等待、拒绝、重试和下游承载。达到阈值时系统应先背压或降级非核心能力，而不是无限堆积；恢复后资源要自动回到基线，积压有明确清理速度，核心交易不因批处理或外部抖动被拖垮。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：先调用远端再开本地事务可以吗？直接回答：仍有远端成功而本地提交失败窗口，必须用可查询状态、幂等和补偿闭环，而非调整顺序假装原子。
- 追问 2：什么情况下可以同步等待远端？直接回答：用户体验需要时可以同步获得尝试结果，但不能长时间持有数据库事务，并要保留未知状态处理。
- 追问 3：补偿等于回滚吗？直接回答：不等于，补偿是新的业务动作，可能失败、产生费用或需要审批，必须可审计和幂等。
- 关联专题：本地事务、传播与跨系统一致性

问题（综合题）：Spring（Java 应用框架）进程内事件和 MQ（消息队列）有什么区别，如何选择？
考点：进程边界、可靠性、事务阶段、重复消费和解耦成本。
口述答案：结论是进程内事件用于同一进程内的生命周期通知或弱耦合协作，MQ（消息队列）用于跨进程持久传递、削峰和独立恢复；二者都不是天然恰好一次。普通进程内事件通常与发布线程和进程同生共死，进程在监听前后崩溃都可能丢失，多个实例也各有自己的事件空间；事务阶段监听只能控制本进程回调相对本地事务的时点，提交后进程立即崩溃仍可能没有执行。MQ（消息队列）通过代理持久化、确认和重投提高可靠性，但会带来重复、乱序、积压、模式演进和运维成本，消费者必须幂等。选择依据是失败是否需要跨重启恢复、是否跨服务、是否需要削峰与独立扩缩容。支付状态变更不能只发布进程内事件触发履约，应在同一本地事务写 Outbox（发件箱），由发布器投递 MQ（消息队列）；容器刷新完成后的本地缓存预热通知可用进程内事件，但需有界且失败不阻塞核心就绪。排障时确认事件发布阶段、线程、监听器异常策略和实例边界，MQ（消息队列）还要看事件号、代理确认、消费位点、重试与死信。验证包含提交前失败、提交后强杀、重复投递、监听器异常和消息积压，最终用订单、资金和履约状态闭环，而非只看“发布成功”日志。
安全与可靠性验收会同时覆盖正常、越权、伪造、重复、乱序和过期输入，所有拒绝都要有脱敏审计，所有重试都要由持久业务键吸收。关键结论不能依赖单机内存或线程上下文，进程重启、实例扩容和消息重放后仍应得到同一业务终态；无法自动确定的结果必须进入未知状态、查证和人工闭环。
最后还要归档可复现输入、核对语句和恢复结果，使后续维护者能独立验证结论，而不是只能相信事故当事人的口头判断。
- 追问 1：异步进程内事件是不是就等于 MQ（消息队列）？直接回答：不是，它通常仍没有跨进程持久化、确认、重放和消费位点，只是换到本地线程池执行。
- 追问 2：事务提交后监听就绝对可靠吗？直接回答：不可靠，提交后到监听完成之间仍可崩溃；可靠业务事件应先持久化。
- 追问 3：所有解耦都上 MQ（消息队列）好吗？直接回答：不好，同进程强一致协作会增加延迟和运维复杂度，应按恢复与容量需求选择。
- 关联专题：请求、事件与异步边界
问题（综合题）：请完整设计一个支持网页请求、消息消费和 Runner（执行器）任务的优雅停机流程。

考点：就绪摘流、在途排空、资源关闭、租约恢复和强杀边界。

口述答案：结论是优雅停机不是执行销毁回调这么简单，而是一套“先拒绝新工作、再处理在途、最后释放资源”的有界协议，并且必须承认宽限期到达后可能强杀。第一步把实例置为不就绪并从服务发现摘除，等待网关和客户端连接传播；网页服务器停止接受新请求但允许短请求完成。消息消费者暂停拉取，只有业务状态和消费确认都安全时才确认；Runner（执行器）停止领取新任务，在途任务完成当前可提交单元、保存检查点并停止续租。随后按依赖反向顺序关闭业务线程池、消息客户端、网页服务器和数据库连接池，所有等待都有截止时间和指标。失败边界包括长连接仍把请求送来、线程忽略中断、远程结果未知、任务副作用完成但状态未提交，以及强杀发生在任何一步。支付服务对未知渠道请求交给查单和对账，WMS（仓储管理系统）库存命令靠幂等请求号重放，Runner（执行器）由租约过期和更高栅栏版本接管。验证要在持续流量、消息和长任务下滚动发布，并在不同阶段强杀；核对停机后新领取数为零、在途曲线下降、连接线程归零、重复动作被幂等吸收、积压可恢复。只证明进程退出码正常不够，最终订单、资金、库存和任务终态必须正确。

设计复盘时我会说明曾考虑的替代方案、没有采用的原因以及剩余边界，把临时止血、永久修复和长期治理分开。行动项必须转化为启动校验、唯一约束、容量门禁、告警或演练，并绑定负责人和期限；下一次相同故障应由系统提前拒绝、快速降级或自动恢复，而不是再次依赖个人经验排查。