Nginx 学习 —— 负载均衡

说到负载均衡,我想说它天生就是不公平的。为什么这么说呢?请你想象这么一个场景,一块蛋糕切成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不参与负载均衡等。具体配置详见官网链接,点击此处传送门。


本文分享自微信公众号 - 芋道源码(YunaiV)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-09-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

我们为什么使用 Redis?

如果你从来没使用过 Redis 数据库,那你肯定会问,为什么我们要用 Redis 数据库,我只使用 MySQL 或 Oracle 就够了。其实 Redis 虽叫...

18520
来自专栏java思维导图

缓存在高并发场景下的常见问题

当数据时效性要求很高时,需要保证缓存中的数据与数据库中的保持一致,而且需要保证缓存节点和副本中的数据也保持一致,不能出现差异现象。这就比较依赖缓存的过期和更新策...

16730
来自专栏Java后端技术栈

关于缓存命中率的几个关键问题!

不命中:无法直接通过缓存获取到想要的数据,需要再次查询数据库或者执行其它的操作。原因可能是由于缓存中根本不存在,或者缓存已经过期。

35610
来自专栏小勇DW3

redis中各种数据类型的常用操作方法汇总

string是redis最基本的类型,你可以理解成与Memcached一模一样的类型,一个key对应一个value。 string类型是二进制安全的。意思是re...

32430
来自专栏Linyb极客之路

优化网站性能必备的6种架构方案,你知道吗?

一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能...

12530
来自专栏木制robot技术杂谈

Ubuntu 搭建 Seafile

本文档用来说明通过预编译好的安装包来安装并运行基于 MySQL/MariaDB 的 Seafile 服务器。(MariaDB 是 MySQL 的分支)

73830
来自专栏芋道源码1024

几个大型网站的Feeds(Timeline)设计简单对比

Facebook起源的NewsFeed,以及Twitter起源的Timeline,核心问题都是如何处理巨大的消息(活动,activity)分发。“推Push”和...

53010
来自专栏IT大咖说

做一个不背锅的运维

内容来源:作者:田逸(sery),来自:http://blog.51cto.com/sery/2162642

21140
来自专栏Java与Android技术栈

给 Java 和 Android 构建一个简单的响应式Local Cache

首先,Local Cache 不是类似于 Redis、Couchbase、Memcached 这样的分布式 Cache。Local Cache 适用于在单机环境...

10220

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励