你有没有遇到过这种情况：网站突然卡顿，刷新好几次才打开，可一看监控，几台服务器里有的累得快冒烟，有的却闲得发慌？问题可能就出在负载均衡策略上。常见的轮询方式看似公平，其实忽略了每台服务器真实的承受能力。这时候，最小连接负载均衡（Least Connections）就派上了用场。
啥是最小连接负载均衡？
简单说，它就像饭店里的领位员。新来的客人不会被平均分配到每个包厢，而是带去人最少、最空的那个。在服务器世界里，这个“人少”指的是当前正在处理的连接数最少。负载均衡器会盯着后端每一台服务器，把新的请求发给此刻连接数最低的那一台。
比如你运营一个在线客服系统，高峰期大量用户同时发起聊天。有的服务器可能已经处理了200个会话，而另一台刚重启，几乎没负担。最小连接策略会自然地把新用户导流到那台轻装上阵的服务器上，避免第一台被压垮。
和轮询比，聪明在哪？
轮询（Round Robin）像排队买票，一人一次，不看业务复杂度。如果某个请求特别耗资源，比如生成一份几百页的PDF报告，这台服务器就得忙一阵子。轮询不管这些，继续往下一台派活，结果可能造成某几台长期高负载。而最小连接是动态的，它知道哪台机器“手头活多”，哪台“正闲着”，分配起来更合理。
Nginx 里怎么配置？
如果你用 Nginx 做反向代理，开启最小连接很简单。把默认的轮询改成 least_conn 就行：
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}加上 least_conn 后，Nginx 会自动跟踪每个后端节点的活跃连接数，新请求优先发给连接最少的那台。
也别把它当万能药
最小连接适合处理时长差异大的请求，比如既有快速查询，又有长时间上传的场景。但如果所有请求都差不多，而且很短，轮询或IP哈希可能更稳定。另外，它只看连接数，不看CPU、内存，所以还得配合健康检查一起用，避免把请求发给虽然连接少但其实已经卡死的机器。
实际运维中，见过有人把视频转码服务从轮询换成最小连接后，超时报警直接少了七成。因为大文件转码耗时长，连接会一直占着，新任务自然就不会往这上面堆了。
负载均衡不是设完就一劳永逸的事。根据业务特点选对策略，才能让服务器群真正高效运转。