Nginx-负载均衡（九）

1. 问题思考？

负载均衡之前使用的什么方案？
- 在早期并发不大的情况，我们一般使用如下图所示的架构。
- 当用户增长量上升，服务器处理请求的能力到达了极限，就会出现加载速度慢，出现宕机情况
负载均衡解决了什么问题？
- 针对上面的问题就可以使用负载均衡策略进行处理，具体如下图
- 当我们其中一台服务出现问题，我们可以通过负载均衡策略将请求转移到其他服务器中。
负载均衡提供的策略？
- 轮询策略（round-robin）：请求在所有可用服务器之间平均分配，负载均衡默认的配置就是轮询。
- 权重策略（weight）：服务器被分配一个权重，请求根据每个服务器的权重分配。
- 随机策略（random）：请求被随机分配在任意一台可用服务器当中。
- ip_hash：客户端的 IP 地址将用作哈希键，来自同一个ip的请求会被转发到相同的服务器。
- 响应时长策略（fair）：根据服务器的响应时间来分配请求，响应时间短的优先分配，即负载压力小的优先会分配。
- 最少连接（least_conn）：将请求分配给活动连接数最少的服务器（较为空闲的服务器）。

2. Nginx 配置负载均衡策略

根据业务场景的不同选择不同的策略方式，如果选择的策略不适合特定场景，可能会导致性能问题。

2.1. 最佳实现（round-robin、random）

最佳实践的两种策略：轮询策略（round-robin）、随机策略（random）

最佳实现的考量指标

这种是最常见的一种配置，当不知道用什么的时候就采用这一类型。

随机策略在大量请求的情况下，按照概率的理论等同于轮询策略。

轮询策略（round-robin）：请求在所有可用服务器之间平均分配

# 默认配置就是轮询策略
upstream server_group {
   server 192.168.206.100:9001;
   server 192.168.206.101:9001;
   server 192.168.206.102:9001;
}
 
server{
   
    # 监听端口
    listen 8003;
    # 匹配请求中的host值
    server_name ruoyi.balance.localhost;
 
    # 监听请求静态资源 html 路径
    location / {
      # 查找目录
      root /home/basics-analysis/web;
      # 默认查找
      index index.html index.htm;
    }
       
    # 监听请求后端服务
    location ^~ /api {
        #nginx的主机地址
        proxy_set_header Host $http_host;
  
        #用户端真实的IP，即客户端IP
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
        # 配置代理服务器
        proxy_pass http://server_group;
    }
 
}

随机策略（random）：请求被随机分配在任意一台可用服务器当中

# 随机策略
upstream server_group {
   random;
   server 192.168.206.100:9001;
   server 192.168.206.101:9001;
   server 192.168.206.102:9001;
}

2.2. 性能优先（weight、fair、least_conn）

性能优先的三种策略：权重策略（weight）、响应时长策略（fair）、最小连接（least_conn）

性能优先的考量指标

从经验或硬件上分为高权重、低权重的机器。

按照节点请求的响应时长来决定是多分配请求，还是少分配请求。

按照保持的连接数。一般来说保持的连接数越多说明处理的任务越多，也是最繁忙的，可以将请求分配给其他机器处理。

权重策略（weight）：服务器被分配一个权重，请求根据每个服务器的权重分配

# 权重策略
upstream server_group {
   server 192.168.206.100:9001 weight=5;
   server 192.168.206.101:9001;
}

响应时长策略（fair）：根据服务器的响应时间来分配请求，响应时间短的优先分配，即负载压力小的优先会分配

# 响应时长策略
upstream server_group {
   fair;
   server 192.168.206.100:9001;
   server 192.168.206.101:9001;
}

最少连接数（least_conn）：将请求分配给活动连接数最少的服务器（较为空闲的服务器）

# 最少连接数
upstream server_group {
   least_conn;
   server 192.168.206.100:9001;
   server 192.168.206.101:9001;
}

2.3. 保持稳定（ip_hash、url_hash）

保持稳定的两种策略：ip_hash、url_hash

保持稳定的考量指标

很多请求都是有状态的，上一次请求到哪个业务节点，这次还要请求到哪台机器。

将客户端的 IP 地址或者 url 作为哈希键，来自同一个ip的请求会被转发到相同的服务器。

保持稳定的两种策略存在的问题

当有一个上游服务器宕机或者扩容的时候，会引发大量的路由变更，进而引发连锁反应，如果上游服务器在有缓存的情况下导致大量缓存失效等问题。

针对这个问题，参考博文：https://blog.csdn.net/qq_34556414/article/details/106156796

ip_hash策略

# ip_hash
upstream server_group {
   ip_hash;
   server 192.168.206.100:9001;
   server 192.168.206.101:9001;
}

url_hash策略

# url_hash
upstream server_group{
   hash $request_uri consistent;
   server 192.168.206.100:9001;
   server 192.168.206.101:9001;
}

3. 故障节点摘除与恢复

经典配置详解

upstream server_group {
   server 192.168.206.100:9001 max_fails=3 fail_timeout=30s;
   server 192.168.206.101:9001 backup;
}

配置详解

指令	默认值	解释
max_fails	1	请求失败多少次之后，暂停使用该节点。需要搭配fail_timeout 一起使用。
fail_timeout	10s	当认定该节点不能使用之后，暂定多久可以使用。
backup	-	类似于switch语句中的default，当主要节点都挂了的时候，会把请求打到这个backup节点