第3章 交易系统性能调优核心概念：延迟、吞吐量、QPS、TP99、性能指标、公司侧重点
性能调优面试的第一个高频考题，就是让你讲清楚延迟、吞吐量、QPS、TP99 这些基础但容易混淆的概念。面试官不仅考察你是否理解定义，更关注你是否能在真实交易场景中说出它们的权衡关系、业务含义以及公司的选择逻辑。
回答这类问题时，采用 "定义先行 → 业务关联 → 权衡分析 → 优化策略 → 公司实践" 的五步框架，可以帮助你系统化表达，从基础概念延伸到实战经验，让面试官看到你的深度思考。本章围绕这五个核心指标，拆解面试问答逻辑，并提供可迁移的项目案例模板。
核心指标对比速查表
| 指标 | 定义 | 衡量方式 | 交易系统关注点 | 典型优化方向 |
|---|---|---|---|---|
| 延迟 | 请求到响应的总耗时 | avg / max / p99 | 用户体验、交易时效性 | 减少IO、优化算法、缓存 |
| 吞吐量 | 单位时间处理交易数 | TPS / QPS | 系统容量、扩展性 | 并行处理、水平扩展 |
| QPS | 每秒查询/请求数 | 总请求数 / 时间 | 并发能力、峰值处理 | 限流、异步、缓存 |
| TP99 | 99%请求的延迟上限 | 排序后第99百分位 | 长尾延迟、稳定性 | 资源隔离、预加载、熔断 |
面试问题：请解释延迟、吞吐量、QPS、TP99 这几个核心性能指标，并说明它们之间的关系。
面试官考察点：基础概念清晰度、指标间逻辑关系理解、能否用交易场景举例
回答框架：定义先行 → 关系描述 → 业务举例 → 权衡说明
示例回答：延迟是单笔交易响应时间，吞吐量是单位时间处理能力，QPS 是每秒请求数，TP99 是 99% 请求的延迟上限。四者相互制约：降低延迟通常以牺牲吞吐量为代价。在交易系统中，证券场景优先低延迟，电商秒杀优先高吞吐，需根据业务平衡。
可能追问：如果 TP99 突然升高，你会如何排查？
避坑提醒：不要只背定义，一定要结合交易场景说明指标间的权衡关系，否则面试官会觉得你缺乏实战视角。
面试问题：在交易系统中，你认为哪个性能指标最重要？为什么？
面试官考察点：业务理解深度、指标优先级判断、场景化思维、是否了解目标公司业务
回答框架：场景区分 → 指标选择 → 原因阐述 → 公司实践
示例回答：取决于业务场景。证券交易系统延迟最重要，毫秒级延迟可能导致巨大损失；电商秒杀系统吞吐量最关键，需支撑万级 QPS。支付系统更关注 TP99 和成功率。面试时建议结合目标公司业务说明，体现场景化思维。
可能追问：如果让你优化一个交易系统的延迟，你会从哪些方面入手？
避坑提醒：不要只给出单一答案，要区分场景说明，否则显得缺乏业务深度。“延迟最重要” 在证券场景正确，在电商场景可能扣分。
面试问题：你们公司是如何衡量交易系统性能的？重点关注意哪些指标？
面试官考察点：实战经验、指标体系设计能力、监控意识、是否经历过真实调优
回答框架：指标分层 → 监控工具 → 告警阈值 → 优化案例
示例回答：我们采用分层指标体系：业务层关注 QPS 和成功率，应用层关注 TP99 和平均延迟，系统层关注 CPU 和内存。使用 Prometheus + Grafana 监控，TP99 超 100ms 触发告警。曾通过优化 SQL 索引将 TP99 从 200ms 降至 50ms，吞吐量提升 40%。
可能追问：你们的告警阈值是如何设定的？有没有出现过误告警？
避坑提醒：不要只说指标名称，要说出具体数值、工具和优化案例，体现真实项目经验。泛泛而谈会被认定为缺乏实战。