在运行时控制Nginx进程

理解Nginx处理流量的进程以及如何在运行时控制它们。

这个部分描述了Nginx在运行时启动的进程以及如何控制它们。

Master和Worker进程

Nginx有一个master进程和一个或多个worker进程，如果缓存是开启的，那么cache loader进程和cache manager进程也会在启动时运行。

master进程的主要工作就是读取和计算配置文件，以及维护worker进程。

worker进程进行实际的请求处理。Nginx依赖OS独立的机制来在worker进程间分发请求。worker进程的数量在nginx.conf中由worker_processes指令定义，它可以被设置成一个固定的数，也可以配置成由可用CPU内核数量来自动调整。

控制Nginx

你可以stop然后restartNginx来重新加载你的配置，或者向master进程发送一个信号。你可以通过运行nginx命令，指定一个-s参数来发送这一信号。

nginx -s <SIGNAL>

<SIGNAL>可以是下列中的一个：

• quit – 优雅地关闭（SIGQUIT信号）
• reload – 重新加载配置文件（SIGHUP信号）
• reopen – 重新打开日志文件（SIGUSR1信号）
• stop – 立即关闭信号（或者快速关闭，SIGTERM信号）

你也可以通过kill工具来直接发送一个信号到master进程，master进程的进程ID默认情况下写入到nginx.pid文件中，你可以在/usr/local/nginx/logs或/var/run目录下找到它。

更多的高级信号的信息（比如执行一个实时二进制升级（live binary upgrades）），请移步nginx.org网站上的Controlling nginx。

创建Nginx Plus和Nginx配置文件

理解Nginx或Nginx Plus配置文件中的基本元素，包括指令（directives）和上下文（context）。

Nginx和NginxPlus和其它服务很像的一点是，它们都使用一个特定格式的基于文本的配置文件。默认情况下，这个文件被命名为nginx.conf。对于Nginx Plus来说，它被放在/etc/nginx目录下。（对于Nginx Open Source，它们被放置的目录依赖于你安装Nginx时使用的包管理器和操作系统。典型的位置是/usr/local/nginx/conf，/etc/nginx或/usr/local/etc/nginx）。

指令

配置文件中包含指令和它们的参数。简单指令由一个分号结尾，其它的指令作为将一些相关指令组合到一起的容器，其它的指令被放在花括号中（{}），它们经常被称作块。下面是一些简单指令的示例：

user             nobody;
error_log        logs/error.log notice;
worker_processes 1;

特定功能的配置文件（Feature-Specific Configuration Files）

为了使配置文件更加易于维护，我们推荐你将它们分开放置到特定于功能的文件中，并将它们放到/etc/nginx/conf.d目录下。在主配置文件中通过使用include指令来引用这些特定功能的文件中的内容。

include conf.d/http;
include conf.d/stream;
include conf.d/exchange-enhanced;

上下文（Contexts）

一些被称作上下文的顶级指令，它们将应用在不同流量类型的指令组合在一起：

• events – 一般连接处理
• http – HTTP流量
• mail – Mail流量
• stream – TCP和UDP流量

被放置在这些上下文之外的指令，我们称它们在main上下文中。

虚拟服务器

在每一个流量处理上下文中，你可以包含一个或多个server块来定义虚拟服务器来控制请求的处理。而在server上下文中你可以使用的指令取决于当前的流量类型。

对于HTTP流量（http上下文），每一个server指令控制着对于在特定域名或IP地址下的资源的处理。而server上下文中的一个或多个location上下文定义者如何处理特定的URI集合。

对于mail和TCP/UDP流量（mail和stream上下文），server指令控制着在特定TCP端口或Unix套接字上到达的流量进程。

一个具有多个上下文的配置示例

user nobody; # 一个在main上下文中的指令

events {
    # 这里可以填写连接处理的配置
}

http {
    # 这里可以填写特定于HTTP的配置，它会影响所有的（本上下文中）虚拟Server

    server {
        # 这里可以填写对于HTTP虚拟服务器1的配置

        location /one {
            # 这里可以填写用于处理具有由`/one`开始的URI的请求
        }

        location /two {
            # 这里可以填写用于处理具有由`/two`开始的URI的请求
        }
    }

    server {
        # 这里可以填写对于HTTP虚拟服务器2的配置
    }

}

stream {
    # 这里可以填写特定于 TCP/UDP的配置 这会影响所有虚拟server
    server {
        # TCP虚拟服务器1的配置
    }
}

继承性

通常来说，一个子上下文——被包含在另一个上下文（它的父上下文）中的上下文——会继承在父级中的指令的设置。一些指令可以出现在多种上下文中，在一些特定情况下，你可以通过在子上下文中包含指令来重写从父上下文中继承的设置。这里是一个例子——proxy_set_header

重新加载配置

如果你想让配置文件的修改产生效果，它必须被重新加载。你可以重启nginx进程或者发送一个reload信号来更新配置而不用打断当前正在处理的请求。详见Controlling NGINX Processes at Runtime。