负载平衡upstream详细配置

原创于 【模棱博客】

负载平衡upstream详细配置

将流量代理到一组服务器

要开始在一组服务器上使用NGINX，首先需要用upstream指令定义组。该指令放置在http上下文中。

组中的服务器使用server指令进行配置（不要与server定义在NGINX上运行的虚拟服务器的块混淆）。例如，以下配置定义了一个名为backend并由三个服务器配置组成的组（可以在三个以上的实际服务器中解析）：

1 2 3 4 5 6 7 8

http {      upstream backend {          server backend1 . example . com weight = 5 ;          server backend2 . example . com ;          server 192.0.0.1 backup ;      } }

到请求传递到服务器组，在被指定的组的名称proxy_pass指令（或fastcgi_pass，memcached_pass，uwsgi_pass，scgi_pass取决于协议）。在下一个示例中，运行在NGINX上的虚拟服务器将所有请求传递给backend上例中定义的服务器组：

1 2 3 4 5 6

server {      location / {          proxy_pass http : //backend;      } }

以下示例总结了上述两个示例，并向backend服务器组显示了代理请求，其中服务器组由三台服务器组成，其中两台运行同一应用程序的两个实例，另一台作为备份服务器，NGINX将HTTP负载平衡应用于分发请求：

1 2 3 4 5 6 7 8 9 10 11 12 13

http {      upstream backend {          server backend1 . example . com ;          server backend2 . example . com ;          server 192.0.0.1 backup ;      }      server {          location / {              proxy_pass http : //backend;          }      } }

选择负载平衡方法

NGINX支持四种负载均衡方式，NGINX Plus还有另一种方法：

1. 轮询  – 考虑到服务器权重，请求均匀分布在服务器上。这个方法是默认使用的（没有指令来启用它）：
   
   1 2 3 4

   upstream backend {    server backend1 . example . com ;    server backend2 . example . com ; }

2. least_conn  – 将考虑到服务器权重的活动连接数最少的服务器发送到请求：
   
   1 2 3

   upstream backend {      least_conn ; server backend1 . example . com ; server backend2 . example . com ; }

   
    
   
   1

3. ip_hash  – 发送请求的服务器由客户端IP地址确定。在这种情况下，使用IPv4地址的前三个八位字节或整个IPv6地址来计算散列值。该方法保证来自相同地址的请求到达相同的服务器，除非它不可用。
   
   1 2 3

   upstream backend {      ip_hash ; server backend1 . example . com ; server backend2 . example . com ; }

   
    
   
   1

   
   如果其中一台服务器需要临时移除，则可以使用该down参数进行标记，以保留客户端IP地址的当前散列。由该服务器处理的请求会自动发送到组中的下一台服务器：
   
   1 2 3 4 5

   upstream backend {      server backend1 . example . com ;      server backend2 . example . com ;      server backend3 . example . com down ; }

4. 通用哈希  – 请求发送到的服务器是由用户定义的键来确定的，该键可以是文本，变量或它们的组合。例如，密钥可以是源IP和端口，或者是URI：
   
   1 2 3

   upstream backend {      hash $ request_uri consistent ; server backend1 . example . com ; server backend2 . example . com ; }

   
    
   
   1

   
   该指令的可选consistent参数hash使得Ketama一致的哈希负载平衡。请求将根据用户定义的散列键值在所有上游服务器上均匀分布。如果将上游服务器添加到上游组中或从上游组中删除，则只有少数密钥将被重新映射，这将在负载平衡缓存服务器和其他积聚状态的应用程序的情况下最小化缓存未命中。
5. minimum_time（NGINX Plus） – 对于每个请求，NGINX Plus会选择平均延迟最低，活动连接数最少的服务器，根据least_time指令中包含的以下参数计算最低平均延迟：
   • header – 从服务器接收第一个字节的时间
   • last_byte – 收到服务器的完整响应
   1 2 3

   upstream backend {      least_time header ; server backend1 . example . com ; server backend2 . example . com ; }

   1

注意：当配置比循环之外的任何方法，使相应的指令（least_conn，ip_hash，hash，least_time）的列表上方server的指令upstream块。

服务器权重

默认情况下，NGINX使用循环法根据权重在组中的服务器之间分配请求。该指令的weight参数server设置服务器的权重，默认情况下为1：

1 2 3 4 5

upstream backend {      server backend1 . example . com weight = 5 ;      server backend2 . example . com ;      server 192.0.0.1 backup ; }

在这个例子中，backend1.example.com的权重为5; 另外两台服务器的默认权重为1，但IP地址为192.0.0.1的服务器被标记为备份服务器，除非两台服务器都不可用，否则不会接收请求。随着权重的这种配置，每六个请求，5个被送到backend1.example.com和一个backend2.example.com。

服务器慢启动

服务器慢启动功能可防止最近恢复的服务器被连接淹没，这可能会超时并导致服务器再次被标记为失败。

在NGINX Plus中，慢启动允许上游服务器在其恢复或可用之后，逐渐将其权重从零恢复到其标称值。这可以通过指令的slow_start参数完成server：

1 2 3 4 5 6

upstream backend {      server backend1 . example . com slow_start = 30s ;      server backend2 . example . com ;      server 192.0.0.1 backup ; }

时间值设置服务器恢复其权重的时间。

需要注意的是如果只有一个单一的服务器组中，max_fails，fail_timeout，和slow_start参数将被忽略，并且该服务器将永远不会被视为不可用。

启用会话持久性

会话持久性意味着NGINX Plus识别用户会话，并将来自此会话的请求路由到同一上游服务器。

NGINX Plus支持三种会话持久性方法。方法用sticky指令设置。

• 该粘性cookie的方法。通过这种方法，NGINX Plus为来自上游组的第一个响应添加一个会话cookie，并识别发送响应的服务器。当客户端发出下一个请求时，它将包含cookie值，NGINX Plus将请求路由到同一个上游服务器：
  
  1 2 3 4

  upstream backend {      server backend1 . example . com ;      server backend2 . example . com ; sticky cookie srv_id expires = 1h domain = . example . com path = / ; }

  
  
  1

  
  在该示例中，srv_id参数设置将要设置或检查的cookie的名称。可选expires参数设置浏览器保存cookie的时间。可选domain参数定义了cookie的设置域。可选path参数定义了cookie的设置路径。这是最简单的会话持久性方法。
• 该粘路线的方法。用这种方法，NGINX Plus会在收到第一个请求时为客户端分配一个“路由”。随后的所有请求都将与指令的route参数进行比较，server以标识请求将被代理的服务器。路由信息取自cookie或URI。
  
  1 2 3 4

  upstream backend {      server backend1 . example . com route = a ;      server backend2 . example . com route = b ; sticky route $ route _cookie $ route_uri ; }

  
  
  1

• 该cookie的学习方法。通过这种方法，NGINX Plus首先通过检查请求和响应来查找会话标识符。然后NGINX Plus会“学习”哪个上游服务器对应哪个会话标识符。通常，这些标识符通过HTTP cookie传递。如果一个请求包含一个已经被“学习”的会话标识符，NGINX Plus会将请求转发给相应的服务器：
  
  1 2 3 4

  upstream backend {    server backend1 . example . com ;    server backend2 . example . com ; sticky learn create = $ upstream_cookie_examplecookie lookup = $ cookie_examplecookie zone = client_sessions : 1m timeout = 1h ; }

  
  
  1

  
  在该示例中，其中一个上游服务器通过EXAMPLECOOKIE在响应中设置cookie 来创建会话。

  强制性参数create指定了一个变量，用于指示如何创建一个新的会话。在我们的例子中，从EXAMPLECOOKIE上游服务器发送的cookie创建新的会话。

  强制性参数lookup指定如何搜索现有会话。在我们的示例中，现有会话EXAMPLECOOKIE在客户端发送的cookie中搜索。

  强制性参数zone指定一个共享内存区域，其中保留有关粘性会话的所有信息。在我们的例子中，该区域被命名client_sessions并且具有1兆字节的大小。

  这是一个更复杂的会话持久化方法，因为它不需要在客户端保留任何cookie：所有信息都保存在共享内存区域的服务器端。

限制连接数

使用NGINX Plus，可以通过设置连接限制来保持所需的连接数量max_conns。

如果max_conns已达到限制，则可以将该请求放入队列中，以便进一步处理，只要该queue指令是指定的。该指令设置可以同时在队列中的最大请求数量：

1 2 3 4

upstream backend {      server backend1 . example . com   max_conns = 3 ;      server backend2 . example . com ; queue 100 timeout = 70 ; }

1

如果队列中充满请求，或者在可选timeout参数中指定的超时期间无法选择上游服务器，则客户端将收到错误消息。

需要注意的是，max_conns如果有空闲时间限制将被忽略存活在其他打开的连接工作进程。因此，与服务器的连接总数可能会超过max_conns内存与多个工作进程共享的配置中的值。

被动健康监测

当NGINX认为服务器不可用时，它会暂时停止向该服务器发送请求，直到它再次处于活动状态。该server指令的以下参数配置要考虑服务器不可用的条件：

• 该fail_timeout参数设置指定次数的失败尝试发生的时间，并仍然认为服务器不可用。换句话说，服务器在设置的时间间隔内不可用fail_timeout。
• 该max_fails参数设置在指定时间内应该发生的失败尝试次数，以便仍然认为服务器不可用。

默认值是10秒和1次尝试。因此，如果NGINX不能向某个服务器发送请求，或者至少没有收到来自该服务器的响应，则立即认为服务器不可用10秒。以下示例显示如何设置这些参数：

1 2 3 4 5 6

upstream backend {      server backend1 . example . com ;      server backend2 . example . com max_fails = 3 fail_timeout = 30s ;      server backend3 . example . com max_fails = 2 ; }

接下来是一些更复杂的功能，用于跟踪NGINX Plus中可用的服务器可用性。

主动健康监测

定期向每个服务器发送特殊请求，并检查满足特定条件的响应可以监视服务器的可用性。

要在您的nginx.conf文件中启用这种类型的运行状况监视，将请求传递给组的位置应包含该health_check指令。另外，服务器组也应该用zone指令动态配置：

1 2 3 4 5 6

http {      upstream backend {          zone backend 64k ; server backend1 . example . com ; server backend2 . example . com ; server backend3 . example . com ; server backend4 . example . com ; }   server { location / { proxy_pass http : //backend; health_check; } } }

此配置定义了一个服务器组和一个具有将所有请求传递给服务器组的单个位置的虚拟服务器。它还使用默认参数启用健康状况监控。在这种情况下，NGINX Plus每隔5秒向后端组中的每个服务器发送“/”请求。如果发生任何通信错误或超时（或代理服务器响应状态码而不是或）身份验证失败的代理服务器。任何健康检查失败的服务器被认为是不健康的，NGINX Plus会停止发送客户端请求，直到它再次通过健康检查。2xx3xx

该zone指令定义了一个在工作进程中共享的内存区域，用于存储服务器组的配置。这使得工作进程可以使用同一组计数器来跟踪组中服务器的响应。该zone指令还使组可动态配置。

这个行为可以使用health_check指令的参数来覆盖：

1 2 3 4

location / {      proxy_pass http : //backend;      health_check interval = 10 fails = 3 passes = 2 ; }

在此，使用该interval参数将2次连续健康检查之间的持续时间增加到10秒。此外，通过设置fails=3参数，连续3次健康检查失败后，服务器将被视为不健康。最后，使用这个passes参数，我们做了这样的事情，服务器需要通过2次连续的检查再次被认为是健康的。

可以在健康检查中设置特定的URI来请求。uri为此使用参数：

1 2 3 4

location / {      proxy_pass http : //backend;      health_check uri = / some / path ; }

提供的URI将被附加到upstream指令中为服务器指定的服务器域名或IP地址。例如，对于backend上面声明的组中的第一个服务器，运行状况检查请求将具有http://backend1.example.com/some/path URI。

最后，可以设置一个健康的回应应该满足的自定义条件。条件match在health_check指令的匹配参数中定义的块中指定。

1 2 3 4 5 6 7

http {      # . . . match server_ok { status 200 - 399 ; body ! ~ "maintenance mode" ; }   server { # . . .   location / { proxy_pass http : //backend; health_check match=server_ok; } } }

如果响应的状态范围是200到399，并且其正文与提供的正则表达式不匹配，则会传递一个健康检查。

该match指令允许NGINX Plus检查状态，标题字段和响应主体。使用此指令可以验证状态是否在指定范围内，响应是否包含标题，或标题或正文是否与正则表达式匹配。该match指令可以包含一个状态条件，一个主体条件和多个标题条件。为了match对应该块，响应必须满足其中指定的所有条件。

例如，以下match指令查找具有状态码的响应200，包含Content-Type具有确切值的标题text/html，并在正文中具有文本“欢迎使用nginx！”。

1 2 3 4 5

match welcome {      status 200 ;      header Content - Type = text / html ;      body ~ "Welcome to nginx!" ; }

在使用感叹号（以下示例!），其中，状态代码是什么条件相匹配的响应其他比301，302，303，和307，并且Refresh 是不标头中。

1 2 3 4

match not_redirect {      status ! 301 - 303 307 ;      header ! Refresh ; }

http://www.flammulina.com/2018/02/25/java-kafkamqredis%E4%BD%9C%E4%B8%BA%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97%E6%97%B6%E7%9A%84%E5%B7%AE%E5%BC%82/