代理一组服务器
- 使用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进行哈希计算。
-
- 通过consistent参数使用ketama一致哈希算法来减少增减服务器对客户端的影响。
- 最小响应时间：对于每个请求，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能够实现什么功能和对其进行小改应该会有一定的帮助。
