案例一：负载均衡(轮循 默认weight = 1)
准备：我这边在同一台电脑上面启动了两个tomcat，端口分别为9601、9602，每个tomcat下面都放了一个nginx-test项目，项目里面有一个写有当前tomcat端口的index.html
修改：nginx.conf文件，在http里面增加：
1 upstream fzjhs { 2 server localhost:9601; 3 server localhost:9602; 4 server localhost:9603; 5 }修改：nginx.conf文件，在server里面增加：
1 location / { 2 proxy_pass http://fzjhs; 3 }测试：打开浏览器输入Url地址 http://localhost/nginx-test/index.html 不停的刷新页面，可以看见index.html上面的端口号一直在9601、9602中间切换、规律为ABABABAB
说明：该策略指的是Nginx请求会把请求挨个、平等的分配到每台服务器。从上面测试可以看出，nginx.conf里面虽然配置了9603端口，但是我这边没有启动9603这个端口，Nginx会自动把它踢下去，如果你这个时候把9603端口启动起来，在上面的测试中就可以看见在9601、9602、9603中间切换
案例二：负载均衡(权重)
准备：我这边在同一台电脑上面启动了两个tomcat，端口分别为9601、9602，每个tomcat下面都放了一个nginx-test项目，项目里面有一个写有当前tomcat端口的index.html
修改：nginx.conf文件，在http里面增加：
1 upstream fzjhs { 2 server localhost:9601 weight=3; 3 server localhost:9602 weight=6; 4 server localhost:9603 weight=1; 5 }修改：nginx.conf文件，在server里面增加：
1 location / { 2 proxy_pass http://fzjhs; 3 }测试：打开浏览器输入Url地址 http://localhost/nginx-test/index.html 不停的刷新页面，可以看见index.html上面的端口号一直在9601、9602中间切换，我这边刷新了十次，9601出现3次，9602出现7次
说明：该策略相当于是在轮循策略基础上，人为控制出现的几率。从上面测试可以看出，nginx.conf里面虽然也给9603端口配置了权重，但是他没有启动；所以9601端口出现的几率为3/9，9602端口出现的几率为6/9；如果这个时候把9603端口启动起来，那么9601端口出现的几率为3/10，9602端口出现的几率为6/10，9603端口出现的几率为1/10
案例三：负载均衡(ip_hash)
准备：我这边在同一台电脑上面启动了两个tomcat，端口分别为9601、9602，每个tomcat下面都放了一个nginx-test项目，项目里面有一个写有当前tomcat端口的index.html
修改：nginx.conf文件，在http里面增加：
1 upstream fzjhs { 2 ip_hash; 3 server localhost:9601 weight=5; 4 server localhost:9602 weight=5;
5 }修改：nginx.conf文件，在server里面增加：
1 location / { 2 proxy_pass http://fzjhs; 3 }测试：打开浏览器输入Url地址 http://localhost/nginx-test/index.html 不停的刷新页面，可以看见index.html上面的端口号要么一直是9601要么一直是9602
说明：该策越可以让某一用户在很长的一个时间段里面只访问固定的服务器；如果使用上面的轮循和权重模式，会出现用户登录之后，用户session存储在9601端口的服务器上面，然后用户一刷新，Nginx又给用户分配到9602端口上面了，这个时候系统又会让用户重新登录
案例四：负载均衡(least_conn)
准备：我这边在同一台电脑上面启动了三个tomcat，端口分别为9601、9602、9603，每个tomcat下面都放了一个nginx-test项目，项目里面有一个写有当前tomcat端口的index.html
修改：nginx.conf文件，在http里面增加：
1 upstream fzjhs { 2 ip_hash; 3 server localhost:9601 weight=5; 4 server localhost:9602 weight=5; 5 server localhost:9603 weight=3; 6 }修改：nginx.conf文件，在server里面增加：
1 location / { 2 proxy_pass http://fzjhs; 3 }测试：打开浏览器输入Url地址 http://localhost/nginx-test/index.html 不停的刷新页面，可以看见index.html上面的端口号一直在9601、9602、9603中间切换
说明：看到上面测试你会想，这tmd不是跟轮循模式一样了？它里面其实有规律的，请看下面例子：
说明例子：当前9601端口上有100个连接数、9602端口上有120个连接数、9603端口上有48个连接数，Nginx会选择9603端口，因为9603的连接数/权重=16是最小的值，而9601的连接数/权重=20，9602的连接数/权重=24
得出：least_conn = 连接数与权重的比值的最小者
负载均衡状态参数配置
weight：权重
1 server localhost:9601 weight=2;down：当前服务器下机、不参与负载均衡
1 server localhost:9601 down;backup：备份服务器、当其他服务器繁忙异常的时候才会使用此服务器
1 server localhost:9601 backup;max_fails：请求最大失败次数、默认为1、当超过这个值得时候返回proxy_next_upstream错误
1 server localhost:9601 max_fails=2;fail_timeout：当请求错误达到max_fails配置值时、暂停服务的时间、默认为10s
1 server localhost:9601 fail_timeout=5s;
proxy_next_upstream怎么用？在什么情况下面会使用？
我这边在同一台电脑上面启动了两个tomcat，端口分别为9601、9602，每个tomcat下面都放了一个nginx-test项目，但是只有9601端口下面的项目里面放了一个写有当前tomcat端口的index.html，这个时候我按照负载均衡轮循配置，配置完成之后，去访问http://localhost/nginx-test/index.html，有一半的几率会出现404错误，如果
max_fails=2，纳闷就会出现2次404错误后，9602端口的服务器才会被踢下去，这个时候想要避免这个问题，就需要通过proxy_next_upstream做如下配置：
1 location / { 2 proxy_pass http://fzjhs; 3 proxy_next_upstream http_404 error invalid_header; 4 }通过上面配置，如果访问9602端口的服务器出现404错误，允许把当前请求转发到其他服务器，这样用户就不会看见页面上面出现404错误。
使用proxy_next_upstream会出现那些问题？proxy_next_upstream注意事项？
注意事项：必须和proxy_pass、upstream块一起使用
出现问题：重复请求