nginx

注意：nginx的conf.d的目录中，都是nginx的配置文件，如果某两个文件的请求转发域名一样，但是属于两个不同的工程，会导致其中某一个工程在启动的时候，跳转到另一个工程的情况

nginx正向代理和反向代理的本质区别：nginx正向代理代理的是发起请求的方，即可以理解为客户端；nginx反向代理代理的是被请求方，即可以理解为服务端。

举两个简单的例子对比：

1 我们访问google，由于防火墙的原因，我们并不能直接访问，而是需要借助VPN来实现，可以看看，正向代理代理的是客户端，客户端是知道目标的，但是目标并不知道客户端是通过VPN访问的。

2 当我们用外网访问百度时，其实会进行一个转发，代理到内网中去，这就是所谓的反向代理，即反向代理“代理”的是服务器端，而且这一个过程对于客户端来说是透明的。

启动nginx之后，其实就是在80端口启动了Socket服务进行监听，nginx涉及Master和Worker进程。

nginx.conf

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负责推送给worker进程更新配置文件，worker进程收到信息后，更新进程内部的线程信息。

方案二：修改配置文件nginx.conf后，重新生成新的worker进程，当然会以新的配置进行处理请求，而且新的请求必须就都交给新的worker进程，至于老的worker进程，等把那些以前的请求处理完之后，kill掉即可。

nginx采用的就是第二种方案达到热部署。

问题二：nginx如何做到高并发下的高效处理？

上文已经提及到nginx worker进程个数与CPU绑定、worker进程内部包含一个线程高效回环处理请求，这的确有助于效率，但是这是不够的。

要同时处理这么多请求，要知道，有的请求需要发生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提供的，可以加快访问速度的机制，说白了，在配置上就是一个开启，同时指定目录，让缓存可以存储到磁盘上。