Nginx(4)之负载均衡实例以及策略

Nginx(4)之负载均衡实例以及策略

微信搜索 zze_coding 或扫描 👉 二维码关注我的微信公众号获取更多资源推送:

本示例是在上一章中反向代理实例的基础上做修改。

实例

目标

浏览器多次请求 www.123.com,让这些请求分摊到占用 808180828083 三个端口的 tomcat 服务。

步骤

1、直接启动上一章中反向代理实例的三个 tomcat 服务。
2、修改 Nginx 配置文件,在 server 节上方添加如下配置:

upstream myserver{
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

3、修改监听域名为 www.123.com 端口为 80server 节下的 location 为如下:

location / {
    root   html;
    proxy_pass http://myserver;
    index  index.html index.htm;
}

4、测试访问会发现请求已经平均分摊到各个 tomcat 服务中。

状态控制

我们可以手动指定参数为 upstream 节下的主机设定其状态,常用参数有如下:

状态概述
down标识当前主机不参与负载均衡,相当于不存在。
backup标识当前主机是一个备用服务器,只有其它服务器都挂了才会用上它。
max_fails & fail_timeout组合使用,指定经过 max_fails 次失败后,标识服务器的停用时间为 fail_timeout
max_conns限定标识主机同一时间最多接收连接数。

例 1:127.0.0.1:8081 不参与负载均衡。

upstream myserver{
    server 127.0.0.1:8081 down;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

例 2:将 127.0.0.1:8081 设定为备用主机。

upstream myserver{
    server 127.0.0.1:8081 backup;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

例 3:指定所有主机请求失败 2 次后,将对应主机停用 20 秒。

upstream myserver{
    server 127.0.0.1:8081 max_fails=2 fail_timeout=20s;
    server 127.0.0.1:8082 max_fails=2 fail_timeout=20s;
    server 127.0.0.1:8083 max_fails=2 fail_timeout=20s;
}

例 4:指定 127.0.0.1:8083 最多同时接收 10 个连接。

upstream myserver{
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083 max_conns=10;
}

负载均衡策略

随着互联网信息的爆炸性增长,负载均衡(load balance)已经不再是一个很陌生的话题,顾名思义,负载均衡即是将负载分摊到不同的服务单元,既保证服务的可用性,又保证响应足够快,给用户很好的体验。快速增长的访问量和数据流量催生了各式各样的负载均衡产品,很多专业的负载均衡硬件提供了很好的功能,但却价格不菲,这使得负载均衡软件大受欢迎,Nginx 就是其中的一个,在Linux 下有 Nginx、LVS、Haproxy 等等服务可以提供负载均衡服务,而且 Nginx 提供了几种分配方式(策略):

轮询(默认)

该策略是 Nginx 负载均衡的默认策略,每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动删除这个挂掉的节点。

权重(weight)

weight 代表权重,是一个数字,默认为 1,权重越高则被分配到的次数越多。
权重和各个服务的访问比率成正比,用于后端服务器性能不均的情况。
权重的配置也很简单,直接在 upstream 节下的 server 属性值后加上 weight=<权重>,例:

upstream myserver{
    server 127.0.0.1:8081 weight=1;
    server 127.0.0.1:8082 weight=3;
    server 127.0.0.1:8083 weight=6;
}

IP 哈希

该方式是将每个请求按 IP 的 hash 结果分配服务,这儿每个访客就会固定访问一个后端服务器,可解决 session 分布问题。
要使用该方式直接在 upstream 节下添加内容为ip_hash 的一行即可,示例:

upstream myserver{
    ip_hash;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

URL 哈希

通过请求 URL 进行 hash,再通过 hash 值选择后端 Server。
一般来讲,要用到 url_hash,是要配合缓存命中来使用。举个例子:有一个服务器集群 A,需要对外提供文件下载,由于文件上传量巨大,没法存储到服务器磁盘中,所以用到了第三方云存储来做文件存储。服务器集群 A 收到客户端请求之后,需要从云存储中下载文件然后返回,为了省去不必要的网络带宽和下载耗时,在服务器集群 A 上做了一层临时缓存(缓存一个月)。由于是服务器集群,所以同一个资源多次请求,可能会到达不同的服务器上,导致不必要的多次下载,缓存命中率不高,以及一些资源时间的浪费。在此类场景下,为了使得缓存命中率提高,很适合使用 url_hash 策略,同一个 url(也就是同一个资源请求)会到达同一台机器,一旦缓存住了资源,再此收到请求,就可以从缓存中读取,既减少了带宽,也减少的下载时间。示例:

upstream myserver{
    hash $request_uri;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

最少连接数(least_conn)

如题,会挑选连接数最少的服务器分发请求,配置如下:

upstream myserver{
    least_conn;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

fair

按后端服务器的响应时间分配请求,响应时间短的优先分配。

由于该方式需要第三方模块提供支持,所以在启动 Nginx 前我们需要先安装 fair 模块,fair 模块的下载以及文档在官网也有说明,地址为 https://www.nginx.com/resources/wiki/modules/fair_balancer/
安装的方式其实就是重新编译 Nginx 生成可执行程序的时候指定添加的模块,进入 Nginx 源文件目录,执行如下命令:

./configure --add-module=<fair_dir>
    fair_dir:fair 模块解压后的根目录;

执行上述操作后再执行 make 命令,会生成 objs/nginx,它是一个可执行程序,直接用它替换原有的程序(/usr/local/nginx/sbin/nginx)即可(当然如果是首次安装则直接 make install 就行了)。

如果使用的 Nginx 版本在 1.14.0 以上,执行 make 编译时会出现错误,这时就要修改源代码了(fair 模块太久木有更新了,瞅了眼 github 上次的提交时间还在 2012 年...),这里有提供已经修改好的源代码,点击下载

配置好第三方模块后要使用该方式直接在 upstream 节下添加内容为fair 的一行即可,例:

upstream myserver{
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
    fair;
}

Copyright: 采用 知识共享署名4.0 国际许可协议进行许可

Links: https://www.zze.xyz/archives/nginx4.html

Buy me a cup of coffee ☕.