面试记录 2026-10-08
题目：单机压测到 300QPS，10 台就能抗住 3000QPS 吗？
难度：medium
标签：arch/high-availability, architecture/high-availability, difficulty/medium
评分：⭐⭐⭐☆☆（3/5）
我的回答
Q7 是 300QPS 单台机的话，它是自身的压力上限。但是 10 台进行分布的时候，你并不能保证每一台都分配到 300，有可能一台分配到 600，其他台其他几台分配到其他的，会出现分配不均的问题。所以并不能完全信任 10 台就能扛住 3000，需要有一定的富余保留，一般在 30%、20%~30% 这样，做一个富余保留，确保机器能扛得住压力。另外在前侧做负载均衡的时候，尽可能的选择更合理的分配算法。不要，尽量不要选择完全随机的。可能选择压力低的去进行分配，或者是轮询，或者是高性能的机器选择权重轮询，有些高性能的分多点，有些低性能的分少点。但是你无法完全的保证每台的压力都是均分的，QPS 没有那么稳定。
点评
优点：核心结论"不能完全信任、需要富余"抓准；说出流量倾斜问题（一台 600、其他少）；提到负载均衡算法（轮询/加权/最小压力）；有容量冗余意识（20-30% 富余）。
不足：未提长尾流量与突发（3000 不是稳态峰值，可能是毛刺）；未提依赖资源瓶颈（DB/缓存/第三方接口可能先挂）；未提容量规划方法论（压测 → 峰值 → 水位 → 冗余）；未量化 30% 富余背后的原因（GC/抖动/长尾请求/慢查询）；未提限流降级兜底；未提水平扩展的隐性成本（一致性、锁、状态同步）。
补充：容量规划黄金公式——真实需求 = 峰值 QPS × (1 + 冗余系数) ÷ 单机稳态 QPS；一般预留 50% 冗余（非 20-30%）；负载均衡策略对比：RR/加权 RR/IP Hash/一致性 Hash/最少连接/响应时间权重。
完整讲解
第一部分：知识重点剖析
核心考点定位：考察容量规划的量化思维——不是"能不能扛"，而是"凭什么说能扛"。
知识点拆解：
- 单机 300 QPS 是"压测上限"，不是"稳态容量"：
- 压测上限是极限水位（如 CPU 95%、GC 频繁），不能作为规划基准
- 稳态水位应该是CPU 50-60%（如 150 QPS），预留响应抖动、GC、慢请求的时间
- 流量倾斜问题（用户提到，正确）：
- 长尾请求：P99/P999 请求耗时可能是 P50 的 100 倍，长尾会让某台机器先被打爆
- 热点数据：某些 key/用户/商品会被集中访问，即使 RR 也无法均分
- 连接粘性：Session/HTTP Keep-Alive 会导致连接倾斜
- 依赖资源瓶颈（用户遗漏）：
- 数据库：连接池、CPU、锁、I/O——DB 单点通常比应用层先崩
- 缓存：Redis 单分片 QPS 上限、内存限制
- 下游接口：第三方 API、消息队列、RPC 服务的容量
- 网络：带宽、TCP 连接数、NAT 表
- 容量规划黄金公式：
机器数 = (峰值 QPS × 冗余系数) ÷ 单机稳态 QPS- 冗余系数：一般 1.5-2（预留 50-100%），用户说的 20-30% 偏低
- 举例：300 QPS 压测上限 → 稳态 150 QPS → 3000 峰值 × 1.5 = 4500 → 需 4500/150 = 30 台，不是 10 台
- 负载均衡策略对比：
| 策略 | 特点 | 适用场景 |
|---|
| 轮询 RR | 均分、简单 | 机器同质 |
| 加权 RR | 按性能权重 | 机器异构 |
| IP Hash | 同 IP 固定机器 | 需要会话保持 |
| 一致性 Hash | 扩缩容只影响小部分 | 缓存集群 |
| 最少连接 | 按实时负载分配 | 请求耗时不均 |
| 响应时间权重 | 按历史响应时间 | 智能调度 |
- 限流降级兜底（用户遗漏）：
- 限流：Sentinel/RateLimiter 单机限流、网关限流、Redis 全局限流
- 降级：核心接口兜底、非核心接口跳过、缓存兜底、静态兜底
- 熔断：Hystrix/Resilience4j，下游慢就熔断
按「稳态 vs 上限 → 流量倾斜 → 依赖瓶颈 → 容量公式 → 兜底策略」递进。
第二部分：考察方向与延伸递进
考察方向：
- 深度：能否量化"稳态水位"和"冗余系数"，说出容量规划公式
- 广度：理解长尾流量、依赖瓶颈、限流降级等隐性风险
- 应用：真实项目中的容量规划流程——压测 → 峰值预估 → 冗余计算 → 灰度验证
延伸递进面试题：
- 3000 QPS 的峰值是怎么预估的？如果预估错了怎么办？
- 解答要点：历史数据 × 业务增长 × 大促倍数；灰度压测验证；预案兜底（限流降级）；分场景预案（正常/大促/异常）
- 单机 300 QPS 的压测是稳态压测还是极限压测？如何判定？
- 解答要点：极限压测看 CPU 95%、GC 频繁、响应时间暴涨；稳态压测要求 CPU 50-60%、P99 稳定；生产规划用稳态水位
- 如果 10 台机器扛不住 3000 QPS，除了加机器还有什么方案？
- 解答要点：读缓存、写异步、异步化、批处理、限流降级、扩容依赖（DB 分库分表）、算法优化、静态化/CDN
第三部分：面试者参考回答（300-600 字口语化）
面试官您好，我的结论是：10 台扛 3000 QPS 风险很大，不能直接上线，需要按容量规划公式重新算。
第一，单机 300 QPS 是压测上限，不是稳态容量。压测上限是 CPU 95%、GC 频繁、响应时间暴涨时的极限水位，不能作为规划基准。稳态水位应该是 CPU 50-60%，也就是单机实际能稳态跑 150 QPS 左右。
第二，流量倾斜是真实存在的。
- 长尾请求：P99 耗时可能是 P50 的 100 倍，长尾请求会让某台机器先被打爆；
- 热点数据：某些 key/用户会被集中访问，即使 RR 也无法均分；
- 连接粘性：Session/Keep-Alive 会导致连接倾斜；
- 所以即使 10 台 RR 分配，也可能出现你说的"一台 600、其他少"的情况。
第三，容量规划黄金公式：机器数 = (峰值 QPS × 冗余系数) ÷ 单机稳态 QPS。
- 冗余系数一般 1.5-2（预留 50-100%），你说的 20-30% 偏低；
- 按稳态 150 QPS 算：3000 × 1.5 ÷ 150 = 30 台，不是 10 台；
- 冗余是为了应对 GC 抖动、长尾请求、慢查询、依赖资源抖动等。
第四，依赖资源瓶颈常常先挂。
- DB：连接池、CPU、锁、I/O——DB 单点通常比应用层先崩；
- 缓存：Redis 单分片 QPS 上限；
- 下游接口：第三方 API、消息队列容量；
- 网络：带宽、TCP 连接数；
- 需要一起评估，不能只看应用层。
第五，负载均衡策略选择（我举的点）：
- RR/加权 RR：机器同/异构时均分；
- 一致性 Hash：扩缩容友好；
- 最少连接：请求耗时不均时最好；
- 响应时间权重：智能调度。
第六，限流降级兜底：
- 限流：Sentinel 单机 + 网关全局 + Redis 全局限流；
- 降级：非核心接口跳过、缓存兜底、静态兜底；
- 熔断：Resilience4j 熔断下游慢调用。
总结：容量规划是"稳态水位 × 冗余系数"，不是"压测上限 × 机器数"。生产实践是压测 → 峰值预估 → 冗余计算 → 灰度验证 → 限流降级兜底五步走，没有兜底就上线是拿业务冒险。