Nginx least_conn最少连接算法原理：动态负载均衡的核心机制详解

前言

在Nginx负载均衡的六大算法中，least_conn（最少连接）是一个经常被低估但非常实用的动态策略。它不按固定顺序转发请求，而是实时观察后端服务器的活跃连接数，把新请求交给最空闲的那一台。

什么是least_conn算法

least_conn（Least Connections，最少连接数）是一种动态负载均衡算法，核心逻辑：新请求优先转发给当前活跃连接数最少的后端服务器。

与轮询不同，least_conn每次做决策时都会看一眼各后端的实时连接数，是一种感知后端负载状态的算法。

为什么不用轮询

轮询有一个隐含假设：每台请求的处理时间大致相同。现实中这个假设经常不成立。

场景一：文件上传下载，某些请求耗时数十秒，导致被分配到的后端持续高负载。

场景二：数据库复杂查询，请求耗时差异大，轮询会造成忙的忙死、闲的闲死。

场景三：后端性能不一致，即便权重配置正确，处理时间差异仍会导致负载不均。

least_conn核心工作原理

Nginx收到一个新请求需要转发时，least_conn的执行逻辑：

1. 遍历upstream中所有可用的后端服务器

2. 读取每台的当前活跃连接数

3. 计算 conns / weight（有效负载值）

4. 选出有效负载值最小的那一台

5. 如果多台并列最小，则在这几台之间执行加权轮询

连接数变化时机：请求转发给后端时+1，后端返回响应连接关闭时-1。

权重如何参与运算

least_conn不是纯粹看连接数，而是看加权后的连接数。

假设三台后端：server A权重5连接数20，server B权重3连接数12，server C权重1连接数3。

此时server C的conns/weight最小，新请求会发给C。

多worker进程下的连接数共享

Nginx默认是多worker进程架构，每个worker都有自己的内存空间。

解决方法：用zone指令在共享内存中维护连接数状态。

配置示例：upstream backend { zone backend 64k; least_conn; server 192.168.1.10:8080 weight=3; }

完整配置示例

http { upstream app_cluster { zone app_cluster 128k; least_conn; server 10.0.0.10:8080 weight=3; } server { listen 80; location / { proxy_pass http://app_cluster; } } }

适用场景

• 请求处理时间差异大：文件上传、视频转码、复杂查询等
• 后端性能不一致：新旧机器混用，权重加least_conn组合效果最好
• 长连接或WebSocket代理：连接持有时间长，连接数比请求数更能反映真实负载

总结

least_conn的核心价值在于动态感知后端负载，让每台后端服务器的单位权重负载趋于平衡。

配置时记住：一定要加zone指令，否则多worker进程下算法失效。