nginx的event loop不负责连接负载均衡，仅在单worker内高效调度连接；真正的负载均衡由os层（reuseport/accept_mutex）、upstream模块（round_robin/least_conn等）和worker协同实现。
Nginx 的 Event Loop 本身不直接做连接负载均衡，它负责的是单个 worker 进程内高并发连接的高效调度；真正的“连接负载均衡”发生在更高层——由 upstream 模块 + 调度算法 + 多 worker 协同共同完成。理解这一点，才能避免把 Event Loop 和负载均衡机制混淆。
Event Loop 是单 worker 的“内部引擎”，不是跨进程调度器
每个 worker 进程独立运行一个 Event Loop，只管理自己收发的连接：
- 它通过 epoll_wait 监听本进程绑定的监听 socket 和所有已建立连接的 fd；
- 新连接 accept 后，由当前 worker 全程处理（读请求、转发、读响应、回写），不移交其他 worker；
- 所以：同一个客户端 TCP 连接一旦被某个 worker 接收，后续所有数据都由该 worker 处理到底，Event Loop 不会把已建立的连接“转给别的 worker”。
这意味着：
✅ 单 worker 内靠 Event Loop 实现万级连接的低开销、非阻塞、事件驱动处理；
❌ Event Loop 不决定“这个新连接该分给哪个后端服务器”，也不决定“该让哪个 worker 接这个连接”。
真正的连接负载均衡由三部分协同实现
1. 操作系统层面：新连接如何分配到不同 worker？
Nginx 启动时，多个 worker 进程会竞争 accept() 同一个监听 socket（默认开启 accept_mutex，避免惊群；也可关闭用 reuseport）。
实际分配取决于：
- Linux 内核的
SO_REUSEPORT（推荐启用）：内核在网卡中断阶段就将新连接哈希分发到不同 worker 的 listen fd，天然均衡； - 或 Nginx 自身的
accept_mutex on（默认）：worker 串行争抢 accept 权限，可能造成轻微不均，尤其在突发流量下。
✅ 建议配置：
events { use epoll; multi_accept on; accept_mutex off; # 关闭互斥锁 reuseport on; # 依赖内核 3.9+，需确认系统支持 }
2. upstream 层面：如何把请求分发到不同后端？
这才是通常说的“负载均衡”。Event Loop 只负责把请求数据读完，然后交由 proxy_pass 触发 upstream 模块决策：
-
round_robin（轮询）：按顺序选一台后端； -
least_conn（最少连接）：选当前活跃连接数最少的后端（对长连接更友好）； -
ip_hash/hash $cookie_sessionid：确保同一用户落到同一后端（会话保持）； -
weight：结合服务器性能差异动态加权。
⚠️ 注意：
keepalive 32配置的是 Nginx 到后端的空闲连接池大小，它复用的是 upstream 连接，和客户端连接无关，但能显著减少后端建连压力。
3. worker 进程间协作：靠配置与系统调优间接均衡
-
worker_processes auto;让 worker 数匹配 CPU 核心数； -
worker_cpu_affinity auto;把每个 worker 绑定到独立核心，避免调度争抢； -
worker_connections 10240;设置单 worker 最大连接数，配合ulimit -n调整系统上限； - 若某 worker 持续过载（如
pidstat -p $(pgrep nginx) 1显示%wait高），说明系统资源（CPU/内存/中断）已成瓶颈，需从系统层优化，而非改 Event Loop。
长连接场景下的负载均衡关键点
HTTP Keep-Alive 下，一个客户端连接可能复用发送几十上百个请求：
- 第一个请求由某个 worker 接收并选定后端（比如 A）；
- 后续请求仍走同一连接，Nginx 会复用此前建立的 upstream 长连接（如果
keepalive池中有空闲到 A 的连接），不重新调度； - 所以：
least_conn在长连接场景下比轮询更有效——它反映的是后端真实承载压力，而非请求计数。
示例配置逻辑：
upstream api_backend { least_conn; server 10.0.1.10:8000 max_conns=500; # 主动限制单台最大并发连接 server 10.0.1.11:8000 max_conns=500; keepalive 64; # 每个 worker 维护最多 64 个空闲到后端的连接 }
不复杂但容易忽略。
