容量、排队、Little’s Law（利特尔定律）与资源模型

适用边界：本册只讲从业务量推导 QPS（每秒查询率）、TPS（每秒事务数）、并发、线程、连接、数据库、磁盘、网络与存储的方法。所有数值均为 E3（演练证据），用于展示单位守恒、假设、敏感性和验证路径，不代表生产容量、SLA（服务等级协议）或真实收益。实际结论必须用线上流量、压测版本、数据分布、依赖配额和业务审计校准。

容量、排队与资源瓶颈闭环

正式图的 PlantUML（统一建模语言）源见 reliability-capacity-queueing.puml。

正式时序图

本册共包含 13 张 Mermaid（图表语法）图，其中 10 张为时序图；每张图、每张表和每组演绎共同回答“输入如何变成资源需求、哪里先饱和、何时必须拒绝、如何证明恢复”。

1. 容量模型先固定对象、单位、窗口与证据等级 {#53-02-k01}

容量不是一个脱离场景的“并发数”。先确定工作对象是查询、事务、消息、报警还是导出任务，再固定统计窗口、平均与峰值、成功口径、重试归并和事实等级。单位必须可约掉：请求/秒 × 秒/请求 = 请求，条/秒 × 字节/条 = 字节/秒；若公式左右单位不同，结论一定有问题。

flowchart LR
    B[业务事件与时间窗] --> R[到达率与峰值]
    R --> S[服务时间与等待时间]
    S --> C[在途并发与资源需求]
    C --> G[线程 连接 数据库 磁盘 网络 存储]
    G --> V[压测与线上证据校准]
    V --> D{证据是否足够}
    D -->|是| A[形成容量边界]
    D -->|否| E[保持 E3 演练证据]

图解读：节点从业务事件走到资源与验证；箭头表示每一步都要保留单位和窗口。前提是同一对象、同一时间语义；正常路径用证据校准，失败路径保持 E3（演练证据）；结论是“实例数”只能是推导结果，不能作为模型起点。

量	符号与单位	必须声明	常见误用
到达率	`lambda`，请求/秒或任务/秒	平均、峰值、峰值持续时间	把日均直接当峰值
服务时间	`S`，秒/个	纯处理还是含下游等待	与端到端等待混用
停留时间	`W`，秒/个	排队加服务的边界	只看接口执行时间
在途量	`L`，个	含队列、执行中、未确认哪些状态	只数工作线程
吞吐	`X`，完成个数/秒	成功完成还是尝试次数	把重试算成有效产出

数据演绎 1：先做量纲检查再算容量

E3（演练证据）：某查询入口候选峰值为 600 请求/秒，候选平均端到端停留时间为 0.15 秒/请求，则平均在途为 600 × 0.15 = 90 请求。若误把 150 毫秒直接代入，会得到 90000，量纲实际是“请求·毫秒/秒”，尚未约分。状态从业务入口到 90 个平均在途；观测信号是入口计数、完成计数、排队与服务时间；结论是先统一成秒，再讨论线程和连接。

2. 从业务量推导平均、峰值和峰值持续时间 {#53-02-k02}

日订单、活跃设备和导出任务是业务量，不是直接的资源速率。推导时先选忙时窗口，再乘集中系数、读写放大、重试放大和增长系数。均值用于成本基线，峰值与持续时间决定是否排队、排多深以及恢复多久；只有峰值没有持续时间，就无法估算队列和存储。

sequenceDiagram
    participant B as 业务预测
    participant M as 时间窗模型
    participant A as 到达率模型
    participant R as 资源模型
    participant V as 验证
    B->>M: 日订单 设备数 任务数
    M->>A: 忙时占比 集中系数 持续时间
    A->>A: 叠加读写与重试放大
    A->>R: 平均率 峰值率 峰值时长
    R->>V: 并发 队列与资源候选
    alt 回放与压测匹配
        V-->>B: 接受区间并登记余量
    else 分布或依赖不匹配
        V-->>M: 修正窗口与放大系数
    end

图解读：业务预测经过窗口和放大系数才成为到达率；正常路径验证后接受区间，失败路径回到分布假设。结论是峰值模型必须能解释“多大、多久、为何集中”。

输入	演练单位	推导作用	敏感项
日业务量	单/日、事件/日	形成日均基线	节假日与增长
忙时占比	百分比/窗口	把日量集中到忙时	营销与批处理重叠
峰均比	倍数	从忙时均值推峰值	秒级突发
写放大	次写/业务事件	推数据库与消息量	状态与审计记录
重试放大	尝试/业务事件	推真实入口压力	超时和未知态

数据演绎 2：日订单到下单 TPS（每秒事务数）

E3（演练证据）：假设候选日订单 864000 单/日，其中 30% 集中在 2 小时，则忙时平均为 864000 × 30% ÷ 7200 = 36 TPS（每秒事务数）；若候选峰均比为 4，入口峰值约 144 TPS（每秒事务数）。每单产生 1 次订单写、2 次库存写、1 条发件箱记录，数据库候选写入为 144 × 4 = 576 次/秒。任一输入增加 25%，结果同比增加 25%；若重试因超时从 1.02 放大到 1.3，入口尝试会从约 147 跳到 187 次/秒。

3. Little’s Law（利特尔定律）区分服务时间、等待与在途 {#53-02-k03}

稳定系统中，Little’s Law（利特尔定律）为 L = lambda × W。W 是对象从进入边界到离开的平均停留时间，等于等待时间加服务时间；若只把服务时间代入，得到的是平均执行中数量，不是队列加执行中的总在途。定律不要求特定到达分布，但要求观察窗口足够长、边界一致、进入与离开守恒且系统近似稳定。

sequenceDiagram
    participant I as 入口
    participant Q as 等待队列
    participant S as 服务单元
    participant O as 完成出口
    I->>Q: 以 lambda 到达
    Note over Q: 等待 Wq
    Q->>S: 获得线程或连接
    Note over S: 服务 S
    S->>O: 成功完成或明确失败
    O-->>I: 同一边界统计离开
    Note over I,O: W = Wq + S, L = lambda × W

图解读：入口、队列、服务与出口构成同一统计边界；箭头区分等待和处理。前提是窗口内流入流出近似守恒；失败路径是积压持续增长或遗漏执行中状态；结论是总在途必须覆盖所有停留阶段。

计算目标	使用时间	公式	解释
平均执行中	服务时间 `S`	`lambda × S`	正占用服务单元的对象
平均排队	等待时间 `Wq`	`lambda × Wq`	尚未获得资源的对象
平均总在途	停留时间 `W`	`lambda × W`	排队加执行中
平均完成率	稳定窗口完成数	`完成数 ÷ 秒数`	不能用拉取数替代

数据演绎 3：查询服务的等待与服务拆分

E3（演练证据）：候选稳定到达率 500 请求/秒，平均数据库与应用服务时间 80 毫秒，平均排队 40 毫秒。执行中约为 500 × 0.08 = 40，排队约为 500 × 0.04 = 20，总在途约为 60。若只看 40 个工作线程，会漏掉 20 个等待对象；若 P99（99 分位响应时间）停留达到 1 秒，尾部在途不能用平均 60 直接代表，仍需有界队列和超时预算。

4. 利用率、排队稳定条件与非线性拐点 {#53-02-k04}

有 m 个近似同质服务单元、单元平均服务率为 mu = 1/S 时，总候选能力为 m × mu，利用率 rho = lambda ÷ (m × mu)。长期稳定至少要求 rho < 1，但“小于 1”不等于安全；当利用率逼近 1，随机波动、长尾、锁和重试会让等待非线性放大。容量目标应由延迟、恢复与故障余量反推，而不是把 100% 利用率当成高效率。

sequenceDiagram
    participant I as 到达流量
    participant Q as 有界队列
    participant P as 服务池
    participant D as 下游依赖
    I->>Q: lambda 持续进入
    Q->>P: 最多 m 个并行
    P->>D: 每个平均服务时间 S
    D-->>P: 成功或变慢
    alt rho 明显低于 1
        P-->>Q: 有余量吸收波动
    else rho 接近或超过 1
        Q->>Q: 等待非线性增长
        Q-->>I: 限流 拒绝或降级
    end

图解读：队列把到达与服务池连接，服务池又受下游约束；正常路径保有余量，失败路径触发有界拒绝。结论是稳定条件只给必要边界，安全水位必须通过分布和故障演练确定。

利用率区间	E3（演练证据）解释	主要风险	候选动作
低于 50%	余量较大	成本可能偏高	核对故障与增长需求
50% 至 70%	常规观察区	局部热点	看分片和尾延迟
70% 至 85%	敏感区	等待放大	限制重试、准备扩容
高于 85%	高风险区	波动即积压	限流、降级、扩瓶颈
不低于 100%	长期不稳定	队列必增	立即降低到达或提高有效服务率

数据演绎 4：服务时间抖动跨过稳定边界

E3（演练证据）：20 个工作单元，每个候选服务时间 40 毫秒/个，单元能力 25 个/秒，总能力 500 个/秒。入口 350 个/秒 时 rho = 70%；若下游变慢使服务时间升到 55 毫秒，总能力降为约 364 个/秒，利用率约 96.2%；再升到 60 毫秒，总能力约 333 个/秒，入口不变却每秒新增约 17 个积压。服务时间只增加 20 毫秒，系统已跨过非线性拐点。

5. 查询模型从 QPS（每秒查询率）落到缓存、线程、连接与数据库 {#53-02-k05}

查询容量要拆成缓存命中与回源两条路径。入口 QPS（每秒查询率）乘回源比例得到数据库查询率，但缓存失效、热点和重复查询会让比例在峰值时变化；应用线程需求由所有路径的占用时间决定，数据库连接需求只由持有连接的那段时间决定。缓存提高平均吞吐，不应被写成数据库容量消失。

sequenceDiagram
    participant U as 用户
    participant A as 查询服务
    participant C as 缓存
    participant P as 连接池
    participant D as 数据库
    U->>A: 峰值查询 QPS
    A->>C: 按业务键查询
    alt 缓存命中
        C-->>A: 返回可接受新鲜度结果
    else 未命中或过期
        A->>P: 等待并获取连接
        P->>D: 执行查询
        D-->>A: 返回并受控回填缓存
    end
    A-->>U: 结果 明确降级或拒绝

图解读：缓存与回源路径占用不同资源；前提是命中率按峰值和业务切片统计。失败路径是击穿导致连接池等待；结论是要分别计算入口、回源和连接持有并发。

层级	候选公式	关键输入	非线性拐点
入口	峰值业务查询 × 尝试放大	峰值与取消	网关排队
缓存	入口 × 命中率	热点与新鲜度	热键或失效风暴
回源	入口 × 未命中率	失效和穿透	数据库连接等待
连接并发	回源率 × 持有时间	查询与网络时间	池耗尽
数据库工作	回源率 × 单次扫描与写入	索引和数据分布	CPU（中央处理器）、锁或磁盘饱和

数据演绎 5：跨境轨迹查询的缓存敏感性

E3（演练证据）：候选峰值 1000 QPS（每秒查询率），缓存命中率 90% 时回源 100 QPS（每秒查询率）；查询持有连接平均 50 毫秒，平均连接并发约 5。若命中率降到 60%，回源变为 400 QPS（每秒查询率），连接并发约 20，是原来的 4 倍；若数据库因扫描变慢到 200 毫秒，连接并发进一步变为 80。入口未变化，命中率和服务时间共同把连接需求放大 16 倍。

6. 下单 TPS（每秒事务数）要展开事务、锁、日志与副作用 {#53-02-k06}

下单 TPS（每秒事务数）是业务终态速率，不等于数据库提交次数。一个订单可能包含幂等检查、订单写、库存条件更新、流水和 Outbox（发件箱）写入；事务服务时间还受锁等待、日志刷盘和索引维护影响。容量先保护库存不变量和幂等，再谈吞吐，不能用排队掩盖超卖或未知态。

sequenceDiagram
    participant U as 用户
    participant O as 订单服务
    participant T as 事务线程
    participant D as MySQL（关系型数据库）
    participant M as MQ（消息队列）
    U->>O: 下单与幂等键
    O->>T: 进入有界执行
    T->>D: 订单 库存 流水 发件箱同事务
    alt 条件更新成功
        D-->>T: 提交并释放锁
        T-->>U: 受理成功
        D->>M: 后续发布可重放事件
    else 库存不足 锁超时或冲突
        D-->>T: 回滚并分类
        T-->>U: 明确拒绝或处理中
    end

图解读：同步路径只承诺已提交的业务事实，消息传播在事务后可重放。失败路径区分库存不足、锁超时和未知；结论是容量模型必须包含事务持有时间和热点键串行边界。

资源	每单候选工作量	主要瓶颈	验证信号
应用线程	1 个同步事务窗口	下游等待	执行与排队时间
数据库连接	事务期间 1 个	池等待	活跃、等待、超时
行锁	热点库存键局部串行	冲突与死锁	锁等待与回滚
日志写入	多行变更的一次提交	刷盘与复制	提交延迟与日志带宽
异步事件	每单 1 条或多条	发布与消费	发件箱超龄与积压

数据演绎 6：WMS（仓储管理系统）下单与热点库存

E3（演练证据）：候选峰值 200 TPS（每秒事务数），平均事务持有连接 120 毫秒，平均连接并发约 24。若一个热门库存键占 30%，该键到达 60 TPS（每秒事务数）；单次条件更新与锁持有 25 毫秒 时，串行上限约 40 TPS（每秒事务数），热点键每秒可能新增 20 个等待，即使数据库总 CPU（中央处理器）仍有余量。将总连接从 50 调到 100不能解除单键串行，正确方向是限量、排队、拆业务键或减少锁内工作。

7. 线程、连接与数据库资源要按持有时间分别预算 {#53-02-k07}

线程承载执行上下文，连接代表对特定下游的有限会话，两者的持有区间不同。线程在等待数据库、网络或锁时仍占线程；连接只在借出到归还期间占用。线程池、连接池和数据库并发应形成递减约束，入口不能把所有线程同时压向同一数据库；容器还要预算每线程栈、堆外缓冲和 JVM（Java 虚拟机）基础内存。

sequenceDiagram
    participant R as 请求
    participant T as 线程池
    participant C as 连接池
    participant D as 数据库
    participant X as 外部依赖
    R->>T: 占用线程
    T->>C: 申请数据库连接
    C->>D: 执行事务
    D-->>C: 归还结果
    C-->>T: 归还连接
    T->>X: 继续等待外部结果
    X-->>T: 完成
    T-->>R: 释放线程
    Note over T,C: 线程持有时间通常大于连接持有时间

图解读：线程覆盖整个请求，连接只覆盖数据库阶段；失败路径可能分别在两个池排队。结论是不能用相同数量配置所有池，也不能因线程空闲就认为数据库有余量。

资源池	需求近似	上限来源	过大代价
工作线程	到达率 × 线程占用时间	CPU（中央处理器）、内存、下游	切换、栈内存、重试放大
数据库连接	数据库到达率 × 连接持有时间	数据库会话与有效并发	锁和内部排队
网络连接	下游到达率 × 网络占用时间	对端配额与端口	文件描述符和缓冲
队列	峰期速率差 × 可排队时间	业务时效与内存	晚失败与恢复拖长

数据演绎 7：容器线程与连接预算

E3（演练证据）：候选入口 300 请求/秒，线程平均占用 200 毫秒，平均线程并发约 60；其中 70% 访问数据库，连接平均持有 50 毫秒，平均连接并发约 300 × 70% × 0.05 = 10.5。候选线程池 80、连接池 20 可作为起点，但若每线程栈按 1 MiB（兆字节）预算，80 个线程仅栈候选就约 80 MiB（兆字节），还未计堆、元空间、直接内存和系统线程。将线程池扩到 300 会新增约 220 MiB（兆字节）栈预算，并可能把数据库瞬时并发打满。

8. 消息积压模型用速率差、存储和恢复时间闭环 {#53-02-k08}

MQ（消息队列）积压变化率为 生产率 - 有效消费率。有效消费率只计算成功完成并确认的业务结果，不用拉取数、线程数或重试尝试替代。峰期新增积压等于正速率差乘持续时间；峰后恢复时间等于已有积压除以“消费率减当前生产率”，若净消化不为正，则理论上永远无法恢复。

sequenceDiagram
    participant P as 生产者
    participant Q as MQ（消息队列）
    participant C as 消费者
    participant D as 下游
    P->>Q: 峰期生产率 lambda
    Q->>C: 按可并行度投递
    C->>D: 受下游限额处理
    D-->>C: 成功 失败或超时
    alt 有效消费率低于生产率
        Q->>Q: 积压与最老年龄增长
    else 峰后有效消费率高于生产率
        C-->>Q: 以净速率消化历史积压
    end

图解读：生产、队列、消费和下游共同决定有效速率；失败路径是超时重试把尝试变多却不增加成功完成。结论是恢复必须同时保护下游和业务幂等。

量	公式或单位	必须同时看	风险
新增积压	`max(生产-消费,0) × 秒`	分区和业务等级	平均掩盖热点
恢复净速率	`消费-当前生产`	成功率与重试	小于等于零无法恢复
存储正文	条数 × 字节/条	P99（99 分位响应时间）消息大小	大消息放大
实际存储	正文 × 副本 × 保留及开销	索引、死信、重试	磁盘提前写满
业务时效	最老消息年龄	队列可见与执行中	条数低也可能超时

数据演绎 8：停机积压与受控恢复

E3（演练证据）：生产率 800 条/秒，消费者停机 15 分钟，新增积压 800 × 900 = 720000 条。恢复后候选有效消费率 1200 条/秒，生产仍为 800 条/秒，净消化 400 条/秒，理论恢复 720000 ÷ 400 = 1800 秒。若每条平均 2 KiB（千字节），仅正文约 1.37 GiB（吉字节）；副本、索引、重试和保留会继续放大。若下游安全能力只有 1000 条/秒，强推 1200 可能通过超时重试降低有效吞吐。

9. IoT（物联网）报警峰值要保护关键覆盖而非总吞吐 {#53-02-k09}

报警风暴同时包含原始事件、聚合事件和通知动作，三者不能用一个 QPS（每秒查询率）替代。入口容量要保留原始审计，处理容量按设备和规则聚合，通知容量受渠道配额和人工承载限制。关键报警应使用独立优先级和最小保障，普通重复报警可合并或延迟，不能为降低队列而丢失关键对象覆盖。

sequenceDiagram
    participant D as 设备
    participant I as 接入层
    participant Q as 分级队列
    participant A as 聚合服务
    participant N as 通知渠道
    participant R as 业务核验
    D->>I: 原始报警峰值
    I->>Q: 保留审计并按等级路由
    Q->>A: 设备 规则 窗口聚合
    alt 关键报警
        A->>N: 独立配额立即通知
    else 重复普通报警
        A->>A: 合并计数与延迟摘要
    end
    N-->>R: 到达回执
    R->>R: 按设备清单核对覆盖与新鲜度

图解读：原始事件、聚合和通知是三个容量域；失败路径是普通噪声抢占关键配额。结论是总吞吐达标也不能证明关键报警未漏。

层级	容量对象	候选策略	恢复证据
接入	原始事件/秒与字节/秒	认证、限租户、持久化	原始序列连续
聚合	设备键与规则计算/秒	窗口去重、合并	聚合可追溯
关键队列	关键事件/秒	独立资源和优先级	覆盖率与最老年龄
通知	通知尝试/秒	渠道限额、退避	到达回执
人工处置	待确认事件/人时	升级与分派	终态和责任人

数据演绎 9：报警峰值与关键通道

E3（演练证据）：2 分钟进入 300000 条原始报警，平均入口 2500 条/秒；聚合服务候选能力 2000 条/秒，若不分级则积压 500 × 120 = 60000 条。假设关键报警占 2%，即平均 50 条/秒，独立关键通道能力 120 条/秒可保持稳定；其余事件先按设备和规则以候选 10:1 聚合后，普通处理输入约 245 条/秒。该聚合比是敏感参数，必须用样本验证，不能写成生产效果。

10. 异步导出同时受数据库、JVM（Java 虚拟机）、磁盘与对象存储约束 {#53-02-k10}

异步只把等待移出请求线程，不会让导出免费。单任务工作集由分页对象、转换缓冲、文件写缓冲和上传窗口组成；总内存近似为基础占用加单任务工作集乘并发。吞吐受数据库扫描、临时磁盘写、压缩 CPU（中央处理器）、网络上传和对象存储并发中的最小者约束，队列上限还要结合交付时效和租户公平。

sequenceDiagram
    participant U as 用户
    participant T as 任务账本
    participant W as 导出工作者
    participant D as 数据库
    participant F as 临时磁盘
    participant O as 对象存储
    U->>T: 创建快照任务
    T->>W: 按配额和租约领取
    loop 有界分页
        W->>D: 游标读取一页
        D-->>W: 返回有限工作集
        W->>F: 流式写入并释放页对象
    end
    W->>O: 分片上传与摘要校验
    O-->>T: 记录产物和可恢复检查点
    T-->>U: 可下载 失败或处理中

图解读：任务账本控制领取，工作者在数据库、磁盘和对象存储间流式推进。失败路径由租约和检查点恢复；结论是数据总量主要增加执行时间和存储，不应线性扩大堆工作集。

资源	候选计算	主要风险	控制手段
堆内存	基础占用 + 单任务工作集 × 并发	OOM（内存溢出）	分页、流式、有界并发
数据库	页查询率 × 每页扫描成本	拖慢在线交易	隔离池、限速、快照
临时磁盘	在途分片字节 + 失败残留	写满与抖动	配额、清理、低水位
网络	上传字节/秒	共享带宽争抢	限速、分片、错峰
对象存储	并发上传与请求率	配额、超时、重试	连接上限、退避、摘要

数据演绎 10：异步导出的多资源最小值

E3（演练证据）：候选单任务分页工作集 48 MiB（兆字节），基础堆占用 600 MiB（兆字节），堆上限 2 GiB（吉字节），预留 35% 后可给任务约 731 MiB（兆字节），内存候选并发上限为 floor(731 ÷ 48) = 15。但数据库允许 8 个导出查询、对象存储允许 6 个并发上传、本地磁盘安全写入只支持 10 个同型任务，因此系统并发上限应取 min(15,8,6,10)=6，再考虑单故障域与在线交易保护后可能继续下调。

11. 磁盘、网络与存储必须同时计算速率、容量和写满时间 {#53-02-k11}

磁盘和存储既有“每秒能写多少”的速率约束，也有“能保留多久”的容量约束。网络同时受带宽、包率、连接和对端限额影响；数据库存储还含索引、日志、版本和副本放大。静态使用率不足以预警高速增长，应用 剩余字节 ÷ 净增长字节/秒计算预计写满时间，并设置滞回恢复水位。

sequenceDiagram
    participant A as 应用
    participant N as 网络
    participant D as 磁盘
    participant S as 存储系统
    participant M as 容量监控
    A->>N: 请求与响应字节率
    N->>D: 日志 消息或临时文件写入
    D->>S: 副本 索引 归档
    S-->>M: 使用量 净增长 保留延迟
    M->>M: 计算预计写满时间
    alt 低于预警窗口
        M-->>A: 限非关键写入并扩容或清理
    else 增长稳定且低于恢复水位
        M-->>A: 分批恢复
    end

图解读：字节从应用经过网络和磁盘进入存储，监控用净增长预测写满；失败路径优先限制非关键写入。结论是容量和吞吐都要考虑副本、索引、恢复与前台流量竞争。

资源	速率公式	容量公式	易遗漏放大
网络	请求率 × 双向字节/请求	通常不累计	协议、重传、复制
消息磁盘	消息率 × 字节/条	字节率 × 保留秒数	副本、索引、死信
数据库	事务率 × 日志与页写	日增量 × 保留与增长期	索引、版本、备份
临时文件	并发任务 × 分片字节	在途加失败残留	合并与重复上传
观测数据	事件率 × 记录字节	字节率 × 保留	标签、索引、副本

数据演绎 11：网络与磁盘双约束

E3（演练证据）：候选消息流 20000 条/秒，平均正文 1 KiB（千字节），正文约 19.5 MiB（兆字节）/秒。若复制因子候选为 3，仅正文写入约 58.6 MiB（兆字节）/秒，尚未计协议和索引；保留 24 小时正文副本约 4.94 TiB（太字节）。某节点剩余 300 GiB（吉字节）且净增长 18 MiB（兆字节）/秒，预计约 4.7 小时写满。若网络只有候选 400 Mbit（兆比特）/秒可用，折算约 50 MiB（兆字节）/秒，网络会先于磁盘理论写入成为瓶颈。

12. 敏感性、故障余量与非线性拐点决定最终配置 {#53-02-k12}

单点估算会制造虚假精确。至少对峰值、服务时间、缓存命中、消息大小、重试、单故障域和增长做低、中、高三档敏感性；线性变量可按比例传播，接近利用率 1、连接池耗尽、锁热点、磁盘高水位和下游限额时会出现非线性拐点。故障余量不是统一乘 30%，而是验证失去一个实例、一个分区或一个依赖配额后仍满足目标。

flowchart TD
    I[候选输入区间] --> S[敏感性矩阵]
    S --> L[线性区: 结果同比变化]
    S --> K[拐点区: 等待 重试 热点放大]
    L --> H[加入增长与故障余量]
    K --> B[限流 降级 拆瓶颈]
    H --> T[阶梯压测与故障注入]
    B --> T
    T --> C{满足用户结果与资源水位}
    C -->|是| O[记录容量区间和重算条件]
    C -->|否| I

图解读：敏感性矩阵把线性区与拐点区分开，再通过故障演练验证。正常路径形成区间和重算条件，失败路径回到输入或架构动作；结论是不使用固定余量口号替代故障域计算。

敏感变量	低/中/高候选	线性影响	可能拐点
峰值到达率	0.8/1.0/1.3 倍	并发与字节率同比	利用率跨 1
服务时间	0.8/1.0/2.0 倍	并发同比、能力反比	队列与超时重试
缓存命中率	95%/90%/60%	回源按未命中率变化	数据库池耗尽
单故障域	无损/损 1 实例/损 1 区域	可用能力下降	剩余分片热点
消息大小	平均/P95（95 分位响应时间）/P99（99 分位响应时间）	网络存储同比	批次与垃圾回收

数据演绎 12：单实例失效后的容量区间

E3（演练证据）：4 个实例候选单实例有效能力 150 请求/秒，总能力 600 请求/秒；候选峰值 400 请求/秒时利用率 66.7%。失去 1 个实例后能力为 450 请求/秒，利用率升至 88.9%，进入高敏感区；若此时服务时间再恶化 20%，单实例能力近似降到 125 请求/秒，剩余总能力 375 请求/秒，低于入口并开始积压。按“额外 30% 余量”看似足够，却未覆盖故障与变慢叠加。

13. 容量排障、项目话术与持续校准形成闭环 {#53-02-k13}

线上容量排障按“用户结果、到达、完成、等待、资源、依赖、重试、业务核验”推进。先判断是流量上升还是服务率下降，再定位队列发生在入口、线程池、连接池、数据库、MQ（消息队列）还是外部配额；止血动作优先限流、分级、暂停低价值任务和抑制重试。恢复必须验证新流量、历史积压、最老年龄和业务不变量，之后把实际参数回填模型并登记重算条件。

flowchart TD
    U[用户结果变差] --> R[比较到达率与有效完成率]
    R --> Q[定位等待层级]
    Q --> P[线程 连接 数据库 磁盘 网络 下游]
    P --> X[限流 分级 降级 暂停重试]
    X --> E[恢复新流量与历史积压]
    E --> B[库存 支付 任务 报警业务核验]
    B --> C[回填服务时间 命中率 配额和故障余量]
    C --> M[更新模型 阈值 演练与项目话术]

图解读：排障从用户结果和速率差进入，经过等待层与资源证据采取止血；恢复后必须业务核验并回填模型。结论是容量文档不是一次性表格，而是随工作负载和事故持续校准的控制闭环。

阶段	核心问题	证据	退出条件
定界	哪类用户结果受损	业务键、版本、区域	影响清单可复算
速率	到达升高还是完成降低	入口、成功完成、重试	速率差明确
等待	队列在哪里	池等待、锁、最老年龄	首个饱和点明确
止血	如何减少新增损失	限流、分级、降级	积压斜率转负或归零
恢复	历史工作如何清理	净消化、差异单	时效与不变量通过
校准	哪个假设失真	实测分布、故障记录	模型版本和重算条件登记

数据演绎 13：五类模型统一排障

E3（演练证据）：同一事故窗内，查询入口不变但回源从 100 升到 400 QPS（每秒查询率），下单热点锁上限低于 60 TPS（每秒事务数），消息积压净增 400 条/秒，关键报警通道仍有余量，导出对象存储并发达到上限。共同原因不是“机器少”，而是缓存失效与共享下游变慢。止血先暂停低优先级导出、限制回源与重试、保护关键报警和库存事务；恢复按各自净吞吐清理，不能用某一队列清零宣布全局恢复。

综合题使用说明

以下综合题统一使用 E3（演练证据）数字，重点训练三到五分钟口述中的单位、假设、非线性拐点、失败边界与项目落地；每题还必须沿真实相对链接回查机制正文。

综合题库

问题：面对“系统能扛多少并发”，请给出一套完整回答框架。
口述答案：我不会先报实例数，而会先确认并发对象：是查询 QPS（每秒查询率）、下单 TPS（每秒事务数）、执行中的消息、长连接，还是异步任务。然后固定业务窗口、平均与峰值、峰值持续时间、数据规模、读写比例、缓存状态、成功口径、重试归并和单故障域。没有生产证据时，所有数字标为 E3（演练证据），只展示计算方法；这一步能避免把日均、线程数或压测最高点误说成生产承诺。
计算时先由业务量得到峰值到达率，再拆服务时间与排队等待。稳定窗口用 Little’s Law（利特尔定律）计算平均总在途，用到达率乘服务时间计算执行中需求；有多个服务单元时计算利用率，并要求有效服务率长期大于到达率。随后分别推线程、数据库连接、外部连接、数据库读写、磁盘字节率、网络字节率和存储保留量。最终容量取所有资源安全上限中的最小值，而不是取应用线程的理论值。
最后做敏感性和验证：把峰值、服务时间、命中率、重试率、消息大小和故障域放入低中高三档，找出连接耗尽、锁热点、下游配额和利用率接近 1 的非线性拐点。阶梯压测要覆盖峰值持续期、恢复期和一个故障域失效，验收成功吞吐、P99（99 分位响应时间）、积压、最老年龄、资源水位与业务不变量。结论以区间表达，并写明限流、降级、扩容条件和重新评估触发器。
落地时我还会给每个输入登记负责人、采集位置、统计周期和最后校准日期。模型预测与线上观测偏差超过候选阈值时先核对口径，再决定调资源或改架构；这样回答既能给出计算结果，也能说明结果怎样持续保持可信。
- 追问 1：为什么不直接报并发数？ 直答 1：对象、窗口和成功口径不同，同一数字没有可比意义。
- 追问 2：最关键的公式是什么？ 直答 2：Little’s Law（利特尔定律）、利用率和积压速率差要组合使用。
- 追问 3：容量取哪个资源？ 直答 3：取线程、连接、数据库、磁盘、网络和下游安全上限中的最小值。
- 追问 4：如何避免夸大？ 直答 4：无生产证据的数字全部标 E3（演练证据），并列验证计划。
- 详情：稳定性口径、证据等级与迁移路线
问题：如何设计一个高峰查询接口的完整容量模型？
口述答案：我先定义用户结果，例如在时限内返回可接受新鲜度的数据或明确降级，而不是把 HTTP（超文本传输协议）成功当作业务成功。业务输入包括日查询量、忙时占比、峰均比、峰值持续时间、租户与热键分布、请求和响应大小。将入口查询分成缓存命中、缓存未命中、无效请求和重试，入口 QPS（每秒查询率）乘未命中率得到回源率；如果一次请求会查多张表或并行调用多个依赖，还要加入查询放大。
资源推导要分段。入口到完成的停留时间决定总在途，线程占用时间决定工作线程，数据库操作率乘连接持有时间决定平均数据库连接。数据库侧继续看扫描行、索引命中、锁、CPU（中央处理器）、磁盘和日志；网络按请求率乘双向字节估算。缓存命中率从 95% 降到 90% 时，未命中率会从 5% 翻倍到 10%，所以命中率必须做敏感性；数据库变慢还会同时拉长连接持有时间，形成乘法放大。
验证时用真实键分布和候选数据规模做阶梯压测，分别注入热键、局部缓存失效、数据库慢查询和连接池缩减。每级记录成功 QPS（每秒查询率）、P95（95 分位响应时间）、P99（99 分位响应时间）、线程排队、连接等待、扫描行、缓存回源与数据库资源。达到吞吐不再增长而等待和错误加速时立即停止。线上保护包括请求合并、预热、互斥回源、连接上限、超时预算、限流和陈旧数据降级，并以用户结果校验恢复。
容量报告还要单列无法缓存、必须强一致和允许陈旧读取的查询比例，因为三类路径的服务时间与降级不同。发布或索引变化后，以同一批业务键回放并对比计划值，防止平均命中率看似稳定却由关键租户承担全部长尾。
- 追问 1：缓存命中率为什么危险？ 直答 1：应看未命中率，命中率小幅下降可能使回源成倍增长。
- 追问 2：连接数怎么算？ 直答 2：数据库到达率乘平均连接持有秒数，再加长尾与故障余量。
- 追问 3：平均延迟够吗？ 直答 3：不够，必须看尾延迟、样本分布和热键切片。
- 追问 4：数据库不忙却排队说明什么？ 直答 4：可能是连接、单分片、热锁或应用线程先饱和。
- 详情：跨境订单履约、面单与轨迹恢复案例
问题：如何从业务订单量推导 WMS（仓储管理系统）下单容量？
口述答案：先把“订单量”拆成可评价业务意图、入口尝试和成功终态。用日订单量乘忙时占比，除以忙时秒数得到忙时平均，再乘峰均比和增长系数得到候选峰值 TPS（每秒事务数）；超时重试按幂等键归并业务成功，但仍计入入口与资源尝试。随后列出每单的同步工作：幂等校验、订单写、库存条件更新、预占流水和 Outbox（发件箱）记录，异步通知只在事务事实提交后传播。
线程需求由同步路径占用时间决定，数据库连接由事务持有时间决定。真正的拐点往往不是数据库总 CPU（中央处理器），而是热门库存键的局部串行、唯一键冲突、日志提交或连接等待。若一个热键每秒到达 60 次、单次锁内工作 25 毫秒，串行候选上限只有每秒 40 次，扩应用线程或总连接不会解除该瓶颈。容量不足时必须明确拒绝、排队或返回处理中，不能绕过库存不为负和幂等不变量。
验证要回放真实或脱敏后的商品热度分布，分别测试普通键、热键、库存不足、重复请求、数据库变慢和一个实例失效。除了业务成功 TPS（每秒事务数）与尾延迟，还要检查锁等待、回滚、连接、发件箱超龄、消息积压和库存对账。恢复后按订单行、库存键、预占与释放流水复算，不以接口错误率下降宣布完成。所有候选数字保留 E3（演练证据）标签，真实上限由环境与业务证据校准。
如果压测发现总吞吐达标但少数热门键超时，我会把单键上限作为独立容量合同，并给运营侧配置限量或预约入口。这样总容量、局部热点与库存正确性都有各自退出条件，不会用全局平均掩盖超卖或长期占用风险。
- 追问 1：业务 TPS（每秒事务数）等于数据库提交率吗？ 直答 1：不等，一个业务终态会放大为多次读写，失败尝试也占资源。
- 追问 2：热点库存怎么发现？ 直答 2：按库存键看到达率、锁等待、回滚和单键完成率。
- 追问 3：缓存预扣能替代数据库吗？ 直答 3：不能，缓存负责削峰，权威流水和条件更新负责最终正确。
- 追问 4：队列满了怎么办？ 直答 4：按业务时效明确拒绝或降级，并保留幂等查询与恢复路径。
- 详情：WMS（仓储管理系统）库存预占与对账补偿案例
问题：支付系统容量评估与普通下单有什么不同？
口述答案：支付首先保护资金正确和未知态收敛，容量不能只看发起接口。业务对象至少有支付意图、渠道尝试、回调、主动查单、账务分录、对账差异和补偿任务；同一支付意图可能产生多次技术尝试，但只允许一个有效确认。模型要分别计算发起 TPS（每秒事务数）、渠道调用率、回调峰值、查单率、账务提交率和对账批次，不能把它们相加后称为成功支付吞吐。
同步路径的线程和连接受渠道延迟影响，超时会增加在途并触发查单；不能把超时直接当失败再盲目重试，否则渠道可能已扣款而本地再次发起。数据库容量要包括支付记录、唯一状态迁移、不可变账务分录和 Outbox（发件箱）；热点可能来自商户、渠道或结算批次。队列消费能力必须大于持续入口并留出差异恢复余量，但扩消费者前要确认账务锁、渠道配额和幂等边界。
压测分正常、慢渠道、重复回调、回调集中、查单放大、数据库锁和消息积压场景。指标包括业务终态完成率、最老未知、渠道配额、连接等待、账务提交、重复命中和对账差异；止血优先阻止新增重复扣款和未知态，必要时关闭高风险渠道、限流或转人工。恢复以渠道事实、本地支付状态和账务分录逐笔一致为准，接口吞吐恢复只是前提。没有真实渠道沙箱和账务核验时，任何容量数仍是 E3（演练证据）。
我还会按渠道、商户和币种拆分容量，避免高吞吐低延迟渠道掩盖慢渠道未知态。每次提高并发前先验证渠道明确允许的请求率、幂等和查单能力；否则宁可排队并告知处理中，也不以追求 TPS（每秒事务数）扩大资金风险。
- 追问 1：支付超时能直接重试吗？ 直答 1：不能，先按支付意图查单，确认未受理后才受控重试。
- 追问 2：回调峰值如何建模？ 直答 2：按渠道集中回放、重投和签名验证成本独立建模。
- 追问 3：最重要的容量指标是什么？ 直答 3：成功终态、最老未知和账务差异要与技术吞吐共同观察。
- 追问 4：扩消费者为何可能无效？ 直答 4：账务锁、渠道配额或数据库连接可能先成为瓶颈。
- 详情：支付资金正确性与对账恢复案例
问题：请完整演练一次 MQ（消息队列）积压与恢复计算。
口述答案：先统一对象和边界：生产率是进入目标主题的业务事件数，有效消费率只计算成功完成并确认的事件，重试、拉取和失败尝试不算有效产出。峰期积压等于初始积压加上正的生产消费速率差乘持续秒数；峰后只有有效消费率大于当前生产率时才有净消化能力，理论恢复时间等于总积压除以净消化率。若净速率为零，队列不会自行恢复；若为负，事故仍在恶化。
E3（演练证据）中生产每秒 12000 条、有效消费每秒 8000 条，持续 600 秒会新增 240 万条。峰后把入口限到每秒 5000 条，数据库安全约束下消费稳定为每秒 10000 条，净消化每秒 5000 条，理论恢复 480 秒。若盲目提到每秒 13000 条却造成 20% 重试，名义吞吐变高，实际成功率和数据库延迟可能恶化，所以恢复计算必须用成功完成率持续修正。
存储还要用积压条数乘平均与 P99（99 分位响应时间）消息大小，再加入副本、索引、死信、重试和保留；业务影响看最老消息年龄、关键事件覆盖和预计恢复，而不只看条数。处置顺序是隔离毒消息、保护关键队列、限制生产和重试、在下游安全水位内扩消费。关闭事故前核验积压、未确认、执行中、死信和业务审计都收敛，并把实际服务率和热点回填容量模型。
对外报告时我会同时给理论恢复、保守区间和阻塞因素，理论值只使用当前成功吞吐。若扩容预热、分区热点或重试使净消化连续低于计划，就重新计算完成时间并同步业务，而不是守着已经失效的精确秒数。
- 追问 1：为什么消费等于生产仍不安全？ 直答 1：没有净恢复能力，历史积压永远清不掉。
- 追问 2：积压条数够吗？ 直答 2：不够，还要看字节、最老年龄、增长斜率和业务等级。
- 追问 3：恢复越快越好吗？ 直答 3：不是，超过下游安全水位会制造重试和二次事故。
- 追问 4：如何证明恢复？ 直答 4：业务完成、确认、死信和权威对账在观察窗内共同收敛。
- 详情：MQ（消息队列）容量、性能、积压与线上排障
问题：如何用 Little’s Law（利特尔定律）设计 Runner（执行器）容量？
口述答案：先定义稳定边界：任务从进入可调度状态到成功、明确失败或转人工为止，平均停留包含等待、执行、重试退避和检查点恢复。稳定窗口内用任务到达率乘平均停留时间估总在途，用到达率乘纯服务时间估平均执行中需求；若队列持续增长，则系统不在稳态，结果只能说明过载，不能证明当前工作者数量足够。
Runner（执行器）的并发上限还受任务可分片性、租户配额、数据库连接、外部接口、CPU（中央处理器）、内存和顺序键约束。不同任务服务时间差异大时，不能只用全局平均，应按任务类型或工作量分级；大任务与短任务共用先进先出队列会造成头阻塞。容量要为高优先级任务保留独立资源，低优先级任务可延迟或暂停，并给队列设置上限和最老年龄目标。
演练要覆盖正常混合负载、慢依赖、一个工作者失效、租约到期、任务重复领取、数据库配额下降和积压恢复。验收不只看每秒领取数，还看成功完成率、等待分位数、重试、外部拒绝、检查点和重复副作用。若到达每秒 40 个、平均停留 90 秒，平均在途约 3600 个，但这只用于状态表和队列基线；工作者数量仍要由各类服务时间与下游限制决定。最终报告区间、优先级、扩缩容条件和失败边界。
自动扩缩容不会只看队列长度，我会加入最老任务年龄、加权剩余工作量和下游余量，并设置冷却时间。扩容后的新工作者先小批领取，确认租约、连接与成功率正常再扩大，避免恢复动作瞬间把数据库或第三方接口再次压垮。
- 追问 1：平均在途等于线程数吗？ 直答 1：不等，总在途包含排队、退避和执行中，线程只覆盖执行阶段。
- 追问 2：任务差异大怎么办？ 直答 2：按类型和工作量分级建模，隔离队列与资源池。
- 追问 3：租约能保证不重复吗？ 直答 3：不能，租约解决所有权，副作用仍需幂等和检查点。
- 追问 4：积压持续增时怎么做？ 直答 4：用速率差算恶化与恢复，先限入口和低优先级任务。
- 详情：SLO（服务等级目标）、事故、容量与 Runner（执行器）项目案例
问题：如何为 IoT（物联网）报警风暴建立容量与优先级模型？
口述答案：我把原始接入、规则聚合、关键事件处理、通知和人工处置拆成五个容量域。原始接入按设备数、上报频率、峰值持续时间和单条字节计算，必须保留可审计事实；聚合按设备、报警类型、规则版本和窗口计算，降低的是后续通知工作量，不是原始事件数量。关键报警单独估到达率和时效，使用独立队列、消费者和通知配额，普通重复报警可以合并、延迟或摘要。
E3（演练证据）中两分钟进入 30 万条事件，平均每秒 2500 条，通用处理能力每秒 2000 条会新增 6 万条积压。若关键事件占 2%，关键到达约每秒 50 条，独立通道候选能力每秒 120 条可以保持稳定；普通事件若经样本验证可按 10 比 1 聚合，后续处理压力显著下降。但占比和聚合比都是敏感参数，规则变更、设备同步抖动和区域集中都可能让它们失效。
验证时注入设备群同时异常、重复抖动、规则升级、通知渠道限速、消费者失效和数据缺样。指标包括原始接入连续性、关键队列最老年龄、聚合可追溯、通知回执、设备覆盖和新鲜度；总消费速度下降不能直接判为成功，可能是采集断开或错误丢弃。恢复后按关键设备清单重算应处理、已处理与已通知事件，缺口重放或人工确认，最后再解除抑制并回填实际峰值和窗口效果。
模型还要预留规则计算和人工处置能力，因为通知成功不代表事件已闭环。对高风险设备设置最长未确认时间和升级责任人；普通聚合摘要若超过业务时限，也应显示延迟而不是继续隐藏在总队列中。
- 追问 1：为什么不共用一个队列？ 直答 1：普通噪声会抢占关键事件的消费者、存储和通知配额。
- 追问 2：聚合是否会丢事实？ 直答 2：不应，原始审计保留，聚合只减少重复处理和通知。
- 追问 3：关键恢复看什么？ 直答 3：按设备清单看覆盖、新鲜度和通知回执。
- 追问 4：峰值结束就能解除限流吗？ 直答 4：不能，先清理关键积压并核对漏报，再分批解除。
- 详情：MQ（消息队列）项目案例中的 IoT（物联网）报警风暴治理
问题：异步导出如何从行数推导线程、内存、磁盘和网络容量？
口述答案：先冻结任务快照和工作量分级，把总行数、平均与高分位行大小、文件格式、分页大小、压缩、分片和交付时限写清。异步只移出请求线程，不减少数据库扫描、对象转换和文件写入。单任务堆工作集由一页对象、转换缓冲、写出窗口和上传缓冲构成，总内存约等于应用基础占用加单任务工作集乘并发；只要分页和释放正确，数据总量主要增加执行时间、临时文件和对象存储，不应让堆线性增长。
对每种资源单独算候选上限：数据库按隔离连接、页查询率和扫描成本；JVM（Java 虚拟机）按堆、线程栈、直接内存和回收余量；临时磁盘按在途分片与失败残留；网络按上传字节率；对象存储按并发、请求率和超时。假设内存允许 15 个任务、数据库允许 8 个、磁盘允许 10 个、对象存储允许 6 个，则总并发取 6，再扣除单故障域和在线交易保护，不能取平均或最大值。
验证应改变总行数、页大小、并发和文件类型，观察峰值堆是否有界、数据库在线查询是否受影响、临时磁盘写满时间、网络、上传成功和任务 P99（99 分位响应时间）。再注入对象存储变慢、实例退出和分片重复，确认租约、稳定游标、摘要与检查点能续跑。队列恢复按剩余工作量而非任务条数估算，并给用户真实进度、取消和预计区间；任何效果数字保持 E3（演练证据）。
为防大租户长期占满全部资源，我会设置租户并发、单任务工作量和全局字节率三层配额。任务估算明显偏差时重新分级或拆分，不能让一个超大文件持续占住数据库连接、磁盘和上传槽位而饿死短任务。
- 追问 1：数据量十倍时堆要十倍吗？ 直答 1：流式分页下不需要，堆主要由页、缓冲和并发决定。
- 追问 2：并发取哪个上限？ 直答 2：取内存、数据库、磁盘、网络和对象存储安全上限中的最小值。
- 追问 3：任务数能代表工作量吗？ 直答 3：不能，应按行数、字节、格式和剩余分片加权。
- 追问 4：如何避免重复文件？ 直答 4：使用确定性对象键、分片摘要、条件状态迁移和交付幂等。
- 详情：异步导出快照、分片交付与 OOM（内存溢出）隔离案例
问题：线程池与数据库连接池应该如何联合配置？
口述答案：我先画请求的资源持有时序：线程从领取请求到返回一直占用，数据库连接只在事务或查询阶段借出，外部连接又是另一段。因此线程并发用入口到达率乘线程占用时间估算，数据库连接并发用数据库到达率乘连接持有时间估算，两者不应机械相等。还要把缓存命中、无需数据库的路径、事务放大、P99（99 分位响应时间）和管理连接分开。
配置遵循逐层收敛：入口并发大于工作线程，工作线程可大于数据库连接，但所有路径同时访问数据库时要通过隔离、限流或队列保护。连接池过小会在应用侧等待，过大会把排队推到数据库内部，增加锁竞争、内存和上下文切换；线程池过大则增加栈内存、任务对象、调度和重试放大。容器总内存还必须扣除堆、线程栈、元空间、直接内存和系统余量，不能只看最大堆。
验证用阶梯负载记录线程活跃与排队、连接活跃与等待、数据库执行、锁、CPU（中央处理器）和成功吞吐。若扩连接后吞吐不升而数据库延迟、锁和错误增加，说明已越过拐点，应回退；若连接等待高而数据库资源仍有余量，再小步扩池。故障场景包括慢事务、连接泄漏、数据库主从切换和一个实例失效，恢复后还要确认池内无陈旧连接和业务事务无未知。
配置变更采用灰度并保留旧值，观察至少覆盖连接建立、负载稳定和事务长尾窗口。若某类慢任务需要更多连接，应使用独立池和配额，不让导出或补偿占用在线下单的保底连接；这比全局放大池更容易控制故障域。
- 追问 1：连接池为何不等于线程池？ 直答 1：资源持有区间和访问比例不同。
- 追问 2：先扩线程还是连接？ 直答 2：先定位等待和真实瓶颈，没有证据不扩任何一层。
- 追问 3：连接池满代表数据库满吗？ 直答 3：不一定，可能是慢事务、泄漏或池过小，需看数据库证据。
- 追问 4：容器内最大风险是什么？ 直答 4：线程栈和堆外预算被忽略，堆未满也可能 OOMKilled（容器内存杀死）。
- 详情：JVM（Java 虚拟机）内存、参数与容器化
问题：如何判断系统已经进入非线性排队区？

口述答案：我不会只看 CPU（中央处理器）百分比，而会在阶梯负载中同时观察入口、成功完成、服务时间、排队时间、线程、连接、锁、磁盘、网络、重试和下游拒绝。正常线性区里，入口增加会带来接近同比的成功吞吐，延迟和错误缓慢变化；接近拐点后，成功吞吐增长放缓或停止，P99（99 分位响应时间）、队列、连接等待和重试斜率陡增，这才是容量边界的直接证据。

利用率是重要提示。设多个服务单元总有效能力为 m × mu，利用率为到达率除以总能力；长期稳定要求小于 1，但接近 1 时几乎没有空闲间隙吸收随机到达和长尾。服务时间从 40 毫秒升到 55 毫秒，看似只增加 15 毫秒，却可能把利用率从 70%推到 96%，再小幅变慢就跨过稳定边界。此时加大队列只会让用户更晚失败。

发现拐点后立即停止继续施压，保留当前版本、流量和资源快照，定位最先饱和的池、锁、分片或依赖。治理可以降低到达、缩短服务、拆热点、批量摊销或扩真实瓶颈，但每次只改变少量变量并复测。容量上限选择在拐点之前满足延迟、错误、恢复和故障余量的区间，而不是选择压测中偶然跑出的最高吞吐；线上再用相同信号持续校准。

我会把拐点前一个稳定台阶、拐点位置和停止原因同时归档，并标明观察窗口和误差，同时核对取消与失败分类。后续版本若声称容量提升，必须在相同负载模型下看到拐点右移且业务正确未退化，不能只比较两个环境的最高瞬时值。

追问 1：CPU（中央处理器）低能排除拐点吗？ 直答 1：不能，锁、连接、磁盘、分区和下游可能先饱和。
追问 2：队列增长就是拐点吗？ 直答 2：通常说明到达超过有效完成或服务抖动，需结合成功吞吐确认。
追问 3：为什么不能压到 100%？ 直答 3：没有波动、恢复和故障余量，尾延迟会非线性放大。
追问 4：上限如何表达？ 直答 4：用版本、场景、区间、停止条件和事实等级表达。
详情：SLO（服务等级目标）、错误预算与尾延迟

问题：如何做容量敏感性分析，而不是只给一个估算值？

口述答案：先列出所有输入及来源，把已测事实、业务预测和 E3（演练证据）假设分开。至少对峰值到达率、峰值持续时间、服务时间均值与 P99（99 分位响应时间）、缓存命中、重试率、消息大小、增长、单故障域和下游配额设置低中高三档。每档重算总在途、线程、连接、数据库操作、字节率、存储、积压和恢复时间，并检查单位是否守恒。

然后区分线性与非线性。到达率增加 20%时，稳定区的并发和字节率通常近似增加 20%；但命中率从 95%降到 90%会让未命中流量翻倍，服务时间拉长又会增加连接持有并降低服务率。利用率接近 1、热门键锁冲突、连接池耗尽、磁盘高水位和外部限额都是拐点，不能用简单乘法继续外推。对这些变量应画二维组合，例如“失去一实例同时服务时间增加 20%”。

最后按影响弹性和不确定性排序验证。高影响、高不确定输入优先用回放、压测或故障注入校准；低影响输入保留范围即可。输出不是一个容量数，而是基本区间、悲观区间、首个瓶颈、触发阈值、可逆动作和重算条件。真实流量结构、版本或依赖配额变化时重新计算，事故后用实际服务时间、重试和恢复速率修正模型，避免敏感性表成为一次性文档。

对无法同时验证的变量，我会明确采用何种保守组合，并记录为什么没有选择更乐观场景。业务负责人据此确认时效或降级取舍，技术团队则把最敏感输入接入监控；输入越接近边界，复核频率越高。

追问 1：哪些变量优先？ 直答 1：对用户结果和容量输出影响大且证据弱的变量优先。
追问 2：为什么要看组合场景？ 直答 2：故障与变慢常叠加，单变量安全不代表组合安全。
追问 3：命中率是线性变量吗？ 直答 3：回源按未命中率变化，接近高命中时百分点变化会成倍放大。
追问 4：最终交付什么？ 直答 4：容量区间、瓶颈、阈值、动作、证据等级和重算触发器。
详情：容量评估的事实边界与成本约束

问题：如何设计单故障域下仍可信的容量余量？

口述答案：我不会统一乘一个余量百分比，而会先定义要承受的故障：单实例、单节点、单分区、单可用区，还是第三方配额下降。根据部署拓扑扣除对应能力，再考虑流量重新分布、缓存冷启动、副本追赶、连接重建和恢复任务与前台流量竞争。剩余系统必须同时满足关键用户结果、延迟、错误和历史积压恢复，才算有故障余量。

例如 4 个实例单实例候选有效能力每秒 150，请求峰值每秒 400 时总利用率约 66.7%；失去 1 个实例后利用率约 88.9%，已经处于高敏感区。若故障同时使下游服务时间增加 20%，剩余总能力可能降到每秒 375，低于入口并开始积压。这个演练说明“平时有 50%空闲”或“额外 30%余量”都可能掩盖具体故障粒度和叠加效应。

验证要真的摘除一个目标故障域，而不是只在表格里扣容量；观察负载均衡、热分片、缓存、连接、重试、队列和 P99（99 分位响应时间），并记录扩容或切换需要多久。若关键路径不能满足，就应降低正常水位、增加独立故障域、预热、隔离关键流量或改进降级。恢复后还要限制副本追赶和积压清理，防止与前台竞争造成第二次事故。

故障演练还要验证监控和人工操作是否能在目标时间内发现并执行，因为理论剩余能力若无法及时切换就没有价值。演练记录实际丢失容量、恢复斜率、切换期间最老等待和业务影响，下一轮配置以实测而不是拓扑图上的名义副本数为准。

追问 1：为什么 30%余量不通用？ 直答 1：故障粒度、实例数、恢复速度和依赖约束不同。
追问 2：故障余量只看吞吐吗？ 直答 2：还要看尾延迟、错误、业务正确和积压恢复。
追问 3：如何验证？ 直答 3：真实移除目标故障域并观察重分布、冷启动和恢复竞争。
追问 4：恢复为什么也有限速？ 直答 4：副本追赶和历史积压会与前台争抢同一资源。
详情：Kubernetes（容器编排平台）调度、资源与 Pod（容器组）生命周期

问题：如何估算磁盘、网络和存储，而不只看请求数？

口述答案：我把每类业务对象转换成字节率。查询按请求率乘请求与响应平均及高分位字节，消息按条数乘消息体，数据库按事务数乘日志、页写和索引放大，导出按文件生成与上传字节。网络还要加入协议、复制、重传和双向流量；磁盘与存储还要加入副本、索引、版本、备份、死信和保留。条数相同而消息大小不同，资源结果可能相差几个数量级。

速率和容量要分开。每秒字节决定网络、磁盘写入和刷盘是否饱和，字节率乘保留秒数决定存储正文，再叠加放大。静态使用率不能表达处置窗口，应计算剩余可用字节除以最近窗口净增长字节每秒，得到预计写满时间；净增长必须扣除正常删除并加入副本追赶。集群总量之外还按节点、分区和目录检查热点，避免总空间充足但局部先满。

验证使用真实大小分布而非只有平均值，测试小消息高包率、大消息头阻塞、批量、压缩、重传、副本恢复和保留删除延迟。记录成功字节率、请求率、CPU（中央处理器）、磁盘延迟、网络重传、存储增长和业务时效。达到预计写满门槛时，先保护支付、库存和关键报警事实，限制非关键写入与重放；删除必须经过保留、归档和恢复能力确认，不能手工清理活跃数据冒险。

容量表会分别注明十进制和二进制字节单位，避免 GB（吉字节）与 GiB（吉字节）混算；网络比特率换算为字节率后再比较。对每个放大项保留来源和最大值，实际压缩或删除不及预期时，预计写满时间能自动按净增长重新计算。

追问 1：平均消息大小够吗？ 直答 1：不够，大消息高分位会影响批次、网络、磁盘和垃圾回收。
追问 2：如何算预计写满？ 直答 2：剩余可用字节除以净增长字节每秒。
追问 3：网络够为何仍慢？ 直答 3：包率、对端配额、序列化、磁盘或连接可能先饱和。
追问 4：磁盘紧张先删关键消息吗？ 直答 4：不能，先限非关键写入和可重建数据，并验证归档与恢复。
详情：MQ（消息队列）容量中的磁盘、网络与保留模型

问题：平均值与峰值应该如何共同进入容量模型？

口述答案：平均值回答长期资源成本和稳定窗口内的基本在途，峰值回答短时排队、资源水位和用户时效；两者不能互相替代。我会同时记录日均、忙时平均、秒级或分钟级峰值、峰值持续时间和峰后流量。业务量先按忙时占比换算成窗口平均，再用峰均比形成候选峰值；峰值若没有持续时间，无法计算积压、临时存储和恢复，只有持续时间没有流量幅度也没有意义。

服务时间同样同时看平均和分布。Little’s Law（利特尔定律）使用平均到达率和平均停留时间校验平均在途，但线程、队列和超时还要承受 P95（95 分位响应时间）、P99（99 分位响应时间）长尾。不能把 P99（99 分位响应时间）直接代入后宣称平均并发，却可以把它作为悲观场景检查队列、连接和内存是否越界。对缓存命中、消息大小和热键也要保留平均与高分位，避免均值把局部尖峰抹平。

方案上，稳定底座按可持续忙时配置，有限短峰可由有界队列、缓存、弹性、预约或降级吸收；但必须证明峰期最老等待和峰后恢复满足业务目标。压测要完整覆盖峰值持续期和恢复期，不能只打一分钟最高点。线上持续比较预测与实际均值、峰值、持续时间和恢复曲线；若营销、批处理或设备上报改变流量形态，立即重算，而不是等日均明显增长后再扩容。

对周期性峰值，我会保存同星期、同活动阶段的分位带；对不可预测峰值，则用入口保护和最坏可恢复时长约束。无论采用弹性还是排队，都要把扩容预热、冷缓存和峰后历史工作算进去，避免资源到位时事故已经越过业务时效。

追问 1：只看峰值是否最安全？ 直答 1：不一定，可能过度配置且仍遗漏峰值持续时间与恢复约束。
追问 2：平均值有什么价值？ 直答 2：用于稳定在途校验、长期成本和趋势基线。
追问 3：P99（99 分位响应时间）能代入定律吗？ 直答 3：不能冒充平均值，但可用于悲观资源和时效校验。
追问 4：短峰一定要扩机器吗？ 直答 4：不一定，可排队或降级，但必须证明等待和恢复可接受。
详情：MQ（消息队列）价值、排队论与分治思想

问题：线上延迟升高时，如何区分服务时间变长与等待变长？

口述答案：我先把端到端停留时间拆成入口队列、线程池等待、连接池等待、锁等待、应用处理、数据库执行、外部调用和网络返回。每个阶段记录开始、获得资源和结束时间，统一关联业务键、实例、版本和依赖。服务时间是资源真正处理单个对象的时间，等待时间是对象尚未获得线程、连接、锁或下游配额的时间；两者相加才是用户看到的响应或任务停留。

若入口不变而数据库执行从 50 毫秒升到 200 毫秒，连接持有与线程占用会同时拉长，随后连接等待和线程排队出现，这是“服务变慢先触发、等待后放大”。若数据库执行稳定但连接等待先升，可能是慢事务、泄漏或连接池配置；若工作线程排队先升而数据库空闲，可能有其他慢路径占满线程。CPU（中央处理器）低也不能排除容量问题，锁、磁盘、网络、分区或第三方配额都可能使线程停在等待。

止血要对应原因：服务时间变长时限制入口和重试、隔离慢依赖、优化查询或降级；等待变长时先保护首个饱和池，不能无界加队列。恢复后同时验证服务时间分布、各层等待、成功吞吐和业务结果。再用 Little’s Law（利特尔定律）检查平均在途是否与到达率乘停留时间一致；偏差较大说明边界遗漏了未确认、退避或执行中对象，需先修正观测再更新容量。

调整参数时每次只改变一个主要限制，并保留前后同窗口数据。若线程等待下降却数据库延迟上升，说明等待只是被搬家，不是系统变快；只有端到端成功吞吐、尾延迟和业务正确同时改善，才能把调整写入正式容量基线。

追问 1：响应时间等于服务时间吗？ 直答 1：不等，响应时间通常包含多层等待与处理。
追问 2：连接等待高就扩池吗？ 直答 2：先查慢事务、泄漏、锁和数据库余量。
追问 3：CPU（中央处理器）低说明什么？ 直答 3：处理器可能不是瓶颈，不能排除输入输出和锁等待。
追问 4：如何验证拆分准确？ 直答 4：用分段时间、链路、池指标和业务键交叉核对。
详情：OpenTelemetry（开放遥测标准）与 SkyWalking（链路追踪系统）链路追踪

问题：服务变慢叠加重试风暴时，容量模型如何修正？

口述答案：先把原始业务到达率与技术尝试率分开。业务意图按幂等键去重，技术尝试包括客户端、网关、应用和消息消费者的重试；容量消耗使用尝试率，业务价值使用最终成功率。依赖变慢会增加服务时间，使线程和连接在途上升；等待超过超时后又触发重试，重试进一步提高到达率，形成“服务率下降、到达率上升”的正反馈，原先基于正常重试率的模型会迅速失效。

修正时按时间窗计算尝试放大系数，即总尝试除以独立业务意图；用放大后的到达率重新计算线程、连接和下游调用，同时用变慢后的服务时间重新计算服务率与利用率。假设业务每秒 300 个、正常尝试系数 1.02，依赖变慢后系数升到 1.5，技术入口变为每秒 450 个；若服务时间又翻倍，总在途可能接近原来的三倍，系统很容易跨过稳定边界。该组合必须作为敏感性场景，而不是分别计算后忘记叠加。

止血优先减少无效尝试：统一超时预算、限制层级重试、指数退避与随机抖动，对支付等未知态先查单，过载时关闭低价值重试并限入口。熔断和降级要返回明确结果，不能诱导客户端立即重试。恢复验收看业务成功、尝试放大、最老未知、连接等待和积压共同回落；重试率恢复前不能因为 CPU（中央处理器）下降就全量放开。复盘把实际放大系数和超时链回填模型与门禁。

我还会检查重试是否跨层叠加，例如客户端两次、应用三次会形成最多六次尝试；应指定唯一责任层。对无法安全重试的副作用调用保留人工或查单路径，使系统过载时先减少不确定性，而不是用更多请求换取表面成功。

追问 1：重试算业务量吗？ 直答 1：不算新增业务意图，但必须算资源尝试量。
追问 2：为什么会正反馈？ 直答 2：变慢拉长等待，超时触发重试，重试又增加负载。
追问 3：支付如何重试？ 直答 3：先查单确认未受理，再带同一幂等键受控重试。
追问 4：何时恢复重试？ 直答 4：服务率、尝试放大、未知态和下游水位在观察窗内稳定后分批恢复。
详情：MQ（消息队列）可靠性、幂等、顺序与重试

问题：缓存大面积失效导致数据库排队，如何计算与处置？

口述答案：先冻结入口 QPS（每秒查询率）、原命中率、失效后命中率、回源查询放大和数据库服务时间。入口乘未命中率得到回源率；例如每秒 1000 次查询，命中率从 90%降到 60%，回源从每秒 100 次升到 400 次。若连接持有 50 毫秒，平均连接并发从 5 增到 20；数据库被压慢到 200 毫秒后又变成 80，入口未增加，连接需求却放大 16 倍。

这类事故的非线性来自两个方向：回源比例上升提高数据库到达率，数据库变慢又拉长连接和线程持有，连接等待触发超时重试后继续放大。处置不能只扩缓存或连接池。我会先限制回源总量，按业务键做请求合并与互斥回源，对热点预热并给过期时间加随机抖动；对可接受陈旧数据的查询返回带版本的旧值，对关键写后读保留权威查询。连接池保持数据库安全上限，避免把排队推入数据库内部。

恢复时分批预热和放开流量，观察命中率按租户、区域和热键切片，确认数据库执行、连接等待、扫描行和 P99（99 分位响应时间）回落。缓存恢复不等于业务恢复，还要检查是否长时间返回陈旧轨迹或库存。复盘补充局部失效、批量过期和缓存不可用的容量场景，把命中率作为高敏感变量，并明确缓存完全失效时的最大回源与降级边界。

发布新缓存规则前先影子统计键数量、对象大小、命中与回源，不直接全量切换。对于缓存完全不可用的悲观场景，数据库保底流量必须由限流器固定；超出部分返回明确降级，防止恢复中的缓存预热再次形成第二轮击穿。

追问 1：命中率下降 10%为何可能很严重？ 直答 1：应看未命中率，可能从 5%变 15%，回源增长三倍。
追问 2：能把连接池同步扩四倍吗？ 直答 2：不能，数据库安全并发可能不允许。
追问 3：请求合并解决什么？ 直答 3：同一热键只保留一个回源，其他请求复用结果。
追问 4：恢复看什么业务证据？ 直答 4：数据新鲜度、覆盖和关键读写结果，不能只看缓存绿色。
详情：Redis（远程字典服务）延迟队列、限流与项目案例

问题：热门商品把单个库存键打满，为什么扩容应用无效？

口述答案：应用总容量是多个可并行工作单元的和，但同一库存键的正确修改通常受条件更新、行锁或顺序语义约束，需要局部串行。假设热门键每秒到达 60 次，单次锁内事务 25 毫秒，理论串行能力约每秒 40 次，该键每秒新增约 20 个等待。其他实例、CPU（中央处理器）和数据库分片即使空闲，也不能在不破坏顺序与不变量的前提下同时修改同一冲突点。

扩应用线程会让更多事务同时争抢锁，增加连接占用、回滚、死锁和超时；扩数据库连接也只是把等待搬到锁队列，成功吞吐不一定增长。正确处置先按库存键限流与排队，快速拒绝超出可售与时效的请求；缩短锁内工作，把外部调用和非关键计算移出事务；能够拆分的业务可按仓、批次或库存单元细化键，但必须保证总量与预占流水守恒，不能随机打散后失去权威边界。

验证使用真实热度分布，而不是均匀随机商品。指标按键查看到达、完成、锁等待、回滚、预占和释放，恢复后对订单行与库存流水对账。缓存预扣可以削峰和尽早拒绝，但最终数据库或权威库存服务仍负责不超卖，缓存与权威状态之间要有差异检测与补偿。容量报告应明确总吞吐和单热键上限是两个不同结论，并给热点识别、隔离和业务降级方案。

热点变化还可能发生在仓、租户或活动批次，所以路由与告警不能只按商品标识。每次拆键都要写出守恒关系和迁移回退，灰度期间双边对账；若拆分不能证明库存总量一致，就保留串行上限并通过产品规则控制入口。

追问 1：总 CPU（中央处理器）低为何仍慢？ 直答 1：单键串行是局部瓶颈，平均资源会掩盖它。
追问 2：加连接有用吗？ 直答 2：通常只增加锁前等待和回滚，不能提高单键串行能力。
追问 3：可以随机分片吗？ 直答 3：只有业务不变量允许拆键并能守恒时才行。
追问 4：缓存预扣的边界是什么？ 直答 4：负责削峰，不替代权威库存和对账。
详情：WMS（仓储管理系统）库存预占、仓内作业与对账补偿

问题：消息队列磁盘快满时，如何同时做容量与恢复决策？

口述答案：先区分静态使用率和净增长。按节点、目录、主题和分区统计剩余字节、生产字节率、删除字节率、副本追赶、死信和重试，净增长等于所有新增减去合法删除；预计写满时间等于剩余可用字节除以净增长字节每秒。集群总空间正常也可能有热点分区或副本重建让单节点先满，所以决策必须落到故障域，不能只看全局百分比。

同时计算业务恢复：当前积压、最老消息年龄、有效消费率与生产率决定是否仍恶化。磁盘紧张时先限制非关键生产、暂停无界重放和低价值统计，保护支付、库存和关键报警事实；控制副本迁移并发，避免恢复写放大与前台竞争。不能手工删除活跃日志段，也不能因为数据库有快照就随意缩短消息保留，必须确认所有消费组、归档、对账、补数工具和恢复时间满足边界。

扩盘或清理后不能立即全量恢复。设置低于保护水位的恢复阈值和观察窗，确认净增长、删除延迟、副本同步、前台 P99（99 分位响应时间）、积压净消化和业务差异稳定，再分批解除限流。复盘用实际平均与高分位消息大小、压缩、副本、索引和故障恢复流量修正存储模型，并为预计 12 小时、6 小时写满等候选门槛做演练校准；没有生产证据时不把门槛写成真实承诺。

所有临时保留调整都设置到期时间和审批记录，事故后自动回到原策略或重新评审。否则一次应急缩短可能永久削弱重放窗口；同样，临时扩盘也要纳入均衡和成本计划，不能掩盖删除任务或死信持续增长。

追问 1：85%使用率一定事故吗？ 直答 1：不一定，要结合净增长和预计写满时间。
追问 2：为什么副本恢复更忙？ 直答 2：缺失日志追赶会增加网络读写并与前台竞争。
追问 3：先删支付消息吗？ 直答 3：不能，应先保护权威事实并限制可重建的低价值流量。
追问 4：恢复为何有低水位？ 直答 4：形成滞回，防止空间刚释放就反复启停。
详情：MQ（消息队列）磁盘、保留、副本与水位治理

问题：报警风暴结束后，如何证明容量和业务都恢复？

口述答案：风暴结束只说明入口峰值下降，不能证明故障窗口内的关键事件已经处理。恢复分三层：技术层看接入连续性、队列、消费者、数据库和通知渠道；容量层看有效消费率是否持续大于当前生产率、最老消息年龄和预计清空时间；业务层以设备和关键事件权威清单核对应处理、已聚合、已通知、已确认和仍未知。任何关键对象缺回执都按未完成处理。

处置期间的去重、抑制和限流必须有规则版本与生效窗口，普通重复事件可合并，但原始审计和严重度变化不能丢。恢复先清关键队列和通知，再按优先级处理普通积压；若通知渠道仍有限速，不能靠扩大消费者把压力推过去。解除抑制也要分批，观察是否重新产生重复风暴，并抽样验证设备状态与用户看到的报警一致。

最终验收包含原始序列连续、关键覆盖和新鲜度达标、通知回执闭环、积压与未确认清理、差异单有责任人。将实际峰值、关键占比、聚合比、服务时间和渠道配额回填模型，再演练一个消费者或渠道失效。若技术指标恢复但设备清单仍有漏报，事故保持开放；若观测缺样，则只能报告未知并采用保守策略，不能把“没有新报警”当成健康。

为避免人为确认能力成为隐藏瓶颈，我会统计待确认年龄、值班负载和升级超时，并在风暴期把相同根因的普通事件合并为处置单。关键事件仍保留逐设备责任与未确认清单，任何自动关闭都必须有回执或明确的业务过期规则。

追问 1：队列清零够吗？ 直答 1：不够，还要核对关键设备覆盖、通知回执和原始审计。
追问 2：无新报警代表恢复吗？ 直答 2：不一定，可能是采集断开或规则错误抑制。
追问 3：先清哪类积压？ 直答 3：先清关键安全事件，再按优先级处理普通事件。
追问 4：何时关闭事故？ 直答 4：技术、容量与业务证据在观察窗内共同通过。
详情：Prometheus（监控系统）告警与报警风暴治理

问题：异步导出发生 OOM（内存溢出）并积压时，如何重建容量模型？

口述答案：先止血并保全证据：暂停新大任务、降低导出并发、隔离异常实例，保存任务参数、堆与垃圾回收证据、线程、临时文件和对象存储状态。区分单任务工作集过大、并发过多、队列对象驻留、直接缓冲或基础内存被低估。容器退出没有 Java（编程语言）异常时还要查 OOMKilled（容器内存杀死），因为堆外、线程栈和本地库也计入总内存。

重建时通过不同总行数、页大小和并发测试单任务峰值工作集，公式为基础占用加工作集乘并发，再加线程栈、元空间、直接内存和回收余量。并发还要受数据库隔离连接、临时磁盘、网络和对象存储配额约束，取最小安全值。积压不能只按任务数计算，应按剩余行、文件字节、格式和分片加权；恢复净吞吐必须扣除新任务入口，并在在线交易与下游安全水位内运行。

任务恢复依赖快照边界、稳定游标、租约、分片摘要和确定性对象键，从最后可信检查点续跑，不全量重做，也不重复交付。验收比较相同数据和并发下的峰值堆、回收后占用、分配率、数据库、磁盘、上传、成功吞吐和 P99（99 分位响应时间），并做长稳测试确认内存回落。最后把单任务上限、系统并发、队列上限、拒绝条件和重算触发写入运行手册。

恢复放量按小、中、大任务分层，先验证短任务能正常交付，再逐步恢复大任务。若内存曲线回落但临时磁盘或数据库等待持续上升，仍不能关闭事故；多资源模型要求所有关键水位和产物完整性一起通过。

追问 1：先调大堆吗？ 直答 1：不先调，先确认工作集、引用和容器总内存。
追问 2：任务数能算恢复时间吗？ 直答 2：不能，需按剩余工作量和安全净吞吐加权。
追问 3：如何防全量重跑？ 直答 3：固定快照、稳定游标、分片摘要和检查点续跑。
追问 4：何时证明修复？ 直答 4：峰值内存有界、长稳回落且任务正确交付。
详情：异步导出 OOM（内存溢出）隔离、容量与恢复

问题：怎样设计一套可信的容量压测与故障验证计划？

口述答案：压测前先冻结版本、配置、实例规格、数据规模、键分布、依赖替身与真实配额，定义用户结果、停止条件和事实等级。流量模型包含忙时平均、阶梯峰值、峰值持续期、恢复期、热键、消息大小和任务混合；分别验证查询、下单、消息、报警和导出，不能用单一接口的均匀请求代表整个系统。生产数据需脱敏，外部副作用必须隔离或使用受控环境。

执行顺序从单资源基准到端到端负载：先测单任务服务时间和资源成本，再逐级增加到达率，观察成功吞吐、服务与等待、P99（99 分位响应时间）、线程、连接、锁、磁盘、网络和存储。达到吞吐不增而等待、错误或重试陡升就停止，记录拐点而不是继续追最高分。随后保持候选峰值足够时间，验证泄漏、磁盘累积和垃圾回收，再进入峰后恢复，检查净消化与业务时效。

故障验证至少移除一个实例或消费者、降低数据库或渠道配额、注入缓存失效、慢依赖和观测缺样，确认限流、降级、幂等和恢复路径。验收不仅是技术指标，还要对账库存、支付、任务产物和关键报警；任何生产外推都必须注明差异。报告保存脚本、输入、时间线、原始结果、失败样本、停止原因和重算条件，压测结果只在同版本、同边界和同故障假设下有效。

每个场景在执行前写预期和判定公式，执行后保存实际值与差异，防止看到结果后移动标准。测试环境无法复制的生产因素，如真实渠道限额或跨区域网络，明确列为残余风险，并通过小流量灰度和在线保护继续验证。

追问 1：为什么要测峰值持续期？ 直答 1：短测看不到泄漏、磁盘累积、热度变化和恢复压力。
追问 2：最高吞吐是容量吗？ 直答 2：不是，容量应位于满足延迟、正确、恢复和故障余量的区间。
追问 3：何时停止施压？ 直答 3：业务红线、资源保护线或非线性拐点任一触发即停止。
追问 4：如何外推生产？ 直答 4：明确环境差异并经线上小流量校准，不能直接复制数字。
详情：SLO（服务等级目标）、事故响应、容量与项目综合演练

问题：容量事故中如何从现象走到首个饱和资源？

口述答案：先按用户路径、租户、区域、版本和业务键定界，确认是慢、拒绝、未知还是业务错误。比较到达率、有效完成率和重试：到达上升说明流量侧变化，完成下降说明服务率或依赖变化，二者都正常却投诉上升则先查观测覆盖。积压变化率能判断是否仍恶化，最老年龄说明业务时效；不能从单个 CPU（中央处理器）告警直接下根因。

接着沿等待链逐层定位：入口排队、线程池、连接池、数据库锁与执行、MQ（消息队列）未确认、磁盘、网络和外部配额。查看哪一层最先出现等待或服务时间变化，再用链路、日志和业务审计验证。后续层的高利用率可能只是上游拥塞的结果；例如数据库变慢先拉长连接持有，线程排队和重试随后出现，首个饱和点仍是数据库查询或锁，而不是线程池。

止血针对首因并保护业务：限入口、暂停低优先级任务、隔离慢依赖、抑制重试、返回明确降级。扩容只有在工作可并行且下游有余量时使用。恢复阶段验证新流量、历史积压、最老未知和业务不变量，并保持观察窗；随后把实际到达、服务时间、命中、配额和故障域回填模型。若证据冲突，保留多个假设并继续取证，不为快速复盘编造单一故事。

时间线中我会标记发布、配置、流量、依赖和人工操作，避免相关性被误当因果。首个饱和点确认后还要解释为何保护机制没有更早动作，是阈值、数据缺失、扩容延迟还是责任不清，并把改进及复验期限放入下一次故障演练验证。

追问 1：第一步为什么不是扩容？ 直答 1：未定位首个饱和资源时，扩容可能把压力推向更弱下游。
追问 2：如何找首因？ 直答 2：按时间线找最先变化的服务或等待段，并用业务证据验证。
追问 3：告警恢复就结束吗？ 直答 3：不结束，还要清历史积压、未知态和业务差异。
追问 4：证据不足怎么办？ 直答 4：报告未知和最坏边界，采取保守保护并补观测。
详情：DevOps（开发运维一体化）与可观测性四闭环

问题：容量、SLO（服务等级目标）与错误预算如何联动？

口述答案：容量模型回答在给定工作负载和故障假设下能否持续完成，SLO（服务等级目标）定义用户结果的目标，错误预算决定可承受风险。三者的连接点是成功事件、延迟达标、未知态、积压年龄和业务不变量。容量不能只保证平均吞吐大于入口，还要保证在目标窗口内完成并留出恢复；如果技术吞吐达标却尾延迟或关键业务结果失守，仍在消费错误预算。

我会把容量水位接入发布和运行决策。正常利用率、队列、连接和依赖配额有余量且预算健康时，允许受控灰度；水位进入敏感区或燃烧加速时缩小批次、延长观察并暂停低价值任务；利用率跨稳定边界、最老年龄超时、预算耗尽或库存资金红线触发时，立即停止高风险放量并限流、降级或回滚。修复与减险通道保留，但同样受最小验证集和业务核验约束。

事故恢复后不能因为短窗错误率回落就恢复全部容量。先确认有效服务率高于入口、历史积压可在目标内清理、重试放大消退、关键不变量和未知态闭环；再按故障域分批放量。错误预算复盘若发现告警过迟，应调整容量前置阈值、队列时效或扩容预热；容量事故也可能暴露 SLO（服务等级目标）分母遗漏执行中和异步结果，需要同步修正口径版本。

联动规则必须版本化并展示豁免、责任人和有效期，防止事故中临时选择更宽松窗口。低流量路径用绝对坏事件和合成探测补足百分比，关键资金、库存与漏报红线则不允许被整体错误预算或容量均值抵消。

追问 1：容量达标就一定满足 SLO（服务等级目标）吗？ 直答 1：不一定，还要满足尾延迟、正确性、未知态和业务时效。
追问 2：预算健康能压到满载吗？ 直答 2：不能，预算不是当前变更安全或资源有余量的证明。
追问 3：容量水位如何接门禁？ 直答 3：以版本化阈值触发缩批、暂停、限流、降级和回滚。
追问 4：恢复后先看什么？ 直答 4：新流量、历史积压、重试、未知态和业务不变量共同通过。
详情：SLI（服务等级指标）、SLO（服务等级目标）与错误预算治理

问题：如何在容量与成本之间做可信取舍？

口述答案：我先把成本定义为“每个正确业务结果的总成本”，而不是机器单价。输入包括计算、内存、数据库、消息、存储、网络、第三方配额、观测、值守、演练，以及失败、补偿和用户损失。容量约束包括峰值、服务时间、尾延迟、单故障域、恢复时间和业务不变量；任何节省都不能突破资金、库存和关键报警红线。没有真实账单或生产结果时，单价和收益只作为 E3（演练证据）敏感性输入。

方案比较至少包含扩实例、扩分区、优化查询、提高缓存、批量、异步、错峰、限流和产品降级。扩应用可能把数据库连接耗尽，增加副本会提高存储与恢复流量，降低观测采样可能损失支付未知态证据；所以每项都写收益、瓶颈转移、退出条件和剩余风险。对短峰可用有界排队和弹性减少长期闲置，对不可预测高损失路径保留更高故障余量，对低价值报表可降低时效但要明确告知。

决策用敏感性而非单点价格：比较流量增长、服务变慢、一个故障域失效和价格变化下的单位正确结果成本。上线后同时看资源费用、成功吞吐、错误预算、补偿和值守，若机器增加却用户结果和恢复没有改善，应停止扩张并重做瓶颈分析。所有方案登记复审日期和可撤销路径，防止低价试点变成高退出成本，也防止以节省资源为名把风险转给用户。

成本结论还要区分一次性迁移、持续资源、最低消费和退出成本，并由业务确认体验取舍。对可重建报表可降保留或延迟，对支付账务和关键报警保留必要冗余；不同等级采用不同容量策略，比全系统一刀切更可信。

追问 1：最便宜方案最好吗？ 直答 1：不一定，应比较单位正确结果成本和失败风险。
追问 2：短峰如何省成本？ 直答 2：用有界排队、弹性、错峰和可解释降级，但要满足时效。
追问 3：观测能削减吗？ 直答 3：可优化低价值信号，关键正确性与未知态证据不能盲减。
追问 4：如何证明扩容值得？ 直答 4：资源增加应带来成功吞吐、尾延迟、恢复或风险的可验证改善。
详情：异步导出容量、成本、降级与故障余量

问题：请用项目话术完整讲一次容量、排队与资源治理方案。

口述答案：我会以 WMS（仓储管理系统）、跨境查询、消息、报警和导出共用一套方法，但不共用一个容量数字。先从业务意图和用户时效出发，固定忙时、峰值、持续时间、数据分布、重试归并和 E3（演练证据）边界；查询用 QPS（每秒查询率）并拆缓存回源，下单用 TPS（每秒事务数）并展开库存事务，消息与报警用生产消费速率差，导出按剩余工作量和多资源最小值。所有公式先做单位守恒。

稳定窗口用 Little’s Law（利特尔定律）区分总在途、执行中与排队，利用率只作为必要稳定条件，接近 1 时重点看尾延迟和重试。资源逐层计算线程、数据库与外部连接、锁和数据库操作、磁盘字节率、网络与存储保留；最终容量取最紧约束。敏感性覆盖峰值、服务时间、命中率、消息大小、重试和单故障域，特别标出热键、连接耗尽、下游配额与磁盘水位等非线性拐点。

运行中以到达、有效完成、等待、资源、依赖和业务审计定位首个饱和点，先限流、分级、暂停低价值任务和抑制重试，再扩真实瓶颈。恢复不仅看告警，还要清历史积压、最老未知，并核对库存、支付、产物和关键报警。压测保存版本、脚本、数据、停止条件与业务对账，结论报告容量区间、失败边界、扩缩容和重算触发，不把演练数字写成生产成绩。这套方法的价值是让容量能计算、能验证、能止损，也能诚实表达。

项目复述最后要补组织闭环：谁维护输入、谁批准阈值、谁在事故中限流、谁确认业务恢复。技术公式只有进入看板、门禁、运行手册和复盘才真正生效；若缺少生产基线，我会明确下一步采集计划和最保守边界，而不是用熟悉的行业数字填空。

追问 1：统一方法是什么？ 直答 1：业务量到速率、速率到在途、在途到资源、资源到瓶颈与验证。
追问 2：为什么不统一容量数？ 直答 2：查询、事务、消息、报警和任务的对象、时效与资源不同。
追问 3：最重要的失败边界是什么？ 直答 3：有效服务率不再大于到达率，或关键业务不变量失守。
追问 4：如何证明没有夸大？ 直答 4：给证据等级、单位、假设、公式、验证和待核对项。
详情：架构案例事实卡与项目证据边界

容量、排队、Little’s Law（利特尔定律）与资源模型

正式时序图

1. 容量模型先固定对象、单位、窗口与证据等级 {#53-02-k01}

数据演绎 1：先做量纲检查再算容量

热门面试题

2. 从业务量推导平均、峰值和峰值持续时间 {#53-02-k02}

数据演绎 2：日订单到下单 TPS（每秒事务数）

热门面试题

3. Little’s Law（利特尔定律）区分服务时间、等待与在途 {#53-02-k03}

数据演绎 3：查询服务的等待与服务拆分

热门面试题

4. 利用率、排队稳定条件与非线性拐点 {#53-02-k04}

数据演绎 4：服务时间抖动跨过稳定边界

热门面试题

5. 查询模型从 QPS（每秒查询率）落到缓存、线程、连接与数据库 {#53-02-k05}

数据演绎 5：跨境轨迹查询的缓存敏感性

热门面试题

6. 下单 TPS（每秒事务数）要展开事务、锁、日志与副作用 {#53-02-k06}

数据演绎 6：WMS（仓储管理系统）下单与热点库存

热门面试题

7. 线程、连接与数据库资源要按持有时间分别预算 {#53-02-k07}

数据演绎 7：容器线程与连接预算

热门面试题

8. 消息积压模型用速率差、存储和恢复时间闭环 {#53-02-k08}

数据演绎 8：停机积压与受控恢复

热门面试题

9. IoT（物联网）报警峰值要保护关键覆盖而非总吞吐 {#53-02-k09}

数据演绎 9：报警峰值与关键通道

热门面试题

10. 异步导出同时受数据库、JVM（Java 虚拟机）、磁盘与对象存储约束 {#53-02-k10}

数据演绎 10：异步导出的多资源最小值

热门面试题

11. 磁盘、网络与存储必须同时计算速率、容量和写满时间 {#53-02-k11}

数据演绎 11：网络与磁盘双约束

热门面试题

12. 敏感性、故障余量与非线性拐点决定最终配置 {#53-02-k12}

数据演绎 12：单实例失效后的容量区间

热门面试题

13. 容量排障、项目话术与持续校准形成闭环 {#53-02-k13}

数据演绎 13：五类模型统一排障

热门面试题

综合题使用说明

综合题库

复习与审计清单