什么是最小连接数调度算法
在做服务器维护时，经常会遇到用户访问量忽高忽低的情况。比如某个电商网站在促销期间，瞬间涌入大量请求，如果分配不当，部分服务器可能忙得宕机，而另一些却闲着发呆。这时候，最小连接数调度算法（Least Connections）就派上用场了。
这个算法的核心思路很简单：把新的请求交给当前连接数最少的那台服务器。不像轮询那样“人人平等”，它更关注实时负载，谁现在最轻松，就让谁接下一个任务。
和轮询比有什么不一样
轮询就像食堂打饭，不管前面的人端了多少菜，都按顺序一人一份。但现实中，有人只打个青菜，有人要五个荤菜，处理时间差很多。如果用轮询，后面排队的人就得干等。
而最小连接数更像是智能分流。比如有三台应用服务器，A正在处理8个请求，B处理3个，C才1个，这时候新来的请求就会自动分配给C。这样能有效避免某台机器被压垮，其他机器却空转的情况。
实际配置示例
在Nginx中启用最小连接数调度非常简单，只需要修改配置文件：
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
};加上 least_conn; 这一行，Nginx就会自动根据各节点的活跃连接数来分配流量。比起默认的轮询策略，更适合处理长连接或响应时间差异大的业务场景。
适用场景举例
想象一个在线客服系统，有的对话只是简单问答，几秒就结束了；有的却要反复沟通，持续几分钟。如果用轮询，短对话的请求可能被分到还在处理长对话的服务器上，导致响应变慢。
换成最小连接数调度后，刚结束一个长对话的服务器，因为连接释放了，会优先收到新请求，整体响应更流畅。类似的情况还包括视频上传、文件下载、API网关等耗时不稳定的服务。
当然，这也不是万能方案。如果所有请求都很轻量且耗时接近，轮询反而更简单高效。关键还是看实际业务特点。
配合权重使用更灵活
有时候服务器配置不一样，比如一台是8核，另一台是4核。可以结合权重调整，让性能强的承担更多压力：
upstream backend {
least_conn;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
};这样调度器会在考虑连接数的基础上，适当向高配机器倾斜，既保证公平，又发挥硬件优势。
在日常运维中，打开监控面板看到各服务器的连接曲线趋于平缓，就知道这个算法起作用了。没有剧烈波动，也没有长期偏斜，用户访问自然也就更稳定。”}