Nginx的worker_processes是反向代理网关层的并发处理骨架，决定并行处理能力上限，推荐设为物理CPU核心数；它与upstream模块分工明确：worker负责接收转发请求，upstream负责调度决策，二者协同实现高并发负载均衡。
Nginx 的 worker_processes 不是负载均衡器的“执行单元”，而是反向代理网关层的并发处理骨架。它和 upstream 负载均衡模块协同工作，但职责分明：worker 进程负责接收、解析、转发请求；upstream 模块负责决策把请求发给哪台后端。二者配合得当，才能让高并发流量平稳、高效地落到后端集群。
worker_processes 决定并行处理能力上限
每个 worker 进程独立运行，监听同一端口（靠内核 SO_REUSEPORT 或 accept_mutex 协调），各自用 epoll 处理成千上万连接。它的数量直接决定 Nginx 能同时调度多少路网络事件：
- 设为 1：所有请求串行排队，吞吐受限，易成瓶颈
- 设为过多（如远超物理核数）：进程切换开销上升，L1/L2 缓存争抢加剧，反而降低吞吐
- 推荐值 = 服务器物理核心数（不是逻辑核数）。例如 2 路 Xeon Silver 4310（每颗 12 核，开启 HT 后共 48 逻辑核），物理核为 2 × 12 = 24 →
worker_processes 24
✅ 验证方法：
lscpu | grep -E "Core|Socket"→ 计算Core(s) per socket × Socket(s)
worker 必须与 upstream 分工明确，不互相替代
upstream 块定义的是“往哪儿转”，而 worker 是“谁来转”：
-
upstream backend { server a:8080; server b:8080; }只是声明可用后端列表和调度策略（轮询/least_conn/ip_hash等） - 真正发起 TCP 连接、读写 HTTP 报文、管理 keepalive 连接的，是每个 worker 进程内部的 event loop
- 一个请求进来，由某个 worker 接收 → 解析 Host/URI → 查 upstream → 按算法选一台 server → 建连或复用长连接 → 代理转发
所以：增加 worker 数量不会改变 upstream 的调度逻辑，但能提升单位时间内的调度并发度。比如 4 个 worker 可以同时对 4 个不同客户端做 IP Hash 计算并分别转发；1 个 worker 则要串行处理。
关键配套配置缺一不可
worker 要真正支撑好负载均衡，需同步调优三项：
-
worker_cpu_affinity auto;—— 自动绑定到物理核，避免跨核缓存失效（尤其在 NUMA 架构下） -
worker_rlimit_nofile 65535;—— 每个 worker 最多打开 65535 文件描述符，匹配worker_connections 65535 -
events { use epoll; multi_accept on; accept_mutex off; }—— 启用高效事件模型，允许单次收多个就绪连接，消除 accept 锁竞争
若只调大 worker_processes 却忽略这些，会出现：连接数上不去、CPU 使用率低但请求排队、TIME_WAIT 堆积等问题。
实际效果取决于后端响应特征
worker + upstream 的组合表现，受后端延迟影响显著：
- 后端响应快（如本地 Redis、静态资源缓存）→ 可适当提高 worker 数（接近逻辑核数），榨干 CPU
- 后端响应慢（如 Java 微服务平均耗时 200ms+）→ worker 数宜保守（= 物理核），重点优化
proxy_buffering和keepalive复用，减少新建连接开销
此时，upstream 中的 max_conns、keepalive、proxy_next_upstream 等参数，比 worker 数更直接影响稳定性与成功率。
