Nginx通过Master-Worker模型与内核accept竞争实现连接级负载分散，Worker进程独立处理连接；反向代理时由upstream模块按轮询、加权轮询、ip_hash或least_conn等算法分发请求，结合被动健康检查与共享内存状态同步保障一致性。
Nginx 的多进程架构本身不直接“分发请求”，而是通过 Master-Worker 模型 + 事件驱动机制，让多个 Worker 进程各自独立、高效地竞争并处理连接，实现天然的请求负载分散。
Master 负责统筹，Worker 真正干活
Master 进程不处理网络请求，只做全局管理：读取配置、启动/监控 Worker、接收信号（如 reload、stop）、平滑升级。真正响应客户端的是多个 Worker 进程——它们数量通常与 CPU 核心数一致，每个都监听相同的端口（如 80/443），靠操作系统内核的 accept() 竞争机制 分配新连接。
- 当一个 TCP 连接到达时，内核唤醒所有处于 epoll_wait 等待状态的 Worker
- 只有一个 Worker 能成功调用 accept() 获取该连接（其余返回 EAGAIN）
- 这个 Worker 就独占该连接的整个生命周期：读请求、解析、转发、收响应、回传
连接建立后，调度由 upstream 决定
单个 Worker 接收请求后，若配置了反向代理（proxy_pass），下一步才是真正的“请求分发”——此时由 upstream 模块 根据配置的算法选择后端服务器：
- 轮询：按顺序轮流选，适合后端性能相近
- 加权轮询：按 weight 值分配比例，比如 weight=3 和 weight=1 的服务器，前者承担约 75% 请求
- ip_hash：对客户端 IP 做哈希，固定映射到某台后端，用于会话保持
- least_conn：选当前活跃连接数最少的后端，适合长连接场景
健康状态影响实际可选范围
upstream 的调度不是静态的。Nginx 开源版默认启用被动健康检查：
- 某后端连续失败 max_fails 次（如 3 次），会在 fail_timeout（如 30s）内被标记为“不可用”
- 被标记的服务器自动从调度池中剔除，后续请求不会选它
- backup 服务器仅在所有主服务器不可用时启用；down 则永久下线，不参与任何调度
没有中心调度器，靠协作与状态同步
Nginx 不设统一的请求分发中心。各 Worker 进程完全独立运行，共享内存（如 upstream 状态、缓存、限流计数器）用于协调关键信息：
- 后端服务器的失败次数、可用状态等保存在共享内存中，所有 Worker 实时可见
- ip_hash 的一致性依赖于各 Worker 使用相同的哈希算法和服务器列表顺序
- least_conn 的“连接数”统计也来自共享内存，确保决策依据一致
