Nginx的upstream目前支持的五种方式的分配，分别是：轮询策略，权重轮询策略，ip_hash策略，fair策略，url_hash策略。

目前我总结的nginx负载策略共两大类，分别是：内置策略和扩展策略。

1)? ??内置策略有3种，包括：轮询策略、加权轮询策略和ip_hash策略。默认情况下内置策略会编译进Nginx的内核，只需要在nginx配置中指明参数即可。

轮询策略

顾名思义，该策略就是服务器将每个前端请求按顺序（时间顺序和排列次序）逐一分配到不同的后端服务器节点。如果后端服务器出现问题，即down掉，那么就会被自动剔除。

例如：当前端有多个请求到后端服务器节点，服务会被轮流分配到下面三个服务器。

? ?upstream s_siat{

? ? server 172.31.3.82:9170;

? ? server 172.31.3.82:9171;

? ? server 172.31.3.82:9173;

? ?}

加权轮询策略

该策略在基本的轮询策略基础上考虑各后端服务器节点接受请求的权重，指定各后端服务器节点被轮询到的机率，主要应用于后端服务器节点性能不均的情况。

例如：通过直接配置weight来设置访问机率，weight的大小和访问比率成正比。下面三个服务器（如果不配置weight，则默认配置为weight=1），第一个的权重是1，第二个的权重是3，第三个的权重是2，那么这三个后端服务器被访问的比率是1:3:2，即server172.31.3.82:9171被访问的机率最高，server172.31.3.82:9171次之，server172.31.3.82:9170访问的机率最小。

? ?upstream s_siat{

? ? server 172.31.3.82:9170;

? ? server 172.31.3.82:9171? weight=3;

? ? server 172.31.3.82:9173? weight=2;

? ?}

注意：因为weight是内置，所以可以直接和其他策略配合使用。

ip_hash策略

? ?该策略是将前端的访问IP进行hash操作，然后根据hash结果将请求分配到不同的后端服务器节点。这样会使得每个前端访问IP会固定访问一个后端服务器节点，好处是前端用户的session只在一个后端服务器节点上，不必考虑一个session存在多台服务器节点出现session贡献问题。

例如：因为weight是内置，所以可以直接和其他策略配合使用。本策略使用的是ip_hash策略，需要在配置upstream中添加ip_hash一行。

upstream s_siat{

?ip_hash;

? ? server 172.31.3.82:9170;

? ? server172.31.3.82:9171? weight=3;

? ? server 172.31.3.82:9173? weight=2;

? ?}

或者：

upstream s_siat{

?ip_hash;

? ? server 172.31.3.82:9170;

? ? server 172.31.3.82:9171;

? ? server 172.31.3.82:9173;

? ?}

两者都是ip_hash策略。只是对应服务器被访问的机率有所改变。

注意：ip_hash模块和后面的Sticky模块不能够同时使用。

2)? ? ? ? 扩展策略有3种，包括：url_hash策略、fair策略和sticky策略。

url_hash策略

该策略将前端请求的url地址进行hash操作，根据hash结果将请求定向到同一后端服务器节点上，后台服务器为缓存是比较有效。一般url_hash需要配合缓冲命中来使用。

例如：在upstream中加入hash语句，server语句中不能谢茹茹weight等其他参数，需要注意与ip_hash的区别。Hash_method是使用的hash算法。

upstream somestream {

? ? ? ?hash $request_uri;

? ? ? ?server 192.168.244.1:8080;

? ? ? ? ? ? server192.168.244.2:8080;

? ? ? ?server 192.168.244.3:8080;

? ? ? ?server 192.168.244.4:8080;

}

server {

? ? ? ? ? ?listen? ? ? 8081 default;

? ? ? ? ? ?server_name? test.csdn.net;

? ? ? ? ? ?charset utf-8;

? ? ? ? ? ?location /get {

? ? ? ? ? ? ? ? ? proxy_pass http://somestream;

? ?}

}

上述是一个极简的监听8081端口的nginx服务，当请求url为/get时，会走url_hash；同样配置了upstream模块，hash$request_uri表明了是按照url规则进行hash策略。

fair策略

? ?该策略请求转发到负载最小的后端服务器节点上。Nginx通过后端服务器节点对响应时间来判断负载情况，响应时间最短的节点负载就相对较轻，Nginx就会将前端请求转发到此后端服务器节点上。

例如：同样只需要在upstream的所有的server后面添加fair一行即可。

upstream s_siat{

? ? server 172.31.3.82:9170;

? ? server 172.31.3.82:9171;

?server 172.31.3.82:9173;

?fair;

? ?}

注意：这种策略具有很强的自适应性，但是实际的网络环境往往不是那么简单，因此需要慎用。

注意：如果浏览器不支持cookie，那么sticky不生效，毕竟整个模块是给予cookie实现。Sticky模块和ip_hash模块不能够同时使用。

注意：Nginx和Apache不同，Nginx每次安装一个新的模块都需要重新编译一次，编译完成之后将Nginx这一个文件拷贝到sbin下面即可。

三 upstream中的其他配置

? ? ? ? 常用upstream的小知识点总结。

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

proxy_passhttp://backserver/;?

upstreambackserver{?

ip_hash;?

server127.0.0.1:9090 down; (down 表示单前的server暂时不参与负载)?

server127.0.0.1:8080 weight=2; (weight 默认为1.weight越大，负载的权重就越大)?

server127.0.0.1:6060 max_fails=3 fail_timeout=30s;（max_fails允许请求失败的次数默认为1，此处允许失败的次数为3。每次失败后暂停的时间为30s）?

server127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候，请求backup机器)

keepalive16;(连接到nginx负载均衡器的最大)

}?

server{

? ?location / {? #（进行url重定向或进行新的代理）

? ? ? ?proxy_pass http://backend;

? ?}

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

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

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

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

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

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

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

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

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

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

cs