Nginx中的模块分类及常见核心模块

1. Nginx 模块分类

Nginx模块可分为:

1. 核心模块
   Nginx 服务器正常运行必不可少的模块，提供错误日志记录 、配置文件解析 、事件
   驱动机制 、进程管理等核心功能
2. 标准HTTP模块
   提供 HTTP 协议解析相关的功能，比如： 端口配置 、 网页编码设置 、 HTTP响应
   头设置 等等
3. 可选HTTP模块
   主要用于扩展标准的 HTTP 功能，让 Nginx 能处理一些特殊的服务，比如： Flash
   多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
4. 邮件服务模块
   实现反向代理功能,包括TCP协议代理
5. 第三方模块
   是为了扩展 Nginx 服务器应用，完成开发者自定义功能，比如： Json 支持、 Lua 支持等
   

2. Nginx核心模块

2.1 user

作用:
进程运行使用的用户和组
示例:

user www www; 

Syntax:	user user [group];
Default:	
user nobody nobody;
Context:	main
Defines user and group credentials used by worker processes. If group is omitted, a group whose name equals that of user is used.

2.2 pid

作用:
指定存储nginx主进程号的文件路径
示例:

pid logs/nginx.pid; 

Syntax:	pid file;
Default:	
pid logs/nginx.pid;
Context:	main
Defines a file that will store the process ID of the main process.

2.3 include

作用:
指明包含进来的其他配置文件
示例:

include vs/*.conf;

Syntax:	include file | mask;
Default:	—
Context:	any
Includes another file, or files matching the specified mask, into configuration. Included files should consist of syntactically correct directives and blocks.

Usage example:

include mime.types;
include vhosts/*.conf;

2.4 worker_processes

作用:
worker进程的数量，应小于等于cpu核心数，auto为当前主机cpu核心数
范例:

worker_processes 4;

Syntax:	worker_processes number | auto;
Default:	
worker_processes 1;
Context:	main
Defines the number of worker processes.

The optimal value depends on many factors including (but not limited to) the number of CPU cores, the number of hard disk drives that store data, and load pattern. When one is in doubt, setting it to the number of available CPU cores would be a good start (the value “auto” will try to autodetect it).

The auto parameter is supported starting from versions 1.3.8 and 1.2.5.

2.5 worker_cpu_affinity

作用:
配置CPU亲和,将worker进程与通过cpumask与指定cpu绑定,减少切换造成的CPU时间损耗.
范例:

worker_cpu_affinity 0001 0010 0100 1000;

Syntax:	worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
Default:	—
Context:	main
Binds worker processes to the sets of CPUs. Each CPU set is represented by a bitmask of allowed CPUs. There should be a separate set defined for each of the worker processes. By default, worker processes are not bound to any specific CPUs.

For example,

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;
binds each worker process to a separate CPU, while

worker_processes    2;
worker_cpu_affinity 0101 1010;
binds the first worker process to CPU0/CPU2, and the second worker process to CPU1/CPU3. The second example is suitable for hyper-threading.

The special value auto (1.9.10) allows binding worker processes automatically to available CPUs:

worker_processes auto;
worker_cpu_affinity auto;
The optional mask parameter can be used to limit the CPUs available for automatic binding:

worker_cpu_affinity auto 01010101;
The directive is only available on FreeBSD and Linux.

2.6 worker_priority

作用:
指定worker进程的nice值，范围[-20,20]
范例:

worker_priority -10;

Syntax:	worker_priority number;
Default:	
worker_priority 0;
Context:	main
Defines the scheduling priority for worker processes like it is done by the nice command: a negative number means higher priority. Allowed range normally varies from -20 to 20.

Example:

worker_priority -10;

2.7 worker_rlimit_nofile

作用:
指定worker进程能够打开的最大文件数
范例:

worker_rlimite_nofile 2000;

Syntax:	worker_rlimit_nofile number;
Default:	—
Context:	main
Changes the limit on the maximum number of open files (RLIMIT_NOFILE) for worker processes. Used to increase the limit without restarting the main process.

2.8 daemon

作用:
是否已守护进程方式运行Nginx
范例:

daemon on

Syntax:	daemon on | off;
Default:	
daemon on;
Context:	main
Determines whether nginx should become a daemon. Mainly used during development.

2.9 master_process

作用:
是否已master-worker模型运行Nginx。该指令适用于 nginx 开发人员。
范例:

master_process on;

Syntax:	master_process on | off;
Default:	
master_process on;
Context:	main
Determines whether worker processes are started. This directive is intended for nginx developers.

2.10 error_log

作用:
配置错误日志路径和日志文件名
范例:

error_log logs/error.log error;

Syntax:	error_log file [level];
Default:	
error_log logs/error.log error;
Context:	main, http, mail, stream, server, location
Configures logging. Several logs can be specified on the same configuration level (1.5.2). If on the main configuration level writing a log to a file is not explicitly defined, the default file will be used.

The first parameter defines a file that will store the log. The special value stderr selects the standard error file. Logging to syslog can be configured by specifying the “syslog:” prefix. Logging to a cyclic memory buffer can be configured by specifying the “memory:” prefix and buffer size, and is generally used for debugging (1.7.11).

The second parameter determines the level of logging, and can be one of the following: debug, info, notice, warn, error, crit, alert, or emerg. Log levels above are listed in the order of increasing severity. Setting a certain log level will cause all messages of the specified and more severe log levels to be logged. For example, the default level error will cause error, crit, alert, and emerg messages to be logged. If this parameter is omitted then error is used.

For debug logging to work, nginx needs to be built with --with-debug, see “A debugging log”.
The directive can be specified on the stream level starting from version 1.7.11, and on the mail level starting from version 1.9.0.

2.11 events

作用:
事件驱动相关配置
范例:

events {                                  #事件驱动相关配置
    use epoll;                            #指明并发连接请求的处理方式
    worker_connections 2048;              #每个worker进程能够打开的最大并发连接数
    #accpet mutex on | off;               
    #处理新连接的方式，on意味着由每个worker轮流处理新请求，off意味着每个新请求到达都会通知所有worker进程
}

Syntax:	events { ... }
Default:	—
Context:	main
Provides the configuration file context in which the directives that affect connection processing are specified.