转载自:http://wiki.jikexueyuan.com/project/nginx/nginx-framework.html

Nginx 在启动后,在 unix 系统中会以 daemon 的方式在后台运行,后台进程包含一个 master 进程和多个 worker 进程。我们也可以让 Nginx 在前台运行,并且通过配置让 Nginx 取消 master 进程,从而可以使 Nginx 以单进程方式运行。很显然,生产环境下我们肯定不会这么做,所以关闭后台模式一般是用来调试用的。

Nginx 是以多进程的方式来工作的:

master 进程主要用来管理 worker 进程,包含:

  1. 接收来自外界的信号
  2. 向各 worker 进程发送信号
  3. 监控 worker 进程的运行状态
  4. 当 worker 进程退出后(异常情况下),会自动重新启动新的 worker 进程。

基本的网络事件,则是放在 worker 进程中来处理了。多个 worker 进程之间同等竞争来自客户端的请求,各进程互相之间是独立的。一个请求,只可能在一个 worker 进程中处理,一个 worker 进程,不可能处理其它进程的请求。worker 进程的个数一般设置与机器cpu核数一致,这与 Nginx 的进程模型以及事件处理模型是分不开的。Nginx 的进程模型,可以由下图来表示:

在 Nginx 启动后,如果我们要操作 Nginx,要怎么做呢?master 进程会接收来自外界发来的信号。所以我们要控制 Nginx,只需要通过 kill 向 master 进程发送信号就行了。比如kill -HUP pid,告诉 Nginx,从容地重启 Nginx,因此服务是不中断的。

master 进程在接收到 HUP 信号后是怎么做的呢?首先 master 进程在接到信号后,会先重新加载配置文件,然后再启动新的 worker 进程,并向所有老的 worker 进程发送信号,告诉他们可以光荣退休了。新的 worker 在启动后,就开始接收新的请求,而老的 worker 在收到来自 master 的信号后,就不再接收新的请求,并且在当前进程中的所有未处理完的请求处理完成后,再退出。当然,直接给 master 进程发送信号,这是比较老的操作方式,Nginx 在 0.8 版本之后 ./nginx -s reload,就是来重启 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 进程中处理。

Nginx 采用这种进程模型有什么好处呢?

  1. 对于每个 worker 进程来说,独立的进程,不需要加锁,所以省掉了锁带来的开销,
  2. 在编程以及问题查找时,也会方便很多。
  3. 采用独立的进程,可以让互相之间不会影响,一个进程退出后,其它进程还在工作,服务不会中断,master 进程则很快启动新的 worker 进程。当然,worker 进程的异常退出,肯定是程序有 bug 了,异常退出,会导致当前 worker 上的所有请求失败,不过不会影响到所有请求,所以降低了风险。

Nginx 是如何处理事件的?

有人可能要问了,Nginx 采用多 worker 的方式来处理请求,每个 worker 里面只有一个主线程,多少个 worker 就能处理多少个并发,何来高并发呢?

Nginx 采用了异步非阻塞的方式来处理请求,也就是说,Nginx 是可以同时处理成千上万个请求的。想想 apache 的常用工作方式(apache 也有异步非阻塞版本,但因其与自带某些模块冲突,所以不常用),每个请求会独占一个工作线程,当并发数上到几千时,就同时有几千的线程在处理请求了。这对操作系统来说,是个不小的挑战,线程带来的内存占用非常大,线程的上下文切换带来的 cpu 开销很大,自然性能就上不去了,而这些开销完全是没有意义的。

为什么 Nginx 可以采用异步非阻塞的方式来处理呢,或者异步非阻塞到底是怎么回事呢?我们先回到原点,看看一个请求的完整过程。

  1. 发起请求
  2. 建立连接
  3. 接收数据
  4. 发送数据

阻塞IO: 具体到系统底层,就是读写事件,而当读写事件没有准备好时,必然不可操作,那就只能等了。阻塞调用会进入内核等待,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 的事件处理模型:

    while (true) {
for t in run_tasks:
t.handler();
update_time(&now);
timeout = ETERNITY;
for t in wait_tasks: /* sorted already */
if (t.time <= now) {
t.timeout_handler();
} else {
timeout = t.time - now;
break;
}
nevents = poll_function(events, timeout);
for i in nevents:
task t;
if (events[i].type == READ) {
t.handler = read_handler;
} else { /* events[i].type == WRITE */
t.handler = write_handler;
}
run_tasks_add(t);
}

好,本节我们讲了进程模型,事件模型,包括网络事件,信号,定时器事件。

初探 Nginx 架构的更多相关文章

  1. 转:初探nginx架构(一)

    来源:http://tengine.taobao.org/book/chapter_02.html 众所周知,nginx性能高,而nginx的高性能与其架构是分不开的.那么nginx究竟是怎么样的呢? ...

  2. 转:初探nginx架构(二)

    From:http://tengine.taobao.org/book/chapter_02.html 上篇文章讲了很多关于nginx的进程模型,接下来,我们来看看nginx的是如何处理事件的. 有人 ...

  3. 初探Nginx架构

    参考链接:http://tengine.taobao.org/book/chapter_02.html nginx在启动后,在unix系统中会以daemon的方式在后台运行,后台进程包含一个maste ...

  4. Nginx学习笔记(一) Nginx架构

    Nginx架构 Nginx全程是什么? Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器. ...

  5. Nginx架构的企业级应用

    Nginx架构的企业级应用 ==================================================== 实现HA高可用集群 实现LB负载均衡集群 Nginx实现反向代理 ...

  6. [转载] 深入 nginx 架构

    原文: http://www.cnbeta.com/articles/402709.htm 了解 nginx 架构帮助我们学习如何开发高性能 web 服务. 为了更好地理解设计,你需要了解NGINX是 ...

  7. nginx架构与基础概念

    1       Nginx架构 Nginx 高性能,与其架构有关. Nginx架构: nginx运行时,在unix系统中以daemon形式在后台运行,后台进程包含一个master进程和多个worker ...

  8. Nginx从入门到放弃-第5章 Nginx架构篇

    5-1 Nginx常见问题_架构篇介绍 5-2 Nginx常见问题_多个server中虚拟主机读取的优先级 5-3 Nginx常见问题_多个location匹配的优先级1 5-4 Nginx常见问题_ ...

  9. 初探Nginx服务器的整体架构

    高度模块化的设计是 Nginx 的架构基础.Nginx 服务器被分解为多个模块,每个模块就是一个功能模块,只负责自身的功能,模块之间严格遵循“高内聚,低耦合”的原则. 核心模块 核心模块是 Nginx ...

随机推荐

  1. Dubbo之生产者

    环境步骤: 安装Zookeepr启动 创建Maven项目搭建生产者和消费者 安装DubboAdmin平台,实现监控 Dubbo注册中心采用的是Zookeeper.为什么采用Zookeeper呢? Zo ...

  2. linux 下监控进程流量情况命令 NetHogs

    摘自: http://www.cnblogs.com/kerrycode/p/4748970.html NetHogs介绍 NetHogs是一款开源.免费的,终端下的网络流量监控工具,它可监控Linu ...

  3. Android USB 开发详解

    Android USB 开发详解 先附上 Android USB 官方文档 Android通过两种模式支持各种 USB 外设和 Android USB 附件(实现Android附件协议的硬件):USB ...

  4. ASM磁盘组mount一例

    环境信息: oracle10gRAC  +  RHEL5.8 问题现象: db1服务器crs服务正常,ASM的data磁盘组处于dismount状态.db2集群服务正常. SQL> select ...

  5. 搭建LoadRunner中的场景(三)场景的执行计划

    所谓场景操作,包括初始化用户组.启动用户组各用户以及停止虚拟用户的全过程.依据设置不同,执行过程中可以最多有5类操作,分别是启动用户组(start group).初始化(Initialize).启动虚 ...

  6. 「NOIP2006」「LuoguP1064」 金明的预算方案(分组背包

    题目描述 金明今天很开心,家里购置的新房就要领钥匙了,新房里有一间金明自己专用的很宽敞的房间.更让他高兴的是,妈妈昨天对他说:“你的房间需要购买哪些物品,怎么布置,你说了算,只要不超过NNN元钱就行” ...

  7. bzoj 2626: JZPFAR k-D树

    题目大意: 平面上n个点,每次给出一个点,求这个点的k远点 题解: 什么叫做k远点呢... 1 2 3 4 5中5是第一远,4是第二远... 看来我语文学的不好 那么我们直接上k-D Tree求k邻近 ...

  8. vue实现图片的上传和删除

    目录 1 UI库使用ElementUI 2 后端使用Express + formidable模块 1 UI库使用ElementUI 安装ElementUI $ npm install --save-d ...

  9. C# FileStream 按大小分段读取文本内容

    该例子首先在C盘根目录创建一个名为'file1.txt'的文本文件. 然后再运行该例子.. 完整代码如下: 引入命名空间: [csharp] view plain copy print? using  ...

  10. static_cast” : 无法从“void (__thiscall CMainFrame::* )(NMTOOLBARA *,LRESULT *)”转换为“void (__thiscall CCmdTarget::* )(NMHDR *,LRESULT

    static_cast” : 无法从“void (__thiscall CMainFrame::* )(NMTOOLBARA *,LRESULT *)”转换为“void (__thiscall CCm ...