Nginx高性能源于事件驱动的异步非阻塞架构，由固定数量Worker进程配合I/O多路复用实现高并发；每个Worker为绑定CPU核心的单线程进程，无锁并行处理请求，遇I/O注册回调而非阻塞；合理配置Worker数（通常等于CPU核心数）可平衡资源开销与吞吐，其本质区别于线程/协程模型，具备低内存占用、强隔离性与高确定性；真实瓶颈常在上游响应、磁盘I/O或SSL握手等环节。
Nginx 的高性能核心在于其基于事件驱动的异步非阻塞架构，而 Worker 进程模型是支撑这一架构的关键机制。它不依赖多线程或每个连接一个进程的传统方式，而是通过固定数量的 Worker 进程，配合操作系统级别的 I/O 多路复用（如 epoll、kqueue），实现高并发下的低资源开销与高吞吐。
Worker 进程如何真正并行处理请求
每个 Worker 进程是独立的、单线程的 OS 进程，绑定到一个 CPU 核心（可通过 worker_cpu_affinity 配置）。它们各自监听相同的端口（借助内核 SO_REUSEPORT 支持或 accept 锁机制避免惊群），接收并处理客户端连接。由于无共享内存和锁竞争（除极少数全局资源外），多个 Worker 可真正并行运行在多核 CPU 上，充分利用硬件并发能力。
- 请求到达后由内核分发给某个空闲 Worker，该 Worker 在单线程内完成解析、静态文件读取、反向代理转发等全部逻辑
- 遇到 I/O 操作（如磁盘读、上游网络等待）时，Worker 不会阻塞，而是注册回调，继续处理其他就绪事件
- 同一时刻，多个 Worker 可同时执行不同请求的计算或等待不同 I/O，形成物理级并行
合理配置 Worker 数量提升实际性能
Worker 数量不是越多越好。默认 worker_processes auto 通常是最优选择，即设为 CPU 核心数。过多会导致上下文切换开销上升、缓存失效加剧；过少则无法压满多核资源。
- 对于纯静态服务或 CPU 密集型场景（如大量 gzip 压缩），Worker 数 ≈ 物理核心数较佳
- 若启用 SSL/TLS 终止，需关注 OpenSSL 的多线程支持与密钥运算负载，必要时可略增 Worker 数或启用 ssl_session_cache 减少重复握手
- 可通过 worker_rlimit_nofile 和系统 ulimit 联动，确保每个 Worker 能打开足够文件描述符（如 65536）
与线程/协程模型的本质区别
Nginx 不使用线程池处理常规 HTTP 请求（aio 或 thread pool 仅用于特定场景，如大文件异步读写）。它的“并发”来自单线程内高效事件循环，而非线程切换。这避免了线程栈内存开销、锁争用与调度延迟。
- 10 万个连接在 Nginx 中可能只占用几百 MB 内存；同等连接数下，传统每连接一线程模型可能耗尽 GB 级内存
- Worker 进程崩溃只影响自身连接，不影响其他 Worker，故障隔离性优于共享内存的多线程服务
- 无需用户态协程调度器，所有事件调度由内核和 Nginx 事件模块协同完成，路径更短、确定性更强
真实瓶颈往往不在 Worker 并行能力本身
当 Worker 利用率持续接近 100%，并不一定说明性能已达极限——需结合 nginx -s stub_status 或 nginx-module-vts 观察活跃连接、等待数、请求处理时长等指标。常见制约点包括：
- 上游服务响应慢，导致 Worker 长时间等待，表现为 active connection 高但 req/sec 低
- 磁盘 I/O 成为瓶颈（尤其未启用 sendfile 或 directio），此时增加 Worker 数反而加剧竞争
- SSL 握手频繁且未复用 session，CPU 花费在加解密上，应优化证书、启用 OCSP stapling 与 TLS 1.3
