负载均衡算法深度对比：轮询哈希与最少连接

负载均衡的核心不仅是分发请求，更关键的是用什么策略分发。不同的算法适用于不同的业务场景，选错了会导致负载不均、会话丢失、性能下降。这篇把五种主流负载均衡算法掰开揉碎对比一下，给实际选型提供参考依据。

轮询与加权轮询

轮询是最简单的算法，请求按顺序逐一分配到每台后端服务器，循环往复。实现简单，不需要维护额外状态，但前提是所有后端服务器处理能力相同。现实环境里这种理想情况不多，所以就有了加权轮询。管理员根据服务器配置分配权重，高配机器多分请求，低配机器少分请求，整体负载更均衡。

加权轮询的缺点是只考虑了服务器能力差异，没考虑请求本身的差异。如果某些请求处理时间长，分到这些请求的机器积压的连接会变多，而轮询算法不会感知到这种不平衡，照样均匀分配，导致慢的越来越慢。对于请求处理时间差异大的场景，轮询类算法不是最佳选择。

最少连接算法

最少连接算法把新请求分给当前活跃连接数最少的服务器。这个策略能动态感知各节点的负载状况，处理慢的节点积压连接多，新请求自然往快的节点走，整体效率比轮询高。Nginx的least_conn指令就是这个算法的实现。

加权最少连接是在最少连接基础上叠加权重因素，既考虑服务器能力又考虑当前负载，分配更精准。LVS的wlc算法就是这种。不过最少连接算法需要负载均衡器实时维护各节点的连接计数，请求量大时这个计数本身也有开销，但对于现代硬件来说基本可以忽略。

IP哈希与会话保持

有些业务需要会话保持，同一个客户端的请求要打到同一台后端服务器上，否则session数据读不到。IP哈希算法通过对客户端IP做哈希运算，把结果映射到固定的后端节点，实现会话绑定。Nginx的ip_hash指令就是这个原理。

IP哈希的问题在于分布不均匀。如果大量用户走同一个NAT出口，这些请求的源IP相同，全部打到同一台后端，负载严重倾斜。另外后端节点增减时，哈希映射关系会变化，大量用户的会话绑定失效，需要重新登录。对于这些问题，通常建议把session放到Redis等共享存储里，从架构层面解决会话问题，而不是依赖IP哈希这种脆弱的方案。

一致性哈希与节点变动

一致性哈希解决了普通哈希在节点变动时大量数据迁移的问题。算法把哈希值空间组织成一个虚拟环，每个节点占据环上若干位置，请求的哈希值顺时针找到最近的节点。节点增减时只影响相邻区间的映射，大部分请求的路由不变。这种特性在缓存场景特别重要，Memcached和Redis Cluster都采用了一致性哈希的思想。

实际使用中会引入虚拟节点。如果每台物理节点只占环上一个位置，节点少时分布很不均匀。给每台物理节点配几十上百个虚拟节点，分布在环上各处，请求分布就均匀多了。虚拟节点数量需要权衡，太少不均匀，太多会占用内存且路由计算变慢，一般取150到200个较合适。一致性哈希配合虚拟节点是大规模集群首选的负载均衡策略。