nginx的负载均衡由upstream模块在请求转发阶段执行，worker进程仅作为执行单元调用该逻辑；每个worker独立处理自身accept的请求，通过内核机制实现连接均匀分发，upstream算法在各worker上下文中一致运行，确保整体流量均衡。
Nginx 的 worker process 本身不直接做负载均衡分发，它负责处理已接收的请求；真正的负载均衡逻辑由 upstream 模块在请求转发阶段执行，而 worker 进程只是调用该逻辑的执行单元。
worker 进程的角色定位
每个 worker 是独立的事件驱动进程，监听相同端口（如 80/443），通过内核机制（epoll/kqueue）高效接收连接。它们之间不共享连接状态，也不协调请求分配——谁 accept 到连接，就由谁全程处理该请求（包括 upstream 转发）。这种“各自为政”设计避免了锁竞争，是高并发的基础。
负载均衡发生在请求处理链路中
当某个 worker 接收到一个 HTTP 请求后，若配置了 proxy_pass http://backend，它会：
- 读取
upstream backend { ... }块中定义的服务器列表 - 根据配置的算法（如
least_conn、ip_hash或加权轮询）选择一台后端服务器 - 发起异步 upstream 连接，并将当前请求代理过去
这个决策过程由 ngx_http_upstream_module 完成，对 worker 来说是透明调用，但实际计算和选择动作发生在 worker 内部上下文中。
多个 worker 如何协同体现“均衡”效果
表面上看，worker 间无调度，但整体流量仍趋于均衡，原因在于：
- 内核层面的连接分发：现代 Linux 使用 SO_REUSEPORT 或 epoll 的 EPOLLEXCLUSIVE，让新连接尽可能均匀落到不同 worker 的 listen socket 上
- 请求处理的随机性：客户端请求到达时间、响应时长、后端健康状态等变量天然分散，长期运行下各 worker 处理请求数接近均值
- upstream 算法全局一致：所有 worker 使用同一份 upstream 配置和相同算法逻辑，确保无论哪个 worker 执行转发，策略行为统一
注意几个常见误解
• “worker 数量 = 负载均衡节点数” —— 错。worker 是 Nginx 自身的处理进程，不是后端服务节点；真正的均衡对象是 upstream 中定义的 server 列表。
• “需要配置 worker 间通信来同步权重或连接数” —— 不需要。Nginx 不维护跨 worker 的全局连接计数，least_conn 统计的是本 worker 当前持有的活跃 upstream 连接数（轻量且无锁）。
• “调整 worker_processes 能改变后端流量比例” —— 不能。它只影响 Nginx 自身并发能力，不影响 upstream 分发逻辑。
