Nginx学习笔记（五）：浅析Nginx原理

一、Nginx的模块

Nginx由内核和模块组成。Nginx本身所做的工作并不是很多，当接收到一个HTTP请求时，Nginx通过查找配置文件将请求映射到一个loation lock，然后根据location中所配置的各个指令启动不同的模块去完成工作。所以，在Nginx中模块才是真正的打工仔。在前面的多个例子中不难发现，通常一个location中的指令会涉及到一个handler模块和多个filter模块。handler模块负责处理请求，filter模块则对相应内容进行处理。一般用户根据自己的需要开发的模块都属于第三方模块。因此，Nginx的模块从结构上分为核心模块、基础模块和第三方模块，具体介绍如下：

• 核心模块：HTTP[模块、EVENT模块和MATL模块。
• 基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块，
• 第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。

Nginx的模块从功能上分为如下三类：

• Handlers（处理器模块）。此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
• Filters （过滤器模块）。此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
• Proxies （代理类模块）。此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。

二、Nginx的进程模型

Nginx默认采用多进程工作方式。当Nginx启动后，会运行一个master进程和多个worker进程。其中master充不仅充当整个进程组与用户的交互接口，同时对进程进行监护；管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。worker用来处理基本的网络事件，worker之间是平等的，他们共同竞争来处理来自客户端的请求。

Nginx的进程模型如图所示：

 

启动Nginx，执行命令：ps-ef | grep nginx

可以看到：在Linux系统中有两个进程，一个为master，一个为worker。master作为管理员不参与任何工作，只负责给多个worker分配不同的任务（worker一般有多个）。记得楚汉传奇里韩信拜将时底下大将不服，于是他就提问：你们谁能统领百万大军，调度有方？

众人默不作答，此时有人反问韩信：那么你如何做到？

韩信答曰：我只需要10个听我命令的将军，就能统领百万大军。我是大将军，我不是领兵的，我是领将的。查天文、观地势；通晓兵法、多谋善断；言必行，行必果，赏罚分明，令行禁止，这才是我该做的。

假如刘邦说要出兵鹏程，大将军韩信接到任务后给众人分发任务，樊哙当先锋官，曹参当押粮官，周勃当中军护卫。这里韩信就是master，其他的手下大将如樊哙、周勃、曹参等，就是worker进程。每名大将手下的百夫长、千夫长就是client。他们的共同目标就是进攻彭城。‘

1、惊群现象

（1）惊群现象的产生

在创建master进程时，首先需要建立监听的socket（listenfd），然后从master进程中fork()出多个worker进程，这样的话每个worker进程多可以监听用户请求的socket。一般来说，当一个连接进来后，所有Worker都会收到通知，但是只有一个进程可以接受这个连接请求，其它的都失败，这就是所谓的惊群现象。

（2）解决方案

Nginx提供了一个accept_mutex（互斥锁），通过这把锁使得在同一时刻只会有一个进程在accpet连接。

（3）互斥锁的工作原理

先打开accept_mutex选项，只有获得了accept_mutex的进程才会去添加accept事件。nginx使用一个叫ngx_accept_disabled的变量来控制是否去竞争accept_mutex锁。ngx_accept_disabled = nginx单进程的所有连接总数 / 8 -空闲连接数量，当ngx_accept_disabled大于0时，不会去尝试获取accept_mutex锁，ngx_accept_disable越大，让出的机会就越多，这样其它进程获取锁的机会也就越大。不去accept，每个worker进程的连接数就控制下来了，其它进程的连接池就会得到利用，这样，nginx就控制了多进程间连接的平衡。

2、worker进程

每个worker进程都有一个独立的连接池，连接池的大小是worker_connections。这里的连接池里面保存的其实不是真实的连接，它只是一个worker_connections大小的一个ngx_connection_t结构的数组。并且nginx会通过一个链表free_connections来保存所有的空闲ngx_connection_t，每次获取一个连接时，就从空闲连接链表中获取一个，用完后，再放回空闲连接链表里面。

一个Nginx能建立的最大连接数，是worker_connections * worker_processes。当然，这里说的是最大连接数，对于HTTP请求本地资源来说，能够支持的最大并发数量是worker_connections * worker_processes，而如果是HTTP作为反向代理来说，最大并发数量应该是worker_connections * worker_processes/2。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。

在Nginx中，一个worker仅包含一个线程，每个worker可以并行处理数千个的并发连接和请求。当一个请求过来时，仅由一个worker进程处理并且只能由这个worker进程完全处理。也就是说当worker进程争抢成功后，就全权负责该请求的处理。Nginx内部的accept_mutex保证了一个时刻只能被一个worker进程获取。当一个worker进程在accept这个连接之后，就开始读取请求、解析请求、处理请求，产生数据后再返回给客户端，最后再断开连接，这就是一个完整的请求过程。

Nginx采用IO多路复用机制，每个worker进程只有一个主线程，通过异步非阻塞的方式来处理请求，并且能将CPU的性能发挥到极致。因此，worker的数量和服务器CPU的数量相等是最为适宜的。

3、几点说明

（1）nginx.conf配置文件信息修改

前面几个案例中我们在修改完nginx.conf文件之后都使用到了nginx -s reload的方式来重新加载nginx。

• 如果配置文件语法有问题，则会提示配置错误，并不会影响到请求的处理。
• 如果配置文件没问题，则执行完reload之后，并不会立刻影响到worker进程，master会等待worker的进程连接请求处理完毕之后杀死该worker进程，然后重新生成一个worker进程，这样worker进程就以新的配置启动了。即：老的连接用老的配置，新的连接用新的配置，当重新加载配置文件时不会中断正在处理的请求。

（2）一个master和多个worker的好处

• 可以使用nginx -s reload进行热部署。
• 每个worker都是独立的进程，如果其中一个worker出现问题，其他的worker都是独立运行的，会继续争抢任务，实现客户端的请求过程，而不会造成服务中断。

三、Nginx的处理流程

Nginx的IO通常使用epoll，epoll函数使用了I/O复用模型。与I/O阻塞模型比较，I/O复用模型的优势在于可以同时等待多个（而不只是一个）套接字描述符就绪。Nginx的epoll工作流程如下：

• 首先，master 进程接受到信号（如nginx -s reload）后启动，读取配置文件，建好需要listen的socket后，然后再fork出多个woker进程，这样每个work进程都可以去accept这个socket
• 当一个client连接到来时，所有accept的work进程都会受到通知，但只有一个进程可以accept成功，其它的则会accept失败，Nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接，从而解决惊群问题
• 当一个worker进程accept这个连接后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完成的请求就结束了
• 一个worker进程可以同时处理多个请求，每个worker进程只有一个主线程，而是采用异步非阻塞的方式来处理并发请求。比如同时有多个http request的时候，worker主线程与第一条request建议连接将其处理转发给下游fast cgi后，并不会挂起等待，而是立马处理下一条，可以理解轮询处理。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换），更多的并发数，只是会占用更多的内存而已。因此nginx 是非常适合处理高并发请求的。

四、Nginx处理HTTP请求流程

http请求是典型的请求-响应类型的的网络协议。http是文件协议，所以我们在分析请求行与请求头，以及输出响应行与响应头，往往是一行一行的进行处理。通常在一个连接建立好后，读取一行数据，分析出请求行中包含的method、uri、http_version信息。然后再一行一行处理请求头，并根据请求method与请求头的信息来决定是否有请求体以及请求体的长度，然后再去读取请求体。得到请求后，我们处理请求产生需要输出的数据，然后再生成响应行，响应头以及响应体。在将响应发送给客户端之后，一个完整的请求就处理完了。

流程图如下：

参考文章：https://www.jb51.net/article/197072.htm