Nginx多进程架构不直接实现负载均衡，而是通过master-worker模型支撑高并发与资源管理：master仅管理worker，worker独立处理请求并协同upstream模块完成后端负载均衡。
Nginx 的多进程架构本身不直接实现“负载均衡”（即不负责将客户端请求分发到多个后端服务器），而是承担自身内部的并发请求分发与资源管理。它通过 master-worker 模型高效利用 CPU 多核，为上层的反向代理和负载均衡功能提供稳定、低开销的运行基础。
多进程模型的核心分工
master 进程不处理网络请求，只负责管理 worker 进程：
- 读取并校验配置文件
- 启动、监控、平滑重启或热重载 worker 进程
- 接收系统信号（如 reload、stop）并转发给 worker
- 不监听端口，也不接受连接
worker 进程才是真正干活的角色：
- 每个 worker 独立监听相同端口（通过内核 SO_REUSEPORT 或 accept_mutex 协作避免惊群）
- 采用异步非阻塞 I/O（epoll/kqueue）处理成千上万并发连接
- 各自维护独立的内存空间和连接池，互不干扰
- 默认数量通常设为 CPU 核心数，最大化硬件利用率
如何支撑高并发下的资源管理
worker 进程通过轻量级事件循环避免线程切换开销，关键机制包括：
- 连接复用：启用 keepalive 可复用 TCP 连接，减少握手与内存分配频次
- 内存池管理：Nginx 自建内存池，按需分配/批量释放，避免频繁 malloc/free
- 请求缓冲控制：通过 client_body_buffer_size、client_max_body_size 等限制单请求资源占用
- 超时分级设置：read_timeout、send_timeout、keepalive_timeout 分别约束不同阶段生命周期
与 upstream 负载均衡的关系
多进程是底层执行框架，upstream 模块才是实现“对后端服务器负载均衡”的功能模块。二者协同方式如下：
- 每个 worker 进程在处理一个 HTTP 请求时，独立调用 upstream 模块选择后端节点
- 健康检查（如 max_fails / fail_timeout）状态由所有 worker 共享（通过共享内存 zone）
- IP Hash、一致性哈希等算法在各 worker 内部计算结果一致，保障会话粘性
- least_conn 算法依赖各 worker 上报的连接数，通过共享内存汇总统计
配置优化建议
让多进程架构更适配负载均衡场景：
- 显式设置 worker_processes auto;，自动匹配 CPU 核心数
- 开启 accept_mutex on;（旧版本）或依赖内核 SO_REUSEPORT（1.9.1+），避免锁竞争
- 为每个 worker 设置合理连接上限：worker_connections 10240;
- 启用 multi_accept on;，让 worker 尽可能一次接收多个就绪连接
- 配合 upstream 的 shared memory zone，确保健康状态全局可见
