Nginx的几种负载均衡upstream

本文暂时不考虑session共享的问题，仅针对upstream的几种方式做简单介绍。

这样定义：

在http{}内增长

1、默认模式（按每一个请求的时间顺序交替*每一个服务器权重同样*分配到不一样的服务器，若是服务器挂了会自动剔除）

1. upstream callbell_ccrm {
2.         server 10.161.215.40 down; 
3.         server 10.165.32.12;
4.         server 10.165.32.13;
5.         server 10.165.32.14 backup;
6.     }

2、 分配权重（是上面一种的升级，第一种默认是权重一致，如今是可自定义weight，即访问的比例，当前是2:1 ，一般服务器配置高的weight大，若是服务器挂了会自动剔除）

1. upstream callbell_ccrm {
2.         server 10.161.215.40 down; 
3.         server 10.165.32.12 weight=2;
4.         server 10.165.32.13 weight=1;
5.         server 10.165.32.14 backup;
6.     }

down 表示单前的server暂时不参与负载 
weight  默认为1.weight越大，负载的权重就越大。 
max_fails ：容许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误 
fail_timeout:max_fails 次失败后，暂停的时间。 
backup： 其它全部的非backup机器down或者忙的时候，请求backup机器。因此这台机器压力会最轻。

注意：前两种方式都是针对每一个请求的，因此一个用户的屡次请求会被分配到不一样服务器上，若是没有实现session，会出现各类问题，此两种方案必须在实现session共享的基础上使用。

3、IP哈希、绑定 （按每一个请求按访问ip的hash结果分配，这样每一个ip的访客都“固定”访问一个后端服务器，不会有session的问题，若是某一台服务器挂了会自动剔除，可是会将请求分配到别的服务器上，此时就会有session不一样步的问题）

1.  upstream callbell_ccrm {
2.         ip_hash; #ip轮询
3.         server 10.161.215.40; 
4.         server 10.165.32.12;
5.     }

 还能够结合权重来使用 ip_hash 如：

1. upstream callbell_ccrm {
2.         ip_hash; #ip轮询
3.         server 10.161.215.40 weight=3;  #权重比为3
4.         server 10.165.32.12 weight=1;#权重比为1
5.     }

这样能够根据便可经过IP来区分访客并固定访问一个服务器，又能够根据权重更好利用服务器资源。

注意：同一个局域网其实出口IP都是同一个，因此都会分配到同一台后台服务器。

ip_hash是有缺陷的，不能在一些状况下使用：

1.nginx不是最前端的服务器。ip_hash要求nginx必定是最前端的服务器，不然nginx得不到正确ip，就不能根据ip做hash。譬如使用的是squid为最前端，那么nginx取ip时只能获得squid的服务器ip地址，用这个地址来做分流是确定错乱的。

2.nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又经过另外的方式分流了，那么某个客户端的请求确定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，而后指向应用服务器。最好的办法是用location做一次分流，将须要session的部分请求经过ip_hash分流，剩下的走其它后端去。

4、其余第三方：fair  按后端服务器的响应时间来分配请求，响应时间短的优先分配。 url_hash 按url的hash来分配。