负载均衡算法：轮询、最小连接与一致性哈希

负载均衡是分发网络流量到多台服务器的核心技术，它能提升系统可用性、扩展性和响应速度。选择正确的负载均衡算法直接影响资源利用率与用户体验。本教程将带你从零掌握三种最经典的算法：轮询、最小连接和一致性哈希，并理解它们背后的思想与适用场景。

轮询（Round Robin）

工作原理

轮询算法将请求按顺序轮流分配给后端服务器池。假设有服务器 A、B、C，请求1发给 A，请求2发给 B，请求3发给 C，请求4再次发给 A，如此循环。

它不关心每台服务器的当前负载、连接数或性能差异，单纯依靠“公平的次序”来分发流量。可以把所有服务器看作一个循环列表，每次取出一台使用。

加权轮询（Weighted Round Robin）

如果服务器性能不均，可以给每台服务器设定一个权重值。性能高的服务器权重更高，在轮询过程中可以获得更多的请求。例如 A 权重 3，B 权重 2，C 权重 1，那么每 6 个请求中，A 处理 3 个，B 处理 2 个，C 处理 1 个。

实现时通常维护一个调度序列，保证请求分配平滑，避免连续命中同一台机器。

优点

• 实现极其简单，无状态，无需记录连接数或请求处理时间。
• 分配绝对均衡（无权重时），在服务器同构且请求处理时间相近的场景下效果良好。
• 计算开销极低，适合高吞吐量的网络层（如 DNS 轮询、L4 负载均衡）。

缺点

• 完全无视服务器实时负载。若某请求处理耗时远高于其他请求，可能导致某些服务器积压严重，而另一些却处于空闲。
• 对会话状态不友好。没有会话保持机制时，同一用户的连续请求可能被分发到不同服务器，需要应用层自行处理 Session 同步。
• 加权轮询的权重是静态的，无法动态反映实时负载变化。

适用场景

• 后端服务器性能完全一致，且请求处理时间差异很小（如静态资源服务、无状态 API）。
• DNS 层面的简单流量调度。
• 短期、轻量级的连接分发，不需要关心连接状态。

最小连接（Least Connections）

工作原理

最小连接算法将新到达的请求分配给当前活动连接数最少的服务器。它假设连接数能直接反映服务器的负载情况：连接数越多，负载越重。算法需要实时追踪每台服务器的活跃连接数，当请求到来时选择连接数最小的那一个；若有多个并列最小，可以使用轮询作为决胜策略。

加权最小连接（Weighted Least Connections）

结合服务器权重与连接数，计算公式通常为：当前连接数 / 权重，比值最小的服务器获得请求。权重表示服务器的处理能力，权重越大的机器可以承担更多的连接。

例如：服务器 A 权重 4，当前连接 20，比值 5；服务器 B 权重 2，当前连接 8，比值 4。B 的比值更小，因此请求发给 B。这样能兼顾静态性能差异与动态负载。

优点

• 动态感知负载：连接数能在一定程度上反映资源消耗，从而实现自适应的流量分配。
• 适合长连接场景：如 WebSocket、数据库连接、文件下载等，连接持续时间很长，连接数是最好的负载指标。
• 加权版本可以平滑融合异构集群，让高配机器承担更多请求。

缺点

• 连接数不等于真实负载。如果请求处理复杂度差异巨大，一个少量连接但都是重型计算任务的服务器可能早已不堪重负，但算法依然认为它“轻载”。
• 需要维护连接计数，带来少量状态开销（对大部分系统可忽略）。
• 在短连接、高瞬时并发的场景下，连接数变化迅速，可能出现短暂的分配不均衡。

适用场景

• 长连接应用（即时通讯、流媒体、数据库代理、WebSocket 网关）。
• 后端服务器性能异构，且请求处理资源消耗与连接数强相关。
• 需要动态调整流量，但没有精确到 CPU、内存级别的负载反馈时。

一致性哈希（Consistent Hashing）

工作原理

一致性哈希最初用于分布式缓存，后来广泛应用于需要会话保持或数据分片的负载均衡场景。它将服务器节点和服务请求的标识（如 IP、Session ID、用户 ID）映射到一个固定范围的哈希环上（通常 0 ~ 2^32-1）。

具体过程：

• 使用同一哈希函数计算每个服务器节点在环上的位置。
• 当请求到来时，计算请求标识的哈希值，沿环顺时针方向找到第一个节点，即为目标服务器。
• 增加或移除节点时，只会影响该节点在环上相邻区间的数据，其他映射保持不变。

虚拟节点

物理节点数量少时，哈希环上的分布可能很不均匀，造成数据倾斜。解决方法是引入虚拟节点：每个物理节点对应多个虚拟节点，虚拟节点均匀散布在环上。请求命中虚拟节点后，实际上映射到对应的物理节点。虚拟节点数量越多，分布越均匀，负载越平衡。

在负载均衡中的应用

一致性哈希最核心的优势是会话保持和最小化扰动。当同一用户的请求总是被路由到同一台后端服务器时，就可以利用服务器本地缓存或 Session，免去分布式存储的复杂性。扩容或缩容时，只需重映射最小量的请求，大幅减少缓存失效和状态迁移。

例如，在 Web 集群中，使用用户 ID 作为哈希键，可以确保同一用户长期连接同一台服务器，而服务器增减时，仅部分用户会被重新分配。

优点

• 极高的扩展性：节点动态增减时，只有少部分映射关系发生变化，不会引起全局雪崩。
• 天然支持会话亲和性：同一标识的请求稳定路由到同一后端，适合有状态服务。
• 去中心化：客户端或代理端只需维护一份哈希环信息，可用少量内存计算目标节点，无需中心协调。

缺点

• 无法根据实时负载动态调整。哈希环决定的路由是静态的，如果某节点瞬间过载，算法本身不会将其流量疏导到其他节点。
• 绝对负载均衡性依赖于虚拟节点的配置，配置不当会出现热点问题。
• 对请求标识有强依赖，若标识没有良好的散列特性，分布会失衡。
• 移除节点时的处理较复杂，需要考虑数据同步、故障转移等。

适用场景

• 分布式缓存系统（如 Memcached、Redis Cluster），要求扩容时缓存命中率影响最小。
• 需要会话保持的有状态服务（用户登录态、购物车）。
• 数据库分片、消息队列分区等需要数据亲和性的场景。
• 对服务扩缩容频繁且要求平滑过渡的架构。

三种算法对比总结

如何选择算法

• 如果你的后端全部无状态、服务器规格相同、响应时间一致，轮询是最简单高效的选择。
• 若请求大多是长连接，或者服务器性能不一，且你希望用连接数作为简单的负载指标，最小连接算法（或加权版本）会更合适。
• 当系统需要会话保持、本地缓存或平滑扩容，并且可以将请求与某个稳定的标识绑定，一致性哈希是不二之选。
• 复杂生产环境常常组合使用：例如用一致性哈希做第一层路由实现会话亲和，再在单个服务器内使用最小连接对后端微服务做负载分配。

理解这些基础算法的设计哲学，是搭建高可用、可扩展分布式系统的关键一步。根据实际业务需求灵活抉择，并通过压测验证，才能打磨出最适合自己的负载均衡方案。