nginx负载均衡_nginx负载均衡策略 - CSDN
精华内容
参与话题
  • nginx负载均衡的5种策略及原理

    万次阅读 多人点赞 2018-08-08 11:59:16
    nginx的upstream目前支持的5种方式的分配 1、轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。  upstream backserver {  server 192.168.0.14;  server 192.168...

    nginx的upstream目前支持的5种方式的分配


    1、轮询(默认)
    每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 
    upstream backserver { 
    server 192.168.0.14; 
    server 192.168.0.15; 


    2、指定权重
    指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 
    upstream backserver { 
    server 192.168.0.14 weight=8; 
    server 192.168.0.15 weight=10; 


    3、IP绑定 ip_hash
    每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 
    upstream backserver { 
    ip_hash; 
    server 192.168.0.14:88; 
    server 192.168.0.15:80; 


    4、fair(第三方)
    按后端服务器的响应时间来分配请求,响应时间短的优先分配。 
    upstream backserver { 
    server server1; 
    server server2; 
    fair; 


    5、url_hash(第三方)
    按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。 
    upstream backserver { 
    server squid1:3128; 
    server squid2:3128; 
    hash $request_uri; 
    hash_method crc32; 


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

    proxy_pass http://backserver/; 
    upstream backserver{ 
    ip_hash; 
    server 127.0.0.1:9090 down; (down 表示当前的server暂时不参与负载) 
    server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大,负载的权重就越大) 
    server 127.0.0.1:6060; 
    server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候,请求backup机器) 


    max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误 
    fail_timeout:max_fails次失败后,暂停的时间

     

    深入解析:

    1 前言



    随着网站负载的不断增加,负载均衡(load balance)已不是陌生话题。负载均衡是将流量负载分摊到不同的服务单元,保证服务器的高可用,保证响应足够快,给用户良好的体验。

    nginx第一个公开版发布于2004年。2011年发布了1.0版。它的特点是稳定性高、功能强大、资源消耗低。从服务器市场占有率来看,nginx已有与Apache分庭抗礼势头。其中,不得不提到的特性就是其负载均衡功能,这也成了很多公司选择它的主要原因。

    我们将从源码的角度介绍nginx的内置负载均衡策略和扩展负载均衡策略,以实际的工业生产为案例,对比各负载均衡策略,为nginx使用者提供一些参考。
     

    2. 源码剖析



    nginx的负载均衡策略可以划分为两大类:内置策略和扩展策略。

    内置策略包含加权轮询和ip hash,在默认情况下这两种策略会编译进nginx内核,只需在nginx配置中指明参数即可。扩展策略有很多,如fair、通用hash、consistent hash等,默认不编译进nginx内核。

    由于在nginx版本升级中负载均衡的代码没有本质性的变化,因此下面将以nginx1.0.15稳定版为例,从源码角度分析各个策略。

    2.1. 加权轮询(weighted round robin)

    轮询的原理很简单,首先我们介绍一下轮询的基本流程。如下是处理一次请求的流程图:



    图中有两点需要注意:

    第一,如果可以把加权轮询算法分为先深搜索和先广搜索,那么nginx采用的是先深搜索算法,即将首先将请求都分给高权重的机器,直到该机器的权值降到了比其他机器低,才开始将请求分给下一个高权重的机器。

    第二,当所有后端机器都down掉时,nginx会立即将所有机器的标志位清成初始状态,以避免造成所有的机器都处在timeout的状态,从而导致整个前端被夯住。

    接下来看下源码。nginx的目录结构很清晰,加权轮询所在路径为nginx-1.0.15/src/http/ngx_http_upstream_round_robin.[c|h],在源码的基础上,针对重要的、不易理解的地方我加了注释。首先看下ngx_http_upstream_round_robin.h中的重要声明:



    从变量命名中就可以大致猜出其作用。解释一下current_weight和weight的区别,前者为权重排序的值,随着处理请求会动态的变化,后者则是配置值,用来恢复初始状态。

    接下我们来看下轮询的创建过程。代码如下图:



    这里有个tried变量需要做些说明:tried中记录了服务器当前是否被尝试连接过。他是一个位图。如果服务器数量小于32,则只需在一个int中即可记录下所有服务器状态。如果服务器数量大于32,则需在内存池中申请内存来存储。

    对该位图数组的使用可参考如下代码:



    最后是实际的策略代码,逻辑较简单,代码实现也只有30行。来看代码。



    2.2. ip hash策略

    ip hash是nginx内置的另一个负载均衡策略,流程和轮询很类似,只是其中的算法和具体的策略有些变化。如下图所示:



    ip hash算法的核心实现请看如下代码:



    可以看到,hash值既与ip有关又与后端机器的数量有关。经测试,上述算法可以连续产生1045个互异的value,这是此算法硬限制。nginx使用了保护机制,当经过20次hash仍然找不到可用的机器时,算法退化成轮询。

    因此,从本质上说,ip hash算法是一种变相的轮询算法,如果两个ip的初始hash值恰好相同,那么来自这两个ip的请求将永远落在同一台服务器上,这为均衡性埋下了较深隐患。

    2.3. fair

    fair策略是扩展策略,默认不被编译进nginx内核。它根据后端服务器的响应时间判断负载情况,从中选出负载最轻的机器进行分流。
    这种策略具有很强的自适应性,但是实际的网络环境往往不是那么简单,因此须慎用。

    2.4.通用hash、一致性hash

    通用hash和一致性hash也是种扩展策略。通用hash可以以nginx内置的变量为key进行hash,一致性hash采用了nginx内置的一致性hash环,可支持memcache。
     

    3 对比测试



    了解了以上负载均衡策略,接下来我们来做一些测试。
    主要是对比各个策略的均衡性、一致性、容灾性等,从而分析出其中的差异性,根据数据给出各自的适用场景。

    为了能够全面、客观的测试nginx的负载均衡策略,我们采用两个测试工具、在不同场景下做测试,以此来降低环境对测试结果造成的影响。

    首先给大家介绍测试工具、测试网络拓扑和基本之测试流程。

    3.1 测试工具

    3.1.1  easyABC

    easyABC是百度内部开发的性能测试工具,培训采用epool模型实现,简单易上手,可以模拟GET/POST请求,极限情况下可以提供上万的压力,在团队内部得到广泛使用。

    由于被测试对象为反向代理服务器,因此需要在其后端搭建桩服务器,这里用nginx作为桩Web Server,提供最基本的静态文件服务。

    3.1.2  polygraph

    polygraph是一款免费的性能测试工具,以对缓存服务、代理、交换机等方面的测试见长。它有规范的配置语言PGL(Polygraph Language),为软件提供了强大的灵活性。其工作原理如下图所示:



    polygraph提供Client端和Server端,将测试目标nginx放在二者之间,三者之间的网络交互均走http协议,只需配置ip+port即可。

    Client端可以配置虚拟robot的个数以及每个robot发请求的速率,并向代理服务器发起随机的静态文件请求,Server端将按照请求的url生成随机大小的静态文件做响应。

    选用这个测试软件的一个主要原因:可以产生随机的url作为nginx各种hash策略key。
    另外polygraph还提供了日志分析工具,功能比较丰富,感兴趣的同学可以参考附录材料。

    3.2. 测试环境

    本次测试运行在5台物理机。其中:被测对象单独搭在一台8核机器上,另外四台4核机器分别搭建了easyABC、webserver桩和polygraph。如下图所示:



    3.3. 测试方案

    给各位介绍一下关键的测试指标:

    均衡性:是否能够将请求均匀的发送给后端
    一致性:同一个key的请求,是否能落到同一台机器
    容灾性:当部分后端机器挂掉时,是否能够正常工作

    以上述指标为指导,我们针对如下4个测试场景分别用easyABC和polygraph测试:

    场景1      server_*均正常提供服务;
    场景2      server_4挂掉,其他正常;
    场景3      server_3、server_4挂掉,其他正常;
    场景4      server_*均恢复正常服务。

    上述四个场景将按照时间顺序进行,每个场景将建立在上一个场景基础上,被测试对象无需做任何操作,以最大程度模拟实际情况。

    另外,考虑到测试工具自身的特点,在easyabc上的测试压力在17000左右,polygraph上的测试压力在4000左右。以上测试均保证被测试对象可以正常工作,且无任何notice级别以上(alert/error/warn)的日志出现,在每个场景中记录下server_*的qps用于最后的策略分析。

    3.4.  结果

    对比在两种测试工具下的测试结果会发现,结果完全一致,因此可以排除测试工具的影响。表1和图1是轮询策略在两种测试工具下的负载情况。

    从图表中可以看出,轮询策略对于均衡性和容灾性都可以做到较好的满足。





    表2和图2是fair策略在两种测试工具下的负载情况。fair策略受环境影响非常大,在排除了测试工具的干扰之后,结果仍然有非常大的抖动。

    从直观上讲,这完全不满足均衡性。但从另一个角度出发,恰恰是由于这种自适应性确保了在复杂的网络环境中能够物尽所用。因此,在应用到工业生产中之前,需要在具体的环境中做好测试工作。





    以下图表是各种hash策略,所不同的仅仅是hash key或者是具体的算法实现,因此一起做对比。实际测试中发现,通用hash和一致性hash均存在一个问题:当某台后端的机器挂掉时,原有落到这台机器上的流量会丢失,但是在ip hash中就不存在这样的问题。

    正如上文中对ip hash源码的分析,当ip hash失效时,会退化为轮询策略,因此不会有丢失流量的情况。从这个层面上说,ip hash也可以看成是轮询的升级版。



    图5为ip hash策略,ip hash是nginx内置策略,可以看做是前两种策略的特例:以来源IP为key。

    由于测试工具不太擅于模拟海量IP下的请求,因此这里截取线上实际的情况加以分析。如下图所示:



    图5 IP Hash策略

    图中前1/3使用轮询策略,中间段使用ip hash策略,后1/3仍然是轮询策略。可以明显的看出,ip hash的均衡性存在着很大的问题。

    原因并不难分析,在实际的网络环境中,有大量的高校出口路由器ip、企业出口路由器ip等网络节点,这些节点带来的流量往往是普通用户的成百上千倍,而ip hash策略恰恰是按照ip来划分流量,因此造成上述后果也就自然而然了。
     

    4 小结



    通过实际的对比测试,我们对nginx各个负载均衡策略进行了验证。下面从均衡性、一致性、容灾性以及适用场景等角度对比各种策略。如下图示:



    我们从源码和实际测试数据角度分析说明了nginx负载均衡的策略,给出了各种策略适合的应用场景。通过分析不难发现,无论哪种策略都不是万金油,在具体场景下应该选择哪种策略一定程度上依赖于使用者对策略的熟悉程度。

    以上分析和测试数据能够对大家有所帮助,期待有更多越来越好的负载均衡策略涌现,造福更多运维开发同学。
     

    参考:

    https://www.cnblogs.com/wpjamer/articles/6443332.html

    https://www.cnblogs.com/andashu/p/6377323.html

    展开全文
  • 使用Nginx实现负载均衡

    万次阅读 多人点赞 2018-12-04 14:34:18
    负载均衡这里面涉及的东西相对也是比较多的,理论就不说太多了,网上,书上很多,今天我们就利用Nginx服务器来实现一个简单的负载均衡 负载均衡算法 源地址哈希法:根据获取客户端的IP地址,通过哈...

    负载均衡的作用

    负载均衡:分摊到多个操作单元上进行执行,和它的英文名称很匹配。就是我们需要一个调度者,保证所有后端服务器都将性能充分发挥,从而保持服务器集群的整体性能最优,这就是负载均衡。
    负载均衡这里面涉及的东西相对也是比较多的,理论就不说太多了,网上,书上很多,今天我们就利用Nginx服务器来实现一个简单的负载均衡


    负载均衡算法

    • 源地址哈希法:根据获取客户端的IP地址,通过哈希函数计算得到一个数值,用该数值对服务器列表的大小进行取模运算,得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡,同一IP地址的客户端,当后端服务器列表不变时,它每次都会映射到同一台后端服务器进行访问。

    • 轮询法:将请求按顺序轮流地分配到后端服务器上,它均衡地对待后端的每一台服务器,而不关心服务器实际的连接数和当前的系统负载。

    • 随机法:通过系统的随机算法,根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。

    • 加权轮询法:不同的后端服务器可能机器的配置和当前系统的负载并不相同,因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重,让其处理更多的请;而配置低、负载高的机器,给其分配较低的权重,降低其系统负载,加权轮询能很好地处理这一问题,并将请求顺序且按照权重分配到后端。

    • 加权随机法:与加权轮询法一样,加权随机法也根据后端机器的配置,系统的负载分配不同的权重。不同的是,它是按照权重随机请求后端服务器,而非顺序。

    • 最小连接数法:由于后端服务器的配置不尽相同,对于请求的处理有快有慢,最小连接数法根据后端服务器当前的连接情况,动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求,尽可能地提高后端服务的利用效率,将负责合理地分流到每一台服务器。


    Nginx

    俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多,其中包括新浪、网易、腾讯、搜狐等企业的一些门户网站等,在3w以上的高并发环境下,ngnix处理能力相当于apache的10倍。
    Nginx在负载均衡这方面就是负载均衡的的一个组件,当然了还有Apache也属于其中的一个组件,还有很多很多。我之前看到过一篇文章,在这方面做过一个简单介绍,下篇文章我会做一个转载来进行说明。


    轮询法

    这个例子我就在我服务器上做了个实验,属于一个简陋版的,实际应用中负载均衡的搭建和配置是比较麻烦的,需要考虑的因素很多
    先说一下,nginx来做这个静态资源代理也是非常不错的,我在这个例子中就是做了这两块的内容。一个就是nginx做静态资源代理,一个是负载均衡的实现。
    由于自己试验,我手里只有两台服务器,所以负责调度分发的nginx服务器和其中一台处理服务器在一起,然后还有另一台单独的处理服务器。大概是这样:

    这里写图片描述
    实际上应该是这样的:
    这里写图片描述
    下面我们来看下Nginx的配置,是如何实现这个负载均衡的?
    说明:我的一号服务器原来装了一个LNMP一键安装包,所以待会你看nginx配置文件的时候可能会发现和你得略有不同,但是没有影响,就是一些配置项。我是将每个项目的配置文件单独放置了,并没有全部配置在nginx.conf文件中。

    //nginx.conf
    //这样配置,我就可以在nginx.conf文件当前路径的vhost文件夹下面单独管理每个项目的配置文件了
    ...
    ...
    ...
    include vhost/*.conf;
    }//这个是文件末尾的闭合大括号
    
    

    比如我有四个项目需要管理,vhost文件夹下如图:
    这里写图片描述
    我们现在来配置test-yii2.conf实现负载均衡。(这个文件其实很早存在的,懒得创建直接使用了)

    //test-yii2.conf
    upstream guwenjie_http {
            server **.***.***.***:9503 weight=1;
            server **.***.***.***:8811 weight=2;
    }
    server
         {
            listen 80;
            #listen [::]:80 default_server ipv6only=on;
            server_name test1.freephp.top;
            index  index.php index.html   index.htm ;
            root   /home/wwwroot/workspace/public/static;
    
            #error_page   404   /404.html;
    
            # Deny access to PHP files in specific directory
            #location ~ /(wp-content|uploads|wp-includes|images)/.*\.php$ { deny all; }
    
            include enable-php.conf;
    		
    		location / {
                 if (!-e $request_filename){
                    #proxy_pass http://127.0.0.1:8855;
                    proxy_pass http://guwenjie_http;
                 }
             }
             
            location /nginx_status
            {
                stub_status on;
                access_log   off;
            }
    
            location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
            {
                expires      30d;
            }
    
            location ~ .*\.(js|css)?$
            {
                expires      12h;
            }
    
            location ~ /.well-known {
                allow all;
            }
    
            location ~ /\.
            {
                deny all;
            }
    
    
    

    千万不要直接复制以上配置文件,因为其中的某些配置可能会对你的配置造成影响,大多数是不要虚理会的,我们主要解释其中几个点。

    • 静态资源代理

    我们将root 目录设置为下面所示目录,这里存放静态资源,其实他真正的存放于 127.0.0.1:8855 项目下的该目录。这里的IP本应是另一台服务器IP,为了测试就使用本机了。
    那么在这种情形下,当你访问配置的域名: test1.freephp.top/index.html 文件的话,我们依然能够访问成功,并且访问到了 127.0.0.1:8855 下 static 目录下的index.html

    ...
    ...
     root   /home/wwwroot/workspace/public/static;
    ...
    ...
    location / {
                 if (!-e $request_filename){
                    proxy_pass http://127.0.0.1:8855;
                 }
             }
    
    • 负载均衡配置

    我们使用 nginx 中的 upstream模块 来实现nginx将跨越单机的限制,完成网络数据的接收、处理和转发。我们主要使用提到的转发功能进行调度分发。

    我定义的 upstream 模块名称是 guwenjie_http (最好定义一个有意义的,这个就很不好 _),我配置了两个IP端口,到时候nginx分发的视乎就往这两个服务器上分发。

    先来对 upstream 进行一个说明吧

    //举例,以下IP,端口无效
     upstream test{ 
          server 11.22.333.11:6666 weight=1; 
          server 11.22.333.22:8888 down; 
          server 11.22.333.33:8888 backup;
          server 11.22.333.44:5555 weight=2; 
    }
    //down 表示单前的server临时不參与负载.
    //weight 默觉得1.weight越大,负载的权重就越大
    //backup: 其他全部的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻
    

    后面的 weight=1,weight=2 是表示权重的意思,数字越大,权重越高,在该例中 8811 这个端口权重就是 8855 的两倍,比如三次请求,大概就是两次分发给 8811 一次分发给 8855 ,其实这个是不需要写的,upstream 模块默认就是轮询法,每个ip分发一次,设置权重(加权轮询法)的意义上面已经解释过了,可以看下。

    upstream guwenjie_http {
            server **.***.***.***:8855 weight=1;
            server **.***.***.***:8811 weight=2;
    }
    ...
    ...
     root   /home/wwwroot/workspace/public/static;
    ...
    ...
    location / {
                 if (!-e $request_filename){
                     proxy_pass http://guwenjie_http;
                 }
             }
    

    源地址哈希法

    什么是源地址哈希法,就是对访问用户的IP进行hash后的结果进行分配,这样每一个用户固定请求同一个后端服务器,能够解决session的问题。
    直接上代码吧

    upstream guwenjie_http {
    		ip_hash; 
            server **.***.***.***:8855;
            server **.***.***.***:8811;
    }
    ...
    ...
    

    fair法(非官方)

    这个fair表示的是按照服务器响应时间的长短来进行分发的,服务器响应时间越短的,优先分发。

    upstream guwenjie_http {
            server **.***.***.***:8855;
            server **.***.***.***:8811;
            fair; 
    }
    ...
    ...
    

    说明

    以上就是简单的负载均衡的实现。准确的来说,这些属于:HTTP重定向实现负载均衡。它有一个比较大的缺点,(引用:)由于不同用户的访问时间、访问页面深度有所不同,从而每个用户对各自的后端服务器所造成的压力也不同。而调度服务器在调度时,无法知道当前用户将会对服务器造成多大的压力,因此这种方式无法实现真正意义上的负载均衡,只不过是把请求次数平均分配给每台服务器罢了。
    但是它确实实现了负载均衡,在一些要去并不强烈的项目中可以使用http重定向来实现均衡每台服务器压力的效果,以达到更高的并发总量。
    之后,我会将看到的另一篇我自己感觉比较好的关于负载均衡分析的文章转发给大家看一下。

    展开全文
  • Nginx负载均衡

    千次阅读 2019-06-23 17:39:57
    一、负载均衡分类 (1)软硬件分类 负载均衡可以通过负载均衡软件实现,也可通过硬件负载均衡器实现。 (2)硬件负载均衡 硬件负载均衡器的性能稳定,且有生产厂商作为专业的服务团队。但其成本很高,一台硬件...

    一、负载均衡分类

    (1)软硬件分类

    负载均衡可以通过负载均衡软件实现,也可通过硬件负载均衡器实现。

    (2)硬件负载均衡

    硬件负载均衡器的性能稳定,且有生产厂商作为专业的服务团队。但其成本很高,一台硬件负载均衡器的价格一般都在十几万到几十万,甚至上百万。知名的负载均衡器有F5、Array、深信服、梭子鱼等

    (3)软件负载均衡

    软件负载均衡成本几乎为零,基本都是开源软件。例如,LVS、HAProxy、Nginx等。

    (4)负载均衡工作层分类

    负载均衡就其所工作的OSI(开放系统互联模型)层次,在生产应用层面分为四类:

    • 七层负载均衡L7:应用层负载均衡,基于HTTP协议的。其是通过虚拟的URL将请求分配到真实的服务器。其一般应用于基于HTTP协议的B/S架构系统。Nginx提供的就是L7负载均衡。
    •  四层负载均衡L4:传输层负载均衡,基于TCP协议的。其是通过虚拟IP+端口号的形式将请求分配到真实的服务器。其一般应用于C/S架构的ERP系统中。F5与LVS均提供的是L4负载均衡。Nginx Plus提供的也是四层负载均衡。
    •  三层负载均衡L3:网络层负载均衡,基于IP协议的。其是通过虚拟IP的形式将请求分配到真实的服务器。有些DNS提供的是L3负载均衡。
    •  二层负载均衡L2:数据链路层负载均衡,其是通过虚拟MAC地址的形式将请求分配到了真实的服务器。有些DNS提供的是L2的负载均衡。

    二、负载均衡的实现

    (1)总体规划

    该机群包含一台Nginx服务器,两台Tomcat服务器。将前面打过包的web工程直接部署到两台Tomcat主机上。然后,在Nginx服务器上设置对这两台Tomcat主机的负载均衡

    (2)新建nginxweb项目

    新建java目录

    选择Mark Diretory as再选择Sources Root下

    3)编辑项目

    新建servlet

    package nginx.web;
    
    import javax.servlet.ServletException;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    import java.io.IOException;
    import java.io.PrintWriter;
    
    @WebServlet("/some")
    public class SomeServlet extends HttpServlet {
        protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
            PrintWriter writer = response.getWriter();
            writer.println("Nginx Ip = " + request.getRemoteAddr());
            writer.println("Tomcat Ip = " + request.getLocalAddr());
        }
    }

    pom.xml文件添加Servlet与JSP依赖

    <!-- Servlet依赖 -->
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>3.1.0</version>
      <scope>provided</scope>
    </dependency>
    
    <!-- JSP依赖 -->
    <dependency>
      <groupId>javax.servlet.jsp</groupId>
      <artifactId>javax.servlet.jsp-api</artifactId>
      <version>2.3.3</version>
      <scope>provided</scope>
    </dependency>
    

    编辑jsp

    <%@ page contentType="text/html;charset=UTF-8" %>
    <html>
    <head>
        <title>webdemo</title>
    </head>
    
    <body background="images/bj.jpg">
        Nginx World Welcome You!<br>
        Nginx Addr = ${pageContext.request.remoteAddr} <br>
        Tomcat Addr = ${pageContext.request.localAddr} <br>
    </body>
    
    </html>
    

    (4)tomcat配置以及部署

    apache-tomcat-8081配置文件server.xml 修改

    apache-tomcat-8082配置文件server.xml 修改

    说明:因为是一台服务器配置,为了端口不冲突,所以这样修改。

    两台tomcat部署项目

    为了看到效果,部署在apache-tomcat-8081的SomeServlet类内容:

    部署在apache-tomcat-8082的SomeServlet类内容:

    (5)Nginx配置

    (6)效果

    三、Nginx负载均衡策略

    Nginx内置了三种负载均衡策略,另外,其还支持第三方的负载均衡。而每种负载均衡主机根据负载均衡策略的不同,又可设置很多性能相关的属性

    (1)轮询

    默认的负载均衡策略,其是按照各个主机的权重比例依次进行请求分配的。该策略适用的场景是:根据主机性能设置不同权重。
    对于每台主机,除了像weight一样可以设置的属性外,还可以设置如下属性

    • fail_ timeout:表示当前主机被Nginx认定为停机的最长失联时间,默认为10秒。常与max_fails联合使用。
    • max_fails:表示在fail_timeout时间内最多允许的失败次数。
    • backup:表示当前服务器为备用服务器。
    • down:表示当前服务器永久停机。

    (2)ip_hash

    指定负载均衡器按照基于客户端IP的分配方式,该策略确保了相同的客户端的请求一直发送到相同的服务器,以保证session会话,解决了session不能跨服务器的问题

    需要注意:

    •  适用场景为有状态服务。
    • 在Nginx1.3.1版本之前,该策略中不能指定weight属性。在一个客户端首次访系统时,采用的是根据权重进行分配的轮询策略。
    •  此策略不能与backup同时使用。
    • 当有服务器被Nginx认为停机后,必须手动指定该主机为down,否则请求仍会落到该服务器。

    (3)least_conn

    四、Nginx Plus的四层负载均衡实现

    Nginx Plus是Nginx的商业版,其官网是: https://nginx.com
    同样是修改nginx.conf文件,添加一个stream模块,其与events、http等模块同级。在其中配置upstream{}与server{}模块。此时需要注意,通行代理配置在server{}中,且不能再是http://开头的了,因为其负载均衡协议不再是HTTP协议了。

    https://www.nginx.com/

    https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

    展开全文
  • Nginx负载均衡配置

    万次阅读 多人点赞 2016-09-01 14:35:55
    原文链接:http://blog.csdn.net/xyang81/article/details/51702900Nginx安装请参考:《Nginx源码安装》 负载均衡的目的是为了解决单个节点压力过大,造成Web服务响应过慢,严重的情况下导致服务瘫痪,无法正常提供...

    原文链接:http://blog.csdn.net/xyang81/article/details/51702900

    Nginx安装请参考:《Nginx源码安装

          负载均衡的目的是为了解决单个节点压力过大,造成Web服务响应过慢,严重的情况下导致服务瘫痪,无法正常提供服务。春节期间在12306网站上买过火车票的朋友应该深有体会,有时查询一张火车票都会很慢,甚至整个网页都卡住不动了。通常一个访问量非常大的Web网站(比如:淘宝、京东、12306等),由于一个Web服务同时能处理的用户并发请求的数量有限,同时还有机器故障的情况,所以一个Web站点通常会在N台机器上各部署一套同样的程序。当某一个服务挂掉的时候,还有第二个、第三个、第N个服务。。。继续为用户提供服务,给用户的感觉,你的服务还在正常的运行!在这些提供同样服务的机器当中,在硬件配置方面也各不一样,这样就会存在部份机器性能非常好,能快速计算并响应用户的请求,另外一部份机器可能配置差点,响应用户的请求的时间会长一些。这就需要我们思考一个问题?如果有一个服务正在同时处理1000个用户的请求,这个服务的上限可能最多能同时处理1000个用户的请求,这时它已经很忙了,如果此时又有一个新请求过来,我们仍然把这个请求分配给这台机器,这时候这个请求就只能在干等着,等这个服务处理完那些请求后,再继续处理它。这样在浏览器中的反应就像12306我们在春节买票一样,卡在那不动了,让用户眼巴巴的干着急。而能提供同样服务的其它机器,这时确很空闲。这样不仅是对服务器资源的浪费,也充分发挥不出弄多台服务器装同一个服务的最高价值。我们通常称对某一台机器的访问量称为负载量,如何将一个用户的请求,合理的分配到一台能快速响应用户请求的服务器上,我们就需要用到一些负载策略。也就体现出了文章主题的用意了:负载均衡,将用户的所有HTTP请求均衡的分配到每一台机器上,充分发挥所有机器的性能,提高服务的质量和用户体验。负载均衡可以通过负载均衡网络硬件设备和Web服务器软件来实现,前者设备成本较高,小公司通常负担不起,所以后者一般是我们的首选。实现负载均衡常用的Web服务器软件有Nginx、HAProxyLVSApache,本文主要介绍Nginx的负载均衡策略,至于Nginx是干嘛的,自行百度。这篇文章介绍了Nginx、HAProxy和LVS的优缺点。

    一、内置负载策略

    Nginx负载均衡是通过upstream模块来实现的,内置实现了三种负载策略,配置还是比较简单的。官网负载均衡配置说明:http://nginx.org/en/docs/http/load_balancing.html

    • 轮循(默认)
      Nginx根据请求次数,将每个请求均匀分配到每台服务器
    • 最少连接
      将请求分配给连接数最少的服务器。Nginx会统计哪些服务器的连接数最少。
    • IP Hash
      绑定处理请求的服务器。第一次请求时,根据该客户端的IP算出一个HASH值,将请求分配到集群中的某一台服务器上。后面该客户端的所有请求,都将通过HASH算法,找到之前处理这台客户端请求的服务器,然后将请求交给它来处理。

    1> 轮循

    http {
    
        # ... 省略其它配置
    
        upstream tomcats {
            server 192.168.0.100:8080;
            server 192.168.0.101:8080;
            server example.com:8080;
        }
    
        server {
            listen 80;
    
            location / {
                proxy_pass http://tomcats;
            }
        }
    
        # ... 省略其它配置
    }
    • proxy_pass http://tomcats:表示将所有请求转发到tomcats服务器组中配置的某一台服务器上。
    • upstream模块:配置反向代理服务器组,Nginx会根据配置,将请求分发给组里的某一台服务器。tomcats是服务器组的名称。
    • upstream模块下的server指令:配置处理请求的服务器IP或域名,端口可选,不配置默认使用80端口。通过上面的配置,Nginx默认将请求依次分配给100,101,102来处理,可以通过修改下面这些参数来改变默认的分配策略:

      • weight
        默认为1,将请求平均分配给每台server

        upstream tomcats {
            server 192.168.0.100:8080 weight=2;  # 2/6次
            server 192.168.0.101:8080 weight=3;  # 3/6次
            server 192.168.0.102:8080 weight=1;  # 1/6次
        }

        上例配置,表示6次请求中,100分配2次,101分配3次,102分配1次

      • max_fails
        默认为1。某台Server允许请求失败的次数,超过最大次数后,在fail_timeout时间内,新的请求将不会分配给这台机器。如果设置为0,Nginx会将这台Server置为永久无效状态,然后将请求发给定义了proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, and memcached_next_upstream指令来处理这次错误的请求。
      • fail_timeout
        默认为10秒。某台Server达到max_fails次失败请求后,在fail_timeout期间内,nginx会认为这台Server暂时不可用,不会将请求分配给它

        upstream tomcats {
            server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15;
            server 192.168.0.101:8080 weight=3;
            server 192.168.0.102:8080 weight=1;
        }

        192.168.0.100这台机器,如果有3次请求失败,nginx在15秒内,不会将新的请求分配给它。

      • backup
        备份机,所有服务器挂了之后才会生效

        upstream tomcats {
            server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15;
            server 192.168.0.101:8080 weight=3;
        
            server 192.168.0.102:8080 backup;
        }

        在100和101都挂了之前,102为不可用状态,不会将请求分配给它。只有当100和101都挂了,102才会被启用。

      • down
        标识某一台server不可用。可能能通过某些参数动态的激活它吧,要不真没啥用。

        upstream tomcats {
            server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15;
        
            server 192.168.0.101:8080 down;
        
            server 192.168.0.102:8080 backup;
        }

        表示101这台Server为无效状态,不会将请求分配给它。

      • max_conns
        限制分配给某台Server处理的最大连接数量,超过这个数量,将不会分配新的连接给它。默认为0,表示不限制。注意:1.5.9之后的版本才有这个配置

        upstream tomcats {
            server 192.168.0.100:8080 max_conns=1000;
        }

        表示最多给100这台Server分配1000个请求,如果这台Server正在处理1000个请求,nginx将不会分配新的请求给到它。假如有一个请求处理完了,还剩下999个请求在处理,这时nginx也会将新的请求分配给它。

      • resolve
        将server指令配置的域名,指定域名解析服务器。需要在http模块下配置resolver指令,指定域名解析服务

        http {
            resolver 10.0.0.1;
        
            upstream u {
                zone ...;
                ...
                server example.com resolve;
            }
        }

        表示example.com域名,由10.0.0.1服务器来负责解析。
        upstream模块server指令的其它参数和详细配置说明,请参考官方文档

    二、第三方负载策略

    1> fair

    根据服务器的响应时间来分配请求,响应时间短的优先分配,即负载压力小的优先会分配。

    由于fair模块是第三方提供的,所以在编译nginx源码的时候,需要将fair添加到nginx模块中。

    假设我的nginx是通过源码安装的,安装在/opt/nginx目录下,而且安装时没有添加fair模块
    

    1> 下载fair模块源码
    下载地址:https://github.com/xyang0917/nginx-upstream-fair

    cd /opt
    wget https://github.com/xyang0917/nginx-upstream-fair/archive/master.zip
    unzip master.zip

    解压后的目录名为:nginx-upstream-fair-master

    2> 重新编译nginx,将fair模块添加到编译参数
    我的nginx源码目录在/opt/nginx-1.10.0

    cd /opt/nginx-nginx-1.10.0
    ./configure --prefix=/opt/nginx --add-module=/opt/nginx-upstream-fair-master
    make

    注意:不要执行make install,这样会覆盖之前nginx的配置
    3> 将新编译的nginx可执行程序拷贝到/opt/nginx/sbin/目录下,覆盖之前安装的nginx
    编译后的nginx执行程序,放在nginx源码的objs目录下

    ps -aux | grep nginx
    kill -9 nginx进程ID  # 停止nginx服务
    cp /opt/nginx-1.10.0/objs/nginx /opt/nginx/sbin/  # 覆盖旧的nginx
    nginx # 启动服务

    配置使用fair负载策略模块:

    upstream tomcats {
        fair;
        server 192.168.0.100:8080;
        server 192.168.0.101:8080;
        server 192.168.0.102:8080;
    }

    由于采用fair负载策略,配置weigth参数改变负载权重将无效。

    2> url_hash

    按请求url的hash结果来分配请求,使每个url定向到同一个后端服务器,服务器做缓存时比较有效。

    1.7.2版本以后,url_hash模块已经集成到了nginx源码当中,不需要单独安装。之前的版本仍需要单独安装,下载地址:https://github.com/evanmiller/nginx_upstream_hash
    安装方法和fair模块一样,先下载url_hash源码,然后重新编译nginx源码,将url_hash模块添加到编译配置参数当中,最后将编译后生成的nginx二进制文件替换之前安装的nginx二进制文件即可。

    upstream tomcats {
        server 192.168.0.100:8080;
        server 192.168.0.101:8080;
        server 192.168.0.102:8080;
        hash $request_uri;
    }
    展开全文
  • Nginx详解(正向代理、反向代理、负载均衡原理)

    万次阅读 多人点赞 2019-08-01 11:02:38
    nginx可以作为一个HTTP服务器进行网站的发布处理,另外nginx可以作为反向代理进行负载均衡的实现。 这里主要通过三个方面简单介绍nginx 反向代理 负载均衡 nginx特点 1. 反向代理 关于代理 说到代理,首先...
  • 当在upstream配置块中没有指定使用的负载均衡算法时,默认使用的是加权轮询。 按照上述配置,Nginx每收到7个客户端的请求,会把其中的5个转发给后端a,把其中的1个转发给后端b, 把其中的1个转发给后端c。 这就是...
  • Nginx动态负载均衡

    万次阅读 2018-12-20 15:00:45
    Nginx一般作为反向代理服务器来实现反向代理来转发处理请求,同时也可以作为静态资源服务器来加快静态资源的获取和处理。 1.正向代理与反向代理 正向代理:  正向代理 是一个位于客户端和原始服务器之间的...
  • Nginx如何实现负载均衡

    千次阅读 2019-05-26 23:55:57
    nginx能够支撑5万并发链接,并且cpu、内存等资源消耗却非常低,运行非常稳定,中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等 2、nginx可以用来做什么 1)反向代理:反向代理(ReversePro.....
  • Nginx 负载均衡

    千次阅读 2020-07-26 22:34:01
    说一下 Nginx 怎么负载均衡,不含第三方策略
  • Nginx负载均衡无法加载css,js

    万次阅读 2016-05-09 15:15:24
    nginx负载均衡服务器无法加载css和js及图片文件,访问tomcat时也只能看到文字而看不到图片,如何解决呢?
  • Nginx与Zuul的区别

    万次阅读 2018-12-24 16:56:56
    1、Nginx与Zuul的区别 相同点:Zuul和Nginx都可以实现负载均衡、反向代理(隐藏真实ip地址),过滤请求,实现网关的效果 ...Nginx负载均衡实现:采用服务器实现负载均衡   Nginx相比zuul功能会更加强...
  • Nginx 负载均衡配置+使用方法

    万次阅读 2018-09-23 18:31:03
    Nginx 负载均衡配置+使用方法 本次环境搭建是在LNMP 环境进行的,具体环境搭建详细教程请看我另一篇博客 这里写链接内容 LNMP环境搭建 首先搭建3台虚拟机,这里我的虚拟机ip分别是 192.168.0.38 192.168....
  • Ribbon 与 Nginx 区别

    万次阅读 2018-09-19 00:15:57
    服务器端负载均衡 Nginx nginx 是客户端所有请求统一交给 nginx,由 nginx 进行实现负载均衡请求转发,属于服务器端负载均衡。 既请求由 nginx 服务器端进行转发。 客户端负载均衡 Ribbon Ribbon 是从 eureka ...
  • 使用nginx实现websocket的负载均衡

    万次阅读 2018-05-19 20:15:06
    使用nginx实现websocket的负载均衡 当web应用访问量过大时,我们就需要做负载均衡,将同一个域名的请求分散到不同的服务器上。nginx就可以做到。它可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做...
  • 当我们用spring cloud部署一套...这时候,我们就可以用ngineureka来帮助我们把服务将application服务映射给nginx,然后只需把nginx的端口暴露给用户即可。ngineureka定期查询注册中心内可用的application,并将它...
  • 问:nginx负载均衡服务器死机或者挂掉之后,怎么自动转到另一台负载均衡服务器上继续转发请求。
  • 使用nginx配置mysql负载均衡

    万次阅读 2018-07-30 10:56:19
    需要注意的是,nginx在1.9版本之前是只能配置http协议的,不接受tcp协议的代理,所以nginx最常见的功能是服务器的负载均衡配置,大致流程如下: 以TONCAT 的web服务器举例: Nginx的作用主要就是分发请求,减少.....
  • Nginx/ZooKeeper 负载均衡的差异

    万次阅读 2016-05-27 11:52:49
    Nginx是著名的反向代理服务器,也被广泛的作为负载均衡服务器 ZooKeeper是分布式协调服务框架,有时也被用来做负载均衡 那么他们的区别是什么?如何选择呢? 下面从实际场景看下他们的关系 Nginx负载...
  • 最近准备做Nginx负载均衡,环境是Nginx+Redis+MySql Nginx添加页面访问和数据库的反向代理。 数据库反向代理后数据库如何同步呢? 比如读数据和写数据之间的同步,写到不同的数据库 之间的同步。 目前想到的解决...
  • Ribbon本地负载均衡 原理:在调用接口的时候、会在eureka注册中心上获取注册信息服务列表,获取到之后,缓存在jvm本地,使用本地实现rpc远程技术进行调用,即是客户端实现负载均衡   Nginx服务器负载均衡 ...
1 2 3 4 5 ... 20
收藏数 110,467
精华内容 44,186
关键字:

nginx负载均衡