## 现象是什么
压测或促销时，并发一上来部分请求直接失败：连接被拒、503、超时，而服务器 CPU 与内存都不忙。资源不缺却丢请求，问题出在各层排队缓冲的容量与超时设置上——请求从客户端到应用要过一条排队的链条，每一层都有自己的队列与等待上限，容量最小的那层先满，先满的那层决定丢多少请求。理解链条才能找到丢请求的确切位置。
## 排队链条拆解
链条从外到内四层。第一层内核层：连接建立要进半连接队列与全连接队列，队列长度由内核参数与监听时的 backlog 共同决定，队列满时新连接被丢弃，客户端表现是连接超时或重传。第二层 Web 服务器层：Nginx 的 worker_connections 用尽、代理队列堆积，请求排队等后端，超过 proxy_timeout 被放弃，日志留下 upstream timed out。第三层应用层：线程池或进程池满，新请求在队列里等，队列上限一到就拒绝，Java 线程池的拒绝策略、PHP-FPM 的排队上限都在这层起作用。第四层依赖层：数据库连接池耗尽，等连接的请求排队，获取连接的超时一过就报错。
## 定位丢在哪层
按报错特征对号入座：连接阶段失败（SYN 后无响应）查内核队列，dmesg 里的丢队列记录是证据；连接成功但响应慢后失败查 Web 与应用层队列，Nginx 日志的 upstream 响应时间、应用线程池的活跃数是证据；应用层报获取连接超时查数据库池。压测时逐层看指标：netstat 的队列堆积数、Nginx 状态页、应用池活跃度、数据库连接数，哪层先顶到上限一目了然。
## 调优思路
内核层扩 somaxconn 与监听 backlog，配合应用显式声明更大的 backlog；Web 层扩 worker_connections、对齐代理超时；应用层按"线程数乘平均耗时"估算池大小，队列长度设为可接受的等待而不是无限；依赖层扩连接池或让慢操作异步化。每层调整后重压对比，丢请求率与各层队列水位是验收指标。顺云云服务器上做容量评估时，把四层队列水位都暴露出来，丢请求从玄学变成可定位可调优的工程问题。