常用负载均衡详解

一、介绍

在互联网场景下，负载均衡（Load Balance）是分布式系统架构设计中必须考虑的一个环节，它通常是指将负载流量（工作任务、访问请求）平衡、分摊到多个操作单元（服务器、组件）上去执行的过程。
目的在于提供负载配比，解决性能、单点故障（高可用）和扩展性（水平伸缩）等问题。

在这里插入图片描述

以上图为例，随着互联网的兴盛，类似淘宝、京东等网站的访问量逐年提升。原先的单台服务或者单集群模式已经远不能满足需求了，这时候就需要横向扩展多台服务或者多个集群来分摊压力，达到提升系统吞吐的能力，这就是著名的分治理论。

但服务器增加了，他们之间的流量负载也必须有一个组件来管控，这就是负载均衡的作用。负载均衡提供了多种算法策略来满足不同的业务负载需求，下面我们详细来讲解下。

二、几种常见的负载均衡策略

2.1 轮询（Round Robin）

RR轮询，即Round Robin。按照请求的顺序轮流分配到不同的服务器，循环往复。这种策略适用于服务器性能相近的情况，可以平均分配负载。但如果某个服务器性能较差或者偶发故障，会影响整个系统的性能和稳定性。
如下图所示：

在这里插入图片描述

分别有5条请求过来
按照顺序轮流分配，web-server1 分配到 1、4，web-server2 分配到 2、5，web-server3 分配到 3。

2.2 按照权重轮询（Weighted Round Robin）

即加权轮询，给不同的服务器分配不同的权重，根据权重比例来决定分配请求的数量。这种策略适用于后端服务器性能不均的情况，可以根据实际情况灵活调整。使得性能更好的服务器能够处理更多的请求，从而提高整个系统的处理效率。
如下图所示：
在这里插入图片描述

分别有5条请求过来
web-server1 因为权重为60%，分配到 1、2、3
web-server2 权重为20%，分配到 4
web-server3 权重为20%，分配到 5

2.3 IP 哈希（IP Hash）

根据客户端的IP地址计算哈希值，将请求分配给特定的服务器，保证相同IP的客户端请求始终发送到同一台服务器。这种策略适用于需要保持客户端会话一致性的场景，例如需要维护用户session的Web应用。
如下图所示：
在这里插入图片描述

IP为192.168.0.99的流量hash计算对应web-service1，所以将1、4流量分配到第1台服务器
IP为192.168.0.96、192.168.0.98的流量hash计算对应web-service3，所以将2、3流量分配到第1台服务器

需要注意的是，虽然IP哈希算法可以确保来自同一IP地址的请求被发送到同一台服务器，这在一些需要保持会话一致性的场景中很有用，但它也可能导致负载不均衡。例如，如果某个IP地址发送了大量的请求，那么处理这些请求的服务器可能会过载，而其他服务器可能处于空闲状态。因此，在使用IP哈希算法时，需要仔细考虑其适用性和潜在的风险。需要对极端情况进行评估，笔者就曾经踩过坑。

2.4 最少连接（Least Connections）

将请求分配给当前连接数最少的服务器，以实现负载均衡。这种策略适用于处理长连接请求的场景，如WebSocket、FTP服务。通过记录每台服务器当前正在处理的连接数，将新请求分配给连接数最少的服务器，可以有效避免某些服务器过载导致性能下降的情况。
如下图所示：
在这里插入图片描述

web-service1、web-service2、web-service3的连接数分别是11、15、2，所以 web-service3 相对空闲
1、2、3请求到来的时候，web-service3持续空闲，而web-service1、web-service2持续hold住连接，所以请求分配给web-service3
该算法对服务器性能差异较大的情况有较好的适应性，请求优先发送到连接数较少的服务器，有助于避免某些服务器过载，提升性能。
缺少点就是需要实时监测连接数，并且每个流量来的时候都要判断下再分发，在流量繁忙时增加了服务器开销，影响性能。

2.5 最短响应时间（Least Response Time）

短响应时间（Least Response Time）算法在负载均衡领域中被广泛应用。这种策略适用于对响应时间有严格要求的应用场景。通过实时监测每台服务器的响应时间，将请求分配给响应时间最短的服务器，可以确保用户获得最快的响应，提升用户体验。
如下图所示：
在这里插入图片描述

同样，这种算法也有自己的优缺点：

优点：

1、提高用户体验：通过选择响应时间最短的服务器来处理请求，可以显著减少用户的等待时间，提高整体的用户体验。
2、动态负载均衡：该算法能够实时地根据服务器的响应时间来调整负载分配，确保每台服务器都能根据其实际性能来处理相应数量的请求。
3、处理高峰期流量：在流量高峰期，最短响应时间算法可以确保请求被迅速处理，避免系统拥堵和延迟。

缺点：

1、计算开销：为了确定每台服务器的响应时间，系统需要不断地进行监测和计算，这可能会增加额外的系统开销。
2、瞬时波动：由于该算法主要依赖于实时的响应时间，因此可能会受到瞬时波动的影响。例如，如果某台服务器在某一时刻由于某种原因（如临时的高负载）响应时间变长，它可能会被暂时排除在负载均衡之外，即使其实际性能可能仍然优于其他服务器。
3、可能忽略其他性能指标：最短响应时间算法主要关注响应时间，可能忽略了其他重要的性能指标，如服务器的处理能力、内存占用等。在某些情况下，这可能导致负载分配不够均衡。