从Nginx的Web请求处理机制中剖析多进程、多线程、异步IO

Nginx服务器web请求处理机制

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

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

多进程方式

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

　　多进程方式的优点在于，设计和实现相对简单，各个子进程之间相互独立，处理客户端请求的过程彼此不受到干扰，并且当一个子进程产生问题时，不容易将影响蔓延到其他进程中，这保证了提供服务的稳定性。当子线程退出时，其占用资源会被操作系统回收，也不会留下任何垃圾。而其缺点也很明显。操作系统中生成一个子进程需要进行内存复制等操作，在资源和时间上回产生一定的额外开销，因此，如果Web服务器接收大量并发请求，就会对系统资源造成压力，导致系统性能下降。

　　初期的Apache服务器就是采用这种方式对外提供服务的。为了应对大量并发请求，Apache服务器采用“预生成进程”的机制对多进程方式进行改进，“预生成进程”的工作方式很好理解。它将生成子进程的时机提前，在客户端请求还没有到来之前就预先生成好，当请求到来时，主进程分配一个子进程和该客户端进行交互，交互完成之后，该进程也不结束，而被主进程管理起来等待下一个客户端请求的到来，改进的多进程方式在一定程度上缓解了大量并发请求情形下Web服务器对系统资源造成的压力。但是优化Apache服务器在最初的构架设计上采用了多进程方式，因此这不能从根本上解决问题。

多线程方式

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

　　由于操作系统产生一个线程的开销远远小于产生一个进程的开销，所以多线程方式在很大程度上减轻了Web服务器对系统资源的要求。该方式使用线程进行任务调度，开发方面可以遵循一定的标准，这相对来说比较规范和有利于协作。但在线程管理方面，改方式有一定的不足。多个线程位于同一个进程内，可以访问同样的内存空间，彼此之间相互影响；同时，在开发过程中不过避免地要开发者自己对内存进行管理，其增加了出错的风险。服务器系统需要长时间连续不停地运转，错误的逐渐积累可能最终对整个服务器产生重大影响。

　　IIS服务，器使用了多线程方式对外提供服务，它的稳定性相对来说还是不错的，但对于经验丰富的Web服务器管理人员而言，他们通常还是会定期检查和重启服务器，以预防不可预料的故障发生。

异步方式

　　异步方式是和多进程方式及多线程方式完全不同的一种处理客户端请求的方式。在介绍改方式之前 ，我们先复习下同步、异步以及阻塞、非阻塞的概念。

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

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

　　在网络通信中，经常可以看到有人讲同步和阻塞等同、异步和非阻塞等同。事实上，这两对概念有一定的区别，不能混淆。两对概念的组合，就会产生四个新的概念，同步阻塞、异步阻塞、同步非阻塞、异步非阻塞。

• 同步阻塞方式，发送方向接收方发送请求后，一直等待响应；接收方处理请求是进行的IO操作如果不能马上得到结果，就一直等到返回结果后，才响应发送方，期间不能进行其他工作。比如、在超时排队付账时，客户（发送方）想收款员（接收方）付款（发送请求）后需要等待收款员找零，期间不能做其他的事情；而收款员要等待收款机返回结果（IO操作）后才能把零钱取出来交给客户（响应请求），期间也只能等待，不能做其他的事情。这种方式实现简单，但是效率不高。
• 同步非阻塞方式，发送方向接收方发送请求后，一直等待响应；接收方处理请求时进行的IO操作如果不能马上得到结果，就立即返回，去做其他事情，但由于没有得到请求处理结果，不响应发送方，发送方一直在等待，一直等IO操作完成后，接收方获得结果响应发送方后，接收方才进入下一次请求过程。在实际中不使用这种方式。
• 异步阻塞方法，发送方向接收方发送请求后，不用等待响应，可以继续其他工作；接收方处理请求是进行的IO操作如果不能马上得到结果，就一直等到返回结果后，才响应发送方，期间不能进行其他工作。这种方式在实际中也不使用。
• 异步非阻塞方式，发送方向接收方发送请求后，不用等待响应，可以继续其他工作；接收方处理请求时进行的IO操作富国不能马上得到结果，也不等待，而是马上返回去做其他事情。当IO操作完成以后，将完成状态和结果通知接收方，接收方再响应发送方。继续使用在超市付账排队的例子。客户（发送方）想收款员（接收方）付款（发送请求）后在等待收款员找零的过程中，还可以做其他事情，比如打电话、聊天等；而收款员在等待收款机处理交易（IO操作）的过程中可以帮助客户将商品打包，当收款机产生结果后，收款员给客户结账（响应请求）。在四种方式中，这种方式是发送方和接收方通信效率最高的一种。

Nginx如何处理请求

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

　　Nginx服务器启动后，可以产生一个主进程（master process）和多个工作进程（worker processes），其中可以在配置文件中指定产生的工作进程数量。Nginx服务器的所有工作进程都用于接收和处理客户端的请求。这类似于Apache使用的改进的多进程机制，预先生成多个工作进程，等待处理客户端请求。

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

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

Nginx事件驱动处理模型

　　在上面我们提到，Nginx服务器的工作进程调用IO后，就去进行其他工作了；当IO调用返回后，会通知工作进程。这里有一个问题，IO调用时如何把自己的状态通知给工作进程的呢？

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

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

　　事件驱动处理库有被称为多路IO复用方法，最常见的包括以下三种：select模型、poll模型和epoll模型。

select库

　　select库，是各个版本的Linux和Windows平台都支持的基本事件驱动模型库，并且在接口的定义上也基本相同，只是部分参数的含义略有差异。使用select库的步骤一般是：

　　首先，创建所关注事件的描述符集合。对于一个描述符，可以关注其上面的读（Read）事件、写（Write）事件以及异常发生（Exception）事件，所以要创建三类事件描述集合，分别用来收集读事件的描述符、写事件的描述符和异常事件的描述符。

　　其次，调用底层提供的select（）函数，等待事件发生。这里需要注意的一点是，select的阻塞与是否设置非阻塞I/O是没有关系的。

　　然后，轮询所有事件描述符集合中的每个事件描述符，检查是否有相应的事件发生，如果有，就进行处理。

　　Nginx服务器在编译过程中如果没有为其他指定其他高性能事件驱动模型库，它将自动编译该库。我们可以使用--with-select_module和--without-select_module两个参数强制Nginx是否编译该库。

poll库

　　poll库，作为Linux平台上的基本事件驱动模型，是在Linux2.1.23中引入。Windwos平台不支持poll库。

　　poll与select的基本工作方式是相同的，都是先创建一个关注事件的描述符集合，再去等待这些事件的发生，然后再轮询描述符集合，检查有没有事件发生，如果有，就进行处理。

　　poll库与select库的主要区别在于，select库需要为读事件、写事件和异常事件分别创建一个描述符集合，因此在最后轮询的时候，需要分别轮询这三个集合。而poll库只需要创建一个集合，在每个描述符对应的结构上分别设置读事件、写事件或者异常事件，最后轮询的时候，可以同时检查者三种事件是否发生。可以说，poll库是select库的优化实现。

　　Nginx服务器在编译过程中如果没有为其制定其他高性能事件驱动模型库，它将自动编译该库。我们可以使用--with-poll_module和--without-poll_module两个参数强制Nginx是否编译该库

epoll库
　　epoll库是Nginx服务器支持的是高性能事件驱动库之一，它是公认的非常优秀的事件驱动模块，和poll库及select库有很大的不同。epoll属于poll库的一个变种，是在Linux2.5.44中引入的，在Linux2.6及以上的版本都可以使用它。poll库和select库在实际工作中，最大的区别在于效率。

　　从前面的介绍我们知道，它们的处理方式都是创建一个待处理事件列表，然后把这个列表发给内核，返回的时候，再去轮询检查这个列表，以判断事件是否发生。这样在描述符比较多的应用中，效率就显得比较低下了。一种比较好的做法是，把描述符列表的管理交由内核负责，一旦有某种事件发生，内核把发生时间的描述符列表通知给进程，这样就避免了轮询整个描述符列表。epoll库就是这样一种模型。

　　首先，epoll库通过相关调用通知内核创建一个有N个描述符的事件列表；然后，给这些描述符设置锁关注的事件，并把它添加到内核的事件列表中去，在具体的编码过程中也可通过相关调用对时间列表中描述符进行修改和删除。

　　完成设置之后，epoll库就开始等待内核通知事件发生了。某一事件发生后，内核讲发生事件的描述符列表上报给epoll库。得到时间列表的epoll库，就可以进行事件处理了。

　　epoll库在Linux平台上是搞笑的。它支持一个进程打开大数目的时间描述符，上限是系统可以打开文件的最大数目；同时，epoll库的IO效率不随描述符数目增加而线性下降，因为它只会对内核上报的“活跃”的描述符进行操作

上面的全部内容均出自于《Nginx高性能Web服务器详情》中第三章Nginx服务器架构初探（我纯手动打上去的/(ㄒoㄒ)/~~  ┭┮﹏┭┮），对于理解Python中三者的关系真的特别有帮助；

Python开发【第九章】：线程、进程和协程---》》http://www.cnblogs.com/lianzhilei/p/5881434.html

Python开发【第十章】：I/O多路复用、异步I/O（综合篇）---》》http://www.cnblogs.com/lianzhilei/p/5955526.html