NGINX负载均衡安装配置手册

概述

Nginx介绍

Nginx ("engine x") 是一个高性能的HTTP 和反向代理服务器，也是一个IMAP/POP3/SMTP 代理服务器。Nginx 是由Igor Sysoev 为俄罗斯访问量第二的Rambler.ru 站点开发的，它已经在该站点运行超过三年了。Igor 将源代码以类BSD许可证的形式发布。

Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道，六间房、https://www.sodocs.net/doc/a32329141.html,等视频分享网站，Discuz!官方论坛、水木社区等知名论坛，盛大在线、金山逍遥网等网络游戏网站，豆瓣、人人网、YUPOO相册、金山爱词霸、迅雷在线等新兴Web 2.0网站。

四层和七层负载均衡

负载均衡设备也常被称为"四到七层交换机"，那补充：所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。

换句换说，二层负载均衡会通过一个虚拟MAC地址接收请求，然后再分配到真实的MAC 地址；三层负载均衡会通过一个虚拟IP地址接收请求，然后再分配到真实的IP地址；四层通过虚拟IP+端口接收请求，然后再分配到真实的服务器；七层通过虚拟的URL或主机名接收请求，然后再分配到真实的服务器。

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。

比如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发

到同一台服务器处理。

七层的负载均衡，就是在四层的基础上（不能空中楼阁，没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个WEB服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

四层和七层两者到底区别在哪里？

负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP 层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。

1、负载均衡分为L4 switch（四层交换），即在OSI第4层工作，就是TCP层啦。此种Load Balance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS，F5

2、另一种叫做L7 switch（七层交换），OSI的最高层，应用层。此时，该Load Balancer 能理解应用协议。例子：haproxy，MySQL Proxy

注意：上面的很多Load Balancer既可以做四层交换，也可以做七层交换。

如果单纯要做HTTP的负载均衡，用haproxy好了。性能很强。

另外，F5和Alteon这样的硬件LB是LVS等软件赶不上。

技术原理上的区别。

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

七层负载均衡应用场景

七层应用负载的好处，是使得整个网络更"智能化", 参考我们之前的另外一篇专门针对HTTP应用的优化的介绍，就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。很多在后台，(例如Nginx或者Apache)上部署的功能可以前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。

另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，通常这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。从技术原理上也可以看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。

现在的7层负载均衡，主要还是着重于应用广泛的HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。4层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。

七层应用需要考虑的问题

1：是否真的必要，七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。

2：是否真的可以提高安全性。例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗DDoS能力，否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。

3：是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。

Nginx做七层负载均衡的优点

1、高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。

2、内存消耗少：在3万并发连接下，开启的10个Nginx进程才消耗150M内存（15M*10=150M）。

3、配置文件非常简单：风格跟程序一样通俗易懂。

4、成本低廉：Nginx为开源软件，可以免费使用。而购买F5 BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币。

5、支持Rewrite重写规则：能够根据域名、URL的不同，将HTTP 请求分到不同的后端服务器群组。

6、内置的健康检查功能：如果Nginx Proxy 后端的某台Web 服务器宕机了，不会影响前端访问。

7、节省带宽：支持GZIP 压缩，可以添加浏览器本地缓存的Header 头。

8、稳定性高：用于反向代理，宕机的概率微乎其微。

9、支持热部署：不间断服务进行更新。

Nginx原理

Nginx的负载均衡是一个基于内容和应用的七层交换负载均衡的实现。同样Nginx也是一个Http的服务端。

nginx配置负载均衡工作在TCP/IP协议的第七层，即应用层，属于七层负载均衡。

七层负载均衡的优势

1.通过对HTTP报头的检查，可以检测出HTTP400、500和600系列的错误信息，因而能透明地将连接请求重新定向到另一台服务器，避免应用层故障。

2.可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增加系统性能。

3.能根据连接请求的类型，如是普通文本、图象等静态文档请求，还是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提高系统的性能及安全性。

Nginx并发能力强的原因

在业界，一直流传这样一句话：Nginx抗并发能力强！为什么Nginx抗并发能力强？原因是使用了非阻塞、异步传输

阻塞：如apache代理tomcat时，apache开启10个进程，同时处理着10个请求，在tomcat没有返回给apache结果时，apache是不会处理用户发出的第11个请求非阻塞：如nginx代理tomcat时，nginx开启1000个并发，同时处理着1000个请求，在tomcat没有返回给nginx结果时，nginx会依然处理后面用户发给的请求

同步传输：比如squid代理tomcat时，浏览器发起请求，然后请求会squid立刻被转到后端服务器，于是在浏览器和后端服务器之间就建立了一个连接。在请求发起到请求完成，这条连接都是一直存在的。

异步传输：比如nginx代理tomcat时，浏览器发起请求，请求不会立刻转到后端服务器，而是将请求数据（header）先保存到nginx上，然后nginx再把这个请求发到后端服务器，后端服务器处理完之后把数据返回到nginx上，nginx将数据流发到浏览器。

假设用户执行一个上传文件操作，由于用户网速较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后端tomcat建立了连接，半小时后文件上传结束，所以，后端tomcat服务器连接保持了半个小时；而nginx异步代理就是先将数据保存在nginx上，因此仅仅是nginx和用户保持了半小时连接，后端服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后端tomcat，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后端服务器连接保持了一秒。

Nginx负载均衡模块(upstream)

nginx配置负载均衡使用的模块是ngx_http_upstream_module，这个模块默认安装，因此不用在编译nginx时做过多配置。相关指令有upstream、server、ip hash、keepalive 等。

Upstream模块是Nginx 负载均衡的主要模块，它提供了简单的办法来实现在轮询和客户端IP之间的后端服务器负载均衡,并可以对服务器进行健康检查。upstream并不处理请求，而是通过请求后端服务器得到用户的请求内容。在转发给后端时，默认是轮询，也可以是ip_hash。

具体配置参数可以参考nginx配置负载均衡详解这篇文章https://www.sodocs.net/doc/a32329141.html,/2012/nginx_offical_doc_0628/202.html

或者官方文档https://www.sodocs.net/doc/a32329141.html,/en/docs/http/ngx_http_upstream_module.html

代理模块（proxy）

Proxy为Nginx的代理模块，允许将用户的HTTP请求转发到后端服务器，同时也可以结合upstream模块，达到负载均衡的目的。

注：proxy相关功能、指令很多，在此只讲与upstream相关的指令和功能

proxy模块常用指令解释：

proxy_pass：指定转发到后端服务器的请求，在location中指定，常用URI类型如下

TCP套接字：proxy_pass http://127.0.0.1:8080;

Unix套接字：proxy_pass http://unix:/tmp/nginx.sock;

Upstream区段：proxy_pass http://nginx_pool;

域名：proxy_pass https://www.sodocs.net/doc/a32329141.html,;

健康检查

Nginx的健康检查主要体现在对后端服务提供健康检查，且功能被集成在upstream模块中，共有两个指令

max_fails:定义定义可以发生错误的最大次数

fail_timeout：nginx在fail_timeout设定的时间内与后端服务器通信失败的次数超过max_fails设定的次数，则认为这个服务器不在起作用；在接下来的fail_timeout时间内，nginx 不再将请求分发给失效的server。

健康检查机制：

Nginx在检测到后端服务器故障后，nginx依然会把请求转向该服务器，当nginx发现timeout或者refused后，会把改请求会分发到upstream的其它节点，直到获得正常数据后，nginx才会把数据返回给用户，这也便体现了nginx的异步传输，而lvs/haproxy/apache责无法做到这些（在lvs/haproxy/apache里，每个请求都只有一次机会，假如用户发起一个请求，结果该请求分到的后端服务器刚好挂掉了，那么这个请求就失败了）

使用nginx做为负载均衡器时，通讯模型类似于LVS-NAT，在某些情况下，随着集群节点数量的增长，nginx将会成为网络通讯的瓶颈，因为所有应答数据包都必须通过nginx，一颗400MHz的处理器能够容纳100Mbps的连接，因此，在一般情况下，网络更可能比LVS Director更可能成为瓶颈。在这种情况下，使用LVS-DR比使用nginx做负载均衡器上更可靠一些。

反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

负载均衡，英文名称为Load Balance，其意思就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

Nginx负载均衡调度策略

nginx的upstream目前支持以下几种方式的分配：

1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

2、weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。好的服务器weight高些，差的服务器weight低些。

例如：

upstream bakend {

server 192.168.0.14 weight=10;

server 192.168.0.15 weight=10;

}

3、ip_hash

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

无法将权重（weight）与ip_hash联合使用来分发连接。如果有某台服务器不可用，你必须标记其为“down”。

例如：

upstream bakend {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

4、fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backend {

server server1;

server server2;

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;

}

Session问题

解决办法：

(1)ip_hash

(2) nginx-upstream-jvm-route (Nginx + tomcat )

nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：upstream backend {

ip_hash;

server 127.0.0.1:8001;

server 127.0.0.1:8002;

}

ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：

1)nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip 时只能得到squid的服务器ip地址。

2)nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求不能定位到同一台session应用服务器上。

模块参数说明

ngx_http_upstream_module

https://www.sodocs.net/doc/a32329141.html,/en/docs/http/ngx_http_upstream_module.html

nginx负载均衡模块：ngx_http_upstream_module

配置例子

指令

upstream

server

ip hash

keepalive

least conn

Embedd Variables

nginx负载均衡模块ngx_http_upstream_module允许定义一组服务器，这组服务器可以被proxy_pass，fastcgi_pass和memcached_pass这些指令引用。

配置例子

upstream backend {

server https://www.sodocs.net/doc/a32329141.html, weight=5;

server https://www.sodocs.net/doc/a32329141.html,:8080;

server unix:/tmp/backend3;

server https://www.sodocs.net/doc/a32329141.html,:8080 backup;

server https://www.sodocs.net/doc/a32329141.html,:8080 backup;

}

server {

location / {

proxy_pass http://backend;

}

}

指令

语法：upstream name {...}

default：－

所属指令：http

定义一组用于实现nginx负载均衡的服务器，它们可以侦听在不同的端口。另外，可以混合使用侦听TCP与UNIX-domain套接字文件

例子：

upstream backend {

server https://www.sodocs.net/doc/a32329141.html, weight=5;

server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;

server unix:/tmp/backend3;

}

默认情况下，请求被分散在使用加权轮询的nginx负载均衡服务器上。在上面的例子中，每七个请求按下面分配：五个请求发送给https://www.sodocs.net/doc/a32329141.html,，127.0.0.1:8080和unix:/tmp/backend3各自分配一个。如果在于服务器通信时发生了一个错误，这个请求会被传递给下一个服务器，以此类推至道所有的功能服务器都尝试过。如果不能从所有的这些nginx负载均衡服务器上获得回应，客户端将会获得最后一个链接的服务器的处理结果。

语法：server 地址 [参数]；

default：－

所属指令：upstream

设置一个nginx负载均衡服务器的地址和其他参数。一个地址可以被指定为域名或IP 地址，和一个可选的端口，或者被定为UNIX-domain套接字文件的路径，使用"unix:"作为前缀。如果端口没指定，则使用80端口。一个被解析到多个IP地址的域名本质上指定了多个服务器。

可以定义下面的参数：

weight=number

设置服务器的权限，默认是1

max_fails=number

设置在fail_timeout参数设置的时间内最大失败次数，如果在这个时间内，所有针对该服务器的请求都失败了，那么认为该服务器会被认为是停机了，停机时间是fail_timeout

设置的时间。默认情况下，不成功连接数被设置为1。被设置为零则表示不进行链接数统计。哪里连接被认为是不成功的可以通过proxy_next_upstream、fastcgi_next_upstream和memcached_next_upstream指令配置（http_404状态不会被认为是不成功的尝试）。

fail_timeout=time

设置多长时间内失败次数达到最大失败次数会被认为服务器停机了

服务器会被认为停机的时间长度

默认情况下，超时时间被设置为10S

fail_timeout与前端响应时间没有直接关系，不过可以使用proxy_connect_timeout和proxy_read_timeout来控制。

backup

标记该服务器为备用服务器。当主服务器停止时，请求会被发送到它这里。

down

标记服务器永久停机了；与指令ip_hash一起使用。

例子：

upstream backend {

server https://www.sodocs.net/doc/a32329141.html, weight=5;

server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;

server unix:/tmp/backend3;

server https://www.sodocs.net/doc/a32329141.html,:8080 backup;

}

语法：ip_hash;

default:-

所属指令：upstream

指定nginx负载均衡器组使用基于客户端ip的负载均衡算法。IPV4的前3个八进制位和所有的IPV6地址被用作一个hash key。这个方法确保了相同客户端的请求一直发送到相同的服务器上除非这个服务器被认为是停机。这种情况下，请求会被发送到其他主机上，然后可能会一直发送到这个主机上。

注意：在版本1.3.2中开始支持IPV6地址。

如果nginx负载均衡器组里面的一个服务器要临时移除，它应该用参数down标记，来防止之前的客户端IP还往这个服务器上发请求。

例子：

upstream backend {

ip_hash;

server https://www.sodocs.net/doc/a32329141.html,;

server https://www.sodocs.net/doc/a32329141.html,;

server https://www.sodocs.net/doc/a32329141.html, down;

server https://www.sodocs.net/doc/a32329141.html,;

} 注意：在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）

语法：keepalive 连接数；

default：－

所属模块：upstream

这个指令在版本1.1.4中出现

nginx负载均衡器的活动链接数缓存。

连接数（keepalive的值）指定了每个工作进程中保留的持续连接到nginx负载均衡器缓存的最大值。如果超过这个设置值的闲置进程想链接到nginx负载均衡器组，最先连接的将被关闭。

应该注意：keepalive指令不限制nginx工作进程可以连接到nginx负载均衡器可以开启的最大公工作进程，如果有需要的话，新进程还是会被发起。连接数应该被设置足够低来满足nginx负载均衡器处理新进的连接。

带有持续连接（keepalive connections）的memcached upstream的配置例子

upstream memcached_backend {

server 127.0.0.1:11211;

server 10.0.0.2:11211;

keepalive 32;

}

server {

...

location /memcached/ {

set $memcached_key $uri;

memcached_passmemcached_backend;

}

}

syntax: least_conn;

default: —

context: upstream

This directive appeared in versions 1.3.1 and 1.2.2.

Specifies that a group should use a load balancing method where a request is passed to the server with the least number of active connections, taking into account weights of servers. If there are several such servers, they are tried using a weighted round-robin balancing method.

nginx负载均衡器内置变量（Embedded Variables）

nginx负载均衡模块ngx_http_upstream_module支持下列内置变量：

$upstream_addr

保存一个服务器的IP地址和端口号或者UNIX-domain套接字文件的路径。如果在处理请求过程中使用了多个服务器，那么它们的地址将以逗号分割，例如：“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”。如果一个内置的从一个服务器组到另一个服务器组的重定向使用X-Accel-Redirect” or error_page ，那么那些服务器组以冒号隔开，例如“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”。

$upstream_response_time

保存nginx负载均衡服务器响应时间，以毫秒计。多个响应也以逗号和冒号隔开。

$upstream_status

保存nginx负载均衡服务器响应代码。多个响应代码也以逗号或冒号隔开。$upstream_http_...

保存nginx负载均衡服务器响应头字段。例如，the “Server” response header field is made available through the $upstream_http_server variable.注意，只有最后一个服务器响应头字段被保存。

ngx_http_proxy_module

https://www.sodocs.net/doc/a32329141.html,/en/docs/http/ngx_http_proxy_module.html

proxy_next_upstream

语法：proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]

确定在何种情况下请求将转发到下一个服务器。转发请求只发生在没有数据传递到客户端的过程中。

proxy_connect_timeout

后端服务器连接的超时时间_发起握手等候响应超时时间

proxy_read_timeout

连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）

proxy_send_timeout

后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

proxy_pass

这个指令设置被代理服务器的地址和被映射的URI

小技巧

upstream bakend{#定义负载均衡设备的Ip及设备状态

ip_hash;

server 127.0.0.1:9090 down;

server 127.0.0.1:8080 weight=2;

server 127.0.0.1:6060;

server 127.0.0.1:7070 backup;

}

在需要使用负载均衡的server中增加

proxy_pass http://bakend/;

每个设备的状态设置为:

1.down 表示单前的server暂时不参与负载

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

3.max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返proxy_next_upstream 模块定义的错误

4.fail_timeout:max_fails次失败后，暂停的时间。

5.backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

nginx支持同时设置多组的负载均衡，用来给不用的server来使用。

client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug

client_body_temp_path 设置记录文件的目录可以设置最多3层目录

location 对URL进行匹配.可以进行重定向或者进行新的代理、负载均衡

Nginx典型应用

四层结构：LVS负载均衡<->Nginx负载均衡<->内容缓存<->Web服务器