服务器如何同时处理多个API请求？指定场景的第四步会发生什么？

你原本的认知只适用于最原始的单线程同步阻塞服务器，绝大多数生产环境的服务器都不会采用这种模型，第四步的具体行为完全取决于服务器采用的并发处理模型。

首先纠正你的核心误解：网络请求的底层接收、TCP握手逻辑都是由操作系统内核负责的，和应用层服务是否处于忙的状态没有直接关系。只要服务器的监听端口处于正常开放状态，客户端B的TCP握手请求会先被内核处理，握手成功后连接会进入内核的backlog队列等待应用层读取，不会出现“连第二个请求都收不到”的情况，只有队列占满时才会直接拒绝连接。

不同服务器模型下的第四步表现 #

1. 单线程同步阻塞模型（仅Demo/极端老旧场景使用） #

• 服务只有一个主线程，同一时间只能执行一个任务
• 处理客户端A的请求时线程会完全阻塞，直到A的所有逻辑处理完成、响应返回后才会空闲
• 第四步行为：客户端B的连接和请求数据会暂存在内核缓冲区排队，直到服务处理完A的请求后才会读取B的请求开始处理，B的响应会产生明显延迟，队列满时才会直接拒绝B的请求

2. 多线程/多进程同步模型（传统WEB服务常用） #

• 服务会启动独立的监听线程+多个工作线程（或进程），监听线程只负责接收新请求，收到后分配给空闲工作线程处理业务逻辑
• 处理A的请求仅会占用单个工作线程，监听线程始终处于空闲可接收状态
• 第四步行为：监听线程直接接收B的请求，分配另一个空闲工作线程处理B的逻辑，A、B两个请求并行处理，互不影响，只要工作线程池没有被占满就不会出现排队

3. 单线程异步非阻塞（事件驱动）模型（Nginx、Node.js默认模型） #

• 服务通过IO多路复用技术（epoll/kqueue/select）监听所有连接的IO事件，单线程即可处理大量并发请求
• 处理A请求时如果遇到IO操作（查询数据库、读写文件、调用其他接口等），不会阻塞等待结果，而是注册一个回调函数后立刻回到监听状态
• 第四步行为：主线程直接接收B的请求开始处理，A、B的IO操作并行等待，各自的回调在IO完成后依次执行，IO密集型场景下即使单线程也能同时处理上万并发请求，只有CPU密集型业务才会阻塞后续请求

4. 多协程/多线程异步模型（Go、Java Netty等现代高并发服务常用） #

• 结合事件驱动和轻量级线程（协程）的优势，并发开销极低
• 第四步行为：A、B两个请求会被自动调度到不同的协程/线程并行处理，只要服务器CPU、内存资源没有耗尽，两个请求的处理几乎不会互相干扰，是目前生产环境性能最高的处理模型

内容的提问来源于stack exchange，提问作者Solver