Nginx 中 Event Loop 如何进行连接负载均衡

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，只管理自己收发的连接：

1. 它通过 epoll_wait 监听本进程绑定的监听 socket 和所有已建立连接的 fd；
2. 新连接 accept 后，由当前 worker 全程处理（读请求、转发、读响应、回写），不移交其他 worker；
3. 所以：同一个客户端 TCP 连接一旦被某个 worker 接收，后续所有数据都由该 worker 处理到底，Event Loop 不会把已建立的连接“转给别的 worker”。

这意味着：

单 worker 内靠 Event Loop 实现万级连接的低开销、非阻塞、事件驱动处理；

❌ Event Loop 不决定“这个新连接该分给哪个后端服务器”，也不决定“该让哪个 worker 接这个连接”。

---

真正的连接负载均衡由三部分协同实现

1. 操作系统层面：新连接如何分配到不同 worker？

Nginx 启动时，多个 worker 进程会竞争 accept() 同一个监听 socket（默认开启 accept_mutex，避免惊群；也可关闭用 reuseport）。

实际分配取决于：

1. Linux 内核的 SO_REUSEPORT（推荐启用）：内核在网卡中断阶段就将新连接哈希分发到不同 worker 的 listen fd，天然均衡；
2. 或 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 模块决策：

1. round_robin（轮询）：按顺序选一台后端；
2. least_conn（最少连接）：选当前活跃连接数最少的后端（对长连接更友好）；
3. ip_hash / hash $cookie_sessionid：确保同一用户落到同一后端（会话保持）；
4. weight：结合服务器性能差异动态加权。

⚠️ 注意：keepalive 32 配置的是 Nginx 到后端的空闲连接池大小，它复用的是 upstream 连接，和客户端连接无关，但能显著减少后端建连压力。

3. worker 进程间协作：靠配置与系统调优间接均衡

1. worker_processes auto; 让 worker 数匹配 CPU 核心数；
2. worker_cpu_affinity auto; 把每个 worker 绑定到独立核心，避免调度争抢；
3. worker_connections 10240; 设置单 worker 最大连接数，配合 ulimit -n 调整系统上限；
4. 若某 worker 持续过载（如 pidstat -p $(pgrep nginx) 1 显示 %wait 高），说明系统资源（CPU/内存/中断）已成瓶颈，需从系统层优化，而非改 Event Loop。

---

长连接场景下的负载均衡关键点

HTTP Keep-Alive 下，一个客户端连接可能复用发送几十上百个请求：

1. 第一个请求由某个 worker 接收并选定后端（比如 A）；
2. 后续请求仍走同一连接，Nginx 会复用此前建立的 upstream 长连接（如果 keepalive 池中有空闲到 A 的连接），不重新调度；
3. 所以：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 个空闲到后端的连接}

不复杂但容易忽略。