nginx worker 进程采用单进程事件驱动+异步非阻塞 i/o 模型，通过 epoll/kqueue 轮询就绪事件，不创建线程、不阻塞等待，一个 worker 可管理数万连接，资源消耗低、上下文切换少。
Nginx 的 Worker Process 并不靠“多线程”或“每个连接一个进程”来处理并发，而是用单进程 + 事件驱动 + 异步非阻塞 I/O 的方式，高效复用有限资源应对海量连接。
每个 Worker 是独立的事件循环
每个 Worker 进程启动后，就运行一个持续轮询的事件循环（基于 epoll/kqueue），监听自己负责的 socket 上的所有就绪事件（新连接、数据到达、写就绪等）。它不阻塞、不等待，收到事件就立即处理——比如读请求头、转发给上游、组装响应、发回客户端。整个过程不创建新线程，也不让出 CPU，内存开销小、上下文切换少。
- 一个 Worker 可同时管理数万连接（只要它们处于空闲或半建立状态）
- 真正消耗 CPU 的是实际读写和逻辑处理，不是连接本身
- 连接生命周期中大部分时间（如等待客户端发数据、等待后端响应）Worker 并不占用 CPU
连接资源由内核与 Worker 协同管理
Worker 不自己分配 socket 或 buffer，而是依赖内核提供就绪通知，并按需调用系统调用（如 accept、recv、send）。关键资源控制点包括：
-
文件描述符（fd）：每个 TCP 连接占 1 个 fd，上限由
worker_rlimit_nofile和系统ulimit -n共同决定 -
内存缓冲区：每个连接会按需分配 client_header_buffer、client_body_buffer 等，大小由配置项硬性限制（如
client_header_buffer_size 1k） -
连接队列：内核维护 syn queue（
net.core.somaxconn）和 accept queue，Nginx 通过multi_accept on一次从队列取多个就绪连接，减少系统调用次数
Worker 之间不共享连接状态，但共享部分资源
Worker 进程彼此隔离，不共享连接套接字或请求上下文，但会争用几类共享资源：
-
accept_mutex：防止多个 Worker 同时调用 accept（惊群），默认开启；高并发下可关掉并配合
listen ... reuseport让内核分发 - 共享内存区：如 limit_req_zone、ssl_session_cache、upstream 状态等，需原子操作，过多 Worker 会导致缓存行伪共享，降低 L3 命中率
-
CPU 缓存与调度：若未绑定 CPU（
worker_cpu_affinity auto），多个 Worker 被调度到同一核心，破坏 epoll 就绪队列的本地性，性能反降
资源不是越多越好，匹配真实负载才关键
盲目增大 worker_processes 或 worker_connections 可能适得其反：
- 64 核机器设 64 个 Worker → 上下文切换飙升、cache 失效严重 → QPS 下降
- 设
worker_connections 65535但ulimit -n只有 1024 → 启动失败或静默降级 - header 缓冲留默认 8K × 4 → 恶意构造 header 触发百 MB 内存分配 → OOM 风险
合理做法是：Worker 数 ≈ CPU 物理核数（≥16 核建议设 8–12），worker_connections 按峰值连接 ×1.2 设定，并同步调高系统限制与缓冲区精度控制。
