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

版权声明:本文为博主原创文章,未经博主允许不得转载。 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

12

 

注意:

使用虚拟主机验证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的反向代理、负载均衡及页面缓存都介绍完了,如有问题请及时讨论。

 

 

 

阅读更多

没有更多推荐了,返回首页