过去经历中怎么应对高并发或高性能场景的？｜阿里巴巴后端开发面经解析

60 秒回答模板

可以按“背景和目标 -> 容量评估 -> 压测验证 -> 瓶颈定位 -> 分层优化 -> 稳定性保障 -> 结果复盘”的结构回答。先说明业务场景、峰值流量、核心链路、SLA、读写比例、数据量级和不可接受的失败类型；再说明如何估算容量，例如峰值 QPS、并发连接数、RT、CPU、内存、数据库连接数、缓存容量、消息堆积水位；然后说明压测方式，包括单接口压测、链路压测、影子流量、阶梯加压、稳定性压测和容量水位判断；接着说明如何通过监控、日志、链路追踪、火焰图、慢 SQL、GC 日志、线程栈、连接池指标定位瓶颈；最后讲优化动作和验证结果，例如缓存命中率提升、数据库压力下降、队列削峰后写入更平滑、线程池拒绝减少、P99 延迟下降、故障恢复时间缩短。不要编造项目背景、QPS、延迟或故障数据，真实经历不足时可以用方法论表达。

考点 先定义问题边界

主线 压测验证容量

易错点 只罗列缓存、MQ、分库分表等名词，没有结合具体场景说明…

深入解析

先定义问题边界

高并发不是简单说加机器或加缓存，需要先把问题边界定义清楚：核心接口是什么、峰值流量来自哪里、读多还是写多、是否有突发流量、是否要求强一致、是否允许异步、可接受的降级策略是什么。容量评估至少要看 QPS、并发用户数、平均响应时间、P95/P99、错误率、CPU、内存、网络带宽、磁盘 IO、数据库连接数、缓存内存、消息队列积压和下游依赖容量。

压测验证容量

合理做法是先建立基线，再逐步加压，观察系统从健康到抖动再到不可用的拐点。压测不能只压单接口，还要覆盖完整链路、真实参数分布、热点数据、缓存命中和未命中场景、读写混合比例、下游依赖延迟。阶梯压测用于找到瓶颈点，稳定性压测用于验证长时间运行是否有内存泄漏、连接泄漏、GC 抖动和消息堆积，突刺压测用于验证限流、熔断、队列削峰和扩容是否有效。

端到端瓶颈定位

高性能问题通常不是单点造成的，需要按入口层、应用层、缓存层、消息层、数据库层、外部依赖逐层定位。入口层看网关限流、连接数、TLS、负载均衡是否均匀；应用层看线程池是否打满、锁竞争是否严重、对象分配和 GC 是否异常；缓存层看命中率、热点 key、穿透、击穿、雪崩；数据库层看慢 SQL、索引、事务、锁等待、连接池和主从延迟。

流量治理

面对突发高并发，入口处要有限流、熔断、降级和排队能力。限流可以按用户、接口、租户、IP、业务维度做令牌桶或漏桶控制；熔断用于保护慢下游，避免线程被拖死；降级用于牺牲非核心功能，保住核心交易或查询链路；队列削峰用于把瞬时写入转成平滑消费，但必须配套幂等、重试、死信、积压告警和消费扩容。

缓存治理

缓存适合读多写少、热点明显、可接受短暂不一致的场景。常见策略包括本地缓存、分布式缓存、多级缓存、预热、异步刷新、过期时间随机化、热点 key 拆分、互斥重建、空值缓存和布隆过滤器。热点 key 可能打爆缓存分片或应用本地锁，缓存击穿会造成大量请求回源，缓存雪崩会让大批 key 同时失效，缓存穿透会让不存在的数据持续打到数据库。

数据库优化

数据库优化不是只加索引。先看访问模式：是否存在全表扫描、低选择性索引、分页过深、事务过大、批量写入不合理、热点行更新、锁等待、N+1 查询和连接池耗尽。优化手段包括建立合适联合索引、改写 SQL、减少返回列、批量写入、读写分离、分库分表、冷热数据拆分、归档历史数据、用缓存承接高频读、用消息队列异步化高频写。

运行时资源

应用层常见问题包括线程池过大导致上下文切换、线程池过小导致排队、无界队列导致内存风险、拒绝策略不合理导致故障放大、数据库连接池过大压垮数据库、连接池过小拖慢请求、HTTP 客户端超时缺失导致线程长期阻塞。锁竞争方面，要避免大范围 synchronized、长事务内加锁、热点对象锁和缓存重建时的全局锁。

扩展与热点

水平扩展的前提是服务尽量无状态，状态放到缓存、数据库、对象存储或专门的会话系统中。扩容时要关注负载均衡是否均匀、实例启动预热、缓存预热、连接池预热、限流阈值是否随实例数变化、下游容量是否同步扩展。对于热点数据，单纯加应用机器不一定有效，因为热点可能集中在缓存分片、数据库行、消息分区或某个下游资源上。

可观测性和预案

高并发治理不能只靠上线前压测，还要有运行时可观测性和稳定性预案。关键监控包括 QPS、RT、P95/P99、错误率、限流量、熔断量、降级量、线程池活跃数、队列长度、连接池使用率、缓存命中率、热点 key、数据库慢 SQL、锁等待、消息堆积、GC、CPU、内存、网络和磁盘。预案包括容量水位告警、扩容脚本、开关降级、灰度发布、回滚方案和故障演练。

易错点

只罗列缓存、MQ、分库分表等名词，没有结合具体场景说明为什么需要这些手段。
直接说加机器，没有分析瓶颈是否在应用层、缓存层、数据库层或下游依赖。
没有容量评估和压测数据，导致回答缺乏可信度。
把队列削峰说成万能方案，忽略幂等、积压、延迟、死信和补偿。
只讲性能优化，不讲限流、熔断、降级、回滚和故障预案。
只关注平均响应时间，忽略 P95、P99、错误率和长尾延迟。
随意调大线程池或连接池，不说明下游承载能力和拒绝策略。

面试官追问

如果从零设计一个高并发接口，第一步做什么？

第一步不是写代码，而是明确业务目标和约束，包括峰值 QPS、延迟目标、读写比例、一致性要求、失败容忍度、下游依赖容量和数据增长预期，再决定是否需要缓存、异步化、分库分表、限流降级和水平扩展。

如何判断系统瓶颈在应用还是数据库？

可以从链路耗时拆分、应用线程池指标、数据库连接池使用率、慢 SQL、数据库 CPU、锁等待、连接等待和执行计划综合判断。应用线程大量阻塞在连接或 SQL 上，数据库大概率是瓶颈；数据库压力不高但应用 CPU、GC、锁等待明显，则应用侧问题更大。

缓存击穿、穿透、雪崩分别怎么处理？

击穿是热点 key 失效后大量请求回源，可用互斥重建、逻辑过期、热点预热处理。穿透是查询不存在的数据打到数据库，可用空值缓存、参数校验、布隆过滤器处理。雪崩是大量 key 同时失效或缓存集群不可用，可用过期时间随机化、多级缓存、限流降级和缓存高可用处理。

消息队列削峰有什么风险？

主要风险是延迟增加、消息积压、重复消费、乱序、丢消息、重试风暴和最终一致性问题。需要用幂等键、事务边界设计、消费限速、死信队列、积压告警、补偿任务和可回放机制保证可靠性。

如何证明优化真的有效？

要用优化前后的对比指标证明，包括峰值 QPS、P95/P99 延迟、错误率、CPU、内存、GC、数据库 QPS、慢 SQL 数量、缓存命中率、消息积压、线程池拒绝数和连接池等待时间，并说明压测模型或线上观测窗口。