标签：
反向代理（ReverseProxy）方式是在服务器端接受客户端的请求，然后把请求分发给具体的服务器进行处理，然后再将服务器的响应结果反馈给客户端。
用户A主动访问服务器B，但是用户A的所有请求都由代理服务器Z来处理，也就是在用户A访问服务器B时，会通过代理服务器Z
反向代理正好与正向代理相反，用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答（即用户A访问的是代理服务器），从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。
参考博客：
http://symphony.b3log.org/article/1381403388981
Nginx是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP代理服务器。
跨平台；配置简单；成本低廉；内置健康检查功能（如果Nginx 代理的后端的某台 Web 服务器宕机了，不会影响前端访问） ；稳定性高；非阻塞，高并发连接（数据复制时，磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。这得益于Nginx使用了最新的epoll模型）；事件驱动（通信机制采用epoll模型，支持更大的并发连接）
对于一个Web服务器来说，首先看一个请求的基本过程：建立连接—接收数据—发送数据，在系统底层看来：上述过程（建立连接—接收数据—发送数据）在系统底层就是读写事件
①如果采用阻塞调用的方式，当读写事件没有准备好时，必然不能够进行读写事件，那么久只好等待，等事件准备好了，才能进行读写事件，那么请求就会被耽搁。
（即当服务器正在进行上一个请求的读写操作时，又来了一个请求，这时服务器并没有准备好，所以不能响应当前的请求，故当前的请求只能等待也不能去做别的事情）
②既然没有准备好阻塞调用不行，那么采用非阻塞调用方式。非阻塞就是：事件马上返回，告诉你事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的。
（非阻塞与阻塞的区别就是当前的请求不是一直等待，而是没准备好，我就去做别的事情，但是过段时间就来访问一下，看看服务器是否准备好）
③非阻塞通过不断检查事件的状态来判断是否进行读写操作，这样带来的开销很大，因此就有了异步非阻塞的事件处理机制。这种机制让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制解决了上面阻塞调用与非阻塞调用的两个问题。
（异步非阻塞的方式为，当服务器正在工作时，又来了一个新的请求，那么我们将这个请求放到队列中，之后我就可以去做其他的事情，当服务器完成当前任务后，直接从队列中选取需要执行的操作执行，返回结果给我即可）
a，以epoll模型为例：当事件没有准备好时，就放入epoll(队列)里面。如果有事件准备好了，那么就去处理；如果事件返回的是EAGAIN，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理它，只有当所有事件都没有准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。
b，与多线程方式相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级，并发数再多也不会导致无谓的资源浪费（上下文切换）。对于IIS服务器，每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战：因为线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去，从而导致在高并发场景下性能下降严重。
通过异步非阻塞的事件处理机制，Nginx实现由进程循环处理多个准备好的事件，从而实现高并发和轻量级。
版权声明：本文为博主原创文章，未经博主允许不得转载。
标签：
原文地址：http://blog.csdn.net/hejingyuan6/article/details/47211221
