`
uule
  • 浏览: 6351994 次
  • 性别: Icon_minigender_1
  • 来自: 一片神奇的土地
社区版块
存档分类
最新评论

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].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; 否则跳转到 a

 

   判定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重新有效。

  

a、假如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; 否则 跳转到b

  b、 假如nginx在等待了proxy_connect_timeout所设置的时间段后(如3秒),连接仍然没有建立成功,nginx就在错误日志中输出“upstream timed out (110: Connection timed out) while connecting to upstream”的记录(这就是timed out(连接超时)产生的真正原因).

   c、 接着,让当前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; 否则跳转到d

  d、 假如nginx在等待了proxy_read_timeout所设置的时间段后(如30秒),server仍然没有对nginx发送来的请求作出响应,nginx就在错误日志中输出“upstream timed out (110: Connection timed out)while reading response header from upstream”的记录(这就是timed out(读超时)产生的真正原因).

   e、 接着,让当前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 Ip_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的请求分配给同一个后台服务器。

 

======================================================================

 

ip_hash

语法:ip_hash

默认值:none

使用环境:upstream

 

当对后端的多台动态应用服务器做负载均衡时,ip_hash指令能够将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上。这样,当来自某个IP的用户在后端Web服务器A上登录后,再访问该站点的其他URL,能够保证其访问的还是后端Web服务器A。如果不采用ip_hash指令,假设来自某个IP的用户在后端Web服务器A上登录后,再访问该站点的其他URL,有可能被定向到后端Web服务器B,C...上,由于用户登录后SESSION信息是记录在服务器A上的,B,C...上没有,这时就会提示用户来登录。

使用ip_hash指令无法保证后端服务器的负载均衡,可能有些后端服务器接收的请求多,有些后端服务器收到的请求少,而且设置后端服务权重等方法将不起作用。所以,如果后端的动态应用服务器能够做到SESSION共享,还是建议采用后端服务的SESSION共享方式代替Nginx的ip_hash方式。

如果后端服务器有时要从Nginx负载均衡中摘除一段时间,你必须其标记为“down”,而不是直接从配置文件中删除或注释掉该后端服务器的信息。例如:


 

这样,当原来为4台后端服务时,摘除backend3.example后,Nginx仍然会按4台服务器进行哈希。如果直接注释掉“server backend3.example.com”这行,Nginx就会按照3台服务器进行重新

哈希,原来被哈希到backend1.example.com的客户端IP有可能被哈希backend2.example.com服务器上,原有的SESSION就会失效。

 

 

设备的状态有:

 

  • down 表示单前的server暂时不参与负载
  • weight 权重,默认为1。 weight越大,负载的权重就越大。
  • max_fails 允许请求失败的次数默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误
  • fail_timeout max_fails次失败后,暂停的时间。
  • backup 备用服务器, 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
  • 大小: 16.1 KB
分享到:
评论

相关推荐

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

    ### nginx负载均衡中RR和ip_hash策略分析 #### 一、引言 在现代互联网架构中,随着业务规模的增长和技术的发展,单台服务器往往难以满足大量用户访问的需求。因此,负载均衡技术应运而生,它能够有效地分散访问请求...

    nginx-负载均衡宕机配置nginx会进行恢复并进行重新监听

    本文将深入探讨Nginx负载均衡机制,特别是当后端服务器出现故障时,Nginx如何识别这些故障,并采取相应的措施来恢复服务。 #### 二、Nginx负载均衡概述 Nginx支持多种负载均衡策略,包括轮询(rr)、基于IP的散列(ip_...

    使用nginx做负载均衡的模块解读

    ngx_http_upstream_module是Nginx实现负载均衡的关键模块,它允许我们定义一组后端服务器,并根据预设的策略将客户端请求分发到这些服务器上,以实现高可用性和负载分布。Nginx的负载均衡功能包括反向代理、与动态...

    Nginx负载均衡

    在nginx中负载均衡主要实现用户访问请求进行调度分配和后端服务器的压力分担。 负载均衡调度算法 轮询(rr) :按时间顺序逐一分配到不同的后端服务器(默认) 权重(weight):加权轮询(wrr)。weight值越大,分配到的访问...

    nginx upstream 容错机制.pdf

    #### 五、Nginx负载均衡方式简介 Nginx支持以下四种负载均衡策略: 1. **RR (轮询模式)**:按顺序将请求分发给后端服务器,如果某台服务器连续失败次数达到`max_fails`时,在`fail_timeout`时间内会被暂时移除,...

    全面了解 Nginx 到底能做什么

    #### 四、Nginx负载均衡 负载均衡是将流量分散到多个后端服务器的一种技术。Nginx支持多种负载均衡算法,包括但不限于: 1. **RR(Round Robin,默认)**: - 按照轮询的方式依次将请求分发给后端服务器。 - 如果...

    linux服务器之LVS、Nginx和HAProxy负载均衡器对比总结

    本篇文章将对比三种常用的Linux服务器负载均衡器:LVS、Nginx和HAProxy,探讨其各自的特点、适用场景和常用算法。 LVS(Linux Virtual Server)是基于IP层的负载均衡器,它具有以下显著特点: 1. 高抗负载能力:...

    基于haproxy构建负载均衡集群.docx

    HAProxy 负载均衡策略非常多,HAProxy 的负载均衡算法现在具体有如下 8 种: 1. roundrobin,表示简单的轮询,这个不多说,这个是负载均衡基本都具备的。 2. static-rr,表示根据权重,建议关注。 3. leastconn,...

    Nginx基本使用介绍.pdf

    * 负载均衡:负载均衡就是将请求分摊到多个操作单元上进行执行,Nginx常用的负载均衡算法包括RR、fair和url_hash等。 * HTTP服务器(动静分离):Nginx可以用作HTTP服务器,提供静态文件服务和动态网站服务。 3. ...

    nginx-tutorial:Nginx安装维护入门学习笔记,以及各种实例

    有这些标签:「异步」「事件」「模块化」「高性能」「高并发」「反向代理」「负载均衡」Linux系统:Centos 7 x64Nginx版本:1.11.5目录配置常用正则全局变量符号参考配置文件内置预定义变量反向代理负载均衡RR权重ip_...

    Nginx 安装

    在负载均衡方面,Nginx支持多种调度策略,如轮询(RR)、ip_hash、权重、fair和url_hash等,这让Nginx可以灵活地应对不同的业务需求。它还能作为静态和动态资源的HTTP服务器,支持动静分离,提高资源的使用效率和...

    2022最新版运维最全面面试题!

    2. **Nginx upstream轮询策略**:Nginx的upstream模块支持多种轮询策略,如轮询(round-robin)、权重轮询(weighted round-robin)、IP哈希(ip_hash)等,以实现负载均衡。 3. **限流**:使用`limit_req_zone`...

    Django高并发负载均衡实现原理详解

    在实际应用中,开发者可能会结合这两种策略,或者使用更高级的负载均衡技术,如Nginx反向代理、IP Hash、一致性哈希等,以适应更复杂的需求。这些技术能够更有效地平衡负载,提高系统容错性,确保在高并发环境下...

    haproxy-2.0.5_for_windows.rar

      5、HAProxy可以对mysql读进行负载均衡,对后端的MySQL节点进行检测和负载均衡,不过在后端的MySQL slaves数量超过10台时性能不如LVS   6、能够提供4层,7层代理。HAProxy支持两种主要的代理模式:"tcp"也即4层...

    掌握LVS概念及原理、调度算法,工作模式.doc

    负载均衡集群是使用户访问请求尽可能平均动态分配,运行时,通过前端一个或多个调度器(Director)软件型:LVS、Haproxy、Nginx 等硬件型:F5、Netscaler、Redware 等。 LVS 的专业术语: LVS 的专业术语包括负载...

Global site tag (gtag.js) - Google Analytics