Nginx的worker_processes不实现负载均衡，而是配置多进程并行处理能力，每个worker独立争抢连接；真正的负载均衡由upstream模块通过轮询、least_conn等算法将请求分发至后端服务器。
Nginx 本身不通过 worker_processes 做“负载均衡”，而是靠它构建多进程协作基础，让多个 worker 进程公平、高效地争抢连接，从而实现操作系统级的请求分发。真正的负载均衡（比如把请求分给后端服务器）是 upstream 模块的事；而 worker_processes 解决的是“谁来接客户端的连接”这个问题。
worker_processes 的作用不是调度，而是并行处理能力配置
它决定启动多少个独立的 worker 进程，每个都具备完整处理 HTTP 请求的能力。这些进程不互相通信，也不由 master 分配请求，而是靠内核的 accept() 争抢机制 或 reuseport（推荐） 来分摊新连接。
- 默认行为（无 reuseport）：所有 worker 进程监听同一个 socket，内核用“惊群”或锁机制让它们轮流 accept 新连接，实际效果接近轮询，但有轻微争抢开销。
-
启用 reuseport（Linux 3.9+）：在 listen 指令中加
reuseport，内核直接为每个 worker 分配独立 socket，连接分发更均衡、无争抢，性能更好。 -
数量建议：设为 CPU 物理核心数（非超线程数），例如 4 核机器通常设
worker_processes 4;；过高反而增加上下文切换开销。
worker_connections 配合 worker_processes 决定并发上限
单个 worker 能同时处理多少连接，由 worker_connections 控制。总并发理论值 ≈ worker_processes × worker_connections。
- 若设
worker_processes 4;和worker_connections 1024;，理论支持约 4096 并发连接。 - 实际受系统限制影响：需同步调大 ulimit -n（文件描述符上限），否则会报 “too many open files”。
- 注意：这个并发数指活跃连接数（含 keep-alive），不是每秒请求数（QPS），QPS 还取决于业务处理耗时。
master-worker 协作保障稳定与平滑升级
master 进程不处理请求，只做三件事：拉起/监控 worker、加载配置、执行热重载或平滑升级。
- 某个 worker 崩溃，master 立即拉起新进程，服务不中断。
- 执行
nginx -s reload时，master 启动新 worker，逐步接管连接，旧 worker 处理完现有请求后退出——零停机更新。 - 所有配置变更（包括
worker_processes）必须通过 reload 生效，不能运行时动态调整进程数。
和 upstream 负载均衡不是一回事
别混淆两个层面：
-
worker_processes是 Nginx 自身接收客户端连接的并行度控制； -
upstream+proxy_pass才是把请求转发到后端集群的负载均衡，用轮询、least_conn、ip_hash 等算法。 - 你可以有 8 个 worker 进程，但 upstream 里只配了 2 台后端服务器——前者管“谁来接电话”，后者管“接完后转给哪个客服”。
