这里是纯粹的IT知识分享频道，关注知识，创造价值。

本期内容让你知道NGINX的基本框架。

最近工作的需要，顺便整理了NGINX的基本框架，供大家学习使用。

1.传统网络应用模型

传统基于进程或线程的处理并发连接的模型一般都会使用单独的进程或线程处理每个连接，并且会在网络或输入/输出（I/O）操作上造成一定的阻塞。

根据应用程序的不同，它在内存和 CPU 消耗方面可能非常低效。因为产生一个单独的进程或线程需要准备一个新的运行时环境，包括分配堆和堆栈内存，以及创建一个新的执行上下文。

额外的CPU时间也花费在创建这些项目上，这最终会由于线程在过度上下文切换时抖动而导致性能不佳。所有这些复杂性都在 Apache 等较旧的 Web 服务器架构中表现出来。

这是提供一组丰富的普遍适用的功能和服务器资源的优化使用之间的权衡。

2.NGINX模型

从一开始，nginx 就是作为一个专门的工具来实现更高的性能、密度和服务器资源的经济使用，同时支持网站的动态增长，因此它遵循了不同的模型。

它实际上受到各种操作系统中基于事件的高级机制的持续开发的启发。最终，是一个模块化的、事件驱动的、异步的、单线程的、非阻塞的架构成为了 nginx 程序代码的基础。

nginx 大量使用多路复用和事件通知，并将特定任务专用于单独的进程。 连接在有限数量的称为工作线程（worker）的单线程进程中的高效运行循环中进行处理。

在每个工作线程（worker）中，nginx每秒可以处理数千个并发连接和请求。

如前所述，nginx 不会为每个连接生成一个进程或线程。

相反，工作进程接受来自共享“侦听”套接字的新请求，并在每个工作进程内执行高效的运行循环，以处理每个工作进程数以千计的连接。

在 nginx 中没有专门的仲裁或分配连接到工作人员； 这项工作是由操作系统内核机制完成的。

启动时，nginx会创建一组初始的侦听套接字。然后worker在处理HTTP请求和响应时，不断地接受、读取和写入套接字。

3.基于模块化思想的代码结构

nginx的工作线程（worker）代码包括核心模块和功能模块。

nginx的核心负责维护紧密的运行循环，并在请求处理的每个阶段执行功能模块代码的适当部分。

功能模块构成了大部分的表示层和应用层功能，同时模块读取和写入网络和存储、转换内容、进行出站过滤、应用服务器端包含操作并在代理激活时将请求传递给上游服务器。

nginx 的模块化架构通常允许开发人员在不修改 nginx 核心的情况下扩展 Web 服务器功能集。

nginx 模块的形式略有不同，即核心模块、事件模块、阶段处理程序、协议、变量处理程序、过滤器、上游和负载均衡器。

在处理与接受、处理和管理网络连接和内容检索相关的各种操作时，nginx在基于Linux、Solaris和BSD的操作系统（如 kqueue、epoll和event ports）的平台上，

使用了操作系统系统提供的事件通知机制和大量磁盘 I/O 性能增强功能。

下图展示了nginx架构的高级视图：

4.工作线程模型详述

run-loop是nginx worker代码中最复杂的部分。 它包括全面的内部调用，并在很大程度上依赖于异步任务处理的思想。

异步操作是通过模块化、事件通知、大量使用回调函数和微调定时器来实现的。 总的来说，关键原则是尽可能不阻塞。

nginx 仍然可以阻塞的唯一情况是当工作进程的磁盘存储性能不足时。

因为nginx不会为每个连接创建一个进程或线程，所以在绝大多数情况下，内存使用非常保守且非常高效。nginx也节省了CPU周期，因为进程或线程没有持续的创建-销毁模式。

nginx所做的是检查网络和存储的状态，初始化新连接，将它们添加到运行循环，并异步处理直到完成，此时连接被释放并从运行循环中删除。

结合系统调用（syscall)的谨慎使用和支持接口（如pool和slab memory allocators）的准确实现，即使在极端工作负载下，nginx 通常也能实现中等到低的CPU使用率。

因为 nginx 派生出多个 worker 来处理连接，所以它可以很好地跨多个CPU核心进行扩展。

通常，为每个内核分配一个单独的工作线程(worker)可以充分利用多核架构，并防止线程抖动和锁定。同时没有资源匮乏，资源控制机制在单线程工作进程中被隔离。

更重要的是，此模型还允许跨物理存储设备实现更大的可扩展性，促进更多的磁盘利用率并避免磁盘 I/O 阻塞。

因此，服务器资源得到更有效的利用，工作负载由多个worker分担。

对于某些磁盘使用和 CPU 负载模式，应调整 nginx worker 的数量。这里的规则有些基础，系统管理员应该为他们的工作负载尝试一些配置。

一般建议可能如下：

如果负载模式是 CPU 密集型的——例如，处理大量 TCP/IP、执行 SSL 或压缩，nginx worker 的数量应该与 CPU 内核的数量相匹配；

如果负载主要受磁盘 I/O 限制——例如，从存储中提供不同的内容集，或大量代理——nginx worker的数量可能是核心数量的一倍半到两倍，

一些工程师改为根据单个存储单元的数量来选择 worker 的数量，尽管这种方法的效率取决于磁盘存储的类型和配置。

对于磁盘I/O阻塞的问题，存在许多机制和配置文件指令来缓解此类磁盘 I/O 阻塞情况。

最值得注意的是，sendfile 和 AIO 等选项的组合通常会为磁盘性能产生很大的空间。

应根据数据集、nginx 可用内存量和底层存储架构来规划 nginx 安装。

5.nginx 进程角色

nginx 在内存中运行多个进程； 有一个主进程和多个工作进程。 还有一些特殊用途的进程，特别是缓存加载器和缓存管理器。

在 nginx 1.x 版本中，所有进程都是单线程的。

主进程以 root 用户身份运行。 缓存加载器、缓存管理器和worker程序作为非特权用户运行。

所有进程主要使用共享内存机制进行进程间通信。

5.1 主进程负责以下任务：

a)读取和验证配置

b)创建、绑定和关闭套接字

c)启动、终止和维护配置数量的工作进程

d)在不中断服务的情况下重新配置

e)控制不间断的二进制升级（启动新的二进制文件并在必要时回滚）

f)重新打开日志文件

g)编译嵌入式 Perl 脚本

5.2 worker进程负责一下任务：

a)接受、处理和处理来自客户端的连接，

b)提供反向代理

c)过滤功能，

d)完成 nginx 能够完成的几乎所有其他工作。

关于监控 nginx 实例的行为，系统管理员应该关注 workers，因为它们是反映 Web 服务器实际日常操作的进程。

5.3缓存加载进程负责以下任务：

a)负责检查磁盘缓存项并使用缓存元数据填充 nginx 的内存数据库。

b)缓存加载器准备nginx实例来处理已经存储在磁盘上专门分配的目录结构中的文件。

它遍历目录，检查缓存内容元数据，更新共享内存中的相关条目

c)在一切干净并准备好使用时退出。

5.4缓存管理器进程负责以下任务

a)主要负责缓存过期和失效。

它在 nginx 正常运行期间保留在内存中，并在出现故障时由主进程重新启动。

6.NGINX缓存

nginx 中的缓存以文件系统上的树形分层数据存储的形式实现。

缓存键是可配置的，并且可以使用不同的特定于请求的参数来控制进入缓存的内容。缓存键和缓存元数据存储在共享内存段中，缓存加载程序、缓存管理器和工作程序可以访问这些内存段。

目前没有任何文件的内存缓存，除了操作系统的虚拟文件系统机制暗示的优化。

每个缓存的响应都放在文件系统上的不同文件中。层次结构（级别和命名细节）通过 nginx 配置指令控制。将响应写入缓存目录结构时，文件的路径和名称源自代理 URL 的 MD5 散列。

将内容放入缓存的过程如下：

当 nginx 从上游服务器读取响应时，内容首先被写入缓存目录结构之外的临时文件。

当 nginx 完成处理请求时，它会重命名临时文件并将其移动到缓存目录。

如果用于代理的临时文件目录在另一个文件系统上，文件将被复制，因此建议将临时目录和缓存目录都放在同一个文件系统上。

当需要明确清除文件时，从缓存目录结构中删除文件也是非常安全的。

nginx 有第三方扩展，可以远程控制缓存内容，并且计划进行更多工作以将此功能集成到主要发行版中。

Okay，感谢你的阅读，恭喜你。想必您已经知道了NGINX的基本框架了，时间关系，关于NGINX的其他的方面的内容，后续慢慢介绍。

你的关注和阅读将会成为原创的动力。Please，Stay tuned.