Nginx实现负载均衡的项目实践
作者:云计算-Security
一、Nginx介绍
Nginx是一款高性能的Http和反向代理服务器,也是一个IMAP/POP3/SMTP服务器(电子邮件代理),最早开发这个产品的目的之一也是作为邮件代理服务器。因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗及其高并发性能强而广泛应用于各种生产部署之中。而且nginx是基于事件驱动模型(epoll)实现的I/O多路复用,并通过异步、非阻塞的方式处理请求。在高连接并发的情况下,Nginx是Apache服务器不错的替代品。而我们为什么要选择Nginx呢?
二、Nginx特点
- 高并发、高性能;
- 高可靠(可以7*24小时不间断运行);
- 可扩展性强(高度模块化设计,添加模块平稳);
- 作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接;
- 作为负载均衡服务器:可以进行自定义配置,支持虚拟主机、支持URL重定向、支持网络监控等。
- Nginx 安装非常的简单,配置文件 非常简洁(还能够支持perl语法),Bugs少;
- 处理静态文件,索引文件以及自动索引;
- 反向代理加速(无缓存),简单的负载均衡和容错;
- 支持热部署(可在不停止服务器的情况下升级nginx)。
这就是为什么要选择Nginx的原因。而且Nginx的功能特点还不止这些,上面只是简单列举了几点常见功能。
三、Nginx负载均衡
在我们实际生产中,一台服务器的处理能力、存储空间是有限的, 不要企图去换更强大的服务器,对大型网站而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器来分担原有服务器的访问及存储压力。实际上这就是我们所谓的负载均衡,Nginx作为负载均衡服务器,它通过反向代理来对后端多台服务器负载均衡。首先来说一下Nginx负载均衡策略及负载均衡算法。
3.1 认识 upstream 模块
upstream 这个模块是写一组被代理的服务器地址(即定义的后端服务器列表中选取一台服务器接受用户的请求 ),然后配置负载均衡的算法。 来看一下最基本的负载均衡实例:
upstream test { server 10.20.151.114:80; server 10.20.151.115:80; } server { .... location / { proxy_pass http://test; --请求转向 test 定义的服务器列表 }
3.2 Nginx负载均衡策略
(1)轮询
最基本的配置方法,上面的例子就是轮询的方式,它是upstream模块默认的负载均衡默认策略。每个请求会按时间顺序逐一分配到不同的后端服务器。
upstream test { server 10.20.151.114:80; weight=1; server 10.20.151.115:80; weight=2; }
(2)ip_hash
每个请求按访问IP的hash结果分配,同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上,可以解决session问题。
upstream test { ip_hash; --同一个IP客户端固定访问一个后端服务器 server 10.20.151.114:80; weight=1; server 10.20.151.115:80; weight=2; }
(3)url_hash
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器。一旦缓存住了资源,再此收到请求,就可以从缓存中读取。
upstream test { hash $request_uri; --实现每个url定向到同一个后端服务器 server 10.20.151.114:80; weight=1; server 10.20.151.115:80; weight=2; }
(4)least_conn
把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端,使它们的负载大致相同;但是,有些请求占用的时间很长,会导致其所在的后端负载较高。这种情况下,least_conn这种方式就可以达到更好的负载均衡效果。
upstream test { least_conn; --把请求转发给连接数较少的后端服务器 server 10.20.151.114:80; weight=1; server 10.20.151.115:80; weight=2; }
(5)weight
权重方式,在轮询策略的基础上指定轮询的几率。
upstream test { server 10.20.151.114:80; weight=1; server 10.20.151.115:80; weight=2; --轮询的几率相对上一条要大 }
(6)fair
此种算法可以依据页面大小和加载时间长短智能地进行负载均衡,也就是根据后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream test { server 10.20.151.114:80; weight=1; server 10.20.151.115:80; weight=2; fair; --实现响应时间短的优先分配 }
nginx负载均衡配置状态参数
- down:表示当前的server暂时不参与负载均衡。
- backup:预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候,才会请求backup机器,因此这台机器的压力最轻。
- max_fails:允许请求失败的次数,默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误。
- fail_timeout:在经历了max_fails次失败后,暂停服务的时间单位秒。max_fails可以和fail_timeout一起使用。
Nginx可分为二层、三层、四层、七层负载均衡。 所谓的二层就是基于MAC地址的负载均衡, 三层就是基于IP地址的负载均衡,四层就是基于IP+端口的负载均衡,七层就是基于URL等应用层信息的负载均衡。因篇幅较长这里不再做具体的介绍,有兴趣的可自行百度。这里以七层负载均衡来做实例。
3.3 Nginx负载均衡实例
环境准备:准备3台Nginx服务器,一台作为负载均衡服务器,其它两台作为后端服务器。
10.20.151.240 ----proxy_server(负载均衡服务器)
10.20.151.112 ----server1(后端服务器1)
10.20.151.113 ----server2(后端服务器2)
(1)负载均衡服务器配置
vim /etc/nginx/nginx.conf --配置主配置文件 vim /etc/nginx/conf.d/test.conf --配置子配置文件
(2)后端服务器配置
vim /usr/local/nginx/conf/nginx.conf --修改配置文件 vim /usr/local/nginx/html/index.html --添加测试数据
(3)负载均衡测试
在浏览器端访问http://10.20.151.240/,在实际生产中,这两个页面返回的结果是一样的,这里是为了测试效果,所以返回了不同的内容。而为什么刷新后又会返回不同结果呢?那是因为负载均衡默认的均衡策略(或算法)是轮询,所以每刷新一次就会从不同的后端服务器返回不同的请求结果,减轻单个后端服务器的访问量,提升客户端的访问效率,从而达到负载均衡的效果。
当我添加权重(weight)时
再次访问http://10.20.151.240/
加权重和没加权重有什么区别呢?在实际生产中,我们一般会将配置较高的服务器的权重设置高一点,其实就是客户端在访问时,权重较高的服务器会被多次请求,这样能减轻配置较低的服务器的请求量,从而更好的实现负载均衡。
当我添加backup状态参数时
再次访问http://10.20.151.240/
此时我故意停掉第一台后端服务器,继续访问http://10.20.151.240/
当我给113这台后端服务器添加backup后,它就会作为热备服务器,添加的主要目的就是当我其他后端服务器都宕机的情况下,我的热备服务器还能继续提供同样的服务(注意:在其他后端服务器还未宕机之前,该热备服务器是不工作的)。因此负载均衡不仅能达到各个后端服务器负载的均衡,同时通过配置相关转态参数还能保证客户端请求时不造成服务器宕机的情况,保证了后端服务器的稳定性。其他状态参数这里我不再做演示(因为配置方式都一样)。
总结
通过上述简单案例不难看出负载均衡的重要性,不管是大中小型企业,都会用到负载均衡,尤其是某些大型购物网站,如果不做负载均衡,估计刚上线几分钟后端服务器就会被客户端的请求给弄瘫痪了。因此Nginx负载均衡实现的就是后端服务器的平均分摊客户端的访问压力,同时借助Nginx的高并发、高性能、高可靠性等特点,对我们的实际生产提供了最大化服务和性能保障。
到此这篇关于Nginx实现负载均衡的项目实践的文章就介绍到这了,更多相关Nginx 负载均衡内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!