有考虑过什么情况下服务器压力会过大？｜阿里巴巴前端面经解析

60 秒回答模板

我会把服务器压力过大理解为系统资源或依赖链路已经无法支撑当前请求量和请求复杂度，表现为响应时间升高、错误率增加、队列堆积、CPU 或内存飙升、数据库连接打满、下游调用超时等。具体场景包括：第一，流量层面，QPS、并发连接数或请求体积突然变大，比如活动、热点事件、爬虫、批量任务集中触发；第二，应用层面，CPU 密集逻辑、序列化、加解密、压缩、复杂计算、GC 频繁、线程池排队都会让服务处理能力下降；第三，存储层面，数据库慢查询、缺索引、大事务、行锁表锁、连接池耗尽、缓存击穿或缓存雪崩都会把压力集中到后端；第四，系统层面，磁盘 IO、网络带宽、文件句柄、端口、内核 backlog 等资源也可能成为瓶颈；第五，依赖层面，下游接口变慢会导致本服务线程被占用，叠加超时和重试后可能形成级联故障。治理上要先通过监控确认瓶颈，看 QPS、并发、p95/p99 延迟、错误率、CPU、内存、GC、线程池队列、连接池、数据库慢查询、缓存命中率和下游耗时；然后做限流、熔断、降级、超时控制、重试收敛、缓存隔离、异步削峰、队列缓冲和热点保护；长期则通过压测评估容量、优化慢路径、拆分服务、读写分离、分库分表、水平扩容和自动扩缩容来提升系统容量。

考点 压力过大的本质

主线 流量与并发压力

易错点 只回答“访问量太大”，没有展开 CPU、内存、IO、数…

深入解析

压力过大的本质

服务器压力过大不是单纯指机器 CPU 高，而是请求进入系统后，处理速度小于到达速度，导致排队、超时、错误和资源耗尽。一个服务即使 CPU 不高，也可能因为数据库连接池打满、下游接口阻塞、线程池队列堆积而无法响应。判断压力是否过大，要结合服务目标来看：比如 p99 延迟是否超出 SLA，错误率是否上升，队列等待是否持续增加，吞吐是否不再随流量增加而增加。

流量与并发压力

最直接的场景是 QPS 或并发连接数超过系统容量，例如促销活动、热点新闻、推送召回、爬虫扫描、恶意流量、客户端重试风暴。流量压力不只看请求数量，还要看请求分布和请求成本：少量高复杂度请求可能比大量简单请求更危险；热点用户、热点商品、热点接口会让压力集中在少数应用实例、缓存 key 或数据库行上。突发峰值尤其危险，因为服务来不及预热，缓存未命中、连接未建立、自动扩容尚未完成时，很容易出现瞬时雪崩。

CPU 瓶颈

CPU 压力通常来自计算密集型逻辑或应用层开销，例如复杂排序、聚合计算、正则回溯、JSON 序列化和反序列化、压缩解压、加解密、图片处理、日志格式化、模板渲染等。CPU 打满后，线程虽然还在运行，但单位时间能处理的请求下降，请求排队时间增加，最终表现为整体延迟上升。还要关注上下文切换和锁竞争，如果线程过多、阻塞唤醒频繁，即使业务计算不复杂，也可能被调度开销拖垮。

内存与 GC 压力

内存压力常见于对象创建过多、大对象堆积、本地缓存无限增长、请求体过大、批量查询一次性加载太多数据、连接或文件句柄泄漏。对于有 GC 的运行时，内存接近阈值后会出现频繁 GC 或长时间停顿，服务吞吐下降，延迟尖刺明显。更严重时会触发 OOM、进程重启或操作系统 swap，导致服务抖动甚至实例被摘除。治理上需要限制单请求数据量、控制缓存大小、排查泄漏、减少临时对象、设置合理堆大小，并用内存水位监控提前发现趋势。

IO 与网络压力

磁盘 IO 压力可能来自大量日志写入、同步落盘、频繁读写本地文件、数据库或消息队列所在磁盘繁忙。网络压力则包括带宽打满、包量过高、连接数过多、TIME_WAIT 堆积、文件描述符不足、请求或响应体过大。IO 瓶颈的特点是 CPU 可能不高，但请求大量处于等待状态，延迟持续升高。排查时要看磁盘利用率、IO wait、网络吞吐、连接状态、丢包重传、句柄数和内核队列。

数据库压力

数据库通常是系统容量的关键瓶颈。无索引查询、慢 SQL、全表扫描、大分页、复杂 join、热点行更新、大事务、锁等待、连接池耗尽都会让数据库响应变慢。数据库一慢，应用线程会被占住，连接池被打满，新的请求继续排队，最终把应用层也拖垮。读多场景可通过索引优化、缓存、读写分离、分页优化、字段裁剪降低压力；写多场景要关注事务范围、批量写入、幂等、分库分表和异步化。

缓存相关压力

缓存本来用于保护数据库，但缓存使用不当也会制造压力。缓存穿透会让不存在的数据反复打到数据库；缓存击穿会让热点 key 过期瞬间大量请求同时回源；缓存雪崩会让大量 key 同时失效；热 key 会让单个缓存分片或节点被打满；大 key 会造成网络传输、序列化和内存压力。治理方式包括空值缓存、布隆过滤器、互斥重建、逻辑过期、过期时间随机化、热点 key 拆分、多级缓存和缓存预热。

锁、线程池与连接池

应用内部的锁竞争会让并发变成串行，尤其是全局锁、热点资源锁、分布式锁持有时间过长，会直接降低吞吐。线程池配置不合理也会放大问题：线程太少会排队，线程太多会造成上下文切换和内存开销，队列太长会隐藏故障并拉高延迟。连接池耗尽也很常见，例如数据库、Redis、HTTP 客户端连接未释放，或者下游太慢导致连接长期占用。排查时要看活跃线程数、队列长度、拒绝次数、锁等待时间、连接池活跃数和等待时间。

下游依赖与级联故障

服务压力不一定来自自身，也可能来自依赖链路。下游接口变慢、第三方服务抖动、DNS 解析异常、消息队列积压、存储服务限流，都会让本服务线程长时间等待。如果超时时间过长，线程被占住；如果重试策略不合理，请求量会被成倍放大；如果没有熔断和隔离，一个非核心依赖可能拖垮核心接口。稳定性设计要有超时、限流、熔断、降级、隔离舱、重试退避和失败兜底。

突发峰值与容量治理

突发峰值包括活动开始瞬间、定时任务集中执行、缓存批量失效、服务发布后冷启动、配置错误导致流量打偏、客户端版本缺陷引发重复请求等。应对峰值不能只依赖临时加机器，需要提前做容量评估、全链路压测、热点预案、缓存预热、队列削峰、自动扩缩容和流量分级。真正稳的系统会知道每个核心接口的容量上限、瓶颈资源、降级开关、扩容耗时和回滚路径。

监控与应急处理

判断服务器压力要依赖监控，而不是靠感觉。核心指标包括 QPS、并发数、p50/p95/p99 延迟、错误率、超时率、CPU、内存、GC、磁盘 IO、网络、线程池、连接池、数据库慢查询、缓存命中率、消息堆积、下游耗时和实例健康状态。应急时先止血：限流、降级非核心功能、关闭高成本接口、减少重试、切流量、扩容、回滚异常发布；再定位瓶颈和根因，最后补充压测、告警和容量模型。

易错点

只回答“访问量太大”，没有展开 CPU、内存、IO、数据库、缓存、连接池和下游依赖等具体瓶颈。
把服务器压力等同于 CPU 高，忽略了数据库连接池打满、锁等待、网络 IO、线程阻塞等非 CPU 型压力。
只讲问题来源，不讲如何通过监控指标定位瓶颈。
只说扩容，不提限流、熔断、降级、超时、重试控制和削峰。
忽略突发峰值和热点流量，把流量当成均匀分布来分析。
没有说明缓存失效、击穿、穿透、雪崩会把压力转移到数据库。
认为线程池和连接池越大越好，没有意识到它们会受下游容量和系统资源约束。
没有提到下游依赖变慢会通过阻塞、超时和重试引发级联故障。
只关注应用服务本身，不考虑数据库、缓存、消息队列、网关、负载均衡等全链路容量。
回答停留在现象层，没有给出线上止血和长期治理思路。

面试官追问

服务器 CPU 不高，但接口很慢，可能是什么原因？

可能是请求阻塞在 IO、数据库、缓存、下游接口、锁等待或连接池等待上。CPU 不高只能说明计算资源不是主要瓶颈，不能说明系统没有压力。应查看线程状态、连接池等待时间、数据库慢查询、下游耗时、磁盘 IO wait 和网络重传。

为什么下游接口变慢会导致本服务压力变大？

因为调用下游时，本服务的工作线程、连接和内存会被占用。下游响应越慢，资源释放越慢，新请求继续进入后会排队。如果再配置了多次立即重试，请求量会被放大，最终可能形成级联故障。

缓存雪崩、击穿、穿透分别如何影响服务器压力？

缓存雪崩是大量 key 同时失效，导致大量请求回源；缓存击穿是热点 key 失效瞬间大量并发请求打到数据库；缓存穿透是查询不存在的数据，缓存无法命中，反复访问后端存储。三者都会削弱缓存保护能力，让数据库和应用承受突增压力。

面对突发流量，限流和扩容哪个更重要？

两者作用不同。限流用于立即保护系统，防止请求无限进入导致雪崩；扩容用于提升可承载容量，但通常存在启动、注册、预热和流量调度时间。线上应先限流降级止血，再结合自动扩容、缓存预热和队列削峰恢复服务能力。

如何判断数据库是不是瓶颈？

可以看数据库 CPU、IO、连接数、慢查询、锁等待、事务时间、查询扫描行数、主从延迟和应用侧数据库调用耗时。如果应用侧大量线程等待数据库连接或 SQL 返回，且慢查询或锁等待明显增加，数据库大概率是瓶颈。

线程池越大是否越能抗压？

不是。线程池过小会排队，过大则会带来上下文切换、内存占用和调度开销，还可能让更多请求同时压向数据库或下游。线程池大小要结合 CPU 核数、任务类型、下游容量、队列长度和拒绝策略来设计。

为什么重试会让服务器压力更大？

重试会把一次失败请求变成多次请求。如果故障原因是下游变慢或容量不足，立即重试会进一步增加负载，造成重试风暴。更合理的做法是设置超时、最大重试次数、指数退避、抖动、幂等保护，并对非核心请求快速失败或降级。

监控哪些指标能提前发现服务器压力过大？

应关注流量、延迟、错误率和资源四类指标，包括 QPS、并发数、p95/p99 延迟、5xx、超时率、CPU、内存、GC、磁盘 IO、网络、线程池队列、连接池使用率、缓存命中率、数据库慢查询、消息堆积和下游调用耗时。