第2章 高频面试问题与回答框架：常见问题、答题结构、公司侧重点
本章聚焦交易系统容量规划面试中最常见的高频问题，帮你建立从「问题拆解 → 框架组织 → 量化表达」的完整回答链路。面试中，同样的问题在不同公司有不同的考察侧重——字节看重微服务场景下的实时容量决策，阿里关注大促弹性与成本，腾讯强调稳定与容灾，美团则聚焦峰值全链路压测。掌握通用框架 + 公司偏好，才能精准命中面试官期待。
大厂面试侧重点对比
| 公司 | 面试侧重点 | 典型场景 | 核心关注指标 |
|---|---|---|---|
| 字节跳动 | 高并发微服务容量决策 | 抖音电商、直播带货 | QPS、延迟治理、服务限流 |
| 阿里巴巴 | 大促弹性与成本优化 | 双11、618大促 | TPS、资源利用率、扩容成本 |
| 腾讯 | 系统稳定与容灾多活 | 微信支付、游戏交易 | 可用性（SLA）、RTO、RPO |
| 美团 | 峰值应对与全链路压测 | 外卖秒杀、到店团购 | 峰值吞吐、成功率、熔断阈值 |
容量规划面试回答框架
面对任何容量规划问题，都可以使用以下五步框架组织回答。这套框架能帮你在1-2分钟内展现结构化思维，避免跳跃和遗漏。
📌 面试问题 1
请分享一次你主导的系统容量规划经历，具体是怎么做的？
- 是否具备真实的容量规划实战经验，还是只会背理论
- 能否用数据驱动的方式展示容量评估和决策过程
- 方案设计是否考虑成本、稳定性和可扩展性
- Situation（背景）：什么业务？什么峰值场景？系统规模多大？
- Task（任务）：容量规划的目标是什么？保障多少QPS/TPS？
- Action（行动）：压测获取单机上限 → 分析瓶颈 → 设计扩容/优化方案 → 灰度验证
- Result（结果）：量化结果（如：支撑了3倍流量，成本仅增加40%）
- 反思：遇到了什么意外？如何改进？
在618大促前，我通过全链路压测发现核心订单系统单机TPS上限为2000。基于历史峰值1.5倍冗余原则，设计水平扩展方案，将集群从8节点扩容至14节点，同时优化缓存命中率至95%以上。最终系统平稳支撑了峰值3.2万TPS，成本仅增加75%。
- 压测数据与实际流量有偏差怎么办？你如何校准？
- 扩容节点数量有计算公式吗？为什么是14台而不是12台？
- 如果扩容后性能提升不如预期，你的排查思路是什么？
不要只讲理论没有数据。 面试官期待听到具体的QPS/TPS数值、节点数、资源利用率等量化信息。脱离数据的容量规划 = 空谈。
不要忽略业务场景。 同样都是扩容，电商大促和实时交易清算的容量规划思路截然不同。
面试官追问路径图
容量规划面试中，面试官常沿着以下四个方向层层追问，用来检验你的思考深度和应变能力。提前预判追问，就能在面试中掌握节奏。
📌 面试问题 2
如何对一个未知系统进行容量评估？
- 面对陌生系统时的方法论和系统性思维
- 是否具备从链路梳理到瓶颈定位的完整分析能力
- 在缺乏数据的情况下如何做合理假设和估算
- 链路梳理：画出系统调用链路，识别核心节点与依赖服务
- 数据采集：收集监控数据、日志、配置信息，关注CPU/内存/IO/网络
- 瓶颈定位：逐层分析资源消耗，找到最先达到上限的节点
- 容量预估：单机上限 × 扩展系数 × 冗余因子，输出区间而非点值
- 方案输出：扩容计划 + 优化建议 + 风险预案
首先梳理调用链路，发现核心瓶颈在数据库主库。通过监控获取当前主库CPU峰值75%，QPS 8000。结合硬件规格推算单机上限约1.2万QPS。按1.5倍冗余系数，建议在QPS达到1万前完成读写分离+缓存优化，预估可支撑至3万QPS。
- 如果系统完全没有任何监控数据，你怎么做容量评估？
- 第三方依赖（如外部API）的容量如何评估？
- 你给出的容量预估置信度有多高？误差范围是多少？
不要一上来就说「压测」。 面试官想先听你的分析思路，而不是直接跳到工具层面。先讲链路梳理和瓶颈定位，再讲压测验证。
避免给出数值。 容量预估是一个区间，使用「约」「预计」「范围在X到Y之间」这样的表述更专业。
📌 面试问题 3
交易系统的容量规划与普通系统有什么不同？
- 对交易系统领域知识的理解深度（一致性、可用性、事务）
- 能否识别出交易系统独有的容量瓶颈
- 是否具备保障核心交易链路的容灾和降级意识
- 特性对比：交易系统强一致、高可用、低延迟，不同于普通系统可接受最终一致
- 核心瓶颈：数据库主库写入瓶颈、热点账户并发、分布式事务性能损耗