Nginx的几种负载均衡upstream

本文暂时不考虑session共享的问题，仅针对upstream的几种方式作简单介绍。 这样定义： 在http{}内增加 一、默认模式（按每个请求的时间顺序交替*每个服务器权重一样*分配到不同的服务器，

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

这样定义：

在http{}内增加

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

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.     }

二、 分配权重（是上面一种的升级，第一种默认是权重一致，现在是可自定义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共享的基础上使用。

三、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分流，剩下的走其它后端去。

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