浅谈Nginx服务器的内部核心架构设计

Nginx?是一个免费的，开源的，高性能的?HTTP?服务器和反向代理商，以及?IMAP?/?POP3代理商服务器。?Nginx?以其高性能，稳固性，丰富的功能，简单的配置和低资源消耗而闻名。?Nginx?是一个?Web?服务器，也可以使用作反向代理商，负载均衡器和?HTTP缓存。

很多高知名度的网站都用?Nginx?，如：?Netflix?，?GitHub?，?SoundCloud?，?MaxCDN?等。

替换高清大图

正文

1. Nginx的整体架构

1.1. 主进程

Nginx?启动时，会生成两种类型的进程*，一个是主进程（?master?），一个（?windows版本的目前只有一个）或者多个工作进程（?worker?）。主进程并不解决网络请求，主要负责调度工作进程，也就是图示的?3?项：加载配置、启动工作进程及非停更新。所以，?Nginx?启动以后，查看操作系统的进程列表，我们就能看到至少有两个Nginx?进程。

1.2. 工作进程

服务器实际解决网络请求及响应的是工作进程（?worker?），在类?unix?系统上，?Nginx可以配置多个worker?，而每个?worker进程都可以同时解决数以千计的网络请求。

1.3. 板块化设计

Nginx?的?worker?进程，包括核心和功能性板块，核心板块负责维持一个运行循环（?run-loop?），执行网络请求解决的不同阶段的板块功能，比方：网络读写、存储读写、内容传输、外出过滤，以及将请求发往上游服务器等。而其代码的板块化设计，也使得我们可以根据需要对功能板块进行适当的选择和修改，编译成具备特定功能的服务器。

1.4. 事件驱动模型

基于异步及非阻塞的事件驱动模型，可以说是?Nginx?得以取得高并发、高性能的关键因素，同时也得益于对?Linux?、?Solaris?及类?BSD?等操作系统内核中事件通知及?I/O性能加强功能的采使用，如?kqueue?、?epoll?及?event ports?。

1.5. 代理商（proxy）设计

代理商设计，可以说是?Nginx?深入骨髓的设计，无论是对于?HTTP?，还是对于?FastCGI?、?Memcache?、?Redis?等的网络请求或者响应，本质上都采使用了代理商机制。所以，?Nginx?天生就是高性能的代理商服务器。

2. Nginx的板块化设计

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

2.1. 核心板块

核心板块是?Nginx?服务器正常运行必不可少的板块，提供错误日志记录、配置文件解析、事件驱动机制、进程管理等核心功能。

2.2. 标准HTTP板块

标准?HTTP?板块提供?HTTP?协议解析相关的功能，比方：端口配置、网页编码设置、?HTTP响应头设置等等。

2.3. 可选HTTP板块

可选?HTTP?板块主要使用于扩展标准的?HTTP?功能，让?Nginx?能解决少量特殊的服务，比方：?Flash多媒体传输、解析?GeoIP?请求、网络传输压缩、安全协议SSL?支持等。

2.4. 邮件服务板块

邮件服务板块主要使用于支持?Nginx?的邮件服务，包括对?POP3?协议、?IMAP?协议和?SMTP协议的支持。

2.5. 第三方板块

第三方板块是为了扩展?Nginx?服务器应使用，完成开发者自己设置功能，比方：?Json?支持、?Lua?支持等。

3. Nginx的请求方式解决

Nginx?是一个高性能的?Web?服务器，能够同时解决大量的并发请求。它结合多进程机制和异步机制，异步机制用的是异步非阻塞方式，接下来就给大家详情一下?Nginx?的多线程机制和异步非阻塞机制。

3.1. 多进程机制

服务器每当收到一个用户端时，就有服务器主进程（?master process?）生成一个子进程（?worker process?）出来和用户端建立连接进行交互，直到连接断开，该子进程就结束了。

用进程的好处是各个进程之间相互独立，不需要加锁，减少了用锁对性能造成影响，同时降低编程的复杂度，降低开发成本。其次，采使用独立的进程，可以让进程互相之间不会影响，假如一个进程发生异常退出时，其它进程正常工作，?master?进程则很快启动新的?worker?进程，确保服务不会中断，从而将风险降到最低。

缺点是操作系统生成一个子进程需要进行内存复制等操作，在资源和时间上会产生肯定的开销。当有大量请求时，会导致系统性能下降。

3.2. 异步非阻塞机制

每个工作进程用异步非阻塞方式，可以解决多个用户端请求。

当某个工作进程接收到用户端的请求以后，调使用?IO?进行解决，假如不能立即得到结果，就去解决其余请求（即为非阻塞）；而用户端在此期间也无需等待响应，可以去解决其余事情（即为异步）。

当?IO?返回时，就会通知此工作进程；该进程得到通知，暂时挂起当前解决的事务去响应用户端请求。

4. Nginx事件驱动模型

在?Nginx?的异步非阻塞机制中，工作进程在调使用?IO?后，就去解决其余的请求，当?IO?调使用返回后，会通知该工作进程。对于这样的系统调使用，主要用?Nginx?服务器的事件驱动模型来实现。

如上图所示，?Nginx?的事件驱动模型由事件收集器、事件发送器和事件解决器三部分基本单元组成。

事件收集器：负责收集?worker?进程的各种?IO?请求；

事件发送器：负责将?IO?事件发送到事件解决器；

事件解决器：负责各种事件的响应工作。

事件发送器将每个请求放入一个待解决事件列表，用非阻塞?I/O?方式调使用事件解决器来解决该请求。其解决方式称为“多路 IO 复使用方法”，常见的包括以下三种：?select?模型、?poll模型、?epoll?模型。

5. Nginx进程解决模型

Nginx?服务器用?master/worker多进程模式。多线程启动和执行的流程如下：

主程序?Master process?启动后，通过一个?for?循环来接收和解决外部信号；

主进程通过?fork()?函数产生?worker子进程，每个子进程执行一个?for?循环来实现?Nginx?服务器对事件的接收和解决。

一般推荐?worker进程数与?CPU内核数一致，这样一来不存在大量的子进程生成和管理任务，避免了进程之间竞争CPU资源和进程切换的开销。而且?Nginx?为了更好的利使用多核特性，提供了?CPU亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会由于进程的切换带来?Cache?的失效。

对于每个请求，有且只有一个工作进程对其解决。首先，每个?worker?进程都是从?master进程?fork?过来。在?master?进程里面，先建立好需要?listen?的?socket（listenfd）?之后，而后再?fork?出多个?worker?进程。

所有?worker?进程的?listenfd?会在新连接到来时变得可读，为保证只有一个进程解决该连接，所有?worker?进程在注册?listenfd读事件前抢占accept_mutex?，抢到互斥锁的那个进程注册listenfd读事件，在读事件里调使用?accept?接受该连接。

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

在?Nginx?服务器的运行过程中，主进程和工作进程需要进程交互。交互依赖于?Socket?实现的管道来实现。

5.1. 主进程与工作进程交互

这条管道与普通的管道不同，它是由主进程指向工作进程的单向管道，包含主进程向工作进程发出的指令，工作进程ID?等；同时主进程与外界通过信号通信；每个子进程具有接收信号，并解决相应的事件的能力。

5.2. 工作进程与工作进程交互

这种交互是和主进程-工作进程交互是基本一致的，但是会通过主进程间接完成。工作进程之间是相互隔离的，所以当工作进程?W1?需要向工作进程?W2?发指令时，首先找到?W2?的进程ID?，而后将正确的指令写入指向?W2?的通道。?W2?收到信号采取相应的措施。

小结

通过这篇文章，我们对?Nginx?服务器的整体架构有了一个整体的认识。包括其板块化的设计、多进程和异步非阻塞的请求解决方式、事件驱动模型等。通过这些理论知识，才能更好地领悟?Nginx?的设计思想。对于我们学习?Nginx?来说有很大的帮助。