微服务容量规划面试题：QPS、RT、P95/P99、压测、瓶颈与扩缩容
本页只放面试标准回答、追问点和知识点跳转。完整原理、流程图、Demo 和生产 Runbook 见容量规划主线。
高频问题
| 面试题 | 标准回答 | 原理知识点 |
|---|---|---|
| 微服务容量规划怎么做 | 先明确业务峰值、SLO、成功率和错误预算；再画出完整调用链，拆 Gateway、应用线程池、HTTP连接池、Redis、MySQL、MQ、第三方依赖的容量预算。压测时找单实例安全吞吐和P99拐点，生产容量要乘安全系数并考虑N-1冗余、发布下线、冷启动和共享下游瓶颈。 | 从SLO推导容量、容量曲线 |
| QPS、TPS、RPS有什么区别 | QPS通常描述每秒查询或请求数；TPS更偏完整业务事务，例如下单、支付、入库；RPS是HTTP层每秒请求数。容量评估不能只看数字，要看一次请求背后调用了哪些下游、是否写库、是否发MQ、是否有锁和热点。 | 核心指标 |
| RT、P95、P99是什么 | RT是响应时间；P95表示95%的请求耗时不超过该值；P99表示99%的请求耗时不超过该值。平均RT会掩盖尾部慢请求，微服务链路会放大P99，因此容量拐点通常先体现在P95/P99升高，而不是平均值或错误率。 | RT与P95/P99 |
| 为什么QPS不高线程池也会满 | 因为并发等于到达率乘以平均停留时间。QPS不高但下游很慢，请求会长时间占住线程、连接和队列，in-flight持续增加，最终线程池满、连接池等待、超时和重试一起出现。 | Little定律、JDK 8 Demo |
| 压测结果怎样转成生产容量 | 不能用最大QPS当生产容量。应找P99开始恶化前的单实例安全吞吐，再乘实例数、安全系数和N-1冗余，并扣除发布、故障、冷启动和下游共享瓶颈影响。压测报告必须说明数据量、热点分布、缓存命中率、依赖真实性和错误率。 | 容量曲线、压测边界 |
| 为什么扩容应用实例后RT不降 | 说明瓶颈可能不在应用CPU，而在MySQL锁、慢SQL、Redis热Key、MQ分区、HTTP连接池、第三方配额、长连接复用或重试风暴。应按实例QPS、P99、线程池、连接池、下游指标和Trace逐层确认，而不是继续盲目扩容。 | 为什么扩容不一定有效、扩容后RT不降 |
| 消费者扩容后Lag短暂下降又堆积是什么原因 | 常见原因是分区或队列数限制了并行度，单条消息处理慢，下游数据库写入慢，毒消息反复重试，生产速度仍大于消费速度，或者扩容后把DB/Redis打成新瓶颈。扩消费者前要看Lag分布、分区数、单分区吞吐和下游容量。 | MQ消费预算、消息堆积 |
| HPA为什么不是万能的 | HPA常按CPU扩容，但微服务可能阻塞在DB、Redis、第三方、锁或连接池，CPU并不高。扩容还存在镜像拉取、JIT、缓存预热、注册中心传播和连接预热窗口，缩容还要优雅下线。生产更应结合P99、in-flight、队列长度、连接等待和Lag等指标。 | HPA和自动扩缩容 |
| 为什么压测没问题上线崩了 | 多半是压测环境与生产不一致：数据量太小、热点不真实、依赖被Mock、缓存命中率过高、日志和Trace采样不同、没有考虑滚动发布少实例、没有计入重试放大和第三方配额。 | 压测没问题上线崩了 |
| 容量规划要监控哪些指标 | 入口看QPS、P95/P99、错误率；应用看线程池active/queue/reject、GC、CPU、内存；调用看连接池等待、超时、重试；DB看慢SQL、锁等待、连接数；Redis看热Key、大Key、命中率；MQ看Lag分布、消费速率、重试和死信。 | 容量预算拆分、生产Runbook |
场景题
1. 线上QPS不高，但接口大量超时，怎么排查
标准回答：
我会先看入口QPS、Avg RT、P95、P99和错误率，确认是不是低QPS慢请求。然后看Tomcat或业务线程池active、queue、reject，再抓线程栈确认线程在等数据库、Redis、HTTP下游、锁还是本地CPU。接着看HTTP连接池pending、DB连接池active、慢SQL、锁等待、Redis热Key和下游P99。若发现弱依赖拖慢核心链路，先短超时降级；强依赖则限流保护并按幂等和状态查询处理超时未知。
原理入口：Little定律、QPS不高但线程池满。
2. 活动前让你评估订单服务能承载多少QPS，你怎么做
标准回答：
我不会直接看当前机器CPU然后估。先明确活动峰值、下单P99和成功率目标；再梳理下单链路，包括Gateway、订单服务、库存、优惠、支付预创建、MySQL事务、Redis和MQ。压测时先测单实例，在P99恶化前取安全吞吐，再乘实例数、安全系数和N-1冗余，同时取下游最小容量作为上限。最后按真实热点SKU、真实库存锁冲突、真实缓存命中率和真实消息发送验证，并准备限流、降级、回滚和对账预案。
3. 消费堆积后加消费者，刚开始有效，过一会又堆积，怎么解释
标准回答：
说明消费者数量可能不是最终瓶颈。短时间有效可能是空闲分区被接管或缓存预热，但后续生产速度仍大于消费速度，或者下游数据库、Redis、ES、第三方接口成为新瓶颈。Kafka还要看分区数，消费者数超过分区数不会继续提升并行度；如果存在毒消息反复重试，也会让Lag恢复增长。排查要看Lag分布、每分区消费速率、单条处理耗时、重试次数、死信、DB写入TPS和锁等待。
4. HPA扩容了，但用户还是慢，怎么回答
标准回答：
HPA创建Pod不等于容量立即生效。新Pod要经历镜像拉取、启动、JIT、类加载、缓存和连接池预热、Readiness、注册中心或Endpoint传播、调用方本地快照刷新和连接池重新分布。如果瓶颈在数据库、Redis热Key、MQ分区或第三方配额，扩Pod也不会降低RT。排查要看每实例QPS是否分摊、P99是否下降、连接是否连到新实例、下游是否成为瓶颈，以及是否存在冷启动和缩容抖动。
面试回答模板
容量规划我会从业务SLO出发，而不是直接加机器。先明确峰值QPS、P99、成功率和错误预算，再画出完整调用链，把Gateway、应用线程池、HTTP连接池、Redis、MySQL、MQ和第三方配额逐层拆开。压测时找P99恶化前的单实例安全吞吐，并考虑安全系数、N-1冗余、滚动发布、冷启动和共享下游瓶颈。上线后通过Trace、P95/P99、线程池、连接池、慢SQL、Redis热Key、MQ Lag和重试次数持续校准容量。如果扩容无效，我会先判断瓶颈是不是在共享下游、连接池、分区、热点或重试风暴，而不是继续盲目加实例。本章小结
容量规划面试不能只说“压测一下”和“加机器”。好的回答必须讲清 QPS、RT、P95/P99、Little 定律、容量拐点、安全系数、N-1冗余、下游共享瓶颈、自动扩缩容窗口和生产排查证据。