Nginx(7)之负载均衡

深藏阁楼爱情的钟 2024-04-17 22:02 69阅读 0赞

负载均衡硬件(F5)或者软件（nginx）将请求分发到不同的服务主机中进行处理，假设有5个request进来，基于一定的均衡策略，我们可能会将其中的3个request交给A服务器去处理，B、C服务器各处理1个request。下面我画张图片简单说明这个模型：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70][]

那么使用负载均衡有什么好处呢？首先优化资源利用率，最大化吞吐量，减少延迟，再者系统的伸缩性和可靠性也得到了相应的保障。

### 一、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数将会越多

上面的均衡策略其实都非常很好理解，但是如果想了解其实现原理，可以看源代码。

### 二、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负载均衡使用到的指令不多，其中比较重要的两个是`upstream`和`proxy_pass`,`upstream`块定义一个后端小集群，里边配置相关的Server组成这个集群，同时`upstream`为这个集群起个相应的名字，本实例叫`myapp1`.`proxy_pass`处，`location`块中，表示对于所有符合`/`的request，将会交给哪个集群进行处理，本实例为`http://myapp1`。

但又一点我们需要注意，上面`http://myapp1`中`myapp1`必须是`upstream`起的名字，对于协议是使用`http`还是`https`,都无所谓，如果你的协议使用`https`，则将`http`直接改成`https`即可。另外，如果你在`upstream`中的`server`指令中指定了协议名，那么在`proxy_pass`指令中就不需要加上协议名称了。

nginx负载均衡使用反向代理实现，也就是我们上面使用到的`proxy_pass`指令，支持的协议不止是`http`和`https`,同时还支持`FastCGI`、`uwsgi`、`SCGI`、`memcached`、`gRPC`，如果你需要使用除了`http`、`https`外的其他协议，我们不能使用`proxy_pass`指令了，应该转而使用相应的指令，如`fastcgi_pass`、`uwsgi_pass`、`scgi_pass`、`memcached_pass`、`grpc_pass`。

该策略处理负载，还是有缺陷的，不能防止某台Server出现负载过高的情况。因为如果有些请求执行时间过长，而系统的并发量却非常大，那么就可能导致某台Server出现request堆积，负载过高。

## **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_fails`和`fail_timeout`,也就是说当nginx检查到某Server发生错误的request数达到`max_fails`或者执行某request执行时间超过`fail_timeout`了，如果发生超时了，nginx将开始使用实时请求优雅地探测Server，如果有响应，则认为对应的Server还是活着的，没有毛病的。

## **2、更多配置** ##

针对上面`upstream`块中的`server`指令，其格式为：`server address [parameters];`，里边的`parameters`可以有很多的参数类型，比如说指定某台Server不参与负载均衡等。具体配置详见官网链接，点击此处传送门。

以上就是nginx本身自带的负载均衡策略，如果以上的策略都满足需求的话，那么久需要安装第三方的支持来提供更多的策略。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/e7c8f148b5814846b4f7aa6f62533c32.png