负载均衡器在系统设计中的作用
当一个网站变得非常流行时 ，负载网站上的均衡计中流量增加，单个服务器的器系负载也增加。并发流量超过单个服务器的统设处理能力 ，导致网站变得对用户响应缓慢 。负载为了应对这些高数据量的均衡计中请求 ，以快速可靠的器系方式返回正确的响应，我们需要对服务器进行扩展。统设这可以通过向网络中添加更多的负载服务器 ，并将所有请求分布到这些服务器上来实现 。服务器租用均衡计中但是器系...谁来决定将哪个请求路由到哪个服务器呢 ？
Load-Balancer-System-Design-Interview.png
答案是...负载均衡器 。让我们详细了解一下负载均衡器的统设概念...
什么是负载均衡器？
负载均衡器就像站在服务器前面的“交通警察” ，将客户端请求分配到所有服务器上 。负载它会有效地分发一组请求操作（如数据库写请求、均衡计中缓存查询）到多个服务器上 ，器系并确保没有任何单个服务器承受过多的请求 ，从而降低应用程序的整体性能 。负载均衡器可以是一个物理设备，源码库也可以是运行在专用硬件上的虚拟实例，或者是一个软件进程 。
考虑一个场景 ，一个应用程序在单个服务器上运行 ，客户端直接连接到该服务器而没有负载均衡 。它看起来可能像下面这样...
我们需要讨论一下这种模型的两个主要问题 ：
单点故障 ：如果服务器崩溃或出现问题 ，整个应用程序将中断 ，对用户在一段时间内不可用。这会给用户创建一个不良的体验 ，这对于服务提供商来说是不可接受的建站模板 。服务器过载 ：一个Web服务器可以处理的请求数量是有限的。如果业务增长 ，请求数量增加 ，服务器将会过载 。为了解决不断增加的请求 ，我们需要添加更多的服务器 ，并将请求分发到这些服务器集群上 。为了解决上述问题 ，并分发请求的数量 ，源码下载我们可以在Web服务器前添加负载均衡器 ，通过将请求分发到多个服务器上 ，允许我们的服务通过在网络中添加任意数量的Web服务器来处理任何数量的请求 。我们可以将请求分散到多个服务器上 。如果由于某种原因 ，其中一个服务器下线 ，服务仍将继续。此外 ，每个请求的延迟将降低 ，因为每个服务器不再受限于RAM/磁盘/CPU 。
负载均衡器通常放置在哪里 ？
下面是负载均衡器可能放置的位置的图示...
负载均衡器的类型
我们可以通过三种方式实现负载均衡 。它们是：
1. 客户端中的软件负载均衡器顾名思义，模板下载所有负载均衡的逻辑位于客户端应用程序中（例如移动应用程序） 。应用程序将获得要与之交互的一组Web服务器/应用程序服务器的列表 。应用程序选择列表中的第一个服务器 ，并请求从服务器获取数据 。如果持续出现故障（在可配置的重试次数之后）且服务器变得不可用 ，则丢弃该服务器并选择列表中的其他服务器以继续处理过程。这是实施负载均衡的一种较便宜的方法 。
2. 服务中的软件负载均衡器这些负载均衡器是一种接收一组请求并根据一组规则重定向这些请求的软件 。这种负载均衡器提供了更大的灵活性 ，因为它可以安装在任何标准设备上（例如Windows或Linux机器） 。它也更便宜 ，因为无需购买或维护物理设备 ，与硬件负载均衡器不同 。
您可以选择使用现成的软件负载均衡器 ，也可以编写自己的自定义软件（例如，为Microsoft Office365的负载均衡负载活动目录查询） 。
3. 硬件负载均衡器顾名思义，我们使用物理设备来将流量分布到网络服务器的集群中。这些负载均衡器也称为第4-7层路由器 ，可以处理各种HTTP 、HTTPS 、TCP和UDP流量 。HLD（硬件负载均衡器）为外部世界提供虚拟服务器地址 。当来自客户端应用程序的请求到达时 ，它将连接转发到最适合的实际服务器 ，执行双向网络地址转换（NAT） 。HLD可以处理大量的流量 ，但价格昂贵 ，灵活性有限。
HLD会持续对每个服务器进行健康检查 ，确保每个服务器都能正确响应 。如果任何服务器没有产生期望的响应，它会立即停止向服务器发送流量。这些负载均衡器难以获取和配置 ，这就是很多服务提供商只将它们用作用户请求的第一个入口点的原因 。随后，内部软件负载均衡器用于将数据重定向到基础设施墙后面。
负载均衡的不同类别
通常 ，负载均衡器分为三个类别：
1. 第4层（L4）负载均衡器在OSI模型中，第4层是传输层（TCP/SSL） ，路由决策在此层进行 。第4层负载均衡器也称为网络负载均衡器，顾名思义 ，它利用网络层信息来进行流量路由决策。它可以控制每秒数百万次的请求 ，并处理所有形式的TCP/UDP流量 。决策将基于数据包使用的TCP或UDP端口以及其源和目标IP地址 。第4层负载均衡器还对请求数据包执行网络地址转换（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. 轮询法（Round Robin）请求在服务器之间按顺序或轮换方式分发 。例如 ，第一个请求发送到第一个服务器 ，第二个请求发送到第二个服务器，第三个请求发送到第三个服务器 ，依此类推 ，对所有请求进行处理 。这种方法容易实现 ，但它不考虑服务器上的负载 ，因此存在一个风险 ，即一个服务器接收到大量请求并变得过载 。
2. 加权轮询法（Weighted Round Robin）这与轮询技术非常相似 。唯一的区别在于，列表中的每个资源都被赋予加权分数 。根据加权分数 ，请求将分发到这些服务器。因此 ，在这种方法中，一些服务器获得整体请求的较大份额 。
3. 最少连接法（Least Connection Method）在此方法中，请求将被定向到具有最少请求或活动连接数量的服务器 。为了执行此操作 ，负载均衡器需要进行一些额外的计算 ，以识别具有最少连接数的服务器。与轮询方法相比 ，这可能会稍微昂贵一些 ，但评估是基于服务器上的当前负载 。当在流量在服务器之间不均匀分布时，这种算法非常有用 。
4. 最短响应时间法（Least Response Time Method）这种技术比最少连接法更复杂 。在这种方法中，请求将被转发到具有最少活动连接和最少平均响应时间的服务器 。服务器的响应时间代表了服务器的负载和整体预期用户体验。
5. 源IP哈希（Source IP Hash）在这种方法中，请求将根据客户端的IP地址发送到服务器。客户端的IP地址和接收计算实例的IP地址将使用密码算法进行计算 。