Nginx采用主线程+多worker进程模型，每个worker基于事件驱动、非阻塞I/O和Epoll实现高并发；通过轻量连接结构和EventLoop分阶段异步处理请求，单worker可支撑10k+连接。
Nginx 并非真正“单线程”，而是采用一个主线程 + 多个工作进程（worker process）的模型，每个 worker 进程内部使用事件驱动 + 非阻塞 I/O + Epoll（Linux）等高效事件通知机制，实现单个进程管理数万并发连接的能力。
EventLoop 是 worker 进程的核心调度机制
每个 worker 进程运行在一个独立的 Unix 进程中，内部只有一个执行流（即不依赖多线程），它通过一个持续循环（EventLoop）不断检查就绪的文件描述符（如监听 socket、客户端连接 socket）：
- 调用 epoll_wait（或 kqueue/select 等）等待事件发生，不占用 CPU
- 一旦有新连接、数据到达、写就绪等事件，立即被唤醒并分发给对应 handler（如 HTTP 模块）
- 所有网络读写均为非阻塞模式，避免因某次 I/O 卡住整个进程
连接不等于线程，内存与系统资源开销极低
Nginx 不为每个连接创建线程或进程，而是用轻量级结构体（ngx_connection_t）维护连接状态，包括缓冲区、读写事件标志、HTTP 请求上下文等：
- 每个空闲连接仅占用约 2–4 KB 内存（含 socket 缓冲区和连接结构）
- 内核中每个 TCP 连接仍需占用一个 fd 和相关内核结构，但 Nginx 本身无线程切换、栈分配、锁竞争等开销
- 配合系统参数优化（如 ulimit -n、net.core.somaxconn），单 worker 轻松支撑 10k+ 连接
真正的并发靠的是异步协作，不是并行执行
EventLoop 下的请求处理是分阶段、可中断、事件触发的。例如一个 HTTP 请求会经历：accept → recv header → parse → file I/O 或 upstream → send response，每一步都注册回调，在对应事件就绪时继续推进：
- 静态文件发送过程中，若内核发送缓冲区满，Nginx 暂停写操作，注册 write event，等可写再继续
- 反向代理场景下，与后端通信也完全异步，同一 worker 可同时管理前端连接和多个后端连接
- 没有“等待响应”导致阻塞，所有等待都转化为事件监听，CPU 始终可用
这种设计让 Nginx 在高并发、低计算负载（如静态服务、API 网关、负载均衡）场景下效率极高，也解释了为何它能在普通服务器上稳定承载数万长连接或数十万 QPS。
