标识设计公司网站,wordpress手机页面悬浮导航栏,济南市莱芜区,wordpress 律师事务所模板nginx在启动后#xff0c;在unix系统中会以daemon的方式在后台运行#xff0c;后台进程包含一个master进程和多个worker进程。我们也可以手动地关掉后台模式#xff0c;让nginx在前台运行#xff0c;并且通过配置让nginx取消master进程#xff0c;从而可以使nginx以单进程…nginx在启动后在unix系统中会以daemon的方式在后台运行后台进程包含一个master进程和多个worker进程。我们也可以手动地关掉后台模式让nginx在前台运行并且通过配置让nginx取消master进程从而可以使nginx以单进程方式运行。很显然生产环境下我们肯定不会这么做所以关闭后台模式一般是用来调试用的在后面的章节里面我们会详细地讲解如何调试nginx。所以我们可以看到nginx是以多进程的方式来工作的当然nginx也是支持多线程的方式的只是我们主流的方式还是多进程的方式也是nginx的默认方式。nginx采用多进程的方式有诸多好处所以我就主要讲解nginx的多进程模式吧。刚才讲到nginx在启动后会有一个master进程和多个worker进程。master进程主要用来管理worker进程包含接收来自外界的信号向各worker进程发送信号监控worker进程的运行状态当worker进程退出后(异常情况下)会自动重新启动新的worker进程。而基本的网络事件则是放在worker进程中来处理了。多个worker进程之间是对等的他们同等竞争来自客户端的请求各进程互相之间是独立的。一个请求只可能在一个worker进程中处理一个worker进程不可能处理其它进程的请求。worker进程的个数是可以设置的一般我们会设置与机器cpu核数一致这里面的原因与nginx的进程模型以及事件处理模型是分不开的。在nginx启动后如果我们要操作nginx要怎么做呢从上文中我们可以看到master来管理worker进程所以我们只需要与master进程通信就行了。master进程会接收来自外界发来的信号再根据信号做不同的事情。所以我们要控制nginx只需要通过kill向master进程发送信号就行了。比如kill -HUP pid则是告诉nginx从容地重启nginx我们一般用这个信号来重启nginx或重新加载配置因为是从容地重启因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢首先master进程在接到信号后会先重新加载配置文件然后再启动新的worker进程并向所有老的worker进程发送信号告诉他们可以光荣退休了。新的worker在启动后就开始接收新的请求而老的worker在收到来自master的信号后就不再接收新的请求并且在当前进程中的所有未处理完的请求处理完成后再退出。当然直接给master进程发送信号这是比较老的操作方式nginx在0.8版本之后引入了一系列命令行参数来方便我们管理。比如./nginx -s reload就是来重启nginx./nginx -s stop就是来停止nginx的运行。如何做到的呢我们还是拿reload来说我们看到执行命令时我们是启动一个新的nginx进程而新的nginx进程在解析到reload参数后就知道我们的目的是控制nginx来重新加载配置文件了它会向master进程发送信号然后接下来的动作就和我们直接向master进程发送信号一样了。现在我们知道了当我们在操作nginx的时候nginx内部做了些什么事情那么worker进程又是如何处理请求的呢我们前面有提到worker进程之间是平等的每个进程处理请求的机会也是一样的。当我们提供80端口的http服务时一个连接请求过来每个进程都有可能处理这个连接怎么做到的呢首先每个worker进程都是从master进程fork过来在master进程里面先建立好需要listen的socket(listenfd)之后然后再fork出多个worker进程。所有worker进程的listenfd会在新连接到来时变得可读为保证只有一个进程处理该连接所有worker进程在注册listenfd读事件前抢accept_mutex抢到互斥锁的那个进程注册listenfd读事件在读事件里调用accept接受该连接。当一个worker进程在accept这个连接之后就开始读取请求解析请求处理请求产生数据后再返回给客户端最后才断开连接这样一个完整的请求就是这样的了。我们可以看到一个请求完全由worker进程来处理而且只在一个worker进程中处理。多线程模型 VS 多进程模型这是个问题那么nginx采用这种进程模型有什么好处呢当然好处肯定会很多了。首先对于每个worker进程来说独立的进程不需要加锁所以省掉了锁带来的开销同时在编程以及问题查找时也会方便很多。其次采用独立的进程可以让互相之间不会影响一个进程退出后其它进程还在工作服务不会中断master进程则很快启动新的worker进程。当然worker进程的异常退出肯定是程序有bug了异常退出会导致当前worker上的所有请求失败不过不会影响到所有请求所以降低了风险。当然好处还有很多大家可以慢慢体会。上面讲了很多关于nginx的进程模型接下来我们来看看nginx是如何处理事件的。有人可能要问了nginx采用多worker的方式来处理请求每个worker里面只有一个主线程那能够处理的并发数很有限啊多少个worker就能处理多少个并发何来高并发呢非也这就是nginx的高明之处nginx采用了异步非阻塞的方式来处理请求也就是说nginx是可以同时处理成千上万个请求的。想想apache的常用工作方式(apache也有异步非阻塞版本但因其与自带某些模块冲突所以不常用)每个请求会独占一个工作线程当并发数上到几千时就同时有几千的线程在处理请求了。这对操作系统来说是个不小的挑战线程带来的内存占用非常大线程的上下文切换带来的cpu开销很大自然性能就上不去了而这些开销完全是没有意义的。同步阻塞 VS 异步非阻塞为什么nginx可以采用异步非阻塞的方式来处理呢或者异步非阻塞到底是怎么回事呢我们先回到原点看看一个请求的完整过程。首先请求过来要建立连接然后再接收数据接收数据后再发送数据。具体到系统底层就是读写事件而当读写事件没有准备好时必然不可操作如果不用非阻塞的方式来调用那就得阻塞调用了事件没有准备好那就只能等了等事件准备好了你再继续吧。阻塞调用会进入内核等待cpu就会让出去给别人用了对单线程的worker来说显然不合适当网络事件越多时大家都在等待呢cpu空闲下来没人用cpu利用率自然上不去了更别谈高并发了。好吧你说加进程数这跟apache的线程模型有什么区别注意别增加无谓的上下文切换。所以在nginx里面最忌讳阻塞的系统调用了。不要阻塞那就非阻塞喽。非阻塞就是事件没有准备好马上返回EAGAIN告诉你事件还没准备好呢你慌什么过会再来吧。好吧你过一会再来检查一下事件直到事件准备好了为止在这期间你就可以先去做其它事情然后再来看看事件好了没。虽然不阻塞了但你得不时地过来检查一下事件的状态你可以做更多的事情了但带来的开销也是不小的。所以才会有了异步非阻塞的事件处理机制具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。它们提供了一种机制让你可以同时监控多个事件调用他们是阻塞的但可以设置超时时间在超时时间之内如果有事件准备好了就返回。这种机制正好解决了我们上面的两个问题拿epoll为例(在后面的例子中我们多以epoll为例子以代表这一类函数)当事件没准备好时放到epoll里面事件准备好了我们就去读写当读写返回EAGAIN时我们将它再次加入到epoll里面。这样只要有事件准备好了我们就去处理它只有当所有事件都没准备好时才在epoll里面等着。这样我们就可以并发处理大量的并发了当然这里的并发请求是指未处理完的请求线程只有一个所以同时能处理的请求当然只有一个了只是在请求间进行不断地切换而已切换也是因为异步事件未准备好而主动让出的。这里的切换是没有任何代价你可以理解为循环处理多个准备好的事件事实上就是这样的。与多线程相比这种事件处理方式是有很大的优势的不需要创建线程每个请求占用的内存也很少没有上下文切换事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费(上下文切换)。更多的并发数只是会占用更多的内存而已。 我之前有对连接数进行过测试在24G内存的机器上处理的并发请求数达到过200万。现在的网络服务器基本都采用这种方式这也是nginx性能高效的主要原因。我们之前说过推荐设置worker的个数为cpu的核数在这里就很容易理解了更多的worker数只会导致进程来竞争cpu资源了从而带来不必要的上下文切换。而且nginx为了更好的利用多核特性提供了cpu亲缘性的绑定选项我们可以将某一个进程绑定在某一个核上这样就不会因为进程的切换带来cache的失效。像这种小的优化在nginx中非常常见同时也说明了nginx作者的苦心孤诣。比如nginx在做4个字节的字符串比较时会将4个字符转换成一个int型再作比较以减少cpu的指令数等等。现在知道了nginx为什么会选择这样的进程模型与事件模型了。对于一个基本的web服务器来说事件通常有三种类型网络事件、信号、定时器。从上面的讲解中知道网络事件通过异步非阻塞可以很好的解决掉。如何处理信号与定时器首先信号的处理。对nginx来说有一些特定的信号代表着特定的意义。信号会中断掉程序当前的运行在改变状态后继续执行。如果是系统调用则可能会导致系统调用的失败需要重入。关于信号的处理大家可以学习一些专业书籍这里不多说。对于nginx来说如果nginx正在等待事件(epoll_wait时)如果程序收到信号在信号处理函数处理完后epoll_wait会返回错误然后程序可再次进入epoll_wait调用。另外再来看看定时器。由于epoll_wait等函数在调用的时候是可以设置一个超时时间的所以nginx借助这个超时时间来实现定时器。nginx里面的定时器事件是放在一颗维护定时器的红黑树里面每次在进入epoll_wait前先从该红黑树里面拿到所有定时器事件的最小时间在计算出epoll_wait的超时时间后进入epoll_wait。所以当没有事件产生也没有中断信号时epoll_wait会超时也就是说定时器事件到了。这时nginx会检查所有的超时事件将他们的状态设置为超时然后再去处理网络事件。由此可以看出当我们写nginx代码时在处理网络事件的回调函数时通常做的第一个事情就是判断超时然后再去处理网络事件。更多Nginx相关知识访问Nginx使用教程栏目
