什么是服务器阻塞？

一、核心概念：用“收费站”比喻

想象一个高速公路的收费站：

服务器 = 收费站

服务器资源（CPU、内存、网络带宽、磁盘I/O） = 收费亭的数量和通行速度

客户端请求 = 一辆辆要通行的汽车

在正常情况下，汽车有序通过，收费站运转流畅。

“服务器阻塞” 就是指在某个时刻，要通行的汽车（请求）数量远远超过了收费亭（服务器资源）的处理能力，结果就是：

1、所有收费亭都满了，正在处理当前的车辆。

2、后面的车辆排起了长队，无法前进，只能等待。

3、整个交通陷入停滞或极度缓慢的状态。

对应到服务器上，就是用户感觉网站/应用打不开、加载极慢、或者直接显示“连接超时”等错误。

二、服务器阻塞的常见表现

当服务器发生阻塞时，用户和开发者会观察到以下现象：

对用户而言

* 网页一直转圈，加载不出来。

* 应用点击后无响应或报错（如 502 Bad Gateway, 504 Gateway Timeout）。

* 视频卡顿、游戏延迟飙升。

对开发者/运维而言

服务器监控指标异常CPU使用率100%、内存耗尽、网络带宽占满、磁盘I/O等待队列过长。

* 服务器日志中出现大量错误或超时记录。

* 数据库连接池耗尽，无法建立新的连接。

三、导致服务器阻塞的主要原因

“堵车”的原因有很多，服务器阻塞也是如此：

1、流量激增（高并发）

场景电商秒杀、热门文章被大量分享、明星发布微博、DDoS攻击等。

原因瞬间涌入的请求数量超过了服务器的设计处理能力。

2、低效的代码或数据库查询

场景一个API接口中包含了未优化的SQL查询，比如没有索引的全表扫描（N+1查询问题）、大循环嵌套等。

原因单个请求就占用了大量的CPU或数据库资源很长时间，导致服务器能同时处理的请求数急剧下降。

3、资源泄漏

场景代码中存在Bug，导致内存、数据库连接、文件句柄等资源在使用后没有被正确释放。

原因可用的资源越来越少，最终耗尽，新的请求无法获取到资源。

4、依赖的服务出现故障或变慢

场景你的服务器需要调用另一个微服务、第三方API（如支付接口、地图服务）或数据库，而这些服务本身响应缓慢或不可用。

原因你的服务器线程/进程在等待这些慢速响应时被挂起，无法处理新的请求，资源被白白占用，从而引发连锁反应。

5、硬件资源不足

场景服务器配置过低（如单核CPU、1GB内存），却要运行一个复杂的应用。

原因硬件性能天生就是瓶颈，即使代码优化得很好，也无力应对稍高的负载。

四、服务器阻塞 vs. 服务器宕机

这是一个重要的区分：

>注意：严重的服务器阻塞最终可能导致服务器因资源耗尽而崩溃，从而转变为宕机。

五、如何解决和预防服务器阻塞？

解决思路就像治理交通拥堵，需要“疏”和“导”结合。

1、横向扩展（Scale Out）

方法使用负载均衡器，在后面部署多台服务器组成集群。

效果当流量增大时，可以将请求分发到不同的服务器上，避免单台服务器过载，这是最常用和最有效的手段。

2、优化代码和数据库

方法优化算法、减少不必要的计算、为数据库查询添加合适的索引、使用缓存（如Redis）来减少对数据库的直接访问。

效果让单个请求处理得更快，降低资源占用。

3、限流和降级

限流在入口处限制单位时间内能通过的请求数量，超出部分直接拒绝，保护服务器不被冲垮。

降级当系统压力过大时，暂时关闭一些非核心功能（如商品评论、推荐列表），保证核心流程（如下单、支付）的畅通。

4、异步处理

方法将耗时的操作（如发送邮件、处理视频、生成报表）放入消息队列（如RabbitMQ、Kafka）中，由后台 worker 慢慢处理，并立即响应用户。

效果释放Web服务器的资源，使其能快速响应更多用户请求。

5、充足的资源和监控

方法根据业务需求提供足够的硬件资源，并建立完善的监控系统（如Prometheus + Grafana），实时监控CPU、内存、磁盘I/O、QPS等关键指标，在问题发生前预警。

服务器阻塞本质上是一个性能瓶颈问题，其核心是对资源的请求速度超过了资源的处理速度，理解其原因和解决方案，是构建高可用、高性能互联网服务的基础。

文章摘自：https://idc.huochengrm.cn/js/17053.html