nginx通过事件驱动模型实现多类型请求并行处理：将所有请求抽象为accept、read、write、timeout四类事件，由单线程worker进程基于epoll统一调度；请求按11个http处理阶段流水线式移交，模块化协同（如static、proxy、websocket模块）挂载回调响应就绪事件；各worker独占资源、复用连接，以毫秒级事件切换模拟高并发并行。
Nginx 实现多类型请求的并行处理，靠的不是“为每种请求开一个线程”，而是把所有请求——无论静态文件、API代理、WebSocket 还是重定向——统一抽象成事件，交由同一个异步事件循环调度。它不区分请求类型，只关注“什么就绪了”，然后调用对应模块去处理。
事件统一抽象：连接、读、写、超时都是一类事件
Nginx 把网络交互拆解为四类基础事件：
- 新连接到达（accept）
- 客户端数据可读（read）
- 响应数据可写（write）
- 定时器触发（timeout）
所有请求类型最终都会落入这四类事件中。比如： - 静态文件请求 → 触发 read（收请求头）→ 触发 write（发文件内容）
- 反向代理请求 → read（收客户端请求）→ write（转发给后端）→ read（等后端响应）→ write（回传给客户端）
- WebSocket 升级请求 → read（解析 Upgrade 头）→ write（返回 101 响应）→ 后续持续 read/write 保持长连接
每个 worker 进程维护一个独立事件循环，用 epoll 监听成千上万个 socket 的状态变化，一旦某个 socket 就绪，就立即调用对应 handler，无需阻塞等待。
多阶段流水线：请求按阶段移交，不卡在某一步
Nginx 将 HTTP 请求处理划分为 11 个标准阶段（如 post_read、server_rewrite、find_config、access、content、log 等），每个阶段可注册多个模块。
- 请求进来后，不是由单个模块从头干到尾，而是按阶段“接力”执行；
- 某一阶段若需等待（如 upstream 等后端响应），当前 worker 不会停住，而是挂起该请求，继续处理其他就绪事件；
- 后端响应到达时，epoll 通知，事件循环唤醒该请求，从上次暂停的阶段继续往下走。
这种设计让 CPU 始终有事可做，避免因 I/O 等待造成空转。
模块化协同：不同请求类型由不同模块接管，共享同一事件引擎
-
ngx_http_static_module处理静态文件，直接调用 sendfile 零拷贝发送； -
ngx_http_proxy_module处理反向代理，管理上游连接池和缓冲区； -
ngx_http_fastcgi_module或ngx_http_grpc_module分别对接 PHP 或 gRPC 后端； -
ngx_http_websocket_module（内置支持）识别 Upgrade 请求，切换为全双工通信模式。
这些模块不自己轮询或建线程，全部基于 Nginx 提供的事件注册接口（如ngx_add_timer、ngx_epoll_add_event）挂载回调，在事件就绪时被调度执行。
连接复用与资源隔离保障并行稳定性
- 每个 worker 进程独占一组资源（内存池、连接链表、定时器红黑树），进程间不共享数据，避免锁竞争；
- keepalive 连接复用减少 TCP 握手开销，一个连接可承载多次不同类型请求（如先 GET 图片，再 POST 表单）；
- worker_connections 限制单进程并发上限，配合 worker_processes 控制总连接数，防止系统资源耗尽。
本质上，Nginx 的“并行”不是时间意义上的同时执行，而是在毫秒级事件粒度下高频切换上下文，让成千上万请求在单线程内看似同时推进——它并行处理的不是请求本身，而是请求生命周期中的就绪事件。
