许多人在日常生活中使用不同的网络服务，他们也从这些服务中得到快速响应。但是，大多数用户并不知道负责将内容传送到 Internet 的过程的规模之大。他们不知道在幕后扩展系统的漫长过程。当成千上万的用户同时在网站上发出请求时，这个漫长的过程涉及跨多个服务器分发请求。
当一个网站变得非常流行时，该网站上的流量就会增加，单个服务器上的负载也会增加。并发流量压倒了单个服务器，网站对用户来说变得更慢。为了满足这些大量数据的请求并以快速可靠的方式返回正确的响应，我们需要扩展服务器。这可以通过向网络添加更多服务器并在这些服务器之间分发所有请求来完成。但…。谁来决定哪个请求应该路由到哪个服务器……？？？
答案是……负载均衡器。让我们详细了解负载均衡器的概念……
什么是负载均衡器？
负载均衡器充当“交通警察”，位于您的服务器前面，并在所有服务器上路由客户端请求。它只是将请求的操作集（数据库写入请求、缓存查询）有效地分布在多个服务器上，并确保没有单个服务器承担过多导致应用程序整体性能下降的请求。负载均衡器可以是物理设备或运行在专用硬件或软件进程上的虚拟化实例。
考虑一个应用程序在单个服务器上运行并且客户端在没有负载平衡的情况下直接连接到该服务器的场景。它看起来像下面这样……
我们需要讨论这个模型的两个主要问题……
- 单点故障：如果服务器出现故障或服务器发生问题，整个应用程序将被中断，并且在一段时间内对用户不可用。它会给用户带来糟糕的体验，这是服务提供商无法接受的。
- 服务器过载： Web 服务器可以处理的请求数量将受到限制。如果业务增长并且请求数量增加，服务器将过载。为了解决越来越多的请求，我们需要添加更多的服务器，我们需要将请求分发到服务器集群。
为了解决上述问题并分配请求数量，我们可以在 Web 服务器前面添加一个负载均衡器，并通过在网络中添加任意数量的 Web 服务器来允许我们的服务处理任意数量的请求。我们可以将请求分散到多个服务器上。出于某种原因，如果其中一台服务器脱机，服务将继续。此外，每个请求的延迟都会下降，因为每个服务器不再是 RAM/磁盘/CPU 的瓶颈。
- 负载平衡器最小化服务器响应时间并最大化吞吐量。
- 负载均衡器通过仅向在线服务器发送请求来确保高可用性和可靠性
- 负载均衡器会持续进行健康检查，以监控服务器处理请求的能力。
- 负载均衡器根据请求的数量或需求添加或删除服务器的数量。
负载均衡器通常放置在哪里？
下面是可以放置负载均衡器的图像……
- 在客户端应用程序/用户和服务器之间
- 在服务器和应用程序/作业服务器之间
- 在应用服务器和缓存服务器之间
- 在缓存服务器和数据库服务器之间
负载均衡器的类型
我们可以通过三种方式实现负载均衡。这些是…
1. 客户端中的软件负载均衡器
顾名思义，负载平衡的所有逻辑都驻留在客户端应用程序（例如手机应用程序）上。将向客户端应用程序提供要与之交互的 Web 服务器/应用程序服务器列表。应用程序选择列表中的第一个并从服务器请求数据。如果任何故障持续发生（在可配置的重试次数之后）并且服务器变得不可用，它会丢弃该服务器并从列表中选择另一个以继续该过程。这是实现负载平衡的最便宜的方法之一。
2. 服务中的软件负载均衡器
这些负载均衡器是接收一组请求并根据一组规则重定向这些请求的软件。此负载平衡器提供了更大的灵活性，因为它可以安装在任何标准设备（例如：Windows 或 Linux 机器）上。与硬件负载平衡器不同，它也更便宜，因为不需要购买或维护物理设备。您可以选择使用现成的软件负载平衡器，也可以编写自定义软件（例如：Microsoft Office365 的负载平衡 Active Directory 查询）以进行负载平衡。
3. 硬件负载均衡器
顾名思义，我们使用物理设备在网络服务器集群中分配流量。这些负载平衡器也称为第 4-7 层路由器，它们能够处理各种 HTTP、HTTPS、TCP 和 UDP 流量。 HLD 向外界提供虚拟服务器地址。当请求来自客户端应用程序时，它会将连接转发到最合适的真实服务器，执行双向网络地址转换 (NAT)。 HLD 可以处理大量流量，但价格昂贵，而且灵活性有限。
HLD 不断对每台服务器进行健康检查，并确保每台服务器都正确响应。如果任何服务器没有产生所需的响应，它会立即停止向服务器发送流量。这些负载均衡器的获取和配置成本很高，这就是许多服务提供商仅在用户请求的第一个入口点使用它的原因。后来内部软件负载平衡器用于重定向基础设施墙后面的数据。
不同类别的负载均衡
通常，负载均衡器分为三类……
1. 第 4 层 (L4) 负载均衡器
在 OSI 模型中，第 4 层是传输层（TCP/SSL），在此进行路由决策。第 4 层负载平衡器也称为网络负载平衡，顾名思义，它利用网络层信息为流量做出路由决策。它每秒可以控制数百万个请求并处理所有形式的 TCP/UDP 流量。该决定将基于数据包使用的 TCP 或 UDP 端口及其源和目标 IP 地址。 L4 负载平衡器还对请求数据包执行网络地址转换 (NAT)，但它不会检查每个数据包的实际内容。此类负载平衡器通过在 IP 地址、交换机和路由器之间分配流量来最大化利用率和可用性。
2. 7 层 (L7) 负载均衡器
第 7 层负载均衡器也称为应用程序负载均衡器或HTTP(S) 负载均衡器。它是最古老的负载平衡形式之一。在 OSI 模型中，第 7 层是执行路由决策的应用层 (HTTP/HTTPS)。第 7 层将内容交换添加到负载均衡中，它使用 HTTP 标头、cookie、统一资源标识符、SSL 会话 ID 和 HTML 表单数据等信息来决定跨服务器的路由请求。
3. 全局服务器负载平衡 (GSLB)
今天，许多应用程序托管在多个地理位置的云数据中心。这就是许多组织转向不同负载均衡器的原因，该负载均衡器可以向任何设备或位置提供更高可靠性和更低延迟的应用程序。随着负载均衡器功能的显着变化，GSLB 满足了 IT 组织的这些期望。 GSLB 扩展了 L4 和 L7 服务器在不同地理位置的能力，并高效地跨多个数据中心分发大量流量。它还确保最终用户在数字工作空间中导航多个应用程序和服务时获得一致的体验。
负载均衡算法
我们需要一个负载平衡算法来决定哪个请求应该重定向到哪个后端服务器。不同的系统使用不同的方式从负载均衡器中选择服务器。公司根据配置使用各种负载平衡算法技术。下面给出了一些常见的负载平衡算法：
1. 循环赛
请求以顺序或轮换的方式分布在服务器上。例如，第一个请求发送到第一个服务器，第二个请求发送到第二个服务器，第三个请求发送到第三个服务器，然后对所有请求继续。它很容易实现，但它不考虑服务器上已有的负载，因此存在其中一台服务器接收大量请求并变得过载的风险。
2. 加权循环
它与循环技术非常相似。唯一的区别是，列表中的每个资源都提供了一个加权分数。根据加权分数，请求被分发到这些服务器。所以在这种方法中，一些服务器在整个请求中获得了更大的份额。
3. 最少连接法
在这种方法中，请求将被定向到请求数或活动连接数最少的服务器。为此，负载均衡器需要做一些额外的计算来识别连接数最少的服务器。与循环方法相比，这可能会稍微贵一些，但评估是基于服务器上的当前负载。当在服务器之间不均匀分布的流量中存在大量持久连接时，该算法最有用。
4. 最短响应时间法
这种技术比最少连接方法更复杂。在这种方法中，请求被转发到具有最少活动连接和最少平均响应时间的服务器。服务器所花费的响应时间代表了服务器上的负载和总体预期的用户体验。
5.源IP哈希
在这种方法中，请求是根据客户端的 IP 地址发送到服务器的。客户端和接收计算实例的 IP 地址是使用加密算法计算的。
如何在系统设计面试中使用负载平衡？
在您的系统设计面试中，您将被问到某种可扩展性问题，您必须解释负载均衡器如何帮助分配流量以及它如何确保应用程序中服务的可扩展性和可用性。您需要从本文中牢记的总体概念是……
- 负载平衡器可实现弹性可扩展性，从而提高数据的性能和吞吐量。它允许您保留许多数据副本（冗余）以确保系统的可用性。如果服务器出现故障或出现故障，您将有备份来恢复服务。
- 负载均衡器可以放置在任何软件层。
- 许多公司使用硬件和软件来实现负载平衡器，这取决于他们系统中的不同规模点。