Nginx 高级配置

nginx官方网站：http://nginx.org/

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。
        例如：
        upstream bakend {
                server 192.168.0.14 weight=10;
                server 192.168.0.15 weight=10;

        }

2) ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

        例如：
        upstream bakend {
                ip_hash;
                server 192.168.0.14:88;
                server 192.168.0.15:80;

        }

3) hash 每个请求按访问$hash_seed的hash结果分配。

        例如：

        upstream bakend {

                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配置参数

例子：

        upstream bakend{
                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处理的规则也不相同：

	fastcgi_pass	proxy_pass
轮询	默认会将请求发送到下一个服务节点上	默认不会将请求发送到下一个服务节点上，直接拒绝请求 在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上
weight	默认会将请求发送到下一个服务节点上	默认不会将请求发送到下一个服务节点上，直接拒绝请求 在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上
hash	默认不会将请求发送到下一个服务节点上，直接拒绝请求	默认不会将请求发送到下一个服务节点上，直接拒绝请求 在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上