Nginx反向代理实现负载均衡总结

我不是女神ヾ 2021-09-20 06:16 364阅读 0赞

从`Nginx`的诞生来源就可以知道，它是为了解决大数据量高并发访问而产生的，这也要感谢`Nginx`的开发者，使`Nginx`现今成为了`LNMP`重要的成员。好了，废话不多说了，下面就来总结介绍下`Nginx`的反向代理如何实现负载均衡。

· 环境准备  
· 反向代理  
· 负载均衡  
· 页面缓存

## 一、环境准备 ##

### 1、两台均衡服务器 ###

由于条件限制，我这里只有一台电脑设备，所以只能使用`Nginx`的虚拟机替代了，他们分别为：

test1.cwteam.com   中存放index.html 内容：Hello Test1
    
    test2.cwteam.com   中存放index.html 内容：Hello Test2

注：

对于虚拟机的配置，不是这里的内容，具体可查看上一篇文章《Nginx常用配置总结》[http://blog.csdn.net/why\_2012\_gogo/article/details/50967447。][http_blog.csdn.net_why_2012_gogo_article_details_50967447]

### 2、测试均衡服务器 ###

![在这里插入图片描述][20190618220449830.png]  
![在这里插入图片描述][20190618220459536.png]

## 二、反向代理 ##

### 1、反向代理原理 ###

当客户端请求反向代理服务器时，代理服务器会根据设置的调度规则定位到指定的服务器，然后从指定的服务器直接返回内容给客户端。有人会问，正向代理是什么？从名字就可知道他的道理，它介于客户端和原始服务器之间，当客户请求代理服务器时，必须指定原始服务器，然后，代理服务器再去请求原始服务器，当原始服务器处理好结果后，交给代理服务器并返回给客户端。

### 2、`Nginx`的反向代理 ###

配置`nginx.conf`文件：

location / {
    
                proxy_pass  http://test1.cwteam.com/index.html;
    
            }

注意：配置后，重启`nginx`。

测试反向代理：

浏览器输入：[http://127.0.0.1][http_127.0.0.1]

正常的话，`Nginx`会反向定位到上面的test1服务器：  
![在这里插入图片描述][20190618222125640.png]  
上图已经说明，我们的反向代理配置成功了，配置中使用了指令：`proxy_pass`（指定代理位置的服务器地址`URL`），下面继续介绍下负载均衡。

## 三、负载均衡 ##

随着业务不断拓展、用户量不断增多，原本一台`Nginx`代理的服务器已经显得吃力，不论在性能、响应速度等都显得力不从心，所以需要对后台服务器做负载均衡，缓解一台或几台服务器的高并发请求压力。

### 1、`Upstream` ###

负载均衡需要使用`Nginx`支持的`HTTP Upstream`模块，该模块通过一个简单的算法调度来实现客户端ip到服务端负载均衡。`Upstream`目前支持4种调度算法：

**A、默认的轮循**

默认的调度算法，在处理客户端的每次请求时，按照时间顺序逐一分配到均衡服务器，可以设定服务器的权重(`weight`)比值，比值越大访问的几率越大，一般用在后台服务器列表访问性能不均匀情况。

**B、`ip_hash`**

记录每次访客的`ip`地址，固定分配给指定的服务器，有效的解决了不同服务器网页`Session`的问题。

**C、`fair`**

根据后端服务器响应的时间长短来分配，响应时间越短被分配几率越大，它属于第三方插件，`Nginx`本身并不支持，如需使用必须下载`Nginx`的`upstream_fair`模块。

**D、`url_hash`**

按访问的地址`url`的`hash`值结果分配， 使每个`url`定向到指定的服务器，可以提高后端服务器的缓存效率，同样的，`Nginx`本身也不支持该算法，需要第三方的`hash`软件。

### 2、`Upstream`支持的状态参数 ###

在`Nginx`的`Upstream`模块中，除了可以通过`server`指定到特定服务器和端口，还可以设置服务器在负载均衡中的状态。目前的状态如下：

**A、`down`**

代表当前的服务器`server`不参与负载均衡。

**B、`backup`**

预留的备用设备，也就是当其它的服务器故障或忙时才会分配它给客户请求，所以它的压力最小。

**C、`max_fails`**

服务器`server`允许请求失败的次数，默认为1次，当失败次数超过限定的次数，就会返回`proxy_next_upstream`错误信息。

**D、`fail_timeout`**

当经历了`max_fails`的次数后，暂停服务的时间，一般与`max_fails`配合使用。

注意：

当服务器的调度算法为`ip_hash`时，服务器在负载均衡中的状态不能是`weight`和`backup`，理由很明显，不做说明。

### 3、`Nginx`配置负载 ###

`Nginx`中配置负载均衡比较简单，只需要修改`nginx.conf`配置文件，添加均衡服务器列表，以及使用`proxy_pass`引用服务器列表即可，具体如下：

**A、upstream**

#upstream
    
    upstream webservers { 
    
      server 127.0.0.1:8080 weight=1;
    
      server 127.0.0.1:8081 weight=1;
    
    }

注：

该配置放在`http{}`内，`server{}`之外，否则会报错。

**B、`proxy_pass`**

location / {
    
      proxy_pass http://webservers;
    
      proxy_set_header X-Real-IP$remote_addr;
    
     }

注：

引用均衡服务器的列表

**C、测试均衡**

浏览器输入：[http://127.0.0.1][http_127.0.0.1] 反复刷新页面，如果看到`test1`和`test2`服务端交替出现，那么说明负载已经成功（如果其中一台服务器挂掉，如`test1`挂掉，那么只会给`test2`服务器分配），测试结果如下：  
![在这里插入图片描述][20190618222747865.png]

### 4、`Nginx`的健康状态检查 ###

配置`upstream`状态`max_fails`和`fail_timeout`，对`Nginx`健康检查。

**A、upstream**

#upstream
    
    upstream webservers { 
    
          server 127.0.0.1:8080 weight=1max_fails=2 fail_timeout=2;
    
    server 127.0.0.1:8081 weight=1 max_fails=2 fail_timeout=2;
    
     }

**B、测试**

这里的结果与上面的测试结果是一样的，这是添加了`max_fails`和`fail_timeout`。

### 5、配置`backup`服务器 ###

这里需要添加一台`backup`虚拟机服务器，具体这里不介绍。服务器地址为：

[http://backup.cwteam.com][http_backup.cwteam.com] 端口：`8082` 内容：`Error is now,please check theerror.log`

**A、`upstream`**

#upstream
    
    upstream webservers {
    
          server 127.0.0.1:8080 weight=1max_fails=2 fail_timeout=2;
    
          server 127.0.0.1:8081 weight=1max_fails=2 fail_timeout=2;
    
          server 127.0.0.1:8082 backup;
    
        }

**B、测试**

为了模拟在`test1`和`test2`服务器都不工作，这里我将`test1`和`test2`的虚拟机配置文件`.conf`中的监听端口分别改为：`8084`和`8085`，然后记得重启`Nginx`服务，这样在服务器列表中的`test1`和`test2`就不能正常工作。

输入：[http://127.0.0.1][http_127.0.0.1] 反复刷新，结果显示：  
![在这里插入图片描述][20190618223018253.png]  
上图，说明了在`test1`和`test2`都坏掉之后，`backup`算法的服务器就会被访问了，下面来继续总结`ip_hash`算法。

### 6、配置`ip_hash`服务器 ###

配置`ip_hash`算法调度服务器时，不能设置服务器的状态为`weight`和`backup`，所以需要关闭`Nginx.conf`中的`backup`状态服务器，配置完成记得重启`nginx`，如下：

**A、`upstream`**

#upstream
    
    upstream webservers {
    
          ip_hash;
    
          server 127.0.0.1:8080 weight=1max_fails=2 fail_timeout=2;
    
          server 127.0.0.1:8081 weight=1max_fails=2 fail_timeout=2;
    
          #server 127.0.0.1:8082 backup;
    
        }

**B、测试**

输入：[http://127.0.0.1][http_127.0.0.1] 反复刷新页面 如果调度的服务器总是`test1`或是`test2`时，那就说明`ip_hash`算法服务器设置成功，结果如下：

### 7、统计`Web`链接的次数 ###

$ netstat -an | grep :8080 | wc -l

注意：

使用虚拟主机验证`Nginx`反向代理及负载均衡是有限制的，正常应该是为每个服务器配置`web`服务器，所以对应的均衡服务器配置验证时，因该以关闭`web`服务器为准，而且在对应的服务器中可以查看日志信息。

## 四、页面缓存 ##

### 1、缓存指令 ###

`Nginx`的缓存配置比较直观简单，具体有下面几个指令需要知道：

**A、`proxy_cache_path`**

格式：`proxy_cache_path path [levels=numbers] keys_zone=zone_name:zone_size[inactive=time] [max_size=size]`

说明：

path －缓存文件存放的位置
    
    levels －缓存目录结构，可以是1、2、3位数字作为目录，最多是3位数字如：1,1:2
    
    keys_zone －指定缓存池名字及大小，每个定义缓存路径必须不同
    
    inactive －设置每个缓存区缓存文件的有效时长，超过该时长没被访问的缓存被删除
    
    max_size －设置不活动的缓存大小，不活动的缓存超过该大小后被删除

**B、`proxy_cache`**

格式：`proxy_cache cache_name`

说明：

指定缓存区域的名字，一个相同的区域可以在不同的地方使用。

**C、`proxy_cache_valid`**

格式：`proxy_cache_valid reply_code [reply code…|any] time;`

说明：

reply_code －不同的应答代码
    
    time －为不同应答设置不同缓存时长 默认为分钟m
    
    any － 代表任何代码

### 2、页面缓存设置 ###

**A、新建缓存页面**

$ mkdir –pv /nginx/cache/webpages

**B、配置`nginx.conf`**

proxy_cache_path /nginx/cache/webpages levels=1:2 keys_zone=webpages:30mmax_size=2g;
    
        server { 
    
            listen       80;
    
            server_name  localhost;
    
            charset utf-8;
    
     
    
            location / { 
    
                proxy_passhttp://webservers;
    
                proxy_set_header X-Real-IP$remote_addr;
    
                proxy_cache webpages;
    
                proxy_cache_valid 20010m;
    
            }
    
        }

最后，测试下配置是否正确：  
![在这里插入图片描述][20190618223618482.png]

$sudo nginx –t

然后，重载下`nginx`服务：

$sudo nginx –s reload

**C、测试结果**

浏览器输入：[http://127.0.0.1][http_127.0.0.1] 然后查看缓存路径下是否生成缓存文件，以及缓存文件格式是否正确，缓存的结果：

/nginx/cache/webpages/f/63／681ad4c77694b65d61c9985553a2763f

上面的路径规则已经按照我们预期设置生成，缓存文件格式是`url`的`hash`格式，下面可以查看下这个文件是否是我们使用的页面，默认生成的缓存目录f 级别是不允许进入访问的，为了演示我已经给予其777权限了。

$cat 681ad4c77694b65d61c9985553a2763f

![在这里插入图片描述][20190618223635271.png]  
**D、如何知道是否访问缓存？**

答案很简单，我们使用谷歌浏览器浏览网页，然后打开开发者面板，查看里面的`Response Headers`响应头中的信息：  
![在这里插入图片描述][20190618223828638.png]  
但从上面是看不出是否调用了缓存文件，因为需要额外配置下。首先，要了解下两个缓存变量：

*  `$server_addr` － 显示的服务器地址
 *  `$upstream_cache_status` － 缓存的状态  
    可能的值为：MISS（未命中）、Hint（命中）、Expired（请求传递到后台）、Stale（后端得到过期的应答）、Updating（正更新，使用旧的应答）等。

那么，在这里如果缓存的状态为`HINT`，就说明命中了缓存，也就是调用了缓存文件。接下来，配置下`nginx.conf`文件，然后重新加载，刷新页面即刻，具体如下：

**A、配置文件`nginx.conf`**

proxy_cache_path /nginx/cache/webpages levels=1:2 keys_zone=webpages:30mmax_size=2g;
    
        server { 
    
            listen       80;
    
            server_name  localhost;
    
            charset utf-8;
    
            #add headers
    
            add_header X-Via$server_addr;
    
            add_header X-Cache$upstream_cache_status;
    
            location / { 
    
                proxy_passhttp://webservers;
    
                proxy_set_headerX-Real-IP $remote_addr;
    
                proxy_cache webpages;
    
                proxy_cache_valid 20010m;
    
            }
    
        }

**B、测试结果**  
![在这里插入图片描述][20190618224012321.png]  
如上图中的`Resonpse Headers`部分，已经说明缓存已经调度了。

好了，关于`Nginx`的反向代理、负载均衡及页面缓存都介绍完了，如有问题请及时讨论。

[http_blog.csdn.net_why_2012_gogo_article_details_50967447]: http://blog.csdn.net/why_2012_gogo/article/details/50967447%E3%80%82
[20190618220449830.png]: /images/20210626/0a29a281011748e3b9eabef9e0144020.png
[20190618220459536.png]: /images/20210626/a96585b71d87430583964fec7a482f12.png
[http_127.0.0.1]: http://127.0.0.1
[20190618222125640.png]: /images/20210626/31837b91051945fd964e16a11fef48fe.png
[20190618222747865.png]: /images/20210626/799e4ae3f7db452ab027d63c5dcb12b2.png
[http_backup.cwteam.com]: http://backup.cwteam.com
[20190618223018253.png]: /images/20210626/c273889e441541999ee825ac0c27a9d6.png
[20190618223618482.png]: /images/20210626/4fe1170a4a754b7caae7176b6a1836a4.png
[20190618223635271.png]: /images/20210626/a4c62457ac534808b8f9cd5297d39fc2.png
[20190618223828638.png]: /images/20210626/65047b75b16d4c8f8ebdc93f9f38cfda.png
[20190618224012321.png]: /images/20210626/6432bd7a442a45e3b7ee1c66acc79584.png