在微服务架构中配置 nginx 的 least_conn 策略，需要在 upstream 块中指定该指令，并配合健康检查与权重参数使用。具体做法是定义后端服务器组，添加 least_conn; 语句，然后为每个服务器节点设置 ip、端口及可选权重。这样 nginx 会将请求转发给当前活跃连接数最少的服务器，实现负载均衡。
如何配置 upstream 块以启用 least_conn
直接在 upstream 块内写入 least_conn; 即可启用该算法。Nginx 会统计每个后端服务器的当前活跃连接数，并将新请求分配给连接数最小的节点。若连接数相同，则按权重轮询。需确保所有后端服务器已正确声明，且无其他冲突的负载均衡指令（如 round_robin 默认行为）覆盖。
http {
upstream backend_service {
least_conn;
server 192.168.1.10:8080 weight=5;
server 192.168.1.11:8080 weight=3;
server 192.168.1.12:8080 backup;
}
server {
listen 80;
location /api/ {
proxy_pass http://backend_service;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
上述配置中，192.168.1.10 权重为 5，192.168.1.11 权重为 3，192.168.1.12 作为备份节点仅在主要节点不可用时接收流量。least_conn 优先于权重进行连接数比较，但在连接数相等时，权重高的节点更可能被选中。预期结果是：高负载下请求均匀分布到低连接数节点，避免单点过载。
least_conn 与 round_robin 的行为差异是什么
least_conn 基于实时连接数分配请求，而 round_robin 仅按顺序轮询，不考虑服务器负载。在微服务中，若后端处理时间差异大，least_conn 能更好平衡响应延迟。round_robin 简单但可能将请求集中到慢速节点。选择 least_conn 适用于长连接或处理耗时不均的场景。
# 对比测试脚本（伪代码）
for i in 1..100:
send_request_to_nginx()
record_response_time()
# 假设后端 A 处理快，B 处理慢
# round_robin: A,B,A,B,... 导致 B 堆积
# least_conn: 动态避开 B，直到 B 空闲
通过压测可验证：round_robin 下慢节点响应时间波动大，least_conn 下各节点响应时间更稳定。实际部署时，建议结合 proxy_next_upstream 处理失败重试，提升可用性。注意 least_conn 不保证绝对公平，仅优化平均延迟。
当后端服务器宕机时 least_conn 如何处理
Nginx 默认启用被动健康检查，若服务器连续失败（默认 5 次），会被标记为不可用并从 least_conn 计算中移除。此时请求仅分发至存活节点。需配置 max_fails 和 fail_timeout 控制检测频率与恢复时间。例如 server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; 表示 30 秒内失败 3 次则暂停 30 秒。
