在 nginx 中，`least_conn` 负载均衡算法结合 `keepalive` 连接复用，核心做法是在 `upstream` 块中同时声明 `least_conn;` 和 `keepalive` 指令。`least_conn` 负责选择当前活跃连接数最少的后端服务器，而 `keepalive` 则在该服务器上维护一个长连接池，避免每次请求都建立新的 tcp 握手。这样做能显著降低高并发下的连接开销，提升响应速度。
least_conn 如何与 keepalive 配合工作
当启用 `least_conn` 时，Nginx 会动态计算每个后端服务器的活跃连接数（即正在处理中的请求数），并优先将新请求分配给连接数最少的那个节点。如果同时配置了 `keepalive`，Nginx 会在选定的节点上尝试从空闲连接池中获取一个已建立的 TCP 连接。若池中有可用连接，则直接复用；若无，则新建连接并将该连接标记为“活跃”，直到请求结束或超时后归还池中。这种机制确保了负载均匀的同时，最大化了连接的重用率。
server {
listen 80;
server_name example.com;
location /api/ {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
upstream backend_pool {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
keepalive 32;
}
上述配置中，`keepalive 32` 表示每个 worker 进程最多缓存 32 个到上游服务器的空闲长连接。当客户端发起请求时，Nginx 首先通过 `least_conn` 算法选出最优后端，然后检查该后端的连接池。如果池非空，则取出一个连接进行代理；如果池为空，则创建新连接。请求完成后，连接不会立即关闭，而是返回池中等待下一次复用。注意，`keepalive` 的值应根据后端服务器的性能和并发量调整，过大可能导致文件描述符耗尽，过小则无法充分发挥复用优势。
连接池满或后端不可用时 least_conn 的行为
当所有后端的连接池都满了，或者某个后端服务器暂时不可达时，`least_conn` 依然会正常工作，但行为会有所不同。如果连接池满，Nginx 会创建新的临时连接来处理请求，这些新连接在完成请求后通常不会被放入池中（取决于具体版本和配置），或者会迅速被回收。如果后端不可达，Nginx 会根据 `max_fails` 和 `fail_timeout` 参数将该服务器标记为故障，并在指定时间内不再向其发送请求，从而保证流量只流向健康节点。此时，`least_conn` 仅在健康服务器之间进行负载均衡。
# 假设后端 192.168.1.10 宕机 # Nginx 会自动将其从负载均衡池中移除 # 请求仅分发至 192.168.1.11 和 192.168.1.12 # 验证命令：curl -I http://example.com/api/ # 观察响应头中的 Server 字段或日志，确认请求未发往宕机节点 # 查看 Nginx 错误日志，确认是否有 upstream connection refused 记录 # tail -f /var/log/nginx/error.log
在实际运维中，建议配合 `proxy_next_upstream` 指令使用，以增强容错能力。例如，设置 `proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;`，这样即使某个后端在处理请求时出错，Nginx 也会自动将请求转发给其他健康节点，而不是直接返回错误给客户端。此外，监控连接池的使用情况也很重要，可以通过 `stub_status` 模块或第三方模块来观察活跃连接数和空闲连接数，以便及时调整 `keepalive` 参数。
基于 keepalive 连接池大小的具体调优问题
针对程序中 `keepalive 32` 这个输入条件，如果并发量极大导致连接池频繁溢出，应该如何调整？答案是增加 `keepalive` 的值，但需考虑系统资源限制。每个空闲连接都会占用一个文件描述符和一定的内存。如果 Nginx 的 worker 进程数较多，总连接数 = worker_processes * keepalive。例如，4 个 worker 进程，每个保持 32 个连接，总共需要 128 个连接。如果系统允许的文件描述符上限较低，可能需要同时调整 `worker_rlimit_nofile`。此外，还可以结合 `proxy_http_version 1.1;` 和 `proxy_set_header Connection "";` 确保 HTTP/1.1 长连接的正确协商，避免因协议版本不匹配导致连接无法复用。
