Nginx 学习系列(二) ------------- 负载均衡

4,558 阅读6分钟

说到负载均衡,我想说它天生就是不公平的。为什么这么说呢?请你想象这么一个场景,一块蛋糕切成5份,现在要将它分给A、B、C3个人,基于公平原则,我们说每个人正常可以分到5/3份,但是,5/3份很明显不好进行划分,诶碰巧这个时候A中午没有吃饭,能多吃几份,B、C肚子偏饱,1份即可,基于不公平原则,我们分给A3份蛋糕,B、C个一份,这样按照一定策略将资源进行划分的方式,是一种均衡的策略。

在web应用中,一个web应用(或者说某个服务)在生产环境中一般是集群部署,然后采用负载均衡硬件(F5)或者软件(nginx)将请求分发到不同的服务主机中进行处理,很明显,这里的蛋糕就相当于我们的web request,假设有5个request进来,基于一定的均衡策略,我们可能会将其中的3个request交给A服务器去处理,B、C服务器各处理1个request。下面我画张图片简单说明这个模型:

那么使用负载均衡有什么好处呢?首先优化资源利用率,最大化吞吐量,减少延迟,再者系统的伸缩性和可靠性也得到了相应的保障。

一、Nginx 负载均衡及相关策略介绍

负载均衡技术少不了相关的均衡策略,Nginx 中提供了 4 种均衡策略,我们可以根据具体的业务场景选择合适的均衡策略。下面分别介绍这 4 中均衡策略:

  • 1、基于轮询的均衡策略:

    轮询嘛,就是说对进到nginx的request按照遍历的方式进行分发,如果request 1 分发到 Server A,那么request 2将被分发到 Server B,......以此循环类推

  • 2、基于最少连接数的均衡策略:

    最少连接,也就是说nginx会判断后端集群服务器中哪个Server当前的 Active Connection 数是最少的,那么对于每个新进来的request,nginx将该request分发给对应的Server.

  • 3、基于ip-hash的均衡策略:

    我们都知道,每个请求的客户端都有相应的ip地址,该均衡策略中,nginx将会根据相应的hash函数,对每个请求的ip作为关键字,得到的hash值将会决定将请求分发给相应Server进行处理

  • 4、基于加权轮询的均衡策略:

    加权轮询,很显然这个策略跟我们开题引入的场景是一样的,nginx会给Server配置相应的权重,权重越大,接收的request数将会越多

上面的均衡策略其实都非常很好理解,但是如果想了解其实现原理,可以看源代码,但是小编就算了,我是看不懂C、C++的。

二、Nginx 不同均衡策略的配置介绍

  • 1、基于轮询的均衡策略:

这个是Nginx默认的均衡算法,如果你不进行相关的配置,默认会执行该策略,配置如下:

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

可以看出,nginx负载均衡使用到的指令不多,其中比较重要的两个是upstreamproxy_pass,upstream块定义一个后端小集群,里边配置相关的Server组成这个集群,同时upstream为这个集群起个相应的名字,本实例叫myapp1.proxy_pass处于location块中,表示对于所有符合/的request,将会交给哪个集群进行处理,本实例为http://myapp1

但又一点我们需要注意,上面http://myapp1myapp1必须是upstream起的名字,对于协议是使用http还是https,都无所谓,如果你的协议使用https,则将http直接改成https即可。另外,如果你在upstream中的server指令中指定了协议名,那么在proxy_pass指令中就不需要加上协议名称了。

nginx负载均衡使用反向代理实现,也就是我们上面使用到的proxy_pass指令,支持的协议不止是httphttps,同时还支持FastCGIuwsgiSCGImemcachedgRPC,如果你需要使用除了httphttps外的其他协议,我们不能使用proxy_pass指令了,应该转而使用相应的指令,如fastcgi_passuwsgi_passscgi_passmemcached_passgrpc_pass

该策略处理负载,小编认为还是有缺陷的,不能防止某台Server出现负载过高的情况。因为如果有些请求执行时间过长,而系统的并发量却非常大,那么就可能导致某台Server出现request堆积,负载过高,snowslide is possible~

  • 2、基于最少连接数的均衡策略:

该策略主要使用了least_conn指令,具体配置如下:

 upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

该策略还是比较人性化的,可以按照机器的实际情况进行刚需分配。

  • 3、基于ip-hash的均衡策略:

当然了,如果我们想实现这样一个功能,我们想让对于相同客户端的请求每次都被分发到同一个Server进行处理,上面两种策略都是不做到。此策略可确保来自同一客户端的请求始终定向到同一服务器,但此服务器不可用时除外。相关配置如下:

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

既然相同客户端的请求能被同一台Server进行处理,那么相同客户端的会话Session就可以实现持久化了。

  • 4、基于加权轮询的均衡策略:

基于加权轮询的策略就不需要过多讲解了,就是在轮询的基础上加上个权重信息

upstream myapp1 {
    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}

这种策略适合Server机器处理能力有区别的情况。

三、nginx 负载均衡更多高级特性及配置

  • 1、健康检查

    不仅人需要体检,机器也是需要体检的,那么就当nginx就是那位体检医生吧!nginx健康检查是什么呢?当我们一个request进来被分发到相应的Server进行处理后,nginx会检查该request执行是否超时,是否执行失败了等情况,然后做出相应的处理---比如说当nginx检查出Server A执行某request时报出502错误了,那么下次nginx负载均衡时就会在upstream块中将Server A排除掉,不分发请求给到Server A了。

    对于健康检查的功能,nginx提供了基本两个指令,即max_failsfail_timeout,也就是说当nginx检查到某Server发生错误的request数达到max_fails或者执行某request执行时间超过fail_timeout了,如果发生超时了,nginx将开始使用实时请求优雅地探测Server,如果有响应,则认为对应的Server还是活着的,没有毛病的。

  • 2、更多配置

    针对上面upstream块中的server指令,其格式为:server address [parameters];,里边的parameters可以有很多的参数类型,比如说指定某台Server不参与负载均衡等。具体配置详见官网链接,点击此处传送门