Nginx笔记（四）

代理一组服务器

• 使用upstream指令来定义一组服务器，指令放在http context里

  • 如：

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

• 使用proxy_pass指令把请求打到被代理的服务器上

  • 如：

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

选择一种负载均衡方法

1. 默认的是权重轮询算法，nginx会按照各个server的权重比来分发请求。

   • 如：

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

2. 最少连接法：每次都选择连接数组少的server，如果有多个server的连接数相同，再根据这几个server的权重分发请求。

   • 例：

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

3. ip哈希：使用IPv4的前三个八字节位或者IPv6的全部来计算哈希值，所以相同地址的请求始终会打到相同的Server上，除非这个server不可用。

   • 如果一个server需要暂时移除，使用down参数来避免请求打到这台机器上，应该哈希到这台机器上的请求会自动的发送到组里的下一台。

   • 如：

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

4. 哈希：使用自定义的key去进行哈希计算。
   • 通过consistent参数使用ketama一致哈希算法来减少增减服务器对客户端的影响。

     • 例：

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

     • 上面的就是通过uri进行哈希计算。

5. 最小响应时间：对于每个请求，nginx选择平均等待时间最小并且连接数最少的。

   • 通过least_time的参数来确定平均等待时间的计算方式。

     • header: Time to receive the first byte from the server
     • last_byte: Time to receive the full response from the server

   • 如：

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

服务器权重

• 默认的权重是1，通过weight参数来指定权重值。

• 通过backup来标记备用服务器，如果其他的都宕机了，请求会打到备用的服务器是上。

• 例：

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

服务器慢启动

• 对于刚刚恢复的服务器，如果一下子被请求淹没可能会再次宕机。

• 可以通过server指令的slow_start参数来让其权重从0缓慢的恢复到正常值。

• 例：

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

• 注意如果一个组里面只有一个server，那么max_fails，fail_timeout和slow_start参数都会被忽略。并且这个服务器永远都不会被认为是不可用的。

Enabling Session Persistence

• Session持久性是指nginx识别客户端的session然后把同一个session的请求路由到同一个server上。
• nginx支持三种session持久的方法，通过sticky指令去设置。

  • sticky cookie方法。通过这种方法，当server第一个响应的时候，nginx添加一个cookie来标识是哪个server响应的，当它下次请求的时候，会带着cookie，nginx会把请求路由到同一台server。

    • 例：

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

  • sticky_route方法，使用这种方法，nginx第一个收到请求的时候会给客户端下发一个路由。后续的请求都会带着路由参数，nginx再来判断请求该打到哪个server上。路由信息可以通过cookie或者uri获取到。

    • 例：

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

  • cookie learn 方法。通过这种方法，nginx通过检测请求和响应来寻找session标记。通常，这些标记通过cookie传递。如果一个请求的包含的session标记已经learned，nginx将会把请求打到正确的server上。

  • 例：

    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;
    }
    

  • 在这个例子中，server通过在响应中设置一个"EXAMPLECOOKIE"来标记一个session。

  • create的参数指定一个变量来指示一个session的创建，在这个例子中，server发送"EXAMPLECOOKIE"表示新的session建立。

  • lookup的参数指定如何寻找一个已经存在的session，在这个例子中，通过查找客户端的"EXAMPLECOOKIE"来搜索现有的session。

  • zone 指定一块共享的内存来保存sticky sessions的信息。上个例子中，这块空间叫做client_sessions，大小为1M。

限制连接数量

• 可以通过max_conns参数来限制连接数，如果达到了最大连接数，请求就可以放到通过queue指令生命的队列中来等待后续的处理 ，queue指令设置了可以放到队列中得最大的请求数、

• 例：

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

• 如果队列排满或者在可选参数timeout设置的时间内无法选择上游服务器，客户端将接到一个错误。

• 注意如果闲置的keepalive连接在另一个worker processes中打开了max_conns限制会被忽略。导致的结果是，在多个工作进程共享内存的配置中，连接的总数可能会超过max_conns的值。

被动的健康监测

• 当nginx认为一个server不可用，它会暂时停止向这个server转发请求直至nginx再次认为它是可用的。

• nginx通过两个参数来控制nginx的判断

  • fail_timeout，当在fail_timeout时间段内，失败次数达到一定数量则认为该server不可用。并在接下来的fail_timeout时间内不会再将请求打到这个server上。 - max_fails，这个max_fails就是上面说的失败的一定数量。

• 默认的值是10秒和1次尝试。

• 例：

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

主动的心跳检测

• 使用health_check指令来检测server是否可用，除此之外还要使用zone指令。

• 例：

  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每五秒请求一次backend组里的每台机器，请求地址是"/"，如果失败或者超时（或者返回的状态码不是2xx或者3xx），nginx就认为这个server宕机了。nginx将停止向它转发请求，直至其再次通过心跳检测。

• 可以通过参数控制health_check指令的行为。

• 例：

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

• 上个例子是每十秒检测一次，如果失败了3次就认为宕机了，如果成功2次就认为通过了检测。

• 也可以检测特定的uri

• 例：

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

• 通过match块自定义成功的状态。

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

• 上个例子中要求status在200到399之间，并且body满足提供的正则表达式。

• match块中可以包含一个status的状态，一个body的状态和多个header的状态。

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

• 使用!

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

• 上个例子表示status不是301、302、303或者307，并且header中不包含Refresh。

至此Nginx笔记结束，了解了这些后，对于看懂一个Nginx的配置，了解Nginx能够实现什么功能和对其进行小改应该会有一定的帮助。