Nginx快速入门:负载均衡upstream配置详解(四)

发布时间:2023年12月22日

0. 引言

我们在第二章的时候简单演示了关于nginx实现负载均衡的演示,而实际上nginx支持很多负载均衡算法,并且多节点的转发也有多种策略。今天我们继续深入学习这块。

1. 负载均衡的应用场景

所谓负载均衡,Load Balance ,就是将请求进行分流,减轻单点压力,实现将流量均摊到各个节点的操作,以此实现分布式化

负载均衡的常见实现方式:

  • 硬件

F5

  • 软件

Nginx
LVS
HAproxy

  • 云负载

阿里云 SLB
腾讯云 CLB
华为云 ELB,之前观察云负载的日志与nginx一样,所以本身也怀疑云负载均衡是基于nginx开发的

因为云负载一般就是购买云厂商的,所以本身不需要我们介入太多配置,F5基于硬件级别,价格昂贵,普通公司也用不起。比较常见的就是基于软件层实现负载均衡,其中比较出名的更是我们今天的主题——nginx。

Nginx负载均衡的应用场景主要有以下2个方面:

  • 1、解决高并发问题,通过分发流量到多个节点,以此拓展整体的并发能力
  • 2、解决单点故障问题,通过部署多节点,当其中一个节点宕机后,还能保障有其他节点提供服务

2. Nginx的负载均衡算法

Nginx自带5种负载均衡算法,是基于ngx_stream_upstream_module模块来实现的,所以语法中主要是利用upstream关键字

  • 1、轮询分发(默认算法)

即请求依次分发给不同的节点,第一次给第一个节点,第二次给第二个节点,轮流请求,如果不显示声明,将会默认该种算法

语法:

upstream xxx { 
	server 192.168.244.11; 
	server 192.168.244.12; 
}
  • 2、按权重分发

按照设置的权重配比,将请求转发给节点,比如权重为1:2,就会将1/3的请求分发给节点1,2/3的请求分发给节点2。
该方式适用于服务器配置有显著差别的场景

upstream xxx { 
	server 192.168.244.11 weight=1; 
	server 192.168.244.12 weight=2; 
}
  • 3、源地址ip哈希法分发

根据请求的发起方的ip计算出来的hash值进行分发,这样可以将相同ip的请求分发到固定节点
以此实现会话保持(如:同一客户的session请求到同一个后台服务)、A/B 测试等应用场景、分布式缓存
但如果客户服务器有多个出口ip的话,这种方式就不再适用

upstream xxx {
    ip_hash;
	server 192.168.244.11; 
	server 192.168.244.12; 
}
  • 4、源地址url哈希法分发

根据其ing求的url的hash值来分发到后端的服务器
为不同业务做分布式缓存的场景下比较适用

upstream xxx {
    hash $remote_addr;
	server 192.168.244.11; 
	server 192.168.244.12; 
}
  • 5、最小连接数法分发

根据后端服务当前的连接情况,动态的选取其中连接数最少的服务器来处理当前请求,简单来说就是哪台服务器处理的越快且资源越空闲就给谁处理。
这样的做法是可以尽可能的提高后台服务器的利用率,合理的分配流量给对应的服务器
这也是几种负载均衡算法中的动态负载算法

upstream xxx {
    least_conn;
	server 192.168.244.11; 
	server 192.168.244.12; 
}

3. Nginx容灾策略

所谓容灾是指当某一节点宕机时,可以自动将流量切换给另一台节点,或者某一个节点不稳定,我们可以设置一个不稳定的判断条件,比如连接3次则认为该服务不可用,以此对服务的可用性进行提升。

Nginx支持2种容灾策略:

  • 1、重试机制

max_fails:可以设置最大重试次数,即进行连接节点,如果连接失败,重新发起连接的次数
fail_timeout:在周期fail_timeout时间内达到max_fails次失败次数后,fail_timeout时间内不再重试
比如设置的max_fails=2,fail_timeout=10s, 那么就是10s如果出现2次超时,则10s内不再请求该节点,待10s后再请求该节点

upstream xxx {
	server 192.168.244.11 max_fails=2 fail_timeout=10s; 
	server 192.168.244.12 max_fails=2 fail_timeout=10s;  
}

这里我们还没有定义每次请求的超时时间是多少,所以要结合咱们在第二章中讲到的proxy_connect_timeout,proxy_read_timeout参数进行配置,如果不设置的话默认是60s,很容易导致服务响应不及时

upstream tomcat {
    server 192.168.244.11 max_fails=2 fail_timeout=10s; 
	server 192.168.244.12 max_fails=2 fail_timeout=10s;  
}

server {
    listen       80;

    location / {
       proxy_pass http://tomcat; # 通过别名实现负载均衡转发
       proxy_set_header HOST $host; # 代理过程中添加host头部信息,防止通过ip访问时域名解析不到,不能被server_name解析到
       proxy_http_version 1.1; # 指定http协议版本
       proxy_connect_timeout 3s; # 连接后台服务器的超时时间
       proxy_read_timeout 3s; # 从后台服务器读取数据的超时时间
       proxy_send_timeout 3s; # 向后台服务器发送数据的超时时间
    }
}
  • 2、主备机制

可以通过给节点设置backup,表示当前节点仅为备用节点,平时并不会分发请求给它,只有当主节点宕机后,才会启动备用节点
一般可以搭配重试机制一起使用

upstream xxx {
	server 192.168.244.11 max_fails=2 fail_timeout=10s; 
	server 192.168.244.12 max_fails=2 fail_timeout=10s;  
	server 192.168.244.13 backup;
}

同时也可以给节点设置状态为down,表示该节点不可用,流量将不会分发给该节点

upstream xxx {
	server 192.168.244.11 down; 
	server 192.168.244.12 max_fails=2 fail_timeout=10s;  
	server 192.168.244.13 backup;
}

4. 案例实操

最后我们通过一个案例来总结我们今天的知识

案例:

实现主备配置,当后台服务10s内3次连接超时时则断开连接,2台节点按1:2权重进行分发,并设置一台备用节点,当两台服务都宕机时,启用备用节点

步骤:
1、准备3台tomcat节点,模拟后端服务。这里我为了方便直接在同一个虚拟机上安装了3台,然后tomcat首页上通过不同的端口号显示来区分
在这里插入图片描述
2、修改nginx配置

upstream tomcat {
  server 192.168.244.41:8080 max_fails=2 fail_timeout=10s weight=1;
  server 192.168.244.41:8081 max_fails=2 fail_timeout=10s weight=2;
  server 192.168.244.41:8083 backup;
}

server {
    listen       80;

    location / {
       proxy_pass http://tomcat;
       proxy_set_header HOST $host;
       proxy_http_version 1.1;
       proxy_connect_timeout 3s;
       proxy_read_timeout 3s;
       proxy_send_timeout 3s;
   }

}

3、重启nginx

nginx -t
nginx -s reload

4、访问nginx,多次访问,发现可以按照1:2比例跳转至8080和8081端口,并且不会访问到8083端口

在这里插入图片描述

5、将8081,8080端口的tomcat停掉,模拟宕机,发现请求转发到8083端口的tomcat了

在这里插入图片描述

6、模拟测试成功

5. 总结

今天我们学习了nginx的负载均衡模块upstream,包括nginx支持的负载均衡策略以及容灾策略,通过案例实际演示了我们如何实现负载均衡配置和主备节点搭建,要真正掌握知识,还需要大家一起根据文章实际演练。

除了多节点的负载均衡转发,我们还有单节点的不同业务转发,根据域名的转发,各种各样的转发、代理配置,下一节,我们将继续讲解nginx的各种转发配置。

文章来源:https://blog.csdn.net/qq_24950043/article/details/135097019
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。