Nginx负载均衡

ゝ一世哀愁。 2023-10-06 18:55 1阅读 0赞

#### Nginx负载均衡 ####

*  简介
 *  四层负载均衡
 *  七层负载均衡
 *  Nginx负载均衡实现原理
 *   *  示例
     *   *  a、用一台服务器来实现负载均衡，配置如下：
         *  b、 另外三台真实服务器的配置如下：
         *  c、分别在三台真实服务器（当然我这里是在一台服务器中用三个端口模拟的）的项目目录下建立index.html文件
         *   *  第一台（/opt/app/code1）：
             *  第二台（/opt/app/code2）：
             *  第三台（/opt/app/code3）：
             *  刷新页面，发现页面可以在三个站点间轮询显示
 *  负载均衡调度中的状态
 *   *  示例
 *  Nginx的调度算法
 *   *  1、加权轮询示例
     *  2、ip\_has策略示例
     *  3、hash关键数值轮询策略
     *  4、url\_hash 示例：
     *   *  url1.html
         *  url2.html
         *  url3.html
         *  a、当我们访问 http://192.168.0.133/url1.html 时，由于一开始就进入了 server1 这台服务器，不管怎么刷新，以后也永远进入server1这台服务器，因为它是根据 request\_uri来做的hash。
         *  b、当我们访问 http://192.168.0.133/url2.html 时，由于一开始就进入了 server3 这台服务器，不管怎么刷新，以后也永远进入server3这台服务器。
         *  c、当我们访问 http://192.168.0.133/url3.html 时，由于一开始就进入了 server2 这台服务器，不管怎么刷新，以后也永远进入server3这台服务器。

## 简介 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70]  
均摊请求，让服务端整体吞吐率提高，满足不断增长的业务需求。

相比于单点服务，当其中一台服务器挂掉后，还可以继续让剩下的服务器继续服务，提高了容灾性。

## 四层负载均衡 ##

即在OSI七层模型中的传输层。因为第四层支持TCP/IP协议。四层负载均衡只需要对客户端的请求进行TCP/IP协议的包转发就能实现负载均衡。

优势  
非常快，只需要最底层进行应用处理，不需要进行一些复杂的逻辑，值需要负责包的转发即可。

## 七层负载均衡 ##

因为是在应用层，因此可以完成很多应用方面的协议请求，比如HTTP协议的负载均衡可以实现HTTP信息的改写，头信息的改写，安全应用规则的控制，转发，rewrite等等方面的规则控制。因此在七层负载均衡里面可以做的事情就更多一些，Nginx就是一个典型的七层负载均衡的SLB。

SLB（Server Load Balancing）服务器负载均衡。

## Nginx负载均衡实现原理 ##

通过 proxy\_pass 转发到后端的服务器上，只是不是转发到一台，而是一组虚拟的服务池（即 upstream server）。在upstream 组里面实现了对于多台服务器请求的不断轮询。

当用户的请求过来后，就会通过 upstream\_module 这个模块将用户的请求分发到不同的服务上，从而实现负载均衡。

故 proxy\_pass 和 upstream 是两个核心的配置。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 1]  
配置语法  
ngx\_http\_upstream\_module官方文档 ： http://nginx.org/en/docs/http/ngx\_http\_upstream\_module.html

### 示例 ###

#### a、用一台服务器来实现负载均衡，配置如下： ####

upstream chrdai {
        server 192.168.0.133:8001;
        server 192.168.0.133:8002;
        server 192.168.0.133:8003;
    }
    
    server {
        listen       80;
        server_name  localhost;
    
        #charset koi8-r;
        access_log  /var/log/nginx/proxy_cache_access.log  main;
    
        location / {
            proxy_pass http://chrdai;
    
            include proxy_params;
        }
    }

说明我们的负载均衡配置成功。

**注意：upstream只能配置在 http 这一层，即 server 层的外面。**

#### b、 另外三台真实服务器的配置如下： ####

我这里是通过同一台服务器的不同端口模拟的。

第一台（/etc/nginx/conf.d/realserver1.conf）：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 2]  
第二台（/etc/nginx/conf.d/realserver2.conf）：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 3]  
第三台（/etc/nginx/conf.d/realserver3.conf）：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 4]

#### c、分别在三台真实服务器（当然我这里是在一台服务器中用三个端口模拟的）的项目目录下建立index.html文件 ####

##### 第一台（/opt/app/code1）： #####

<!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>upstream</title>
    </head>
    <body>
        <p>Test upstream1</p>
    </body>
    </html>

##### 第二台（/opt/app/code2）： #####

<!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>upstream</title>
    </head>
    <body>
        <p>Test upstream2</p>
    </body>
    </html>

##### 第三台（/opt/app/code3）： #####

<!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>upstream</title>
    </head>
    <body>
        <p>Test upstream3</p>
    </body>
    </html>

##### 刷新页面，发现页面可以在三个站点间轮询显示 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 5]

下面我们来模拟其中一台服务器挂掉后，负载均衡是如何工作的。

如果是真实服务器，可以将nginx进程kill掉，但是由于我这里是在同一台服务器下面的三个端口来模拟的，所以不能直接kill掉Nginx进程。

我这里通过在 iptables 中添加一条规则来将所有来自 8002 端口的请求都 drop 掉，即不在对外提供 8002 端口的服务。

`iptables -I INPUT -p tcp --dport 8002 -j DROP`

此时我们在来访问页面，发现只会显示 upstream1 和 upstream3，upstream2已经被略过了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 6]  
**说明当我们的负载均衡发现如果有一台服务器挂掉后，会自动略过这台服务器。**

## 负载均衡调度中的状态 ##

<table> 
 <tbody> 
  <tr> 
   <td><strong>状态</strong></td> 
   <td><strong>说明</strong></td> 
  </tr> 
  <tr> 
   <td>down</td> 
   <td>当前的server暂时不参与负载均衡</td> 
  </tr> 
  <tr> 
   <td>backup</td> 
   <td>预留的备份服务器</td> 
  </tr> 
  <tr> 
   <td>max_fails</td> 
   <td>允许请求失败的次数</td> 
  </tr> 
  <tr> 
   <td>fail_timeout</td> 
   <td>经过max_fails失败后，服务暂停的时间（默认是10秒）</td> 
  </tr> 
  <tr> 
   <td>max_conns</td> 
   <td>限制最大的接收连接数</td> 
  </tr> 
 </tbody> 
</table>

max\_conns 的应用场景是，当我们把两个不同配置的服务器加在了同一个upstream下时，比如一个是四核，一个是8核的服务器，总不能让两台服务器承受相同的请求连接数吧，默认的轮询策略会均匀分配，这时我们就可以通过这个参数来限制后端服务最大的请求数。

### 示例 ###

upstream chrdai {
        //8001不启用
        server 192.168.0.133:8001 down;
        //8002设为备份机
        server 192.168.0.133:8002 backup;
        server 192.168.0.133:8003 max_fails=1 fail_timeout=10s;
    }
    
    server {
        listen       80;
        server_name  localhost;
    
        #charset koi8-r;
        access_log  /var/log/nginx/proxy_cache_access.log  main;
    
        location / {
            proxy_pass http://chrdai;
    
            include proxy_params;
        }
    }

此时我们在访问，发现只有8003 在提供服务。  
![在这里插入图片描述][814fb520df29400a9630e48047a2575a.png]  
下面我们用iptables规则来限制来自8003的请求，看8002能否从备份状态恢复为提供服务状态。

`iptables -I INPUT -p tcp --dport 8003 -j DROP`

服务端经过一段时间的尝试，发现8003挂了，果然将8002转正了。

![在这里插入图片描述][a1d7ab3a89644a07b7b9e56ef2b2cc9d.png]  
我们再次刷新页面，在8003没有恢复之前，都是访问的8002。

下面我们来将8003的服务恢复过来。

iptables -F

再次刷新页面，发现又是由8003来提供服务了，8002继续轮为备胎。

![在这里插入图片描述][6434cf2c99394bee8e0a4271b758a126.png]

结论：

当我们负载均衡中其中一台服务器挂掉后，会略过该服务器，剩下的服务器继续提供服务。

当所有的主服务器都挂掉后，备用服务器会转正。

当主服务器恢复后，继续由主服务器提供服务，备用服务器继续轮为备胎。

## Nginx的调度算法 ##

<table> 
 <tbody> 
  <tr> 
   <td>调度算法名称</td> 
   <td>说明</td> 
  </tr> 
  <tr> 
   <td>轮询</td> 
   <td>按时间顺序逐一分配到不同的后端服务器</td> 
  </tr> 
  <tr> 
   <td>加权轮询</td> 
   <td>weight值越大，分配到的访问几率越高</td> 
  </tr> 
  <tr> 
   <td>ip_hash</td> 
   <td>每个请求按访问IP的的hash结果分配，这样来自同一个IP的固定访问一个后端服务器</td> 
  </tr> 
  <tr> 
   <td>url_hash</td> 
   <td>按照访问的url的hash结果来分配请求，使每个url定向到同一个后端服务器</td> 
  </tr> 
  <tr> 
   <td>least_conn</td> 
   <td>最少链接数，哪个机器连接数少，就分给哪个机器</td> 
  </tr> 
  <tr> 
   <td>hash关键数值</td> 
   <td>hash自定义的key</td> 
  </tr> 
 </tbody> 
</table>

### 1、加权轮询示例 ###

upstream chrdai {
        server 192.168.0.133:8001;
        server 192.168.0.133:8002 weight=5;
        server 192.168.0.133:8003;
    }
    //理论上来讲，如果请求7次，应该有 5 次会请求 8002 所对应的这台服务器

### 2、ip\_has策略示例 ###

upstream chrdai {
        ip_hash;
        server 192.168.0.133:8001;
        server 192.168.0.133:8002;
        server 192.168.0.133:8003;
    }

服务器会根据 REMOTE\_ADDR 做 hash，同一个ip的请求，不管请求多少次，都会请求相同的一台服务器。

它的缺点是，如果中间有一层代理，那么取到的就不是客户端真实的ip，这样就无法基于用户真实的ip来做轮询了。而会跟代理服务器的ip来固定走一台服务器。

如果按照ip来分配，往往取不到用户端真实的ip。还有一个问题就是当服务端使用了缓存，假如一个用户先访问了服务器1，服务器1缓存了一部分资源，下一次访问的时候被轮询到了服务器2，那么上一次的缓存就无效了，Nginx又增加了更加友好的hash策略。

### 3、hash关键数值轮询策略 ###

//version>1.7.2
    Syntax：hash key [consistent];
    Default：-;
    Context：upstream;

### 4、url\_hash 示例： ###

upstream chrdai {
        hash $request_uri;
        server 192.168.0.133:8001;
        server 192.168.0.133:8002;
        server 192.168.0.133:8003;
    }

在 /opt/app/cod1 目录下新建三个文件。

#### url1.html ####

<!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>upstream</title>
    </head>
    <body>
        <p>server1 url1</p>
    </body>
    </html>

#### url2.html ####

<!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>upstream</title>
    </head>
    <body>
        <p>server1 url2</p>
    </body>
    </html>

#### url3.html ####

<!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>upstream</title>
    </head>
    <body>
        <p>server1 url3</p>
    </body>
    </html>

/opt/app/code2 和 /opt/app/code3 目录下也创建三个 urlx.html，页面内容和上面同理，修改一下 server的值和url的值即可。

此时由于我们的hash策略是根据 reques\_uri 来的，所以会有如下结果。

#### a、当我们访问 http://192.168.0.133/url1.html 时，由于一开始就进入了 server1 这台服务器，不管怎么刷新，以后也永远进入server1这台服务器，因为它是根据 request\_uri来做的hash。 ####

![在这里插入图片描述][554a0a0dfb8d4a58a95cafe307178843.png]

#### b、当我们访问 http://192.168.0.133/url2.html 时，由于一开始就进入了 server3 这台服务器，不管怎么刷新，以后也永远进入server3这台服务器。 ####

![在这里插入图片描述][8a81657e66f44e77a2a1a275e07eeae0.png]

#### c、当我们访问 http://192.168.0.133/url3.html 时，由于一开始就进入了 server2 这台服务器，不管怎么刷新，以后也永远进入server3这台服务器。 ####

![在这里插入图片描述][6e4a0621b12b48ceb5463332550d739f.png]

总结：

加权轮询和轮询都是基于请求来进行分配的。

ip\_hash策略，当中间有代理服务或者有设置缓存都有一定的局限性。

通常使用自定义的 url\_hash策略来控制轮询。

当加权轮询策略和ip\_hash 或者 url\_hash 策略混用的时候，因为weight控制的是轮询策略下的权重，ip\_hash是根据请求来源的ip加入轮询的算法。所以用了ip\_hash或者url\_hash的策略，就不需要添加weight的参数了。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/96dbb7cf8b9a40e58f38b596644c8275.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/ee5b5d9289d54f29b81a2ba64cb2f343.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/6637a5db6eec480e92d12667beff36fc.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/5ca29e964696472bbe21da2a6fd2cf47.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/9322b43898b547d38faf0e1f99a26e3a.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/550dc2f33a824173babbaf63c7fedaf5.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/d8f1987ee0ae4b9c93d035a06aef49fd.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaWd1YW5nMTAy,size_16,color_FFFFFF,t_70
[814fb520df29400a9630e48047a2575a.png]: https://img-blog.csdnimg.cn/814fb520df29400a9630e48047a2575a.png
[a1d7ab3a89644a07b7b9e56ef2b2cc9d.png]: https://img-blog.csdnimg.cn/a1d7ab3a89644a07b7b9e56ef2b2cc9d.png
[6434cf2c99394bee8e0a4271b758a126.png]: https://img-blog.csdnimg.cn/6434cf2c99394bee8e0a4271b758a126.png
[554a0a0dfb8d4a58a95cafe307178843.png]: https://img-blog.csdnimg.cn/554a0a0dfb8d4a58a95cafe307178843.png
[8a81657e66f44e77a2a1a275e07eeae0.png]: https://img-blog.csdnimg.cn/8a81657e66f44e77a2a1a275e07eeae0.png
[6e4a0621b12b48ceb5463332550d739f.png]: https://img-blog.csdnimg.cn/6e4a0621b12b48ceb5463332550d739f.png