负载均衡 反向代理

http模块的 upstream 配置
配置1：
Upstream backserver {
server 127.0.0.1:9100;
#其它所有的非backup机器down的时候，才请求backup机器
server 127.0.0.1:9200 backup;
}
配置2：
Upstream backserver {
server 127.0.0.1:9100;
#down表示当前的server是down状态，不参与负载均衡
server 127.0.0.1:9200 down;
}
一般在项目上线的时候，可以分配部署不同的服务器上，然后对Nginx重新reload。
reload不会影响用户的访问，或者可以给一个提示页面,系统正在升级…

配置 3 最少连接
web请求会被转发到连接数最少的服务器上
upstreambackserver {
least_conn;
server 127.0.0.1:8080;
server 127.0.0.1:9090;
}

方式 1： 权重
upstream www.myweb.com {
server 127.0.0.1:9100 weight=3;
server 127.0.0.1:9200 weight=1;
}

其中weight=1表示权重，用于后端服务器性能不均的情况，访问比率约等于权重之比，权重越大
访问机会越多。upstream是配置nginx与后端服务器负载均衡非常重要的一个模块，并且它还能
对后端的服务器的健康状态进行检查，若后端服务器中的一台发生故障，则前端的请求不会转发
到该故障的机器

方式 2 ：ip_hash

upstream www.myweb.com {
ip_hash;
server 127.0.0.1:9100 ;
server 127.0.0.1:9200 ;
}
1）由IP计算哈希值的算法如下，其中公式中hash初始值为89，iphp->addr[i]表示客户端的IP，通过三次哈希计算得出一个IP的哈希值：

for (i = 0; i < 3; i++) {

 hash = (hash * 113 + iphp->addr[i]) % 6271;

}

2）在选择下一个server时，ip_hash的选择策略是这样的：

它在上一次哈希值的基础上，再次哈希，就会得到一个全新的哈希值，再根据哈希值选择另外一个后台的服务器。

哈希算法仍然是

for (i = 0; i < 3; i++) {

 hash = (hash * 113 + iphp->addr[i]) % 6271;

}

在这种ip_hash策略，如果一个后台服务器不能提供提服务（连接超时或读超时），该服务器的失败次数就会加一，当一个服务器的失败次数达到max_fails所设置的值，就会在fail_timeout所设置的时间段内不能对外提供服务，这点和RR是一致的。

如果当前server不能提供服务，就会根据当前的哈希值再哈希出一个新哈希值，选择另一个服务器继续尝试，尝试的最大次是upstream中server的个数，如果server的个数超过20，也就是要最大尝试次数在20次以上，当尝试次数达到20次，仍然找不到一个合适的服务器，ip_hah策略不再尝试ip哈希值来选择server,而在剩余的尝试中，它会转而使用RR的策略，使用轮循的方法，选择新的server。

ip_hash（通过客户端请求ip进行hash，再通过hash值选择后端server）
你服务端的一个特定url路径会被同一个用户连续访问时，如果负载均衡策略还是轮询的话，那该
用户的多次访问会被打到各台服务器上，这显然并不高效（会建立多次http链接等问题）。甚至
考虑一种极端情况，用户需要分片上传文件到服务器下，然后再由服务器将分片合并，这时如果
用户的请求到达了不同的服务器，那么分片将存储于不同的服务器目录中，导致无法将分片合并。
所以，此类场景可以考虑采用nginx提供的ip_hash策略。既能满足每个用户请求到同一台服务器，
又能满足不同用户之间负载均衡。

方式 3：轮询

upstream www.myweb.com {
server 127.0.0.1:9100 ;
server 127.0.0.1:9200 ;

}

pstream tomcats {

 server 10.1.1.107:88 max_fails=3 fail_timeout=3s weight=9;

 server 10.1.1.132:80 max_fails=3 fail_timeout=3s weight=9;

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