Nginx:负载均衡小专题(二)

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
应用型负载均衡 ALB,每月750个小时 15LCU
简介: Nginx:负载均衡小专题(二)

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指令支持三个参数:

  1. header:使用接收响应头的时间作为响应时间。
  2. last_byte:使用接收完整响应的时间作为响应时间。
  3. 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 注意事项

实现会话持久性时,需要考虑以下几点:

  1. 性能影响:会话持久性可能会导致负载分配不均衡,特别是当某些会话比其他会话更活跃时。
  2. 容错:如果启用了会话持久性,当某个服务器不可用时,原本发送到该服务器的请求可能会丢失会话数据。可以考虑使用共享会话存储(如Redis)来缓解这个问题。
  3. 扩展性:在添加或删除服务器时,会话持久性可能会受到影响。使用一致性哈希可以最小化这种影响。
  4. 安全性:使用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;
}


备份服务器的工作机制如下:

  1. Nginx首先尝试将请求发送到主服务器。
  2. 如果所有主服务器都无法响应(例如,由于服务器宕机、网络问题或达到最大连接数),Nginx会尝试使用备份服务器。
  3. 一旦有主服务器恢复可用,Nginx会停止向备份服务器发送新的请求,转而使用恢复的主服务器。

备份服务器配置的一个重要优点是它提供了一种简单而有效的故障转移机制。这对于维护高可用性服务特别有用,可以在主服务器出现问题时保持服务的连续性。

然而,使用备份服务器时也需要注意一些事项:

  1. 容量规划:备份服务器应该有足够的资源来处理所有主服务器的负载。在最坏的情况下,备份服务器可能需要处理所有的流量。
  2. 同步问题:如果应用程序依赖于服务器状态,可能需要考虑如何在主服务器和备份服务器之间同步数据。
  3. 监控:应该密切监控备份服务器的使用情况。如果备份服务器经常被使用,这可能表明主服务器存在持续的问题,需要进行调查和解决。
  4. 定期测试:应该定期测试备份服务器,确保它们在需要时能够正常工作。这可以通过模拟主服务器故障或在维护窗口期间将流量切换到备份服务器来实现。
  5. 性能考虑:备份服务器可能不总是与主服务器具有相同的性能特征。在使用备份服务器时,应用程序的性能可能会有所不同。

除了基本的备份服务器配置,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

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
27天前
|
负载均衡 算法 搜索推荐
Nginx 常用的负载均衡算法
【10月更文挑战第17天】在实际应用中,我们需要根据具体的情况来选择合适的负载均衡算法。同时,还可以结合其他的优化措施,如服务器健康检查、动态调整权重等,来进一步提高负载均衡的效果和系统的稳定性。
112 59
|
1月前
|
负载均衡 应用服务中间件 Linux
nginx学习,看这一篇就够了:下载、安装。使用:正向代理、反向代理、负载均衡。常用命令和配置文件,很全
这篇博客文章详细介绍了Nginx的下载、安装、配置以及使用,包括正向代理、反向代理、负载均衡、动静分离等高级功能,并通过具体实例讲解了如何进行配置。
149 4
nginx学习,看这一篇就够了:下载、安装。使用:正向代理、反向代理、负载均衡。常用命令和配置文件,很全
|
23天前
|
负载均衡 算法 应用服务中间件
Nginx 常用的负载均衡算法
【10月更文挑战第22天】不同的负载均衡算法各有特点和适用场景。在实际应用中,需要根据具体的业务需求、服务器性能和网络环境等因素来选择合适的算法。
27 3
|
27天前
|
负载均衡 监控 应用服务中间件
除了 Nginx,还有以下一些常见的负载均衡工具
【10月更文挑战第17天】这些负载均衡工具各有特点和优势,在不同的应用场景中发挥着重要作用。选择合适的负载均衡工具需要综合考虑性能、功能、稳定性、成本等因素。
|
1月前
|
负载均衡 应用服务中间件 nginx
Nginx的6大负载均衡策略及权重轮询手写配置
【10月更文挑战第9天】 Nginx是一款高性能的HTTP服务器和反向代理服务器,它在处理大量并发请求时表现出色。Nginx的负载均衡功能可以将请求分发到多个服务器,提高网站的吞吐量和可靠性。以下是Nginx支持的6大负载均衡策略:
148 7
|
1月前
|
负载均衡 算法 Java
腾讯面试:说说6大Nginx负载均衡?手写一下权重轮询策略?
尼恩,一位资深架构师,分享了关于负载均衡及其策略的深入解析,特别是基于权重的负载均衡策略。文章不仅介绍了Nginx的五大负载均衡策略,如轮询、加权轮询、IP哈希、最少连接数等,还提供了手写加权轮询算法的Java实现示例。通过这些内容,尼恩帮助读者系统化理解负载均衡技术,提升面试竞争力,实现技术上的“肌肉展示”。此外,他还提供了丰富的技术资料和面试指导,助力求职者在大厂面试中脱颖而出。
腾讯面试:说说6大Nginx负载均衡?手写一下权重轮询策略?
|
1月前
|
缓存 负载均衡 算法
nginx学习:配置文件详解,负载均衡三种算法学习,上接nginx实操篇
Nginx 是一款高性能的 HTTP 和反向代理服务器,也是一个通用的 TCP/UDP 代理服务器,以及一个邮件代理服务器和通用的 HTTP 缓存服务器。
67 0
nginx学习:配置文件详解,负载均衡三种算法学习,上接nginx实操篇
|
1月前
|
开发框架 负载均衡 前端开发
Nginx负载均衡
Nginx负载均衡
|
1月前
|
负载均衡 Java 应用服务中间件
Nginx负载均衡配置
Nginx负载均衡配置
|
1月前
|
负载均衡 算法 应用服务中间件
nginx反向代理与负载均衡
nginx反向代理与负载均衡
37 1