least_conn是一种动态负载均衡策略，优先将新请求分发给当前活跃连接数最少的健康后端服务器，适用于长连接场景；nginx和haproxy均原生支持，但统计粒度与一致性机制不同。
least_conn 是一种动态负载均衡策略，核心思想是将新请求优先分发给当前活跃连接数最少的后端服务器，适用于长连接、连接持续时间差异大的场景（比如 WebSocket、数据库代理、RPC 服务等），比轮询或加权轮询更能避免某台机器因连接堆积而过载。
原理：实时跟踪并比较连接数
负载均衡器需要持续维护每台后端服务器的当前活跃连接数（通常指已建立但尚未关闭的 TCP 连接），每次有新连接接入时，遍历所有健康节点，选择连接数最小的那个。如果多个节点连接数相同，一般会按顺序或哈希 fallback 到其中一个（避免总选同一台）。
- 连接数统计需准确：必须在连接建立（如 TCP SYN+ACK 完成）时 +1，连接断开（如收到 FIN 或超时关闭）时 −1
- 健康检查必须开启：只对状态为 healthy 的节点参与 least_conn 计算，故障节点会被自动剔除
- 不依赖响应时间或 CPU 等指标：纯粹看连接数量，实现轻量、低延迟
Nginx 中启用 least_conn
Nginx 自带支持，只需在 upstream 块中指定 least_conn 指令：
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
注意：Nginx 的 least_conn 是 per-worker 进程独立统计的，不是全局精确计数（多进程模型下无共享内存）。对高并发场景影响较小，但在极端不均衡时可能略有偏差；若需强一致性，可考虑用 OpenResty + shared dict 或外部协调服务。
HAProxy 中配置 leastconn（注意拼写）
HAProxy 使用的是 leastconn（无下划线），且支持更精细控制：
backend web_servers
balance leastconn
server s1 192.168.1.10:8080 check
server s2 192.168.1.11:8080 check
server s3 192.168.1.12:8080 check
- 支持
leastconn+roundrobin混合：当多个后端连接数相同时，自动切到 roundrobin 模式分发 - 可结合
weight：加权 leastconn，例如server s1 ... weight 2表示同等连接数下倾向多分担 - 连接数统计粒度更准：基于 HAProxy 自身的连接生命周期管理，非依赖系统 netstat
自研或微服务网关中实现要点
若在 Spring Cloud Gateway、Envoy 或自研网关中实现，关键在于：
- 维护一个线程安全的连接计数器（如
ConcurrentHashMap<string atomicinteger></string>） - 在 filter/interceptor 中拦截连接建立与释放事件（例如 Netty 的
channelActive/channelInactive） - 负载选择逻辑：过滤掉不健康节点 → 找出 min(connections) 的候选集 → 若多个，用 IP 哈希或轮询选一个
- 避免锁竞争：可采用分段计数（per-server + per-worker）再聚合，或使用 CAS 更新
