Nginx高级配置

Nginx高级配置
1. Nginx连接后端的方式：反向代理(proxy_pass)、直连
fastcgi(fastcgi_pass)
例子：
fastcgi_pass backend1;
proxy_pass http://backend2;
location块中配置此项，表示用反向代理或直连fastcgi的方式连接后端服务，其中backend1、backend2为upstream配置，其中配置下游的ip&port列表和调度参数，见下文。

注意：fastcgi_pass与proxy_pass是互斥配置，不能同时生效。

2. Nginx调度与负载均衡配置(upstream 配置)
1) 轮询（默认）每个请求按时间顺序逐一分配到不同的后端服务器。

weight指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况，weight默认值为1。

例如：
upstreambakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
2) ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

例如：
upstreambakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
3) hash 每个请求按访问$hash_seed的hash结果分配。

例如：
upstreambakend {
hash $hash_seed;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
4) fair（第三方）按后端服务器的响应时间来分配请求，响应时间短的优先分配，需要第三方插件。

upstream backend {
server 192.168.0.14:88;
server 192.168.0.15:80;
fair;
}
5) url_hash（第三方）按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

例：在upstream中加入hash语句，server 语句中不能写入weight等其他的参数，hash_method是使用的hash算法 upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
3. upstream配置参数
例子：
upstreambakend{
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060 max_fails=1 fail_timeout=10s;
server 127.0.0.1:7070 backup;
}
proxy_pass http://bakend/;或fastcgi_pass backend; 为每个设备的状态设置为:
1) down 表示单前的server暂时不参与负载，一般用于标记故障机。

2) weight 默认为1.weight越大，负载的权重就越大。

3) max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回
proxy_next_upstream模块定义的错误
4) fail_timeout:max_fails次失败后，暂停改服务的时间，超过时间后继续向该服务发送流量，默认为10s。

5) backup：备用服务器，其它所有的非backup机器down或者忙的时候，启用backup机器。

4.容错机制
1) Nginx 默认判断失败节点状态以connect refuse和time out状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，所以nginx判断其还是存活状态；
2) 除非添加了fastcgi_next_upstream 或proxy_next_upstream 指令设置对404、502、503、504、500和time out 等错误进行转到备机处理；
3) 在next_upstream 过程中，会对fails 进行累加，如果备用机处理还是错误则直接返回错误信息（但404不进行记录到错误数，如果不配置错误状态也不对其进行错误状态记录）
综述，nginx 记录错误数量timeout 和connect refuse 是永远被记录错误状态，而502、500、503、504只有在配置proxy_next_upstream 或fastcgi_next_upstream 后nginx 才会记录这4种HTTP 错误到fails 中，当fails 大于等于max_fails 时，则该节点失效；
注意：
fastcgi_next_upstream 与proxy_next_upstream 支持的错误并不一致： fastcgi_next_upstream ：
error | timeout | invalid_header | http_500 |
http_503 | http_403 | http_404 | off
proxy_next_upstream ：
error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_403 | http_404 | off ...
当fastcgi 的服务异常时，因为fastcgi_next_upstream 不支持http_502错误，无法对fastcgi 异常进行判断，
所以fastcgi_pass 与proxy_pass 处理的规则也不相同：。