初探Nginx架构之进程模型与事件处理机制

文章内容：

0.序

1.概述

2.Nginx的进程模型

3.Nginx的事件处理机制

   3.1基本知识：

   3.2网络事件的事件处理机制

   3.3通过几个问题，进一步理解Nginx的网络事件处理机制

   3.4如何处理信号和定时器呢？

4.总结

5.参考文章

 

0.序

     本文主要参考http://tengine.taobao.org/book/chapter_2.html#connection 初探Nginx架构，实际上是这篇文章的一个概括总结

1.概述

     nginx在启动后，在unix系统中会以daemon的方式在后台运行，后台进程包含一个master进程和多个worker进程。我们也可以手动地关掉daemon模式，让nginx在前台运行，这个时候，nginx就是一个单进程的，很显然，生产环境下我们肯定不会这么做，所以关掉daemon的方式，一般是用来调试用的，在后面的章节里面，我们会详细地讲解如何调试nginx。所以，我们可以看到，nginx是以多进程的方式来工作的，当然nginx也是支持多线程的方式的，只是我们主流的方式还是多进程的方式，也是nginx的默认方式。nginx采用多进程的方式有诸多好处，所以我就主要讲解nginx的多进程模式吧

 2.Nginx的多进程模式（即Nginx的进程模型）

         nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的。worker进程的个数与机器cpu个数一致，这里面的原因与nginx的进程模型及事件处理模型有关。nginx的进程模型，可以由下图来表示：

 

     在nginx启动后，如果我们要操作nginx，要怎么做呢？从上文中我们可以看到，master来管理worker进程，所以我们只需要与master进程通信就行了。master进程会接收来自外界发来的信号，再根据信号做不同的事情。所以我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill -HUP pid，则是告诉nginx，从容地重启nginx，我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。当然，直接给master进程发送信号，这是比较老的操作方式，nginx在0.8版本之后，引入了一系列命令行参数，来方便我们管理。比如，./nginx -s reload，就是来重启nginx，./nginx -s stop，就是来停止nginx的运行。如何做到的呢？我们还是拿reload来说，我们看到，执行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，就知道我们的目的是控制nginx来重新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。

     小结：nginx启动后，我们操作nginx，是通过用户与master进程进行通信。master接收来自外界发来的信号，就会根据信号做出不同的事情。

     

     现在，我们知道了当我们在操作nginx的时候，nginx内部做了些什么事情，那么，worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master进程fork过来，在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。

     惊群现象：指一个fd的事件被触发后，等候这个fd的所有线程/进程都被唤醒。虽然都被唤醒，但是只有一个会去响应。

     小结：master（master进程会先建立好需要listen的socket）--------fork生成子进程workers，继承socket（此时workers子进程们都继承了父进程master的所有属性，当然也包括已经建立好的socket，当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的）------当一个连接进入，产生惊群现象

     Nginx对惊群现象的处理：

     nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。

     worker进程工作：

     当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。

     小结：1）一个完整的请求读取请求、解析请求、处理请求，产生数据后，再返回给客户端，最后断开连接。

               2）一个完整的请求完全由一个worker进程处理。

     采用这种方式的好处：

     1）节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多

     2）独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，大家可以慢慢体会。

 

 

3.Nginx的事件处理机制

3.1基本知识：

          对于一个基本的web服务器来说，事件通常有三种类型，网络事件、信号、定时器。

3.2网络事件的事件处理机制

     首先看一个请求的完整过程：

          大致过程：

               建立连接---接收数据---发送数据。

     再次看系统底层的操作：

                上述过程（建立连接---接收数据---发送数据）在系统底层就是读写事件。

               1）如果采用阻塞调用的方式，当读写事件没有准备好时，必然不能够进行读写事件，那么久只好等待，等事件准备好了，才能进行读写事件。那么请求就会被耽搁。

               阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。好吧，你说加进程数，这跟apache的线程模型有什么区别，注意，别增加无谓的上下文切换 ？所以，在nginx里面，最忌讳阻塞的系统调用了。

               2）既然阻塞调用不行，那么采用非阻塞方式。非阻塞就是，事件没有准备好，马上返回EAGAIN，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的。（这儿貌似应该是采用的是同步非阻塞，不过不清楚是不是，也可能是我对同步异步理解有误）

               小结：非阻塞通过不断检查事件的状态来判断是否进行读写操作，这样带来的开销很大。

               3）因此才有了异步非阻塞的事件处理机制。具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。他们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制解决了我们上面两个问题。

               以epoll为例：当事件没有准备好时，就放入epoll里面。如果有事件准备好了，那么就去处理；如果事件返回的是EAGAIN，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理她，只有当所有时间都没有准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。

               4）与多线程的比较：

                    与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。 我之前有对连接数进行过测试，在24G内存的机器上，处理的并发请求数达到过200万。现在的网络服务器基本都采用这种方式，这也是nginx性能高效的主要原因。

               小结：通过异步非阻塞的事件处理机制，Nginx实现由进程循环处理多个准备好的事件，从而实现高并发和轻量级。

3.3通过几个问题，进一步理解Nginx的网络事件处理机制

     问题1： Nginx采用worker进程来处理请求，一个worker进程只有一个主线程，那么有多少个worker子进程就能处理多少个并发，那么能够处理的并发数有限。

              概括的将，Nginx如何实现高并发？

     回答1：采用异步非阻塞的事件处理机制。之所以能够并发处理大量的未处理完的请求，是通过异步非阻塞方式，由进程循环处理多个准备好的事件。以epoll为例，为准备好的事件都会放入epoll中，只要有事件准备好，就会进行处理。                   

     问题2：何为异步非阻塞方式

     回答2：见http://blog.csdn.net/yankai0219/article/details/8018232 

     问题3：Nginx与Apache对于高并发处理上的区别。

     回答3：对于Apache，每个请求都会独占一个工作线程，当并发数到达几千时，就同时有几千的线程在处理请求了。这对于操作系统来说，占用的内存非常大，线程的上下文切换带来的cpu开销也很大，性能就难以上去，同时这些开销是完全没有意义的。

               对于Nginx来讲，一个进程只有一个主线程，通过异步非阻塞的事件处理机制，实现了循环处理多个准备好的事件，从而实现轻量级和高并发。

     问题4：为何推荐worker的个数为cpu的个数？

     回答4：因为更多的worker书，只会导致进程相互竞争cpu资源，从而带来不必要的上下文切换

 3.4如何处理信号和定时器呢？

          

          首先，信号的处理。对nginx来说，有一些特定的信号，代码着特定的意义。信号会中断掉程序当前的运行，在改变状态后，继续执行。如果是系统调用，则可能会导致系统调用的失败，需要重入。关于信号的处理，大家可以学习一些专业书籍，这里不多说。对于nginx来说，如果nginx正在等待事件（epoll_wait时），如果程序收到信号，在信号处理函数处理完后，epoll_wait会返回错误，然后程序可再次进入epoll_wait调用。

 

          另外，再来看看定时器。由于epoll_wait等函数在调用的时候是可以设置一个超时时间的，所以nginx借助这个超时时间来实现定时器。nginx里面的定时器事件是放在一个最小堆里面，每次在进入epoll_wait前，先从最小堆里面拿到所有定时器事件的最小时间，然后计算出epoll_wait的超时时间，然后进入epoll_wait。所以，当没有事件产生，也没有中断信号时，epoll_wait会超时，也就是说，定时器事件到了。这时，nginx会检查所有的超时事件，将他们的状态设置为超时，然后再去处理网络事件。由此可以看出，当我们写nginx代码时，在处理网络事件的回调函数时，通常做的第一个事情就是判断超时，然后再去处理网络事件。

 

 

4.总结

     Nginx的进程模式是一个Master进程+多个worker子进程。用户通过与Master进程通信，实现对Nginx的操作。worker子进程通过响应和处理Http请求。

     Nginx的事件处理机制，采用异步非阻塞事件处理机制，一个worker进程只有一个主线程，通过异步非阻塞的事件处理机制，实现了循环处理多个准备好的事件，从而实现轻量级和高并发。