Nginx 高级配置

julley

　　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_passproxy_pass轮询默认会将请求发送到下一个服务节点上　　默认不会将请求发送到下一个服务节点上，直接拒绝请求
　　在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上
weight默认会将请求发送到下一个服务节点上　　默认不会将请求发送到下一个服务节点上，直接拒绝请求
　　在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上
hash　　默认不会将请求发送到下一个服务节点上，直接拒绝请求
　　默认不会将请求发送到下一个服务节点上，直接拒绝请求
　　在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上