nginx采用事件驱动的单线程循环调度模型，将http请求拆解为可中断的状态节点，通过模块化回调、零拷贝缓冲区复用及多worker进程隔离实现高并发处理。
Nginx 在非阻塞 IO 模式下的请求处理，并不依赖传统“流水线（pipeline）”式的多阶段串行架构，而是基于事件驱动的单线程循环调度模型——它没有严格意义上的硬件或逻辑流水线，但通过高效的状态机与事件分发机制，实现了类流水线的高吞吐行为。
核心不是流水线，而是事件状态机
Nginx 的每个 worker 进程维护一个独立的事件循环（event loop），将一次 HTTP 请求的生命周期拆解为多个可中断、可恢复的状态节点：accept → read header → parse → location match → upstream prepare → write response → close。这些状态并非硬编码的固定流水段，而是由模块按需注册回调，在对应 I/O 事件就绪时被触发执行。
- 连接建立后，不会立即读取全部请求体，而是先读 header，解析完再决定是否需要继续读 body（如 POST 数据）
- 转发到 upstream 时，也不会阻塞等待响应；而是注册读事件监听，同时转去处理其他就绪请求
- 每个阶段只做最小必要操作，完成后主动让出控制权，靠 epoll/kqueue 通知下一次就绪
零拷贝与缓冲区复用支撑高效流转
为减少内存复制和系统调用开销，Nginx 在非阻塞路径中大量使用链式缓冲区（ngx_chain_t）和内存池管理：
- 请求头、响应头、静态文件内容等均复用预分配的 buffer，避免频繁 malloc/free
- sendfile 系统调用直接将磁盘页映射到 socket 发送队列，绕过用户态拷贝
- 当上游返回 chunked 响应时，Nginx 以“边收边发”方式组装 ngx_buf_t 链，实现流式透传
模块协作形成逻辑处理链，而非物理流水线
Nginx 的 http 模块（如 rewrite、access、proxy、gzip）按配置顺序注册 handler 钩子，构成一条逻辑处理链。但该链的执行完全受事件驱动调度：
- rewrite 模块修改 URI 后，不立即跳转，而是标记状态，待当前阶段完成再进入下一匹配环节
- proxy 模块发起 upstream 连接后，worker 并不等待 connect 完成，而是继续轮询其他事件；connect 就绪后才触发后续 write request 流程
- 所有模块共享同一套 event loop 和 timer wheel，超时、重试、健康检查均由统一事件机制驱动
负载分散靠进程级隔离，不靠流水线级并行
所谓“高并发处理能力”，本质来自多 worker 进程 + 单进程内异步非阻塞的组合设计：
- master 进程 fork 出多个 worker，各自拥有独立的 epoll 实例和内存空间
- 新连接由内核 SO_REUSEPORT 或 accept mutex 机制分发给某个 worker，之后全程由该 worker 独立完成所有阶段
- 不存在跨 worker 的“阶段接力”，也无中央调度器协调流水节拍——每个 worker 是自治的请求处理器
