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  A  max_fails=3 fail_timeout=4s weight=9;
          server  B  max_fails=3 fail_timeout=4s weight=9;
          server  C  max_fails=3 fail_timeout=4s weight=9;
          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].w
eight)  //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.2.4.1 如果nginx在等待了proxy_read_timeout所设置的时间段后（如30秒），server仍然没有对nginx发送来的请求作出响应，nginx就在错误日志中输出“upstream timed out (110: Connection timed out) while reading response header from upstreamweight的所有形式”的记录（这就是 timed out（读超时）产生的真正原因）.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。