nginx负载均衡中RR和ip_hash策略分析

1、nginx 负载均衡中rr 和 ip_hash 策略分析一、nginx 的 upstream目前支持负载均衡方式的分配1、rr（默认）每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。例如：upstream tomcats server 07:88 max_fails=3 fail_timeout=3s weight=9; server 32:80 max_fails=3 fail_timeout=3s weight=9; 2、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决 s

2、ession的问题。例如：upstream tomcats ip_hash; server 07:88; server 32:80; 3、fair （第三方）按后端服务器的响应时间来分配请求，响应时间短的优先分配。4、url_hash（第三方）按访问 url 的 hash结果来分配请求，使每个url 定向到同一个后端服务器，后端服务器为缓存时比较有效。下面，我们针对rr 和 ip_hash 的负载均衡策略进行分析。因为每一种负载均衡策略都是在upstream 的框架中使用，upstream 控制总的工作流程，负载均衡策略仅仅提供选择或释放server 的函数，所

3、以，我们在分析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_fail

4、s=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 秒之内该服

5、务器不能被访问。对于 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 值的大小，由高

6、到底排序。本例中，在数组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 都失败，

7、 不能提供服务了，通过 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

8、 (peern.current_weight * 1000 / peeri.current_weight peern.weight * 1000 / peeri.weight) /peeri.current_weight不为 0 并且该 server 的 current_weight 大于 0，就选择 sever n, 把编号 n 赋给 rrp-current ，成功返回。如果当 upstream 的 peers 数组中的所有server 的 current_weight 都为零时，立即无条件地把所有server的 current_weight 设置为初始值。for (i = 0; i num

9、ber; i+) peeri.current_weight = peeri.weight; 然后，当所有server 的current_weight设置为初始值后，重新查找peers 数组中current_weight 最大的 server。把编号赋给rrp-current ，返回。2.2.2 判断当前rrp-current 所指向的server 是否有效，如果无效，就会让rrp-current+ ，判断 peers数组中下一个server， 是否有效。 至到找到有效的server 为止 . 跳转到 2.2.3; 否则跳转到 判断 server 是否有效的方法是：1）如果 se

10、rver 的失败次数 （peers-peeri.fails ）没有达到了max_fails 所设置的最大失败次数，则该server 是有效的。2）如果 server 已经达到了max_fails 所设置的最大失败次数，从这一时刻开始算起，在 fail_timeout 所设置的时间段内，server 是无效的。3）当 server 的失败次数（peers-peeri.fails ）为最大的失败次数，当距离现在的时间超过了fail_timeout 所设置的时间段，则令 peers-peeri.fails =0，使得该server 重新有效。 如果 peers中所有的 server 都

11、是无效的 ; 就会尝试去backup 的数组中找一个有效的 server, 如果找到，跳转到 2.2.3; 如果仍然找不到，表示此时upstream 中无 server 可以使用。就会清空所有peers数组中所有的失败次数的记录，使所有server 都变成了有效。这样做的目的是为了防止下次再有请求访问时，仍找不到一个有效的server. for (i = 0; i number; i+) peers-peeri.fails = 0; 并返回错误码给nginx, nginx 得到此错误码后，就不再向后台server 发请求， 而是在 nginx的错误日志中输出 “no live upstream

12、s while connecting to upstream” 的记录（这就是 no live产生的真正原因） ，并直接返回给请求的客户端一个502 的错误。2.2.3 当找到一个有效的server 后，令该server 的 current_weight 减一，然后， nginx 就会尝试与该server 建立连接。如果成功建立连接，跳转到2.2.4; 否则跳转到 如果 nginx 在等待了proxy_connect_timeout 所设置的时间段后（如3 秒） ，连接仍然没有建立成功，nginx 就在错误日志中输出“upstream timed out (11

13、0: 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 都尝试了一遍， 没有

14、server可以提供服务，返回一个504 的错误给客户端。2.2.4 当 nginx 与 server 建立连接成功后， 如果 server 响应请求，把处理结果返回给nginx, 跳转到 2.2.5; 否则跳转到 如果 nginx 在等待了 proxy_read_timeout 所设置的时间段后 （如 30 秒） ， server仍然没有对nginx 发送来的请求作出响应，nginx 就在错误日志中输出“upstream timed out (110: connection timed out) while reading response header fro

15、m upstream”的记录（这就是timed out（读超时）产生的真正原因）. 接着，让当前server 的失败次数加一（peer-fails+; 如果该 server 最大失败次达到最大失败次数，将在一段时间内该server 是无效的），如果当前nginx 与后台服务器的尝试次数没有达到upstream中 server的总个数，重新跳转到2.2.2, 轮循下一个server, 继续尝试。 如果达到最大尝试次数，就表示 uptream 中所有的 server 都尝试了一遍， 没有 server可以提供服务，返回一个504 的错误给客户端。2.2.5 nginx 收到后台se

16、rver 传送过来的结果后，就会返回给客户端一个200 的正确结果。 这样， nginx 作为反向代理的功能也就完成了。三、ip_hash 策略3.1 ip_hash和 rr 的策略有两点不同在于：当一个客户请求到nginx 后，1）nginx 如何选择一个最初的server, 2）以及当前选择的server 不能提供服务时，如何选择下一个server. 3.2 rr 策略回顾从第二部分对rr 的介绍中，我们知道：当一个客户请求到达后，rr 策略是从upstream 的所有server 中选择一个当前权重（current_weight ）最大的server 作为最初的server. upstr

17、eam 的所有 server 是按照由高到低排序后存储在一个peers数组中，当最初选择的server不能提供服务时，rr 策略就会选择peers数组中的下一个元素作为当前server，继续尝试，如果已经达到数组的最大元素，就会从第一个元素再轮循。3.3 ip_hash策略介绍在 ip_hash 策略中，它选择最初的server 的方法是根据请求客户端的ip 计算出一个哈希值，再根据哈希值选择后台的服务器。1）由 ip 计算哈希值的算法如下，其中公式中hash 初始值为89，iphp-addri 表示客户端的 ip， 通过三次哈希计算得出一个ip 的哈希值：for (i = 0; i addri) % 6271; 2）在选择下一个server 时， ip_hash 的选择策略是这样的：它在上一次哈希值的基础上，再次哈希，就会得到一个全新的哈希值，再根据哈希值选择另外一个后台的服务器。哈希算法仍然是for (i = 0; i addri) % 6271; 在这种ip_hash 策略，如果一个后台服务器不能提供提服务（连接超时或读超时），该服务器的失败次数就会加一，当一个服务器的失败次数达到max_fails 所设置的值，就会在fail_timeout 所设置的时间段内不能对外提供服务，这点和rr 是一致的。如果当前server 不能提供服务，就会根据当前的哈希值再哈