Nginx反向代理实现负载均衡总结_熟悉nginx反向代理，负载均衡-CSDN博客

本文链接：https://blog.csdn.net/why_2012_gogo/article/details/50967520

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

从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。

2、测试均衡服务器

二、反向代理

1、反向代理原理

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

2、Nginx的反向代理

配置nginx.conf文件：

location / {

proxy_pass http://test1.cwteam.com/index.html;

}

注意：配置后，重启nginx。

测试反向代理：

浏览器输入：http://127.0.0.1

正常的话，Nginx会反向定位到上面的test1服务器：

上图已经说明，我们的反向代理配置成功了，配置中使用了指令：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 反复刷新页面，如果看到test1和test2服务端交替出现，那么说明负载已经成功（如果其中一台服务器挂掉，如test1挂掉，那么只会给test2服务器分配），测试结果如下：

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 端口：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 反复刷新，结果显示：

上图，说明了在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 反复刷新页面如果调度的服务器总是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;

}

最后，测试下配置是否正确：

$sudo nginx –t

然后，重载下nginx服务：

$sudo nginx –s reload

C、测试结果

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

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

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

$cat 681ad4c77694b65d61c9985553a2763f

D、如何知道是否访问缓存？

答案很简单，我们使用谷歌浏览器浏览网页，然后打开开发者面板，查看里面的Response Headers响应头中的信息：

但从上面是看不出是否调用了缓存文件，因为需要额外配置下。首先，要了解下两个缓存变量：

$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、测试结果

如上图中的Resonpse Headers部分，已经说明缓存已经调度了。

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