Nginx：负载均衡小专题（一）：https://developer.aliyun.com/article/1582113
4. 负载均衡算法详解
4.1 轮询（Round Robin）
轮询是Nginx默认的负载均衡算法，也是最简单的一种算法。在这种算法下，Nginx会按照上游服务器在配置文件中的顺序，依次将请求分配给每个服务器。当分配到最后一个服务器时，Nginx会重新从第一个服务器开始分配。
轮询算法的工作原理如下：
假设我们有三个上游服务器A、B和C。第一个请求会被发送到服务器A，第二个请求会被发送到服务器B，第三个请求会被发送到服务器C，第四个请求又会回到服务器A，如此循环。
轮询算法的配置非常简单，只需要在upstream块中列出服务器即可：
upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
在这个配置中，Nginx会平均地将请求分配到三个服务器上。
轮询算法的优点是简单、公平，每个服务器都有机会处理请求。它适用于上游服务器性能相近，且请求处理时间相对均衡的场景。
然而，轮询算法也有其局限性。它不考虑服务器的当前负载状况，可能会导致某些性能较弱的服务器过载。此外，它也不能保证来自同一客户端的请求总是被发送到同一服务器，这可能会影响需要会话一致性的应用。
4.2 加权轮询（Weighted Round Robin）
加权轮询是轮询算法的一个变体，它允许管理员为每个上游服务器分配一个权重值。权重值决定了服务器接收请求的比例。权重越高的服务器会接收到更多的请求。
加权轮询算法的工作原理如下：
假设我们有三个上游服务器A、B和C，它们的权重分别是4、2和1。在一个完整的分配周期中（总共7个请求），服务器A会收到4个请求，服务器B会收到2个请求，服务器C会收到1个请求。
加权轮询的配置方法是在server指令中使用weight参数：
upstream backend { server 192.168.1.10:8080 weight=4; server 192.168.1.11:8080 weight=2; server 192.168.1.12:8080 weight=1; }
在这个配置中，第一个服务器的请求处理能力是第三个服务器的4倍，第二个服务器的请求处理能力是第三个服务器的2倍。
加权轮询算法的优点是可以根据服务器的性能来分配负载，性能较好的服务器可以处理更多的请求。这种算法适用于上游服务器性能不均衡的场景。
然而，加权轮询算法仍然不考虑服务器的实时负载状况，也不能保证会话一致性。此外，确定合适的权重值可能需要一定的经验和持续的调整。
4.3 最少连接（Least Connections）
最少连接算法是一种动态负载均衡算法，它会将新的请求分配给当前活动连接数最少的服务器。这种算法的目标是使所有服务器的活动连接数尽可能均衡。
最少连接算法的工作原理如下：
当新的请求到达时，Nginx会检查所有上游服务器当前的活动连接数。然后，它会将请求发送到活动连接数最少的服务器。如果有多个服务器的活动连接数相同且最少，Nginx会使用轮询算法在这些服务器之间选择。
要启用最少连接算法，需要在upstream块中添加least_conn指令：
upstream backend { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
最少连接算法的优点是可以更好地平衡服务器的负载，特别是在请求处理时间差异较大的情况下。它可以防止某些服务器因长时间处理请求而过载，而其他服务器却处于空闲状态。
然而，最少连接算法也有其局限性。它可能会导致新的请求集中到刚刚启动的服务器上，因为新服务器的连接数最少。此外，频繁地检查服务器的连接数可能会带来一些额外的开销。
最少连接算法适用于上游服务器性能相近，但请求处理时间差异较大的场景。它可以更好地应对突发流量和长连接请求。
在实际应用中，可以根据具体的需求和场景选择合适的负载均衡算法。有时候，可能需要结合多种算法或进行自定义配置来达到最佳的负载均衡效果。
4.4 IP 哈希（IP Hash）
IP哈希是一种特殊的负载均衡算法，它根据客户端的IP地址来确定请求应该被发送到哪个上游服务器。这种算法的主要目的是确保来自同一IP地址的请求总是被发送到同一个服务器，从而实现会话持久性。
IP哈希算法的工作原理如下：
当一个新的请求到达时，Nginx会计算客户端IP地址的哈希值。然后，它会使用这个哈希值来选择一个上游服务器。由于同一个IP地址的哈希值总是相同的，所以来自同一IP的请求会始终被发送到同一个服务器（除非该服务器不可用）。
要启用IP哈希算法，需要在upstream块中添加ip_hash指令：
upstream backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
IP哈希算法的主要优点是可以实现简单的会话持久性，这对于一些需要保持用户状态的应用非常有用。例如，在电子商务网站中，可以确保用户的购物车信息始终存储在同一个服务器上。
然而，IP哈希算法也有一些局限性。首先，它可能导致负载分配不均衡，特别是当某些IP地址产生大量流量时。其次，如果使用了网络地址转换（NAT），多个客户端可能会共享同一个IP地址，这会影响负载均衡的效果。最后，如果上游服务器的数量发生变化，大部分客户端的请求可能会被重新分配到不同的服务器，这可能会导致会话丢失。
为了缓解这些问题，Nginx提供了一些额外的配置选项。例如，可以使用keepalive指令来维护与上游服务器的持久连接，这可以提高性能并减少会话丢失的风险。
4.5 通用哈希（Generic Hash）
通用哈希是一种更灵活的负载均衡算法，它允许管理员基于请求的任意关键字来进行负载均衡。这个关键字可以是任何字符串，通常是请求的某个属性，如URI、请求参数或者HTTP头部的值。
通用哈希算法的工作原理如下：
Nginx会计算指定关键字的哈希值，然后使用这个哈希值来选择一个上游服务器。只要关键字保持不变，请求就会被一致地发送到同一个服务器。
要启用通用哈希算法，需要在upstream块中使用hash指令，并指定用于计算哈希的关键字：
upstream backend { hash $request_uri consistent; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
在这个例子中，我们使用请求的URI（$request_uri）作为哈希关键字。consistent参数启用了一致性哈希，这可以在添加或删除服务器时最小化请求重新分配。
通用哈希算法的主要优点是其灵活性。它可以基于任何请求属性来实现负载均衡，这使得它能够适应各种复杂的场景。例如，可以基于用户ID来实现会话持久性，或者基于请求的某个参数来将相关的请求发送到同一个服务器。
然而，通用哈希算法也有一些注意事项。首先，选择合适的哈希关键字很重要，它应该能够均匀地分布请求。其次，如果哈希关键字的分布不均匀，可能会导致负载不平衡。最后，如果不使用一致性哈希，更改服务器配置可能会导致大规模的请求重新分配。
4.6 最少时间（Least Time）- 仅 Nginx Plus
最少时间算法是Nginx Plus（商业版）提供的一种高级负载均衡算法。这种算法会将新的请求发送到估计响应时间最短的服务器。响应时间的估计基于两个因素：服务器的当前活动连接数和服务器的平均响应时间。
最少时间算法的工作原理如下：
当新的请求到达时，Nginx Plus会计算每个上游服务器的估计响应时间。这个估计值是基于服务器的当前活动连接数和之前请求的平均响应时间。然后，Nginx Plus会将请求发送到估计响应时间最短的服务器。
要启用最少时间算法，需要在upstream块中使用least_time指令：
upstream backend { least_time header; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
least_time指令支持三个参数：
header：使用接收响应头的时间作为响应时间。last_byte：使用接收完整响应的时间作为响应时间。inflight：考虑不完整请求的数量。
最少时间算法的主要优点是它能够更精确地平衡负载，特别是在服务器性能不均衡或请求处理时间差异较大的情况下。它可以有效地将请求分配到最快的可用服务器，从而提高整体的响应速度和系统吞吐量。
然而，最少时间算法也有一些限制。首先，它需要Nginx Plus的商业许可。其次，它可能会导致性能较好的服务器接收更多的请求，这可能不适合某些需要均匀分配请求的场景。最后，频繁地计算和比较响应时间可能会带来一些额外的开销。
在实际应用中，最少时间算法特别适合那些对响应时间敏感的应用，如实时交易系统或在线游戏服务器。它可以确保用户请求被发送到当前最快的服务器，从而提供最佳的用户体验。
IP哈希、通用哈希和最少时间这三种算法都有其特定的应用场景。选择合适的负载均衡算法需要考虑多个因素，包括应用的特性、服务器的性能、网络环境以及业务需求等。在某些情况下，可能需要结合使用多种算法或进行自定义配置来实现最佳的负载均衡效果。
- 文章信息 -
Author: 李俊才 (jcLee95)
Visit me at CSDN: https://jclee95.blog.csdn.net
My WebSite：http://thispage.tech/
Email: 291148484@163.com.
Shenzhen China
Address of this article:https://blog.csdn.net/qq_28550263/article/details/140280776
HuaWei:https://bbs.huaweicloud.com/blogs/430621
5. 高级负载均衡配置
5.1 会话持久性（Session Persistence）
会话持久性用来确保来自同一客户端的请求始终被发送到同一台服务器。这对于维护用户会话状态、提高缓存效率以及确保某些应用程序的正确功能至关重要。
接下来，我们分别介绍Nginx中实现会话持久性主要的几种方法。
5.1.1 IP哈希
IP哈希是实现会话持久性最简单的方法之一。它使用客户端的IP地址作为选择上游服务器的依据。配置方法如下：
upstream backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
IP哈希的优点是配置简单，不需要修改应用程序。但它也有一些限制：如果客户端使用代理或NAT，多个用户可能会被视为同一个IP，导致负载不均衡。此外，如果服务器配置发生变化，大部分客户端的请求可能会被重新分配。
5.1.2 粘性cookie
粘性cookie是一种更精确的会话持久性方法。Nginx会在响应中添加一个特殊的cookie，其中包含了处理请求的服务器信息。后续的请求会携带这个cookie，Nginx根据cookie的值将请求路由到相同的服务器。
要使用粘性cookie，需要在upstream块中使用sticky指令：
upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; sticky cookie srv_id expires=1h domain=.example.com path=/; }
在这个配置中，srv_id是cookie的名称，expires=1h设置cookie的过期时间为1小时，domain和path定义了cookie的作用域。
粘性cookie的优点是精确度高，可以准确地将请求路由到特定的服务器。缺点是需要在客户端存储额外的cookie，可能会稍微增加带宽使用。
5.1.3 路由哈希
路由哈希是一种基于请求特定属性进行负载均衡的方法。它可以用来实现会话持久性，特别是在不能或不想使用cookie的情况下。例如，可以基于用户ID或会话ID来路由请求：
upstream backend { hash $arg_user_id consistent; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }
在这个配置中，$arg_user_id是一个Nginx变量，表示URL查询参数中的user_id。consistent参数启用了一致性哈希，这可以在添加或删除服务器时最小化请求的重新分配。
路由哈希的优点是灵活性高，可以基于任何请求属性来实现会话持久性。缺点是可能需要修改应用程序以确保关键的路由信息（如用户ID）在每个请求中都可用。
5.1.4 注意事项
实现会话持久性时，需要考虑以下几点：
- 性能影响：会话持久性可能会导致负载分配不均衡，特别是当某些会话比其他会话更活跃时。
- 容错：如果启用了会话持久性，当某个服务器不可用时，原本发送到该服务器的请求可能会丢失会话数据。可以考虑使用共享会话存储（如Redis）来缓解这个问题。
- 扩展性：在添加或删除服务器时，会话持久性可能会受到影响。使用一致性哈希可以最小化这种影响。
- 安全性：使用cookie进行会话持久性时，需要注意保护cookie不被篡改。可以考虑使用加密或签名来增强安全性。
选择合适的会话持久性方法需要根据具体的应用需求和基础设施情况来决定。在某些情况下，可能需要在应用层面实现会话管理，而不是依赖负载均衡器。无论选择哪种方法，都需要仔细测试和监控，以确保系统的性能和可靠性。
5.2 备份服务器（Backup Servers）
Nginx的负载均衡配置中，备份服务器是一个非常有用的概念。备份服务器通常在主服务器不可用时才会被使用，这为系统提供了额外的冗余和可靠性。当所有的主服务器都无法响应请求时，Nginx会将流量转发到备份服务器，从而确保服务的持续可用性。
要在Nginx中配置备份服务器，我们需要在upstream块中的server指令上使用backup参数。以下是一个基本的配置示例：
upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080 backup; }
备份服务器的工作机制如下：
- Nginx首先尝试将请求发送到主服务器。
- 如果所有主服务器都无法响应（例如，由于服务器宕机、网络问题或达到最大连接数），Nginx会尝试使用备份服务器。
- 一旦有主服务器恢复可用，Nginx会停止向备份服务器发送新的请求，转而使用恢复的主服务器。
备份服务器配置的一个重要优点是它提供了一种简单而有效的故障转移机制。这对于维护高可用性服务特别有用，可以在主服务器出现问题时保持服务的连续性。
然而，使用备份服务器时也需要注意一些事项：
- 容量规划：备份服务器应该有足够的资源来处理所有主服务器的负载。在最坏的情况下，备份服务器可能需要处理所有的流量。
- 同步问题：如果应用程序依赖于服务器状态，可能需要考虑如何在主服务器和备份服务器之间同步数据。
- 监控：应该密切监控备份服务器的使用情况。如果备份服务器经常被使用，这可能表明主服务器存在持续的问题，需要进行调查和解决。
- 定期测试：应该定期测试备份服务器，确保它们在需要时能够正常工作。这可以通过模拟主服务器故障或在维护窗口期间将流量切换到备份服务器来实现。
- 性能考虑：备份服务器可能不总是与主服务器具有相同的性能特征。在使用备份服务器时，应用程序的性能可能会有所不同。
除了基本的备份服务器配置，Nginx还提供了一些高级选项来微调备份服务器的行为。例如，可以为备份服务器设置权重，或者配置多个备份服务器：
upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080 backup; server 192.168.1.13:8080 backup weight=2; }
在这个配置中，我们有两个主服务器和两个备份服务器。第二个备份服务器的权重为2，这意味着当主服务器不可用时，它会接收比第一个备份服务器更多的请求。
备份服务器是Nginx负载均衡配置中的一个强大特性。通过适当的配置和管理，备份服务器可以显著提高系统的可靠性和可用性。然而，它们也增加了系统的复杂性，需要仔细的规划和管理。在实际应用中，应该根据具体的需求和资源情况来决定是否使用备份服务器，以及如何最佳地配置它们。
5.3 慢启动（Slow Start）
慢启动是Nginx Plus（商业版）提供的一项高级功能，旨在保
慢启动是Nginx Plus（商业版）提供的一项高级功能，旨在保护新加入或刚刚恢复的上游服务器免受突发流量的冲击。这个功能特别适用于那些需要预热或初始化的服务器，例如需要加载大量数据到内存或预热缓存的应用服务器。
慢启动的工作原理是在服务器刚刚上线或重新可用时，逐步增加发送到该服务器的请求数量。这个过程通常持续几分钟，在此期间，Nginx Plus会逐渐增加新服务器的有效权重，直到达到其配置的权重值。
要启用慢启动，需要在server指令中使用slow_start参数。例如：
upstream backend { server 192.168.1.10:8080 slow_start=30s; server 192.168.1.11:8080 slow_start=30s; server 192.168.1.12:8080 slow_start=30s; }
在这个配置中，每个服务器都设置了30秒的慢启动时间。这意味着当一个服务器变为可用状态时，Nginx Plus会在30秒内逐步增加发送到该服务器的请求数量。
慢启动功能的主要优势包括：
首先，它可以防止新加入的服务器立即承受全负荷，给予服务器足够的时间来预热和初始化。这对于某些需要加载大量数据或建立复杂连接的应用尤其重要。
其次，慢启动可以帮助维持整个系统的稳定性。当一个新的服务器加入集群时，如果立即接收大量请求，可能会导致性能下降或甚至崩溃。慢启动通过逐步增加负载，可以平滑地将新服务器整合到现有的负载均衡方案中。
再次，慢启动为运维人员提供了更大的灵活性。在进行系统维护或升级时，可以安全地将服务器重新加入集群，而不必担心突发的流量会对服务造成影响。
然而，使用慢启动功能时也需要注意一些事项：
首先，慢启动只在使用加权负载均衡算法（如加权轮询或加权最少连接）时才有效。如果使用IP哈希等其他算法，慢启动将不会生效。
其次，慢启动时间不应设置得过长。过长的慢启动时间可能会导致其他服务器承受过多负载，特别是在高流量情况下。通常，30秒到几分钟的慢启动时间就足够了，具体取决于应用的特性和预热需求。
最后，慢启动功能需要与健康检查机制配合使用。只有当健康检查确认服务器已经准备好接受请求时，慢启动过程才会开始。因此，确保配置了适当的健康检查策略是很重要的。
慢启动是一个强大的功能，可以显著提高负载均衡系统的稳定性和可靠性。通过允许新服务器或重新上线的服务器逐步接入流量，它为系统管理员提供了更精细的控制，有助于确保服务的平稳运行和良好的用户体验。在设计高可用性、高性能的Web应用架构时，慢启动功能是一个值得考虑的重要选项。
5.4 连接限制（Connection Limiting）
连接限制允许管理员控制每个上游服务器可以处理的并发连接数。通过实施连接限制，可以防止单个服务器过载，确保系统的整体稳定性和性能。
在Nginx中，连接限制主要通过max_conns参数来实现。这个参数可以应用于upstream块中的每个server指令。它定义了每个服务器可以同时处理的最大活动连接数。当服务器达到这个限制时，Nginx会将新的请求分配给其他可用的服务器。
以下是一个使用max_conns参数的配置示例：
upstream backend { server 192.168.1.10:8080 max_conns=100; server 192.168.1.11:8080 max_conns=100; server 192.168.1.12:8080 max_conns=100; }
在这个配置中，每个上游服务器的最大并发连接数被限制为100。这意味着如果一个服务器已经有100个活动连接，Nginx将不会向其发送新的请求，直到有连接被释放。
连接限制的实施需要考虑几个重要因素：
首先，设置适当的max_conns值至关重要。这个值应该基于服务器的处理能力、可用资源以及应用程序的特性来确定。设置过低可能会导致资源未充分利用，而设置过高则可能导致服务器过载。
其次，当所有上游服务器都达到其连接限制时，Nginx的行为取决于配置。默认情况下，如果没有可用的服务器，Nginx会返回错误。然而，可以通过配置队列来改变这种行为。
使用queue指令可以设置一个请求队列，当所有服务器都达到连接限制时，新的请求将被放入这个队列中等待处理。例如：
upstream backend { server 192.168.1.10:8080 max_conns=100; server 192.168.1.11:8080 max_conns=100; server 192.168.1.12:8080 max_conns=100; queue 100 timeout=30s; }
在这个配置中，当所有服务器都达到最大连接数时，最多100个请求可以在队列中等待，最长等待时间为30秒。如果队列已满或等待超时，Nginx将返回错误给客户端。
此外，连接限制还可以与其他负载均衡特性结合使用，以实现更精细的控制。例如，可以结合使用权重和连接限制：
upstream backend { server 192.168.1.10:8080 weight=2 max_conns=200; server 192.168.1.11:8080 weight=1 max_conns=100; }
在这个配置中，第一个服务器的权重是第二个的两倍，同时它也能处理两倍的并发连接。
实施连接限制时，还需要注意监控和调优。应该定期检查服务器的负载情况，并根据实际情况调整max_conns值。可以使用Nginx的状态模块或第三方监控工具来跟踪连接数和服务器性能。
值得注意的是，连接限制主要用于防止服务器过载，但它并不能解决所有的性能问题。在某些情况下，可能还需要考虑其他因素，如网络带宽、数据库性能等。因此，连接限制应该作为整体性能优化策略的一部分，而不是唯一的解决方案。
Nginx：负载均衡小专题（三）：https://developer.aliyun.com/article/1582116
