Nginx Worker进程采用单线程事件驱动模型，通过少量进程+异步I/O实现高并发，核心优势是避免阻塞和减少上下文切换；默认worker_processes设为CPU核心数，每个Worker可处理数万连接，内存占用低、系统调用高效。
Nginx 的 Worker 进程采用单线程、事件驱动（epoll/kqueue）模型，并非靠多线程并发，而是通过少量 Worker 进程 + 高效异步 I/O 实现高并发处理，其性能优势核心在于“避免阻塞”和“减少上下文切换”。
Worker 进程不等于线程，更不是每个请求一个进程
每个 Worker 进程是独立的单线程进程，内部不创建子线程；它用一个循环持续监听并分发事件（如新连接、数据到达、超时等）。一个 Worker 可同时处理成千上万的 HTTP 请求——只要这些请求不触发阻塞操作（如同步磁盘读写、慢速上游响应、未优化的 Lua 脚本等）。
- 默认配置下，Worker 数量通常设为 CPU 核心数，让每个 Worker 绑定到一个核心，减少跨核缓存失效
- Worker 之间不共享内存（除共享内存区如 limit_req、upstream 状态外），避免锁竞争
- 请求在单个 Worker 内部由事件循环串行调度，但因几乎无阻塞，实际表现为高度并发
相比传统多线程模型，显著降低系统开销
Apache 的 prefork 或 worker MPM 在高并发下需创建大量进程/线程，导致：内存占用高（每个线程栈约 1–8 MB）、频繁的上下文切换（尤其活跃线程数 > CPU 核数时）、内核调度压力大。而 Nginx 的 Worker 模型：
- 内存占用稳定：一个 Worker 进程常驻内存约几 MB，可支撑数万连接
- 上下文切换极少：仅在 Worker 进程间（由 OS 调度）发生，远少于每请求一线程的场景
- 系统调用更高效：依赖 epoll_wait() 一次性获取多个就绪事件，而非轮询或为每个连接单独 select/poll
真正发挥优势的关键配置与前提
Worker 并行能力不是自动生效的，需匹配硬件与使用方式：
- worker_processes auto; —— 让 Nginx 自动设为 CPU 核心数，避免过多 Worker 争抢 CPU 或过少导致负载不均
-
worker_connections 10240; —— 单个 Worker 最大并发连接数，需结合
ulimit -n调整系统文件描述符上限 - 禁用阻塞操作：避免在 location 中使用
proxy_buffering off导致后端慢时阻塞整个 Worker；慎用auth_request同步校验或未加超时的 upstream 调用 - 启用
accept_mutex on;（默认）可减少惊群效应；Linux 下还可开启epoll和reuseport（需内核 ≥ 3.9）进一步提升连接分发效率
适合的场景与典型瓶颈识别
该模型在静态资源服务、反向代理、API 网关等 I/O 密集型场景优势明显；但在 CPU 密集型任务（如大量实时图像压缩、复杂正则重写）中，单 Worker 的串行执行会成为瓶颈。
- 若 top 显示某个 Worker 进程 CPU 持续 100%，而其他 Worker 很空闲，说明存在 CPU 阻塞逻辑（如不当的 rewrite 正则、OpenResty 中未 yield 的 Lua 循环）
- 若所有 Worker 的 CPU 均不高但请求延迟飙升、连接堆积，常见原因是 upstream 响应慢且未配超时，或磁盘 I/O 成瓶颈（如 access_log 未缓冲、大量小文件 sendfile 未优化）
- 可通过
nginx -s signal或stub_status模块观察各 Worker 的活跃连接、等待连接数，辅助定位不均衡问题
