Nginx工作进程模型
浏览数：21 /
时间：2015年06月20日
前面提到过，Nginx不为每个连接派生进程或线程，而是由worker进程通过监听共享套接字接受新请求，并且使用高效的循环来处理数千个连接。Nginx不使用仲裁器或分发器来分发连接，这个工作由操作系统内核机制完成。监听套接字在启动时就完成初始化，worker进程通过这些套接字接受、读取请求和输出响应。
事件处理循环是Nginx worker代码中最复杂的部分，它包含复杂的内部调用，并且严重依赖异步任务处理的思想。异步操作通过模块化、事件通知、大量回调函数以及微调定时器等实现。总的来说，基本原则就是尽可能做到非阻塞。Nginx worker进程唯一会被阻塞的情形是磁盘性能不足。
由于Nginx不为每个连接派生进程或线程，所以内存使用在大多数情况下是很节约并且高效的。同时由于不用频繁的生成和销毁进程或线程，所以Nginx也很节省CPU时间。Nginx所做的就是检查网络和存储的状态，初始化新连接并添加到主循环，异步处理直到请求结束才从主循环中释放并删除。兼具精心设计的系统调用和诸如内存池等支持接口的精确实现，Nginx在极端负载的情况下通常能做到中低CPU使用率。
Nginx派生多个worker进程处理连接，所以能够很好的利用多核CPU。通常一个单独的worker进程使用一个处理器核，这样能完全利用多核体系结构，并且避免线程抖动和锁。在一个单线程的worker进程内部不存在资源匮乏，并且资源控制机制是隔离的。这个模型也允许在物理存储设备之间进行扩展，提高磁盘利用率以避免磁盘I/O导致的阻塞。将工作负载分布到多个worker进程上最终能使服务器资源被更高效的利用。
针对某些磁盘使用和CPU负载的模式，Nginx worker进程数应该进行调整。这里的规则比较基本，系统管理员应根据负载多尝试几种配置。通常推荐：如果负载模式是CPU密集型，例如处理大量TCP/IP协议，使用SSL，或者压缩数据等，Nginx worker进程应该和CPU核心数相匹配；如果是磁盘密集型，例如从存储中提供多种内容服务，或者是大量的代理服务，worker的进程数应该是1.5到2倍的CPU核心数。一些工程师基于独立存储单元的数目来决定worker进程数，虽然这个方法的有效性取决于磁盘存储配置的类型。
Nginx开发者在下个版本中要解决的一个主要问题是怎么避免磁盘I/O引起的阻塞。目前，如果没有足够的存储性能为一个worker进程的磁盘操作提供服务，这个进程就会阻塞在磁盘读写操作上。一些机制和配置指令用于缓解这个磁盘I/O阻塞的场景，最显著的是sendfile和AIO指令，这通常可以降低许多磁盘利用率。应该根据数据集（data set），可用内存数，以及底层存储架构等来规划安装Nginx。
当前的worker模型的另一个问题是对嵌入脚本的支持有限。举例来说，标准的Nginx发布版只支持Perl作为嵌入脚本语言。这个原因很简单：嵌入脚本很可能会在任何操作上阻塞或者异常退出，这两个行为都会导致worker进程挂住而同时影响数千个连接。将脚本更简单，更可靠地嵌入Nginx，并且更适合广泛应用的工作已经列入计划。
Nginx 进程角色
Nginx在内存中运行多个进程，一个master进程和多个worker进程。同时还有一些特殊用途的进程，例如缓存加载和缓存管理进程。在Nginx 1.x版本，所有进程都是单线程的，使用共享内存作为进程间通信机制。Master进程使用root用户权限运行，其他进程使用非特权用户权限运行。
master进程负责下列工作: 读取和校验配置文件；创建、绑定、关闭套接字；启动、终止、维护所配置数目的worker进程；不中断服务刷新配置文件；不中断服务升级程序（启动新程序或在需要时回滚）；重新打开日志文件；编译嵌入Perl脚本；worker进程接受、处理来自客户端的连接；提供反向代理和过滤功能以及其他Nginx所具有的所有功能。由于worker进程是web服务器每日操作的实际执行者，所以对于监控Nginx实例行为，系统管理员应该保持关注worker进程。
缓存加载进程负责检查磁盘上的缓存数据并且在内存中维护缓存元数据的数据库。基本上，缓存加载进程使用特定分配好的目录结构来管理已经存储在磁盘上的文件，为Nginx提供准备，它会遍历目录，检查缓存内容元数据，当所有数据可用时就更新相关的共享内存项。
缓存管理进程主要负责缓存过期和失效。它在Nginx正常工作时常驻内存中，当有异常则由master进程重启。
Nginx缓存简介
Nginx在文件系统上使用分层数据存储实现缓存。缓存主键可配置，并且可使用不同特定请求参数来控制缓存内容。缓存主键和元数据存储在共享内存段中，缓存加载进程、缓存管理进程和worker进程都能访问。目前不支持在内存中缓存文件，但可以用操作系统的虚拟文件系统机制进行优化。每个缓存的响应存储到文件系统上的不同文件，Nginx配置指令控制存储的层级（分几级和命名方式）。如果响应需要缓存到缓存目录，就从URL的MD5哈希值中获取缓存的路径和文件名。
将响应内容缓存到磁盘的过程如下：当Nginx从后端服务器读取响应时，响应内容先写到缓存目录之外的一个临时文件。Nginx完成请求处理后，就将这个临时文件重命名并移到缓存目录。如果用于代理功能的临时目录位于另外一个文件系统，则临时文件会被拷贝一次，所以建议将临时目录和缓存目录放到同一个文件系统上。如果需要清除缓存目录，也可以很安全的删除文件。一些第三方扩展可以远程控制缓存内容，而且整合这些功能到主发布版的工作已经列入计划。
事件处理循环是Nginx worker代码中最复杂的部分，它包含复杂的内部调用，并且严重依赖异步任务处理的思想。异步操作通过模块化、事件通知、大量回调函数以及微调定时器等实现。总的来说，基本原则就是尽可能做到非阻塞。Nginx worker进程唯一会被阻塞的情形是磁盘性能不足。
由于Nginx不为每个连接派生进程或线程，所以内存使用在大多数情况下是很节约并且高效的。同时由于不用频繁的生成和销毁进程或线程，所以Nginx也很节省CPU时间。Nginx所做的就是检查网络和存储的状态，初始化新连接并添加到主循环，异步处理直到请求结束才从主循环中释放并删除。兼具精心设计的系统调用和诸如内存池等支持接口的精确实现，Nginx在极端负载的情况下通常能做到中低CPU使用率。
Nginx派生多个worker进程处理连接，所以能够很好的利用多核CPU。通常一个单独的worker进程使用一个处理器核，这样能完全利用多核体系结构，并且避免线程抖动和锁。在一个单线程的worker进程内部不存在资源匮乏，并且资源控制机制是隔离的。这个模型也允许在物理存储设备之间进行扩展，提高磁盘利用率以避免磁盘I/O导致的阻塞。将工作负载分布到多个worker进程上最终能使服务器资源被更高效的利用。
针对某些磁盘使用和CPU负载的模式，Nginx worker进程数应该进行调整。这里的规则比较基本，系统管理员应根据负载多尝试几种配置。通常推荐：如果负载模式是CPU密集型，例如处理大量TCP/IP协议，使用SSL，或者压缩数据等，Nginx worker进程应该和CPU核心数相匹配；如果是磁盘密集型，例如从存储中提供多种内容服务，或者是大量的代理服务，worker的进程数应该是1.5到2倍的CPU核心数。一些工程师基于独立存储单元的数目来决定worker进程数，虽然这个方法的有效性取决于磁盘存储配置的类型。
Nginx开发者在下个版本中要解决的一个主要问题是怎么避免磁盘I/O引起的阻塞。目前，如果没有足够的存储性能为一个worker进程的磁盘操作提供服务，这个进程就会阻塞在磁盘读写操作上。一些机制和配置指令用于缓解这个磁盘I/O阻塞的场景，最显著的是sendfile和AIO指令，这通常可以降低许多磁盘利用率。应该根据数据集（data set），可用内存数，以及底层存储架构等来规划安装Nginx。
当前的worker模型的另一个问题是对嵌入脚本的支持有限。举例来说，标准的Nginx发布版只支持Perl作为嵌入脚本语言。这个原因很简单：嵌入脚本很可能会在任何操作上阻塞或者异常退出，这两个行为都会导致worker进程挂住而同时影响数千个连接。将脚本更简单，更可靠地嵌入Nginx，并且更适合广泛应用的工作已经列入计划。
Nginx 进程角色
Nginx在内存中运行多个进程，一个master进程和多个worker进程。同时还有一些特殊用途的进程，例如缓存加载和缓存管理进程。在Nginx 1.x版本，所有进程都是单线程的，使用共享内存作为进程间通信机制。Master进程使用root用户权限运行，其他进程使用非特权用户权限运行。
master进程负责下列工作: 读取和校验配置文件；创建、绑定、关闭套接字；启动、终止、维护所配置数目的worker进程；不中断服务刷新配置文件；不中断服务升级程序（启动新程序或在需要时回滚）；重新打开日志文件；编译嵌入Perl脚本；worker进程接受、处理来自客户端的连接；提供反向代理和过滤功能以及其他Nginx所具有的所有功能。由于worker进程是web服务器每日操作的实际执行者，所以对于监控Nginx实例行为，系统管理员应该保持关注worker进程。
缓存加载进程负责检查磁盘上的缓存数据并且在内存中维护缓存元数据的数据库。基本上，缓存加载进程使用特定分配好的目录结构来管理已经存储在磁盘上的文件，为Nginx提供准备，它会遍历目录，检查缓存内容元数据，当所有数据可用时就更新相关的共享内存项。
缓存管理进程主要负责缓存过期和失效。它在Nginx正常工作时常驻内存中，当有异常则由master进程重启。
Nginx缓存简介
Nginx在文件系统上使用分层数据存储实现缓存。缓存主键可配置，并且可使用不同特定请求参数来控制缓存内容。缓存主键和元数据存储在共享内存段中，缓存加载进程、缓存管理进程和worker进程都能访问。目前不支持在内存中缓存文件，但可以用操作系统的虚拟文件系统机制进行优化。每个缓存的响应存储到文件系统上的不同文件，Nginx配置指令控制存储的层级（分几级和命名方式）。如果响应需要缓存到缓存目录，就从URL的MD5哈希值中获取缓存的路径和文件名。
将响应内容缓存到磁盘的过程如下：当Nginx从后端服务器读取响应时，响应内容先写到缓存目录之外的一个临时文件。Nginx完成请求处理后，就将这个临时文件重命名并移到缓存目录。如果用于代理功能的临时目录位于另外一个文件系统，则临时文件会被拷贝一次，所以建议将临时目录和缓存目录放到同一个文件系统上。如果需要清除缓存目录，也可以很安全的删除文件。一些第三方扩展可以远程控制缓存内容，而且整合这些功能到主发布版的工作已经列入计划。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
