Nginx快速入门：负载均衡upstream配置详解（四）

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