负载均衡的三种方式轮询最少连接和哈希

一台服务器扛不住并发，加机器是第一反应，但请求怎么分到每台机器上就是新问题。常说的负载均衡的三种方式，一般指轮询、最少连接和源地址哈希这三种调度思路，下面挨个说清适用场景。

轮询

请求按顺序一台一台轮流发，实现最简单，nginx 的 upstream 默认就是这种。机器配置一致时够用，配置不齐会出问题：两核小机器和十六核大机器接同样的活，小机器先累垮。解决办法是加权轮询，给大机器多分、小机器少分，权重别拍脑袋定，按机器实际压测的吞吐来配。

谁身上的活跃连接少，新请求就发给谁。轮询按次数分，最少连接按实际负担分，请求处理时长差别大、机器配置不均的场景下它更公平，长连接业务多的系统一般优先选它，nginx 里对应的配置项是 least_conn，一行的事。

对客户端 IP 做哈希运算，同一个 IP 永远落到同一台机器。会话存在本机内存、又没上集中式缓存的老系统，靠它避免用户这次请求在 A 机、下次到 B 机导致登录状态丢失。缺点也明显：某台机器挂了，它接的那批用户要重新登录；公司出口 IP 集中时，流量分布还容易失衡。

无论选哪种算法，健康检查都得配上：定期探测后端节点的端口或接口，挂掉的机器自动摘出分发列表，恢复了再加回来。少了这一步，算法再合理也会把请求往宕机的机器上送。

上面是调度算法，具体实现还有硬件和软件之分。硬件负载均衡如 F5 这类专用设备，性能强价格贵，金融类系统用得多；软件方案常见的有 nginx、HAProxy、LVS，互联网项目里占主流。DNS 轮询、CDN 分流算是入口层面的均衡手段，可以和后端方案叠加用。

选型给个实际判断：请求又快又均匀、机器配置一致，轮询最省心；请求耗时长短悬殊，上最少连接；有会话保持的老系统来不及改造，源地址哈希先顶着，长期看还是把会话挪到 Redis 集中存，算法就能随便挑。负载均衡的三种方式没有绝对优劣，看业务形态选。