Nginx常用模块一

Nginx 由内核和模块组成。Nginx本身做的工作实际很少，当它接到一个HTTP 请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作， 因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。用户根据自己的需要所开发的模块都属于第三方模块。 正是有了这么多模块的支撑，Nginx的功能才会如此强大。

Nginx的模块从结构上分为核心模块、基础模块和第三方模块：

  • 核心模块： HTTP 模块、 EVENT 模块和 MAIL 模块；
  • 基础模块： HTTP Access 模块、 HTTP FastCGI 模块、 HTTP Proxy 模块和 HTTP Rewrite 模块；
  • 第三方模块： HTTP Upstream Request Hash 模块、 Notice 模块和 HTTP Access Key 模块。

Nginx的模块从功能上分为如下三类：

  • Handlers（处理器模块）：此类模块直接处理请求，并进行输出内容和修改headers信息等操作。 Handlers处理器模块一般只能有一个；
  • Filters（过滤器模块）：此类模块主要对其他处理器模块输出的内容进行修改操作，最后Nginx输出；
  • Proxies（代理类模块）：此类模块是Nginx的HTTP Upstream之类的模块， 这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。

1、核心功能 （Core functionality）

worker_processes

Syntax:	worker_processes number | auto;
Default: worker_processes 1;
Context: main

最佳值取决于许多因素，包括（但不限于）CPU核心的数量、存储数据的硬盘驱动器的数量和负载模式。一般将其设置为可用CPU核心的数量。

worker_cpu_affinity

Syntax:	worker_cpu_affinity cpumask ...;
        worker_cpu_affinity auto [cpumask];
Default: —
Context: main

将工作进程绑定到CPU集。每个CPU集由允许的CPU的位掩码表示。应该为每个工作进程定义一个单独的集合。默认情况下，工作进程不绑定到任何特定的CPU。该指令仅在FreeBSD和Linux上可用。例如：

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;
#将每个工作进程绑定到单独的CPU

worker_processes    2;
worker_cpu_affinity 0101 1010;
#将第一个工作进程绑定到CPU0/CPU2,将第二个工作进程绑定到CPU1/CPU3,这个例子适用于超线程情况

worker_processes auto;
worker_cpu_affinity auto;
#1.9.10版本后允许将工作进程自动绑定到可用的CPU

worker_priority

Syntax:	worker_priority number;
Default: worker_priority 0;
Context: main

为工作进程定义调度优先级，就像由nice命令执行一样：负数表示优先级更高。允许范围通常在### 20到20之间

worker_rlimit_nofile

Syntax:	worker_rlimit_nofile number;
Default: —
Context: main

更改工作进程的最大打开文件数（rlimit_nofile）限制,默认较小，生产环境一般需要调高，如：65535

worker_connection

Syntax:	worker_connections number;
Default: worker_connections 512;
Context: events

设置能够被一个工作进程打开的最大并发连接数。应该记住，这个数字包括所有连接（例如，与代理服务器的连接等），而不仅仅是与客户机的连接。另一个需要考虑的问题是，实际同时连接的数量不能超过打开文件的最大数量的当前限制（ worker_rlimit_nofile.）。

use

Syntax:	use method;
Default: —
Context: events

指定要使用的连接处理方法。通常不需要显式地指定它，因为nginx默认使用最有效的方法。如：use epoll;

accept_mutex

Syntax:	accept_mutex on | off;
Default: accept_mutex off;
Context: events

如果启用:on，工作进程将轮流接受新的连接。否则，将通知所有工作进程有关新连接的信息，但只有一个进程可以获得连接。如果新连接的数量较低，则某些工作进程可能会浪费系统资源。在版本1.11.3之前，默认值为on。