系统设计：负载均衡器

原文：towardsdatascience.com/system-design-load-balancer-9a3582176f9b

简介

大型分布式应用每秒处理超过数千个请求。在某个时刻，处理单个机器上的请求变得不再可能。这就是为什么软件工程师关心水平扩展，即整个系统持续地组织在多个服务器上。在这种配置中，每个服务器只处理所有请求的一部分，基于其容量、性能和几个其他因素。

服务器之间的请求可以以不同的方式分配。在这篇文章中，我们将研究最流行的策略。顺便说一下，不可能概述最佳策略：每种策略都有其自身的特性，应根据系统配置来选择。

负载均衡器的使用

负载均衡器可以出现在不同的应用层。例如，大多数 Web 应用由前端、后端和数据库层组成。因此，可以在不同的应用部分使用多个负载均衡器来优化请求路由：

• 在用户（客户端）和前端服务器之间；

• 在前端和后端服务器之间；

• 在后端服务器和数据库之间。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/c4a597a5b4b86886fc7887201729c8d5.png

负载均衡器可以出现在不同的架构层。

尽管在不同的层上存在负载均衡器，但相同的平衡策略可以应用于所有这些层。

健康检查

在由多个服务器组成的系统中，任何服务器在任何时刻都可能过载、失去网络连接，甚至崩溃。为了跟踪它们的活跃状态，必须由一个独立的监控服务定期执行常规的健康检查。此服务定期向所有机器发送请求并分析它们的响应。

大多数时候，监控系统检查返回响应的速度以及机器当前正在处理的活跃任务或连接的数量。如果一个机器在给定的时间限制内没有提供答案，那么监控服务可以启动一个触发器或程序，以确保机器尽快恢复正常功能状态。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/c9a66d5badf08e60dbed014a30056ef4.png

健康检查示意图：监控系统发送请求以检查服务器的响应时间。由于第三个服务器没有返回响应，监控系统触发一个事件来重启它。所有接收到的统计数据信息都发送到负载均衡器以调整其参数。

通过分析这些传入的监控统计数据，负载均衡器可以调整其算法以加速平均请求处理时间。这一方面本质上与动态平衡算法（在下面的章节中讨论）相关，这些算法始终依赖于系统中的活跃机器状态。

静态与动态算法

平衡算法可以分为两组：静态和动态：

• 静态算法是简单的平衡策略，仅依赖于系统预先定义的静态参数。最常考虑的参数是 CPU、内存限制、超时、连接限制等。尽管简单，静态策略在处理机器性能特征快速变化的情况时并不稳健。因此，静态算法更适合确定性场景，在这种情况下，系统在一段时间内接收到的请求比例相等，需要相对相同数量的资源来处理。

• 另一方面，动态算法依赖于系统的当前状态。监控的统计数据会被考虑并用于定期调整任务分配。通过在实时拥有更多变量和信息，动态算法可以使用高级技术在任何给定情况下产生更均匀的任务分配。然而，定期的健康检查需要处理时间，可能会影响系统的整体性能。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/357bb46f880617218ed7c895bf3e4a46.png

静态与动态平衡算法的比较

平衡策略

在本节中，我们将发现最流行的平衡机制及其变体。

0. 随机

对于每个新的请求，随机方法会随机选择处理该请求的服务器。

尽管算法简单，但在系统服务器共享相似的性能参数且从未过载的情况下，随机算法表现良好。然而，在许多大型应用中，服务器通常承载着大量的请求。这就是为什么应该考虑其他平衡方法。

1A. 轮询

轮询可以说是随机方法之后最简单的现有平衡技术。每个请求都是根据其在请求序列中的绝对位置发送到服务器的：

• 请求 1 分配给了服务器 1；

• 请求 2 分配给了服务器 2；

• …

• 请求 k 分配给了服务器 k。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/1701b0e7a1df757948b54d92d0f404bc.png

轮询示例。所有服务器按顺序处理请求。

当服务器数量达到最大值时，轮询算法将从第一个服务器重新开始。

1B. 加权轮询

轮询有一个基于性能能力（如 CPU 和其他系统特性）的加权变体，每个服务器都被分配了一个权重。然后，每个服务器接收与其权重成比例的请求数量，与其他服务器相比。

这种方法确保请求根据系统中每个服务器的独特处理能力均匀分布。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/7c346e5d023efb5857690d4e856379e3.png

加权轮询示例。在配置阶段，所有服务器都被分配了一个与其性能能力（例如 CPU）相对应的权重。之后，每个服务器都会接收到与其权重成比例的请求数量。

1C. 粘性轮询

在粘性轮询版本中，特定客户端的第一个请求根据正常的轮询规则发送到服务器。然而，如果客户端在特定时间段内或会话生命周期内再次发起请求，那么请求将发送到之前相同的服务器。

这确保了来自任何客户端的所有请求都由同一服务器一致处理。这种方法的优点是，与同一客户端的请求相关的所有信息都只存储在单个服务器上。想象一下，一个新的请求正在到来，它需要从特定客户端的先前请求中获取信息。使用粘性轮询，可以从单个服务器快速访问所需数据，如果从多个服务器检索相同数据，这将快得多。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/e705109b56546849f0711f6b890f6a9d.png

粘性轮询示例。每个客户端的会话都被映射到特定的服务器，并且所有请求都发送到该服务器。

2A. 最少连接

最少连接是一种动态方法，其中当前请求被发送到当前处理最少活跃连接或请求的服务器。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/8d8819c0ce0bbd24a3754b8222d7e9df.png

最少连接示例。具有最少活跃连接的服务器接收当前请求。

2B. 加权最少连接

最少连接数的加权版本的工作方式与原始版本相同，只是每个服务器都与一个权重相关联。为了决定哪个服务器应该处理当前请求，将每个服务器的活跃连接数除以其权重，然后处理请求的服务器是结果值最低的服务器。

3. 最小响应时间

与考虑具有最少活跃连接数的服务器不同，这种平衡算法选择在过去一定时间内平均响应时间最低的服务器。

有时这种方法与最少活跃连接数结合使用：

• 如果只有一个服务器具有最少的连接数，那么它将处理当前请求；

• 如果有多个服务器的连接数相同，那么将选择其中响应时间最低的服务器来处理请求。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/515281fbaf2fcfd4411426ad9b90679a.png

最少连接数与最小响应时间组合的示例。具有最少连接数的服务器接收当前请求。如果相等，则选择响应时间最低的服务器。

4A. IP 哈希

负载均衡器有时会根据各种客户端属性做出决策，以确保所有之前的请求和数据都只存储在一个服务器上。这个局部性方面允许在系统中快速访问本地用户数据，而无需向其他服务器发送额外的请求来检索数据。

实现这一目标的一种方法是将客户端 IP 地址纳入哈希函数，该函数将给定的 IP 地址与一个可用的服务器关联起来。

理想情况下，选定的哈希函数必须将所有传入请求均匀地分布在所有服务器上。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/27075d4255fd851fe26c1b721c2548db.png

IP 哈希的示例。请求根据客户端 IP 地址计算出的哈希值路由到服务器。

实际上，IP 哈希的局部性方面与一致性哈希很好地协同工作，这****保证了用户的数据在任何时刻都可靠地存储在一个地方，即使在服务器关闭的情况下。

系统设计：一致性哈希

4B. URL 哈希

URL 哈希与 IP 哈希类似，只是请求的 URL 被哈希，而不是 IP 地址。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/668c05a50cee093dd8aeb0934e011b66.png

URL 哈希示例。请求根据执行请求的域名计算出的哈希值路由到服务器。

当我们希望在单个服务器上存储特定类别或领域的信息，且与请求客户端无关时，这种方法很有用。例如，如果一个系统经常汇总所有用户收到的支付信息，那么定义一组所有可能的支付请求并将它们始终哈希到单个服务器上将是高效的。

5. 组合

通过利用所有先前方法的信息，可以结合它们以推导出针对每个系统独特需求的新方法。

例如，可以实施一种投票策略，其中将n个独立平衡策略的决策汇总。最频繁出现的决策被选为最终答案，以确定哪个服务器应该处理当前请求。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ac699568f3c8296831f0363d73ff8330.png

投票策略示例。服务器 4 被各种负载均衡器选为最常选择的服务器。

重要的是不要使事情过于复杂，因为更复杂的策略设计需要额外的计算资源。

结论

负载均衡是系统设计中的关键主题，尤其是在高负载应用中。在本文中，我们探讨了各种静态和动态平衡算法。这些算法在复杂性和做出最佳决策所需的计算资源之间提供了权衡。

最终，没有单一的平衡算法可以在所有场景中都是最佳选择。适当的选择取决于多个因素，如系统配置设置、需求和传入请求的特征。

资源

• 负载均衡（计算）| 维基百科

除非另有说明，所有图像均为作者所有。