Nginx服务器的web请求处理机制

Nginx服务器的web请求处理机制

从设计架构上说，Nginx服务器是与众不同的。不同之处一方面体现在它的模块化设计，另一方面，也是最重要的一方面，体现在它对客户端请求的处理机制上。

web服务器和客户端是一对多的关系，web服务器必须有能力同时为多个客户端提供服务。一般来说，完成并行处理请求工作有三种方式可供选择：多进程方式、多线程方式和异步方式。

多进程方式

多进程方式是指，服务器每当接收到一个客户端时，就由服务器主进程生成一个子进程出来和该客户端建立连接进行交互，直到连接断开，该子进程就结束了。

多进程方式的优点

这种方式的有点在于，设计和实现相对简单，各个子进程之间相互独立，处理客户端请求的过程彼此不受到干扰，并且当一个子进程产生问题时，不容易将影响蔓延到其他进程中，这保证了提供服务的稳定性。当子进程退出时，其占用资源会被操作系统回收，也不会留下任何垃圾。

多进程方式的缺点

这种方式的缺点也很明显，操作系统中生成一个子进程需要进行内存复制等操作，在资源和时间上会产生一定的额外开销，因此，如果web服务器接收大量并发请求，就会对系统资源造成压力，导致系统性能下降。

多线程方式

多线程方式和多进程方式相似，服务器每当接收到一个客户端时，会由服务器主进程派生出一个线程出来和该客户端进行交互。

多线程方式的优点

由于操作系统产生一个线程的开销远远小于产生一个进程的开销，所以多线程方式在很大程度上减轻了Web服务器对系统资源的要求。该方法使用线程进行任务调度，开发方面可以遵循一定的标准，这相对来说比较规范和有利于协作。

多线程方式的缺点

在线程管理方面，多线程的方式有一定的不足，多个线程位于同一个进程内，可以访问同样的内存空间，彼此之间相互影响；同时，在开发过程中不可避免的要由开发者自己对内存进行管理，其增加了出错的风险。服务器系统需要长时间连续不停地运转，错误的逐渐积累可能最终对整个服务器产生重大影响。

异步方式

异步方式是和多线程方式及多进程方式完全不同的一种处理客户端请求的方式。首先，先来回顾一下同步、异步以及阻塞、非阻塞的概念。

网络通信中的同步机制和异步机制是描述通信模式的概念。同步机制，是指发送方发送请求后，需要等待接收到接收方发回的响应后，才接着发送下一个请求；异步机制和同步机制相反，在异步机制中，发送方发出一个请求后，不等待接收方相应这个请求，就继续发送下一个请求。在同步机制中，所有的请求在服务器端得到同步，发送方和接收方对请求的处理步调是一致的；在异步机制中，所有来自发送方的请求会形成一个队列，接收方处理完成后同之发送方。

阻塞和非阻塞用来描述进程处理调用的方法，在网络通信中，主要指网络套接字Socket的阻塞和非阻塞方式，而Socket的实质也就是IO操作。Socket的阻塞调用方式为，调用结果返回前，当前线程从运行状态被挂起，一直等到调用结果返回之后，才进入就绪状态，获取CPU后继续执行；Socket的非阻塞调用方式和阻塞调用方式正好相反，在非阻塞方式中，如果调用结果不能马上返回，当前线程也不会被挂起，而是立即返回执行下一个调用。

Nginx服务器处理请求的方式

Nginx服务器的一个显著优势是能够同时处理大量并发请求。它结合多进程机制和异步机制对外提供服务。异步机制使用的是异步非阻塞方式。

Nginx服务器启动后，可以产生一个主进程和多个工作进程，其中可以在配置文件中指定产生的工作进程的数量。Nginx服务器的所有工作进程都用于接收和处理客户端请求。实际上，Nginx服务器的进程模型有两种：SIngle模型和Master-worker模型。SIngle模型为单进程方式，性能较差，一般在实际工作中不使用。Master-worker模型实际上被更广泛地称为Master-Slave模型。

Nginx的每个工作进程使用了异步非阻塞方式，可以处理多个客户端请求，当某个工作进程接收到客户端的请求之后，调用IO进行处理，如果不能立即得到结果，就去处理其他的请求；而客户端在此期间也无需等待响应，可以去处理其他的事情；当IO调用返回结果时，就会通知此工作进程；该进程得到通知，暂时挂起当前处理的事务，去响应客户端请求。

客户端请求数量增长、网络负载繁重时，Nginx服务器使用多进程机制能够保证不增加系统资源的压力；同时使用异步非阻塞方式减少了工作进程在IO调用上的阻塞延迟，保证了不较低对请求的处理能力。

Nginx服务器的事件处理机制

将IO调用的状态通知工作进程有两种方案。一是，让工作进程在进行其他工作的过程中每隔一段时间就去检查一下IO的运行状态，如果完成，就去响应客户端，如果为完成，就继续正在进行的工作；二是，IO调用在完成后能主动通知工作进程。对于前者，虽然工作进程在IO调用过程中没有等待，但不断的检查仍然在时间和资源上导致了不小的开销，最理想的解决方案是第二种。

具体来说，select/poll/epoll/kqueue等这样的系统调用就是用来支持第二种解决方案的。这些系统调用，也常被称为事件驱动模型，它们提供了一种机制，让进程可以同时处理多个并发请求，不用关心IO调用的具体状态。IO调用完全由事件驱动模型来管理，事件准备好之后就同之工作进程事件已经就绪。