server server server max_fails=3 fail_timeout=4s weight=9; max_fails=3 fail_timeout=4s weight=9; max_fails=3 fail_timeout=4s weight=9;
nginx 负载均衡中RR 和ip_hash 策略分析
一、nginx 的upstream 目前支持负载均衡方式的分配
1、RR （默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。例如：
upstream 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;
}
2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session 的问题。
例如：
upstream tomcats {
ip_hash;
server 10.1.1.107:88;
server 10.1.1.132:80;
}
3、fair （第三方）按后端服务器的响应时间来分配请求，响应时间短的优先分配。
4、url_hash （第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
下面，我们针对RR 和ip_hash 的负载均衡策略进行分析。因为每一种负载均衡策略都是在upstream 的框架中使用，upstream 控制总的工作流程，负载均衡策略仅仅提供选择或释放server 的函数，所以，我们在分析RR 时结合upstream（ngx_http_upstream.c）。ip_hash 大部分内容与RR 一致，只是重新实现RR 中的ngx_http_upstream_get_peer 函数。
二、RR 策略
RR机制分为三个部分：初始化upstream，获取一个可用的后台服务器和释放后台服务器。
以下分析以此配置为例:
upstream backend {
server D backup;
Server E backup; }
2.1 初始化upstream
对于例子中的upstream backend 来说，
首先初始化各个server, 除了设置IP 和端口号外，还要设置如下置weight ，current_weight ，max_fails 和fail_timeout 。其中max_fails 和fail_timeout 这两个参数是组合使用的，表示server 如果失败次数达到max_fails 次，并保持fail_timeout 秒之内该服务器不能被访问。
对于serverA 来说，设置如下serverA.weight =9;
serverA.current_weight = 9; //初始值等于配置文件中的weight.
serverA.max_fails = 3;
serverA.fail_timeout = 4;
接着，创建两个server 类型(在下文介绍中，server 类型等同于peer 类型，都是用来指明存储upstream中一个server的信息)的数组，peers和backup,分别存储正常的轮循server 和备用server. 并且，按照数组中各个server 的weight 值的大小，由高到底排序。
本例中，在数组peers 中存储serverA、serverB 和serverC, 并记录server 的总个数
peers->number=3; 在数组backup 中存储serverD 和serverE, 并记录server 的总个数
backup->number=2;
最后，设置upstream 中各个变量的值。
rrp 表示当前要轮循的server 数组，初始设置为Upstream->rrp = peers.
tries表示尝试的次数，当尝试一个server失败后，tries的值就会减一。初始设置为peers 的总个数。
Next表示当peers数组中server都失败，不能提供服务了，通过upstream-〉next，切换到back 数组中选择server.
2.2 具体的RR 策略
2.2.1 ) 选择最初要轮循的server, 把它给rrp->current 变量，跳转到2.2.2 当一个客户端请求到达nginx 后，nginx 就会在upstream 的peers 数组中挑选一个current_weight 最大的server 作为当前请求最初要轮循的server. 在peers 数组中选取current_weight 最大的算法如下：由于peers数组中的server是按照weight值的大小排序好的。它是通过双重循环，满足下列条件后,
if (peer[n].current_weight * 1000 / peer[i].current_weight > peer[n].weight * 1000 / peer[i].weight)
//peer[i].current_weight 不为0
并且该server 的current_weight 大于0，就选择sever n, 把编号n 赋给rrp->current ，成功返回。
如果当upstream 的peers 数组中的所有server 的current_weight 都为零时，立即无条件地把所有server 的current_weight 设置为初始值。for （i = 0; i < peers->number; i++）
{ peer[i].current_weight = peer[i].weight;
}
然后，当所有server 的current_weight 设置为初始值后，重新查找peers 数组中
current_weight 最大的server。把编号赋给rrp->current，返回。
2.2.2 判断当前rrp->current 所指向的server 是否有效，如果无效，就会让rrp->current++ ，判断peers数组中下一个server,是否有效。至到找到有效的server为止.跳转到2.2.3;否则跳转到
2.2.2.1
判断server 是否有效的方法是：
1）如果server的失败次数（peers->peer[i].fails）没有达到了max_fails所设置的最大失败次数，则该server是有效的。
2）如果server 已经达到了max_fails 所设置的最大失败次数，从这一时刻开始算起，在fail_timeout 所设置的时间段内，server 是无效的。
3）当server的失败次数（peers->peer[i].fails ）为最大的失败次数，当距离现在的时间超过了fail_timeout所设置的时间段，则令peers->peer[i].fails =0，使得该server重新有效。
2.2.2.1如果peers中所有的server都是无效的；就会尝试去backup的数组中找一个有效的server,如果找到，跳转到2.2.3;如果仍然找不到，表示此时upstream中无server可以
使用。就会清空所有peers数组中所有的失败次数的记录，使所有server都变成了有效。这
样做的目的是为了防止下次再有请求访问时，仍找不到一个有效的server.
for （i = 0; i < peers->number; i++） {
peers->peer[i].fails = 0;
}
并返回错误码给nginx, nginx 得到此错误码后，就不再向后台server 发请求，而是在nginx 的错误日志中输出“no live upstreams while connecting to upstream ”的记录（这就是no live 产生的真正原因），并直接返回给请求的客户端一个502的错误。
2.2.3当找到一个有效的server后，令该server的current_weight减一，然后，nginx就
会尝试与该server 建立连接。如果成功建立连接，跳转到 2.2.4; 否则跳转到 2.2..3.1
2.2..
3.1 如果nginx 在等待了proxy_connect_timeout 所设置的时间段后（如3 秒），连接仍然没有建立成功，nginx 就在错误日志中输出“ upstream timed out （110: Connection timed out）while connecting to upstream ”的记录（这就是timed out （连接超时）产生的真正原因）.
2.2.3 .2接着，让当前server的失败次数加一（peer->fails++;如果该server最大失败次达到最大失败次数，将在一段时间内该server是无效的），如果当前nginx与后台服务器
的尝试次数没有达到upstream中server的总个数，重新跳转到 2.2.2,轮循下一个server,继
续尝试。如果达到最大尝试次数，就表示uptream 中所有的server 都尝试了一遍，没有server 可以提供服务，返回一个504 的错误给客户端。
2.2.4 当nginx 与server 建立连接成功后，如果server 响应请求，把处理结果返回给nginx, 跳转到 2.2.5; 否则跳转到 2.2.4.1
2.241如果nginx在等待了proxy_read_timeout所设置的时间段后（如30秒）,server 仍然没有对nginx 发送来的请求作出响应，nginx 就在错误日志中输出“upstream timed out （110: Connection timed out） while reading response header from upstream ”的记录（这就是timed out （读超时）产生的真正原因）.
2.2.4.2接着，让当前server的失败次数加一（peer->fails++;如果该server最大失败次达到最大失败次数，将在一段时间内该server 是无效的），如果当前nginx 与后台服务器的尝试次数没有达到upstream中server的总个数，重新跳转到2.2.2,轮循下一个server,继
续尝试。如果达到最大尝试次数，就表示uptream 中所有的server 都尝试了一遍，没有server 可以提供服务，返回一个504 的错误给客户端。
2.2.5 Nginx收到后台server传送过来的结果后，就会返回给客户端一个200的正确结果。这样，nginx 作为反向代理的功能也就完成了。
三、Ip_hash 策略
3.1 lp_hash和RR的策略有两点不同在于：
当一个客户请求到nginx 后，
1 ）nginx 如何选择一个最初的server,
2）以及当前选择的server 不能提供服务时，如何选择下一个server.
3.2 RR 策略回顾
从第二部分对RR 的介绍中，我们知道：
当一个客户请求到达后，RR 策略是从upstream 的所有server 中选择一个当前权重
（current_weight ）最大的server 作为最初的server.
upstream的所有server是按照由高到低排序后存储在一个peers数组中，当最初选择的server 不能提供服务时，RR策略就会选择peers数组中的下一个元素作为当前server，继续尝试，如果已经达到数组的最大元素，就会从第一个元素再轮循。
3.3 ip_hash策略介绍
在ip_hash策略中，它选择最初的server的方法是根据请求客户端的IP计算出一个哈希值，再根据哈希值选择后台的服务器。
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。
3) 除了以上部分不同外，IP_hash的其余部分和RR完全一样，因为它的其余部分功能的实现都是通过调用RR 中的函数。
4) IP_hash优势是把同一个客户IP的请求分配给同一个后台服务器。