首页 > 代码库 > Nginx 高级配置

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错误,则会将请求发送到下一个服务节点上

 

Nginx 高级配置