Nginx是一款轻量级的Web做事器、反向代理做事器,由于它的内存占用少,启动极快,高并发能力强,在互联网项目中广泛运用。
上图基本上解释了当下流行的技能架构,个中Nginx有点入口网关的味道。
反向代理做事器?
常常听人说到一些术语,如反向代理,那么什么是反向代理,什么又是正向代理呢?
正向代理:
反向代理:
由于防火墙的缘故原由,我们并不能直接访问谷歌,那么我们可以借助来实现,这便是一个大略的正向代理的例子。这里你能够创造,正向代理“代理”的是客户端,而且客户端是知道目标的,而目标是不知道客户端是通过访问的。
当我们在外网访问百度的时候,实在会进行一个转发,代理到内网去,这便是所谓的反向代理,即反向代理“代理”的是做事器端,而且这一个过程对付客户端而言是透明的。
Nginx的Master-Worker模式
启动Nginx后,实在便是在80端口启动了Socket做事进行监听,如图所示,Nginx涉及Master进程和Worker进程。
Master进程的浸染是?
读取并验证配置文件nginx.conf;管理worker进程;
Worker进程的浸染是?
每一个Worker进程都掩护一个线程(避免线程切换),处理连接和要求;把稳Worker进程的个数由配置文件决定,一样平常和CPU个数干系(有利于进程切换),配置几个就有几个Worker进程。
思考:Nginx如何做到热支配?
所谓热支配,便是配置文件nginx.conf修正后,不须要stop Nginx,不须要中断要求,就能让配置文件生效!
(nginx -s reload 重新加载/nginx -t检讨配置/nginx -s stop)
通过上文我们已经知道worker进程卖力处理详细的要求,那么如果想达到热支配的效果,可以想象:
方案一:
修正配置文件nginx.conf后,主进程master卖力推送给woker进程更新配置信息,woker进程收到信息后,更新进程内部的线程信息。(有点valatile的味道)
方案二:
修正配置文件nginx.conf后,重新天生新的worker进程,当然会以新的配置进行处理要求,而且新的要求必须都交给新的worker进程,至于老的worker进程,等把那些以前的要求处理完毕后,kill掉即可。
Nginx采取的便是方案二来达到热支配的!
思考:Nginx如何做到高并发下的高效处理?
上文已经提及Nginx的worker进程个数与CPU绑定、worker进程内部包含一个线程高效回环处理要求,这的确有助于效率,但这是不足的。
作为专业的程序员,我们可以开一下脑洞:BIO/NIO/AIO、异步/同步、壅塞/非壅塞...
要同时处理那么多的要求,要知道,有的要求须要发生IO,可能须要很永劫光,如果等着它,就会拖慢worker的处理速率。
Nginx采取了Linux的epoll模型,epoll模型基于事宜驱动机制,它可以监控多个事宜是否准备完毕,如果OK,那么放入epoll行列步队中,这个过程是异步的。worker只须要从epoll行列步队循环处理即可。
思考:Nginx挂了怎么办?
Nginx既然作为入口网关,很主要,如果涌现单点问题,显然是不可接管的。
答案是:Keepalived+Nginx实现高可用。
Keepalived是一个高可用办理方案,紧张是用来防止做事器单点发生故障,可以通过和Nginx合营来实现Web做事的高可用。(实在,Keepalived不仅仅可以和Nginx合营,还可以和很多其他做事合营)
Keepalived+Nginx实现高可用的思路:
第一:要求不要直接打到Nginx上,该当先通过Keepalived(这便是所谓虚拟IP,VIP)
第二:Keepalived该当能监控Nginx的生命状态(供应一个用户自定义的脚本,定期检讨Nginx进程状态,进行权重变革,,从而实现Nginx故障切换)
我们的主沙场:nginx.conf
很多时候,在开拓、测试环境下,我们都得自己去配置Nginx,便是去配置nginx.conf。
nginx.conf是范例的分段配置文件,下面我们来剖析下。
虚拟主机
实在这是把Nginx作为web server来处理静态资源。
第一:location可以进行正则匹配,该当把稳正则的几种形式以及优先级。(这里不展开)
第二:Nginx能够提高速率的个中一个特性便是:动静分离,便是把静态资源放到Nginx上,由Nginx管理,动态要求转发给后端。
第三:我们可以在Nginx下把静态资源、日志文件归属到不同域名下(也即是目录),这样方便管理掩护。
第四:Nginx可以进行IP访问掌握,有些电商平台,就可以在Nginx这一层,做一下处理,内置一个黑名单模块,那么就不必等要求通过Nginx达到后端在进行拦截,而是直接在Nginx这一层就处理掉。
反向代理【proxy_pass】
所谓反向代理,很大略,实在便是在location这一段配置中的root更换成proxy_pass即可。root解释是静态资源,可以由Nginx进行返回;而proxy_pass解释是动态要求,须要进行转发,比如代理到Tomcat上。
反向代理,上面已经说了,过程是透明的,比如说request -> Nginx -> Tomcat,那么对付Tomcat而言,要求的IP地址便是Nginx的地址,而非真实的request地址,这一点须要把稳。不过好在Nginx不仅仅可以反向代理要求,还可以由用户自定义设置HTTP HEADER。
负载均衡【upstream】
上面的反向代理中,我们通过proxy_pass来指定Tomcat的地址,很显然我们只能指定一台Tomcat地址,那么我们如果想指定多台来达到负载均衡呢?
第一,通过upstream来定义一组Tomcat,并指定负载策略(IPHASH、加权论调、最少连接),康健检讨策略(Nginx可以监控这一组Tomcat的状态)等。
第二,将proxy_pass更换成upstream指定的值即可。
负载均衡可能带来的问题?
负载均衡所带来的明显的问题是,一个要求,可以到A server,也可以到B server,这完备不受我们的掌握,当然这也不是什么问题,只是我们得把稳的是:用户状态的保存问题,如Session会话信息,不能在保存到做事器上。
缓存
缓存,是Nginx供应的,可以加快访问速率的机制,说白了,在配置上便是一个开启,同时指定目录,让缓存可以存储到磁盘上。详细配置,大家可以参考Nginx官方文档,这里就不在展开了。
转载链接地址:http://blog.51cto.com/zhangfengzhe/2064524
作者:zfz_linux_boy的原创作品