一个大型网络平台能轻松面对数百万请求而不产生崩溃，负载均衡器（Load Balancer）是绝对的关键组件。

负载均衡器会在多个服务器之间分配工作流，也就是将用户请求转发到不同的机器上，可以确保服务的高可用性、响应速度和可扩展性。那么问题来了，负载均衡器的背后会有很多服务器，那么这些服务器之间要如何分配请求呢？显然这就涉及到了负载均衡算法，而了解核心的负载均衡算法可以让我们更好地设计和优化应用程序，以及故障排除。

负载均衡算法分为两大类：静态和动态。

下面我们就来介绍这每一种算法的区别，并深入讨论它的工作原理和优缺点。

Round Robin（轮询法）

静态负载均衡算法只负责将请求转发到服务器，而不会考虑服务器的实时条件和性能指标，所以它的优势是简单，缺点是适应性和精确性较差。而 Round Robin 在概念上是最简单的静态负载均衡算法，它会将请求均匀地转发给每一个服务器。

每来一个请求，就按照顺序转发给每一个服务器，比如请求 1 转发给 A，请求 2 转发给 B，请求 3 转发给 C。然后请求 4 再转发给 A，不断循环往复，就是将请求均匀分配到每个服务器上。当然我们这里只用三台服务器举例，更多的服务器也是同样的转发方式。

Round Robin 这种算法易于实现和理解，如果你的服务器配置都是一样的，那么 Round Robin 也是一个不错的负载均衡算法，虽然它比较简单。但现实情况是，不同服务器的处理能力可能不一致，那么此时 Round Robin 算法就会有几率导致处理能力较弱的服务器出现过载，因此你需要对服务器的资源进行监控。

Sticky Round Robin（粘性轮询法）

Sticky Round Robin 是 Round Robin 的扩展，它会将来自同一用户的连续请求发送到同一台服务器。

因为同一个用户的请求会转发到相同的服务器，那么就可以将相关数据提前保存起来，从而提升性能。但由于新来的用户是随机分配的，会容易出现负载不均衡的情况。

Weighted Round Robin（加权轮询法）

Weighted Round Robin 允许操作者为不同的服务器分配不同的权重或优先级，权重较高的服务器将按照比例接收更多的请求。

服务器 A、B、C 的权重比值为 3: 1: 1，所以假设有 5 个请求，服务器 A 要处理 3 个，服务器 B、C 分别处理 1 个。加权轮询法允许我们考虑服务器的异构能力，但缺点是必须手动配置权重，这在动态变化的场景中不够灵活。

IP/URL Hash

除了 Round Robin 系列算法之外，我们还可以对客户端的 IP 地址或请求的 URL 进行哈希，然后来决定请求要被映射到哪一台服务器中。

如果哈希函数选择得当，那么请求可以被均匀分发，然而选择一个好的哈希函数是具有挑战性的。

Least Connections（最少连接算法）

说完了静态负载均衡算法，我们再来看看动态负载均衡算法。相比静态，动态均衡算法在分发请求时会考虑到服务器的性能指标以及当前所剩资源，从而动态调整。

Least Connections 算法会将每个新的请求转发到当前活跃连接数最少的服务器，显然这就需要负载均衡器实时跟踪每个后端服务器上的活跃连接数。

如果再来一个新请求，它会被转发给服务器 A。因此最小连接算法可以灵活地对请求进行分配，以确保每台机器都能最大程度的处理请求，不会出现资源闲置。但如果连接不均匀地堆积，负载可能不经意地集中在某些服务器上。

Least Time（最少响应时间算法）

Least Time 和 Least Connections 类似，只不过它是将请求转发到延迟最低或者响应速度最快的服务器，负载均衡器需要持续评估每个服务器的延迟，并最终决定将请求转发到哪一个服务器上。

这种方法具有高度自适应性和反应迅速的特点，但它需要持续地监测后端服务器的延迟，这会带来显著的开销并增加复杂性。并且它也没有考虑每个服务器已经有多少个正在处理的请求，它只是将请求转发给延迟最低的服务器。

以上就是常见的 6 种负载均衡算法，总的来说，简单的静态算法和更自适应的动态算法之间存在明显的权衡，我们需要考虑特定的性能目标、能力和约束来选择负载均衡策略。

像轮询这样的静态算法很适合无状态的应用程序，而动态算法则有助于优化大型复杂应用的响应时间和可用性，至于具体选择哪种算法则取决于当前的业务。