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

选择一种负载均衡方法

默认的是权重轮询算法，nginx会按照各个server的权重比来分发请求。
- 如：
```
upstream backend {
   server backend1.example.com;
   server backend2.example.com;
}
```
最少连接法：每次都选择连接数组少的server，如果有多个server的连接数相同，再根据这几个server的权重分发请求。
- 例：
```
upstream backend {
    least_conn;

    server backend1.example.com;
    server backend2.example.com;
}
```
ip哈希：使用IPv4的前三个八字节位或者IPv6的全部来计算哈希值，所以相同地址的请求始终会打到相同的Server上，除非这个server不可用。
- 如果一个server需要暂时移除，使用down参数来避免请求打到这台机器上，应该哈希到这台机器上的请求会自动的发送到组里的下一台。
- 如：
```
upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}
```
哈希：使用自定义的key去进行哈希计算。
- 通过consistent参数使用ketama一致哈希算法来减少增减服务器对客户端的影响。
  - 例：
```
upstream backend {
    hash $request_uri consistent;

    server backend1.example.com;
    server backend2.example.com;
}
```
  - 上面的就是通过uri进行哈希计算。
最小响应时间：对于每个请求，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能够实现什么功能和对其进行小改应该会有一定的帮助。

Nginx笔记（四）

代理一组服务器

选择一种负载均衡方法

服务器权重

服务器慢启动

Enabling Session Persistence

限制连接数量

被动的健康监测

主动的心跳检测

你可能感兴趣的:(Nginx笔记（四）)