GoCode

面试知识

架构稳定性指标与容量评估

53-架构稳定性指标与容量评估 面试知识整理。

架构稳定性指标与容量评估

1. 简历关联点

架构师面试里，面试官很容易追问：“你们系统 QPS（每秒查询率）多少？”“P99（99 分位响应时间）是多少？”“几台机器？”“CPU（中央处理器）打满怎么处理？”“怎么做压测？”“数据库扛不住怎么办？”

这些问题不是要背固定数字，而是要看你有没有稳定性指标意识、容量估算方法、性能测试方法、资源选型方法和扩容判断能力。

本模块用于准备：

  • 架构稳定性指标。
  • 容量估算和服务器选型。
  • Docker（容器技术）/Kubernetes（容器编排平台）资源配置。
  • 性能测试、压力测试、冒烟测试。
  • 服务、数据库、Redis（远程字典服务）、MQ（消息队列）的扩容判断。
  • 面试可口述的技术数据样例。

2. 面试主线

回答稳定性和容量问题时，建议按“指标 -> 当前规模 -> 瓶颈 -> 方案 -> 验证 -> 监控 -> 演进”来讲。

业务规模
  -> 核心指标
  -> 容量估算
  -> 资源配置
  -> 压测验证
  -> 线上监控
  -> 扩容和优化

一句话模板：

我不会只说系统能扛多少并发，而会说明统计口径，比如 QPS（每秒查询率）、TPS（每秒事务数）、P95（95 分位响应时间）、P99（99 分位响应时间）、错误率、CPU（中央处理器）、内存、线程池、数据库连接池和 MQ（消息队列）积压。容量设计上先按峰值和突增倍率估算，再通过压测验证，线上通过监控和告警持续校准。

3. 核心稳定性指标

3.1 QPS（每秒查询率）、TPS（每秒事务数）和并发数

指标含义面试解释
QPS（每秒查询率）每秒请求数常用于接口、查询、网关入口流量
TPS（每秒事务数）每秒完成事务数常用于下单、支付、库存扣减这类业务事务
并发数同时在处理的请求或用户数和响应时间强相关，不等于 QPS（每秒查询率）
Throughput（吞吐量）单位时间处理量可按请求、消息、订单、数据量统计

估算关系：

并发数 ≈ QPS（每秒查询率） * 平均 RT（响应时间，秒）

示例：
QPS（每秒查询率）= 500
平均 RT（响应时间）= 200ms（毫秒）= 0.2s（秒）
并发处理请求数 ≈ 500 * 0.2 = 100

注意：

  • QPS（每秒查询率）看入口请求量。
  • TPS（每秒事务数）看真正完成的业务事务。
  • 并发用户数不等于系统并发处理数，用户可能在思考、浏览、等待。

热门面试题

  1. 问题（基础题）：QPS（每秒查询率）和 TPS（每秒事务数）有什么区别？

    • 考点：请求口径和业务事务口径。
    • 回答思路：QPS（每秒查询率）偏接口请求量，TPS（每秒事务数）偏完整业务事务完成量，比如下单成功数或支付成功数。
    • 进阶追问：一个下单流程调用 5 个接口，QPS（每秒查询率）和 TPS（每秒事务数）怎么换算？

  2. 问题（原理题）：并发数和 QPS（每秒查询率）是什么关系？

    • 考点：Little’s Law（利特尔法则）、响应时间。
    • 回答思路：粗略看，并发处理请求数约等于 QPS（每秒查询率）乘以平均 RT（响应时间）。响应越慢，同样 QPS（每秒查询率）下占用的并发资源越多。
    • 进阶追问：为什么下游慢会导致线程池被打满？

  3. 问题（项目追问题）：订单系统说能扛 500 QPS（每秒查询率），你会补充哪些口径？

    • 考点：指标口径、场景、链路。
    • 回答思路：要说明是查询 QPS（每秒查询率）还是下单 TPS（每秒事务数），是单接口还是全链路，是平均 RT（响应时间）还是 P99（99 分位响应时间），是否包含库存、支付、MQ（消息队列）和数据库。
    • 进阶追问：如果 500 QPS（每秒查询率）里 80% 是查询、20% 是写入，容量估算怎么变化？

3.2 RT（响应时间）、P95（95 分位响应时间）和 P99（99 分位响应时间）

平均 RT（响应时间）容易掩盖长尾问题，所以架构师面试要主动提 P95（95 分位响应时间）和 P99（99 分位响应时间）。

指标含义价值
平均 RT（响应时间）所有请求平均耗时看整体体验，但会掩盖长尾
P95（95 分位响应时间）95% 请求不超过该耗时看大多数用户体验
P99（99 分位响应时间）99% 请求不超过该耗时看长尾和稳定性
Max RT（最大响应时间）最慢请求耗时排查极端异常

可口述样例：

普通查询接口：
P95（95 分位响应时间）控制在 200ms（毫秒）以内
P99（99 分位响应时间）控制在 500ms（毫秒）以内

下单写接口：
P95（95 分位响应时间）控制在 300ms（毫秒）到 500ms（毫秒）
P99（99 分位响应时间）控制在 800ms（毫秒）到 1s（秒）

外部支付/物流接口：
要单独统计下游 RT（响应时间），不能算成内部服务能力

注意：这些是面试练习口径，不要当成真实生产事实硬说。真实数据要以项目监控为准。

热门面试题

  1. 问题（基础题）：为什么不能只看平均 RT（响应时间）？

    • 考点：长尾请求、用户体验。
    • 回答思路：平均值会被大量快请求稀释，P95（95 分位响应时间）和 P99（99 分位响应时间）更能反映慢请求和长尾稳定性。
    • 进阶追问：P99（99 分位响应时间）突然升高通常说明什么？

  2. 问题（原理题）：P99（99 分位响应时间）高但平均 RT（响应时间）正常，怎么排查？

    • 考点：长尾、资源争用、慢依赖。
    • 回答思路：看 Trace（链路追踪）里慢在哪段，再看线程池、连接池、GC（垃圾回收）、慢 SQL（结构化查询语言）、Redis（远程字典服务）热点 key（键）、下游接口。
    • 进阶追问：如果只有少量请求慢，为什么也要重视？

  3. 问题（项目追问题）：跨境物流接口 P99（99 分位响应时间）很高怎么办？

    • 考点：外部依赖隔离、超时、异步。
    • 回答思路：物流接口是外部慢依赖，不应阻塞主链路；要设置超时、异步任务、线程池隔离、重试退避和渠道级熔断。
    • 进阶追问：如何证明慢在第三方而不是内部系统？

3.3 错误率、可用性和 SLA（服务等级协议）

指标含义示例
Error Rate（错误率）失败请求占比5xx（服务器错误）、超时、业务失败
Availability（可用性）系统可用时间比例99.9%（三个 9）
SLA（服务等级协议）对外承诺指标可用性、响应时间、故障恢复
SLO（服务等级目标）内部目标比 SLA（服务等级协议）更细

可用性换算：

可用性理论月不可用时间
99%约 7.2 小时
99.9%约 43 分钟
99.99%约 4.3 分钟

面试表达：

我会把接口错误分成系统错误、业务失败和外部依赖失败。比如支付失败不一定是系统不可用，但支付接口 5xx（服务器错误）或超时增加，就要看服务、数据库、通道和网络。

热门面试题

  1. 问题（基础题）：错误率怎么定义？

    • 考点：技术失败和业务失败。
    • 回答思路：要先定义口径，5xx（服务器错误）、超时、异常属于技术失败；库存不足、用户取消属于业务失败，不应混在一起。
    • 进阶追问：支付失败率高一定是系统问题吗？

  2. 问题（原理题）：99.9% 可用性意味着什么？

    • 考点：SLA（服务等级协议）量化。
    • 回答思路：表示理论上一个月不可用时间约 43 分钟，架构上要通过监控、冗余、故障切换和应急预案支撑。
    • 进阶追问：如何把可用性目标拆到服务级别？

  3. 问题（项目追问题）：订单系统可用性下降时先保什么？

    • 考点：核心链路保护、降级策略。
    • 回答思路：优先保护下单、支付、库存核心链路；报表、通知、推荐、非核心查询可以降级或延迟。
    • 进阶追问：如何避免降级影响资金一致性？

4. 资源与饱和度指标

4.1 CPU（中央处理器）和 Load Average（平均负载）

指标健康口径风险
CPU（中央处理器）使用率长期 50%-70% 较稳长期 80% 以上要关注
Load Average（平均负载）接近 CPU（中央处理器）核数以内较稳高于核数很多说明排队严重
上下文切换越低越好线程过多、锁竞争、I/O（输入输出）等待

面试表达：

我不会等 CPU（中央处理器）到 100% 才扩容。核心服务长期超过 70% 就要关注，超过 80% 且伴随 P99（99 分位响应时间）升高，就要考虑扩容或优化。还要区分是 CPU（中央处理器）计算打满，还是 I/O（输入输出）等待导致负载高。

热门面试题

  1. 问题（基础题）：CPU（中央处理器）使用率高一定代表机器不够吗？

    • 考点：资源瓶颈判断。
    • 回答思路：不一定。要看是计算密集、锁竞争、GC（垃圾回收）、线程过多上下文切换，还是 I/O（输入输出）等待。扩容是止血手段，根因还要结合 top（进程监控命令）、jstack（线程栈工具）、Trace（链路追踪）和火焰图定位。
    • 进阶追问：CPU（中央处理器）不高但 Load Average（平均负载）高，可能是什么问题？

  2. 问题（项目追问题）：核心服务 CPU（中央处理器）长期 80% 以上，你怎么处理？

    • 考点：止血、定位、复盘。
    • 回答思路：先限流或扩容保护核心链路，再定位热点接口、热点线程、慢 SQL（结构化查询语言）和下游依赖，最后沉淀容量阈值和告警规则。
    • 进阶追问：为什么只扩容可能把数据库打崩？

4.2 内存、JVM（Java 虚拟机）和 GC（垃圾回收）

指标关注点
内存使用率是否持续上涨，是否接近容器限制
JVM（Java 虚拟机）Heap（堆）老年代占用、对象增长
GC（垃圾回收）次数Minor GC（年轻代垃圾回收）和 Full GC（完全垃圾回收）频率
GC（垃圾回收）耗时是否影响 P99（99 分位响应时间）
Direct Memory（直接内存）NIO（新输入输出）、Netty（网络通信框架）场景

可口述样例：

4C8G（4 核 CPU，8GB 内存）容器：
JVM（Java 虚拟机）堆可先设 4GB（吉字节）左右
保留 2GB（吉字节）给 Metaspace（元空间）、Direct Memory（直接内存）、线程栈和系统开销
容器 memory limit（内存限制）不要只等于 Xmx（最大堆内存）

热门面试题

  1. 问题（基础题）：容器里为什么 Xmx（最大堆内存）不能等于 memory limit（内存限制）？

    • 考点：JVM（Java 虚拟机）非堆内存。
    • 回答思路：Java（编程语言）进程除了 Heap（堆）还有 Metaspace（元空间）、Direct Memory（直接内存）、线程栈、JIT（即时编译）和本地库开销。如果 Xmx（最大堆内存）贴满 memory limit（内存限制），容器容易 OOMKilled（容器内存杀死）。
    • 进阶追问：JVM（Java 虚拟机） OOM（内存溢出）和容器 OOMKilled（容器内存杀死）有什么区别？

  2. 问题（原理题）：P99（99 分位响应时间）突然抖动和 GC（垃圾回收）有什么关系？

    • 考点：Stop The World（停顿世界）和长尾延迟。
    • 回答思路：GC（垃圾回收）停顿会让部分请求等待，从而拉高 P95（95 分位响应时间）和 P99（99 分位响应时间）。排查时要把接口慢请求时间点和 GC（垃圾回收）日志、堆使用率、对象分配速率对齐。
    • 进阶追问：Full GC（完全垃圾回收）频繁时你先看哪些对象？

4.3 线程池、连接池和队列

资源指标风险
线程池activeCount（活跃线程数）、queueSize（队列大小）、rejectCount（拒绝次数）任务堆积、拒绝、重试风暴
数据库连接池active connections（活跃连接数）、wait count（等待次数）连接耗尽、请求排队
Redis（远程字典服务）连接池连接使用率、超时缓存访问变慢
MQ（消息队列）backlog（积压量）、消费延迟下游处理不过来

面试表达：

很多线上故障不是 CPU（中央处理器）先满，而是线程池、连接池或队列先饱和。比如下游慢导致线程池被占满，上游重试放大流量，最终 P99（99 分位响应时间）升高并触发雪崩。

热门面试题

  1. 问题（基础题）：线程池和连接池为什么要单独监控？

    • 考点：隐性饱和资源。
    • 回答思路：CPU（中央处理器）和内存正常时，线程池队列、数据库连接池等待、Redis（远程字典服务）连接超时也会让请求排队。它们是比机器资源更贴近业务链路的饱和指标。
    • 进阶追问：线程池队列越大越好吗？

  2. 问题（项目追问题）：MQ（消息队列）积压持续增长怎么办？

    • 考点：生产消费速率和下游瓶颈。
    • 回答思路：先看生产峰值、消费速率、consumer lag（消费者延迟）、单 Partition（分区）热点和下游写库耗时。止血可以临时扩 Consumer（消费者），但根因可能是消费逻辑慢、批量写入不足或数据库瓶颈。
    • 进阶追问：为什么增加 Consumer（消费者）不一定能提升消费能力？

5. 容量估算方法

5.1 从业务量估算 QPS（每秒查询率）

日订单量：100 万
峰值集中时间：2 小时
峰值订单量占比：50%
峰值 TPS（每秒事务数）≈ 1000000 * 50% / 7200 ≈ 70
考虑活动突增 5 倍：350 TPS（每秒事务数）
如果每个订单平均触发 5 个内部请求：内部 QPS（每秒查询率）≈ 1750

面试表达：

我会先从业务量估算入口 TPS（每秒事务数），再乘以内链路调用倍数估算内部 QPS（每秒查询率），再按峰值倍率留容量。不能只看日均值，因为日均值会严重低估高峰压力。

热门面试题

  1. 问题（基础题）：为什么不能用日均请求量做容量设计？

    • 考点：峰值流量和流量分布。
    • 回答思路：日均值会摊平高峰。容量估算要看峰值窗口、峰值占比、活动突增倍率和核心链路调用倍数，否则会低估下单、支付、库存扣减这类峰值场景。
    • 进阶追问：如果没有历史数据，你怎么估算首版容量？

  2. 问题（项目追问题）：WMS（仓储管理系统）出库波峰怎么估算？

    • 考点：业务动作拆分。
    • 回答思路：先拆成创建波次、拣货、复核、称重、出库、库存扣减、轨迹推送等动作，再分别估算 TPS（每秒事务数）和内部 QPS（每秒查询率），最后看数据库写入、MQ（消息队列）和外部物流接口瓶颈。
    • 进阶追问：哪些动作适合同步，哪些适合异步？

5.2 服务实例数估算

假设压测得到：

单个 4C8G（4 核 CPU，8GB 内存）服务实例
稳定处理能力：200 QPS（每秒查询率）
目标峰值：600 QPS（每秒查询率）
冗余系数：1.5
实例数 ≈ 600 / 200 * 1.5 = 4.5
建议部署：5 个实例

注意：

  • 单机能力要来自压测，不要拍脑袋。
  • 冗余系数用于覆盖突发流量、实例故障和发布滚动。
  • 核心服务至少 2 个实例，避免单点。

热门面试题

  1. 问题（基础题）：服务实例数怎么估算？

    • 考点：单实例能力、峰值、冗余。
    • 回答思路：先压测得到单实例稳定 QPS（每秒查询率）或 TPS（每秒事务数），再用目标峰值除以单实例能力，乘以冗余系数，最后结合最小多副本和滚动发布需要确定实例数。
    • 进阶追问：为什么不能只按平均 CPU（中央处理器）使用率估算实例数？

  2. 问题（项目追问题）：服务扩到 10 个实例后吞吐没提升，可能是什么原因？

    • 考点：下游瓶颈和水平扩展上限。
    • 回答思路：可能瓶颈在数据库连接数、慢 SQL（结构化查询语言）、Redis（远程字典服务）热点 key（键）、MQ（消息队列）分区数、外部接口限流或锁竞争。服务无状态扩容只能解决服务层瓶颈。
    • 进阶追问：如何通过压测证明瓶颈转移了？

5.3 数据库容量估算

维度估算方法
写入 TPS（每秒事务数）下单、支付、库存、日志分别估算
表数据量日增量 * 保留天数
索引大小索引字段越多，写入成本越高
连接数服务实例数 * 每实例连接池上限
慢 SQL（结构化查询语言）超过 500ms（毫秒）建议告警

可口述样例：

订单主表日增 100 万
保留 3 年：约 10.9 亿行
如果不归档、不分区、不分库，后续查询和维护成本会明显上升
可以先做按时间归档和冷热分离，再评估分库分表

热门面试题

  1. 问题（基础题）：数据库容量评估看哪些指标？

    • 考点：写入、存储、查询、连接。
    • 回答思路：看写入 TPS（每秒事务数）、表行数、索引大小、慢 SQL（结构化查询语言）、连接数、锁等待、磁盘 I/O（输入输出）和备份恢复时间。不同指标对应不同治理手段。
    • 进阶追问：单表多少行必须分库分表？

  2. 问题（项目追问题）：订单表几年后会很大，你怎么提前设计？

    • 考点：冷热分离和演进路径。
    • 回答思路：先按日增量和保留周期估算总量，设计时间维度归档、状态归档、读模型和索引策略；查询侧避免无条件扫历史，确实超过单库能力再设计分库分表。
    • 进阶追问：历史订单查询怎么兼顾性能和用户体验？

5.4 Redis（远程字典服务）内存估算

缓存 key（键）数量：100 万
平均 value（值）：1KB（千字节）
纯数据约：1GB（吉字节）
考虑 key（键）、对象头、编码、碎片和冗余：可能需要 2GB（吉字节）到 4GB（吉字节）

热门面试题

  1. 问题（基础题）：Redis（远程字典服务）内存为什么不能只按 value（值）大小算？

    • 考点：对象开销和内存碎片。
    • 回答思路：Redis（远程字典服务）还要存 key（键）、对象头、编码结构、过期字典、复制缓冲区和内存碎片，所以容量要乘以冗余系数，并持续观察 used_memory（已用内存）和 mem_fragmentation_ratio（内存碎片率）。
    • 进阶追问：big key（大键）会带来哪些稳定性问题？

  2. 问题（项目追问题）：库存缓存热点很高怎么办？

    • 考点：hot key（热键）治理。
    • 回答思路：可以做本地缓存、拆 key（键）、请求合并、限流、预热和多级缓存；扣减类场景还要保证 MySQL（关系型数据库）条件更新或 Lua（脚本语言）脚本的正确性兜底。
    • 进阶追问：本地缓存会不会导致库存不一致？

5.5 MQ（消息队列）容量估算

峰值生产：5000 msg/s（每秒消息数）
消费者单实例处理：500 msg/s（每秒消息数）
需要消费者实例：5000 / 500 = 10
如果允许 10 分钟积压：
积压容量：5000 * 600 = 300 万条消息

热门面试题

  1. 问题（基础题）：MQ（消息队列）容量估算看生产端还是消费端？

    • 考点：端到端吞吐。
    • 回答思路：两端都要看。生产端决定峰值进入速度，消费端决定系统消化能力；如果生产速率长期大于消费速率，backlog（积压量）和 consumer lag（消费者延迟）会持续上升。
    • 进阶追问：如何估算最大可接受积压时间？

  2. 问题（项目追问题）：IoT（物联网）报警风暴时 MQ（消息队列）怎么保护？

    • 考点：削峰、降噪、分级。
    • 回答思路：入口限流和按设备维度聚合，重要报警单独 Topic（主题）或优先级通道，普通报警允许窗口聚合和延迟消费，同时监控 Broker（代理节点）磁盘、consumer lag（消费者延迟）和通知成功率。
    • 进阶追问：报警降噪如何避免误伤高级报警？

6. 服务器、Docker（容器技术）和 Kubernetes（容器编排平台）选型

6.1 服务规格选择

规格适合场景
2C4G（2 核 CPU，4GB 内存）低流量后台、轻量任务
4C8G（4 核 CPU，8GB 内存）常见 Java（编程语言）业务服务起步规格
8C16G（8 核 CPU，16GB 内存）高吞吐服务、较重计算或大连接数
16C32G（16 核 CPU，32GB 内存）数据处理、报表、批任务，不建议盲目给普通服务

面试表达：

普通 Java（编程语言）业务服务我一般会从 4C8G（4 核 CPU，8GB 内存）或 2C4G（2 核 CPU，4GB 内存）起步，通过压测校准。不是机器越大越好，过大实例会影响弹性和资源利用率。

热门面试题

  1. 问题（基础题）：为什么 Java（编程语言）服务常从 2C4G（2 核 CPU，4GB 内存）或 4C8G（4 核 CPU，8GB 内存）起步？

    • 考点：成本、弹性和 JVM（Java 虚拟机）开销。
    • 回答思路：这类规格能覆盖多数中等业务服务的启动、线程池、连接池和堆内存需求，同时保持弹性扩缩容粒度。真正规格要通过压测和线上监控校准。
    • 进阶追问：什么时候需要 8C16G（8 核 CPU，16GB 内存）以上规格？

  2. 问题（项目追问题）：为什么不建议所有服务都给大机器？

    • 考点：资源利用率和故障影响面。
    • 回答思路：大实例弹性差、发布影响面大、资源碎片高，也容易掩盖代码和 SQL（结构化查询语言）问题。更好的方式是按服务画像选择规格，用指标驱动扩缩容。
    • 进阶追问：批任务和在线接口的规格选择有什么区别？

6.2 Docker（容器技术）资源限制

配置含义建议
CPU request（CPU 请求）调度时保证的 CPU（中央处理器）按稳定用量设置
CPU limit（CPU 限制）最大可用 CPU（中央处理器）避免抢占过多资源
memory request（内存请求）调度时保证内存按稳定使用量设置
memory limit（内存限制）最大内存预留 JVM（Java 虚拟机）非堆空间

JVM（Java 虚拟机）容器注意点：

  • Xmx（最大堆内存）不能等于容器 memory limit（内存限制）。
  • 需要给 Metaspace（元空间）、Direct Memory（直接内存）、线程栈、JIT（即时编译）和系统库留空间。
  • 容器 OOMKilled（容器内存杀死）和 JVM（Java 虚拟机） OOM（内存溢出）不是一回事。

热门面试题

  1. 问题（基础题）：Docker（容器技术）里 request（请求）和 limit（限制）有什么区别？

    • 考点：调度保障和资源上限。
    • 回答思路：CPU request（CPU 请求）和 memory request（内存请求）用于调度时预留资源，CPU limit（CPU 限制）和 memory limit（内存限制）用于限制容器上限。设置过低会导致限流或 OOMKilled（容器内存杀死），设置过高会降低集群利用率。
    • 进阶追问：CPU limit（CPU 限制）过低为什么会让 RT（响应时间）抖动？

  2. 问题（项目追问题）：容器频繁 OOMKilled（容器内存杀死）怎么排查？

    • 考点：堆内和堆外。
    • 回答思路：先看 memory limit（内存限制）、Xmx（最大堆内存）、Direct Memory（直接内存）、线程数、堆外缓存和日志缓冲，再区分 JVM（Java 虚拟机） OOM（内存溢出）还是容器层 OOMKilled（容器内存杀死）。
    • 进阶追问：为什么监控里 Heap（堆）没满也会 OOMKilled（容器内存杀死）？

6.3 Kubernetes（容器编排平台）扩缩容

机制触发依据
HPA（水平自动扩缩容）CPU（中央处理器）、内存、自定义 QPS（每秒查询率）
滚动发布分批替换 Pod（容器组）
Pod（容器组）探针存活探针、就绪探针
PDB（Pod 中断预算）限制同时不可用 Pod（容器组）数量

面试表达：

HPA（水平自动扩缩容）只看 CPU（中央处理器）不一定够。很多业务瓶颈在连接池、线程池、RT（响应时间）或 MQ（消息队列）积压，所以核心服务最好结合自定义指标扩缩容。

热门面试题

  1. 问题（基础题）：Kubernetes（容器编排平台）自动扩容只看 CPU（中央处理器）够不够？

    • 考点：扩容指标选择。
    • 回答思路：不够。CPU（中央处理器）适合计算型服务，但业务系统还要看 QPS（每秒查询率）、RT（响应时间）、线程池队列、连接池等待和 MQ（消息队列）积压。否则可能已经排队严重，但 CPU（中央处理器）并不高。
    • 进阶追问：什么场景适合用自定义 Metrics（指标）做 HPA（水平自动扩缩容）？

  2. 问题（项目追问题）：滚动发布期间如何避免容量不足？

    • 考点：冗余和发布容量。
    • 回答思路：要保证最小可用 Pod（容器组）数量、PDB（Pod 中断预算）、就绪探针和预留容量。容量估算时要考虑发布期间少量实例不可用，所以不能把日常资源压到极限。
    • 进阶追问：就绪探针和存活探针分别解决什么问题？

7. 性能测试体系

测试类型目标观察指标
Smoke Test（冒烟测试）验证核心功能是否可用主流程成功率、错误日志
Benchmark Test（基准测试）得到单接口基础能力QPS（每秒查询率）、RT（响应时间）、CPU（中央处理器）
Load Test（负载测试）在预期负载下验证稳定性P95（95 分位响应时间）、P99（99 分位响应时间）、错误率
Stress Test（压力测试）找系统极限和瓶颈拐点、错误率、资源饱和
Spike Test（峰值测试）验证突增流量限流、队列、熔断
Soak Test（稳定性测试）长时间运行看泄漏内存、GC（垃圾回收）、连接数
Capacity Test（容量测试）确认容量上限最大稳定 QPS（每秒查询率）
Chaos Test（故障演练）验证故障恢复降级、切换、告警、恢复时间

7.1 压测流程

flowchart TD
    A["明确目标"] --> B["准备数据"]
    B --> C["设计脚本"]
    C --> D["小流量冒烟"]
    D --> E["逐步加压"]
    E --> F["观察瓶颈"]
    F --> G["优化和复测"]
    G --> H["输出容量报告"]

压测报告至少包括：

  • 测试环境和机器规格。
  • 压测接口和业务场景。
  • 数据量和数据分布。
  • QPS（每秒查询率）、TPS（每秒事务数）、P95（95 分位响应时间）、P99（99 分位响应时间）。
  • CPU（中央处理器）、内存、GC（垃圾回收）、线程池、连接池。
  • 数据库慢 SQL（结构化查询语言）、Redis（远程字典服务）命中率、MQ（消息队列）积压。
  • 瓶颈和优化建议。

热门面试题

  1. 问题（基础题）：冒烟测试和压力测试有什么区别？

    • 考点：测试目标。
    • 回答思路：Smoke Test（冒烟测试）验证核心流程是否可用，通常小流量、快反馈；Stress Test（压力测试）是逐步加压找系统极限和瓶颈。前者看能不能跑通，后者看扛到哪里会坏。
    • 进阶追问：为什么压测前要先做 Smoke Test（冒烟测试）？

  2. 问题（项目追问题）：你怎么输出一份可信的压测报告？

    • 考点：可复现和指标闭环。
    • 回答思路：报告要写清环境、机器规格、数据量、脚本、接口比例、QPS（每秒查询率）、TPS（每秒事务数）、P95（95 分位响应时间）、P99（99 分位响应时间）、错误率、资源指标、瓶颈和优化复测结果。
    • 进阶追问：压测环境和生产环境不一致时，结论怎么处理？

8. 扩容决策

8.1 服务扩容

服务扩容触发条件：

  • CPU（中央处理器）长期超过 70%。
  • P95（95 分位响应时间）和 P99（99 分位响应时间）持续升高。
  • 线程池 activeCount（活跃线程数）长期接近最大值。
  • 队列持续积压。
  • 错误率或超时率升高。

面试表达：

服务扩容前我会先确认瓶颈是不是服务本身。如果瓶颈在数据库或下游接口，盲目扩服务实例只会放大下游压力。

热门面试题

  1. 问题（基础题）：什么时候应该扩服务实例？

    • 考点：服务层瓶颈。
    • 回答思路：当 CPU（中央处理器）、RT（响应时间）、线程池队列、错误率等指标说明瓶颈在服务层，并且下游仍有余量时，可以水平扩服务实例。扩容前要确认不是数据库或第三方接口瓶颈。
    • 进阶追问：为什么扩服务可能导致数据库连接数暴涨？

  2. 问题（项目追问题）：活动流量突然上来，怎么快速止血？

    • 考点：应急手段。
    • 回答思路：先入口限流、降级非核心功能、临时扩实例、拉高缓存命中率、关闭重任务，再观察 P95（95 分位响应时间）、P99（99 分位响应时间）、错误率和 MQ（消息队列）积压。
    • 进阶追问：临时扩容后如何复盘？

8.2 数据库扩容

数据库扩容路径：

  1. SQL（结构化查询语言）和索引优化。
  2. 慢查询治理。
  3. 读写分离。
  4. 冷热分离和归档。
  5. 分区表。
  6. 分库分表。
  7. 数据迁移和双写校验。

面试表达：

我不会一上来就分库分表。先看慢 SQL（结构化查询语言）、索引、数据归档和读写分离。如果单表数据和写入 TPS（每秒事务数）确实超过单库能力，再设计分片键、扩容迁移、跨库查询和数据校验。

热门面试题

  1. 问题（基础题）：数据库扩容为什么不应该第一步就是分库分表？

    • 考点：复杂度和收益。
    • 回答思路：分库分表会带来分片键、跨库查询、分布式事务、迁移校验和运维复杂度。应先做索引、SQL（结构化查询语言）、归档、读写分离和缓存，确认单库能力不足后再拆。
    • 进阶追问：分库分表前需要做哪些预案？

  2. 问题（项目追问题）：库存扣减库写压力高怎么办？

    • 考点：热点写和正确性。
    • 回答思路：先确认是否热点 SKU（库存单位），可用 Redis（远程字典服务）预扣削峰、MySQL（关系型数据库）条件更新兜底、按库存维度拆分热点、异步同步库存事件，但不能牺牲不超卖正确性。
    • 进阶追问：库存扣减能不能只靠缓存？

8.3 Redis（远程字典服务）扩容

触发条件：

  • 内存使用率长期超过 70%-80%。
  • big key（大键）或 hot key（热键）明显。
  • 网络带宽接近上限。
  • 单实例 CPU（中央处理器）打高。
  • 主从同步延迟明显。

扩容方式：

  • 拆 key（键）和治理 big key（大键）。
  • 本地缓存 + Redis（远程字典服务）多级缓存。
  • Redis Cluster（Redis 集群）。
  • 读写分离。

热门面试题

  1. 问题（基础题）：Redis（远程字典服务）什么时候需要扩容？

    • 考点：内存、CPU（中央处理器）、网络和热点。
    • 回答思路：内存长期 70%-80% 以上、CPU（中央处理器）打高、网络带宽接近上限、big key（大键）或 hot key（热键）明显、主从延迟增加时都要评估扩容或治理。
    • 进阶追问：Redis Cluster（Redis 集群）扩容会带来什么风险？

  2. 问题（项目追问题）：缓存命中率下降会影响哪些指标？

    • 考点：缓存穿透到数据库。
    • 回答思路：会增加数据库 QPS（每秒查询率）、慢 SQL（结构化查询语言）、连接池等待和 P99（99 分位响应时间），严重时让核心链路从缓存瓶颈转成数据库瓶颈。
    • 进阶追问：如何监控缓存击穿和穿透？

8.4 MQ（消息队列）扩容

触发条件：

  • backlog（积压量）持续增长。
  • consumer lag（消费者延迟）持续升高。
  • 单 Partition（分区）热点。
  • Broker（代理节点）磁盘或网络打满。

扩容方式：

  • 增加 Consumer（消费者）实例。
  • 增加 Partition（分区）。
  • 拆 Topic（主题）。
  • 优化消费逻辑。
  • 批量消费和异步落库。

热门面试题

  1. 问题（基础题）：MQ（消息队列）积压时先扩 Partition（分区）还是 Consumer（消费者）？

    • 考点：并行度上限。
    • 回答思路：先看当前 Partition（分区）数量和 Consumer（消费者）数量。如果 Consumer（消费者）少于 Partition（分区），可以先扩 Consumer（消费者）；如果 Consumer（消费者）已经达到 Partition（分区）并行度上限，就要评估扩 Partition（分区）或拆 Topic（主题）。
    • 进阶追问：扩 Partition（分区）为什么可能影响消息顺序？

  2. 问题（项目追问题）：物流轨迹消费慢怎么优化？

    • 考点：消费逻辑和批处理。
    • 回答思路：先定位慢在解析、去重、状态机合并、数据库写入还是外部回调；优化可以做批量拉取、批量写入、幂等索引、异步补偿和消费者扩容。
    • 进阶追问：如何保证重复轨迹不会污染状态机？

9. 项目口述数据样例

下面是面试练习用的合理口径，回答时要说“类似系统里我会按这个口径做容量评估和压测”，不要说成未经确认的真实生产指标。

场景可口述样例
订单查询300-1000 QPS（每秒查询率），P95（95 分位响应时间）200ms（毫秒）以内
下单写入100-500 TPS（每秒事务数），P99（99 分位响应时间）1s（秒）以内
支付回调重点看成功率、幂等冲突数、回调延迟
物流轨迹更看 MQ（消息队列）吞吐、积压和消费延迟
IoT（物联网）报警更看峰值写入、聚合率、通知成功率
Java（编程语言）服务2C4G（2 核 CPU，4GB 内存）或 4C8G（4 核 CPU，8GB 内存）起步
核心服务实例数至少 2-3 个实例，避免单点
CPU（中央处理器）长期 60%-70% 以内更稳
数据库慢 SQL（结构化查询语言）超过 500ms（毫秒）告警
MQ（消息队列）积压超阈值告警并自动扩消费者

10. 面试口述模板

10.1 你们系统能扛多少并发？

我会先说明口径。并发不是只看在线用户数，而要看入口 QPS（每秒查询率）、核心 TPS（每秒事务数）和 P95（95 分位响应时间）/P99（99 分位响应时间）。类似订单系统里，我会先按日订单量、峰值占比和突增倍率估算容量，再通过压测验证单实例能力。比如单个 4C8G（4 核 CPU，8GB 内存）实例稳定处理 200 QPS（每秒查询率），目标峰值 600 QPS（每秒查询率），再乘以 1.5 冗余系数，大概需要 5 个实例。线上还要持续看 CPU（中央处理器）、线程池、连接池、数据库和 MQ（消息队列）积压，避免只扩服务不看下游瓶颈。

10.2 CPU（中央处理器）打满怎么办？

我会先区分是计算密集、锁竞争、GC（垃圾回收）、死循环还是 I/O（输入输出）等待。排查上先看监控，再用 top（进程监控命令）和 jstack（线程栈工具）定位热点线程，必要时用 Arthas（Java 诊断工具）或火焰图看热点方法。止血上可以限流、扩容、关闭非核心任务；根因上再优化算法、SQL（结构化查询语言）、线程池或锁竞争。

10.3 数据库扛不住怎么办？

我不会第一反应就是分库分表。先看慢 SQL（结构化查询语言）、索引、连接池、锁等待和 Buffer Pool（缓冲池）命中率。读压力高先考虑缓存和读写分离，历史数据多先归档和冷热分离，写压力确实超过单库能力再考虑分库分表。分库分表前必须设计分片键、全局 ID（标识）、跨库查询、迁移和校验。

11. 本模块复习清单

  • 能解释 QPS（每秒查询率）、TPS（每秒事务数）、并发数的区别。
  • 能解释平均 RT（响应时间）、P95（95 分位响应时间）、P99（99 分位响应时间）。
  • 能用业务量估算峰值 QPS（每秒查询率）和实例数。
  • 能说清 CPU（中央处理器）、内存、GC（垃圾回收）、线程池、连接池、队列指标。
  • 能说清 Docker（容器技术）和 Kubernetes（容器编排平台）的资源配置注意点。
  • 能区分冒烟测试、负载测试、压力测试、容量测试、稳定性测试。
  • 能说明服务、数据库、Redis（远程字典服务）、MQ（消息队列）什么时候扩容。
  • 能用一套合理但谨慎的技术数据进行面试口述。

12. 精通级分册入口与学习路线

根文档完整保留既有正文，作为兼容入口；本节只追加分册导航、事实边界、学习路线与复核统计，不以导航替换原有学习内容。原正文收口基线的 SHA-256（安全散列算法）为 b889fb91e4fb2d7a2e4a70c102107856d6e929e55d6481882cd1f239471abcec。

12.1 七篇分册与七张正式图

顺序分册入口主训练目标正式图
00稳定性口径、信号边界与迁移路线先定义用户结果、业务正确、技术健康与证据边界信号路线源图 / 渲染图
01SLI（服务等级指标）、SLO（服务等级目标）、错误预算与业务技术成功率固定分子、分母、未知态、错误预算与发布约束错误预算源图 / 渲染图
02容量、排队、Little’s Law（利特尔定律）与资源模型从业务量推导排队、资源、余量与容量边界容量排队源图 / 渲染图
03故障模型、RPO（恢复点目标）、RTO（恢复时间目标）与容灾恢复识别故障域、恢复点、恢复时间与业务验收故障恢复源图 / 渲染图
04压测、恢复与混沌演练方法设计可退出压测、故障注入与恢复验证压测演练源图 / 渲染图
05成本、容量治理、扩缩容、降级与预算把成本、弹性、降级与错误边界放进同一决策成本扩缩容源图 / 渲染图
06稳定性事故、项目口述、容量排障与综合题库用事故处置、项目表达和综合题检验完整闭环综合故障域源图 / 渲染图

七张正式图均由一份 PlantUML（统一建模语言）源文件和一张 PNG（便携式网络图形）渲染图组成；源文件与渲染图分别按 puml（PlantUML 源文件扩展名） 和 png（便携式网络图形扩展名） 统计。

12.2 事实边界、推荐顺序与快速复习

  • E0（待核对）：未找到源码、运行记录或原始业务凭证；只能说明待核对项和核对动作。
  • E1（源码与可复现证据）：可由源码、配置、脚本、原始事件或可复现实验直接核验的事实。
  • E2（已有材料映射）：来自既有简历、项目材料或已成稿模块的可追溯映射，不外推为新的线上结论。
  • E3（演练证据）：用于复算机制、容量、失败窗口或验收方法的假设输入与演练结果，不代表真实生产指标、SLA（服务等级协议）或项目收益。

推荐首次学习顺序为 00 -> 01 -> 02 -> 03 -> 04 -> 05 -> 06：先锁定结果口径与事实边界，再建立目标与预算、容量模型、恢复目标、演练方法和成本约束，最后用事故口述与综合题检验表达。快速复习时，先读本根“面试主线”和“核心稳定性指标”恢复框架，再读 00 分册 的边界、02 分册 的容量推导、03 分册 的恢复验收，最后用 06 分册 完成口述演练。

12.3 分册统计与复核口径

统计范围仅为 53-架构稳定性指标与容量评估/ 下的 00-06 七篇 Markdown（标记语言）分册，不含本根兼容正文。知识标记按既有 HTML（超文本标记语言）注释计数；六字段章节题要求“问题、考点、回答思路、详细答案、进阶追问、进阶回答”六个字段在同一知识题块各恰好一次；口述答案按相应字段计数。Mermaid（图表语法）按围栏计数，时序图按围栏内 sequenceDiagram（时序图声明） 计数；标准表按表头紧随 Markdown（标记语言）分隔行计数；数据演绎按 E3（演练证据）演绎标题计数；正式图资源按目录内非空 PlantUML（统一建模语言）源文件与 PNG（便携式网络图形）渲染图计数。

分册知识标记六字段章节题口述答案Mermaid（图表语法）/时序图标准表E3（演练证据）数据演绎PlantUML（统一建模语言）/PNG（便携式网络图形）
0082409 / 41081 / 1
0113392613 / 1013131 / 1
0213392613 / 1013131 / 1
0313392613 / 1013131 / 1
0412362012 / 1012121 / 1
0512362012 / 812121 / 1
0612364512 / 1112121 / 1
合计8324916384 / 6385837 / 7

复核结果：interview_kb_audit（面试知识库审计工具） 对本模块全部 Markdown（标记语言）文件审计为 0 个问题；固定 mmdc（Mermaid 命令行工具） 11.4.2 已对七篇分册的 84 张 Mermaid（图表语法）图和根正文的 1 张 Mermaid（图表语法）图真实渲染通过，共 85 / 85，输出均非空；7 组 PlantUML（统一建模语言）源文件与 PNG（便携式网络图形）渲染图均已核验非空。