worker_processes 不直接参与负载均衡决策，但影响并发处理能力；应设为cpu物理核心数（如4核设4或auto），配合worker_connections决定最大并发连接数，并可结合worker_cpu_affinity绑定核心以提升稳定性。
worker_processes 设置本身不直接参与负载均衡决策，但它决定了 Nginx 能否高效支撑负载均衡所需的并发处理能力。合理配置 worker_processes 是负载均衡稳定、低延迟运行的前提，而非替代 upstream 调度逻辑。
worker_processes 数量影响并发吞吐上限
Nginx 的每个 worker 进程是单线程、事件驱动的，独立处理连接和请求转发。若进程数过少（如默认 1），即使后端有多个服务器，所有代理请求都挤在同一个 worker 中排队，容易成为瓶颈；若过多（超过 CPU 核心数），反而引发上下文切换开销和锁竞争。
- 推荐设为 CPU 物理核心数（非超线程数），例如 4 核服务器设 worker_processes 4;
- 使用 auto 值可由 Nginx 自动探测： worker_processes auto;（适用于大多数现代 Linux 环境）
- 可通过 lscpu 或 nproc 命令确认可用核心数
必须配合 worker_connections 才能释放真实并发能力
worker_processes 只定义“有多少个工人”，真正决定“每个工人能同时干多少活”的是 worker_connections。两者共同决定理论最大并发连接数：max_connections = worker_processes × worker_connections。
- 若负载均衡后端有 10 台服务器，每台平均承载 2000 并发连接，则 Nginx 至少需支持 20000+ 连接（含客户端连接 + 到后端的 proxy 连接）
- 常见搭配： worker_processes 4; 与 worker_connections 10240; → 理论支持约 40960 并发连接
- 注意：实际值受系统级限制（如 ulimit -n）制约，需同步调高 open files 限制
绑定 CPU 核心可减少缓存抖动，提升负载均衡响应一致性
启用 worker_cpu_affinity 能让每个 worker 固定运行在指定 CPU 核心上，避免频繁迁移导致 L1/L2 缓存失效，对高频率代理转发场景（如 API 网关型负载均衡）尤为明显。
- 4 核服务器示例：worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000; - 更简洁写法（Nginx 1.9+）：worker_cpu_affinity auto;
- 该设置与 upstream 的轮询、least_conn 等算法无冲突，但能让各 worker 更稳定地执行其分担的代理任务
与 upstream 负载均衡策略协同的关键点
worker_processes 属于“资源供给层”，upstream 属于“流量分发层”，二者分工明确但需对齐规模：
- 当启用 keepalive connections（如 proxy_http_version 1.1 + keepalive）时，worker 进程会复用到后端的长连接，此时更依赖 worker_connections 的余量，而非单纯增加 worker 数
- 若使用 ip_hash 或 sticky session，请求分布可能不均，更需要每个 worker 具备足够连接容量，避免某 worker 过载而其他空闲
- 健康检查（health_check）产生的探针请求也由 worker 进程发起，worker 数不足会导致检查延迟或漏检
