Nginx是这款轻量的Web伺服器、逆向全权伺服器，虽然它的缓存挤占少（两个worker民主化只挤占10-12M缓存），开启非常快，高mammalian潜能强，在网络工程项目中应用。
上图大体上说明了当今社会盛行的控制技术架构，当中Nginx有点儿出口处交换机的香味。
逆向全权伺服器
时常听人说到许多名词，如逆向全权，所以甚么是逆向全权，甚么又是萨德基全权呢？上面是两个单纯的归纳。
萨德基全权
虽然内网的其原因，他们并无法间接出访Google，那么他们能借助于VPN来同时实现，这是两个单纯的萨德基全权的范例。这儿你能辨认出，萨德基全权“全权”的是应用程序，所以应用程序是晓得最终目标的，而最终目标是不晓得应用程序是透过VPN出访的。
萨德基全权左图
逆向全权
当他们出外网出访腾讯的这时候，只不过会展开两个转贴，全权到内部网去，这是简而言之的逆向全权，即逆向全权“全权”的是服务端，所以这两个操作过程对应用程序来说是透明化的。
逆向全权左图
Nginx的Master-Worker模式
要开启nginx，只需要输入命nginx，当中xxx是你nginx的安装目录。
nginx民主化
开启Nginx后，只不过是在80端口开启了Socket服务展开监听，如图所示，Nginx涉及Master民主化和Worker民主化。
Master-Worker模式
Master民主化的作用：读取并验证配置文件nginx.conf；管理worker民主化；
Worker民主化的作用：每两个Worker民主化都维护两个线程（避免线程切换），处理连接和请求；注意Worker民主化的个数由配置文件决定，一般和CPU个数相关（有利于民主化切换），配置几个就有几个Worker民主化，上面的范例只有1个Worker民主化。
思考1：Nginx如何做到热部署？
简而言之热部署，是配置文件nginx.conf修改后，不需要stop Nginx，不需要中断请求，就能让配置文件生效！（nginx -s reload 重新加载/nginx -t检查配置/nginx -s stop）
透过上文他们早已晓得worker民主化负责处理具体的请求，所以如果想达到热部署的效果，能想象：
方案一：修改配置文件nginx.conf后，主民主化master负责推送给worker民主化更新配置信息，worker民主化收到信息后，更新民主化内部的线程信息。
方案二：修改配置文件nginx.conf后，重新生成新的worker民主化，当然会以新的配置展开处理，所以新的请求都必须交给新的worker民主化，至于老worker民主化，等把那些以前的请求处理完毕，kill掉即可。
Nginx采用的是方案二来达到热部署的！
思考2：Nginx如何做到高mammalian下的高效处理？
上文早已提及Nginx的worker民主化个数与CPU绑定、worker民主化内部包含两个线程高效回环处理请求，这的确有助于效率，但这是不够的。
作为专业的程序员，他们能开一下脑洞：BIO/NIO/AIO、异步/同步、阻塞/非阻塞…
要同时处理所以多的请求，要晓得，有的请求需要发生IO，可能需要很长时间，如果等着它，就会拖慢worker的处理速度。
Nginx采用了Linux的epoll模型，epoll模型基于事件驱动机制，它能监控多个事件是否准备完毕，如果OK，所以放入epoll队列中，这个操作过程是异步的。worker只需要从epoll队列循环处理即可。
思考3：Nginx挂了怎么办？
Nginx既然作为出口处交换机，很重要，如果出现单点问题，显然是不可接受的。答案是：Keepalived+Nginx同时实现高可用。
Keepalived是两个高可用解决方案，主要是用来防止伺服器单点发生故障，能透过和Nginx配合来同时实现Web服务的高可用。（只不过，Keepalived不仅仅能和Nginx配合，还能和很多其他服务配合）
Keepalived+Nginx同时实现高可用的思路：
第一：请求不要间接打到Nginx上，应该先透过Keepalived（这是简而言之虚拟IP，VIP）
第二：Keepalived应该能监控Nginx的生命状态（提供两个用户自定义的脚本，定期检查Nginx民主化状态，展开权重变化,，从而同时实现Nginx故障切换）
Keepalived+Nginx
他们的主战场：nginx.conf
很多这时候，在开发、测试环境下，他们都得自己去配置Nginx，是去配置nginx.conf。nginx.conf是典型的分段配置文件，上面他们来分析下。在 Nginx 内部，你能指定多个虚拟伺服器，每个虚拟伺服器用 server{} 上下文描述。
虚拟主机
nginx的配置文件主要由指令构成，指令主要包括名称和参数，以分号;结束。如下是两个虚拟伺服器的配置：listen 指令来指定该虚拟主机在监听给定的 IP 端口组合；server_name指令检测 Host 头以决定请求到底匹配到哪个虚拟主机…nginx的配置项很多，具体可以查阅网上资料。
http的server段
出访结果
只不过这是把Nginx作为web server来处理静态资源，
1：location能展开正则匹配，应该注意正则的几种形式以及优先级。（这儿不展开）
2：Nginx能提高速度的当中两个特性是：动静分离，是把静态资源放到Nginx上，由Nginx管理，动态请求转贴给后端。
3：他们能在Nginx下把静态资源、日志文件归属到不同域名下（也即是目录），这样方便管理维护。
4：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地址，所以他们如果想指定多台来达到负载均衡呢？
1：透过upstream来定义一组Tomcat，并指定负载策略（IPHASH、加权论调、最少连接），健康检查策略（Nginx能监控这一组Tomcat的状态）等。
2：将proxy_pass替换成upstream指定的值即可。
负载均衡需要注意的问题：选择不同的负载均衡算法，可能会带来不同的问题，如果选择轮询方式，所以两个请求，能到A server，也能到B server，他们得注意用户状态的保存问题，如Session会话信息，无法在保存到伺服器上。
如果选择散列，没有了上面的问题，但是又得考虑，甚么样的散列算法尽可能均匀打到后端的伺服器上，总之实际应用中需要根据场景权衡选择。
