Nginx （二）Nginx的配置

1. 运行中的Nginx间的关系

  Nginx通过一个master管理多个worker进程，一般情况下， worker进程的数量与服务器上的CPU核心数相等。 每一个worker进程都是繁忙的， 它们在真正地提供互联网服务， master进程则很“清闲”， 只负责监控管理worker进程。 worker进程之间通过共享内存、 原子操作等一些进程间通信机制来实现负载均衡等功能。

Nginx是支持单进程（master进程） 提供服务的， 那么为什么产品环境下要按照masterworker方式配置同时启动多个进程呢？ 这样做的好处主要有以下两点：
·由于master进程不会对用户请求提供服务， 只用于管理真正提供服务的worker进程，所以master进程可以是唯一的， 它仅专注于自己的纯管理工作， 为管理员提供命令行服务，包括诸如启动服务、 停止服务、 重载配置文件、 平滑升级程序等。 master进程需要拥有较大的权限， 例如， 通常会利用root用户启动master进程。 worker进程的权限要小于或等于master进程， 这样master进程才可以完全地管理worker进程。 当任意一个worker进程出现错误从而导致coredump时， master进程会立刻启动新的worker进程继续服务。
·多个worker进程处理互联网请求不但可以提高服务的健壮性（一个worker进程出错后， 其他worker进程仍然可以正常提供服务） ， 最重要的是， 这样可以充分利用现在常见的SMP多核架构， 从而实现微观上真正的多核并发处理。 因此， 用一个进程（master进程） 来处理互联网请求肯定是不合适的。 另外， 为什么要把worker进程数量设置得与CPU核心数量一致呢？ 这正是Nginx与Apache服务器的不同之处。 在Apache上每个进程在一个时刻只处理一个请求， 因此， 如果希望Web服务器拥有并发处理的请求数更多， 就要把Apache的进程或线程数设置得更多， 通常会达到一台服务器拥有几百个工作进程， 这样大量的进程间切换将带来无谓的系统资源消耗。 而Nginx则不然， 一个worker进程可以同时处理的请求数只受限于内存大小， 而且在架构设计上， 不同的worker进程之间处理并发请求时几乎没有同步锁的限制， worker进程通常不会进入睡眠状态， 因此， 当Nginx上的进程数与CPU核心数相等时（最好每一个worker进程都绑定特定的CPU核心） ， 进程间切换的代价是最小的。

2. Nginx配置的通用语法

（1）块配置

events {...
	
}
http {
	upstream backend {
		server 127.0.0.1:8080;
				
	}
	gzip on;
	server {
		location /webstatic {
				gzip off;
		}
	}
}

上面代码段中的events、 http、 server、 location、 upstream等都是块配置项， 块配置项之后是否如“location/webstatic{...}”那样在后面加上参数， 取决于解析这个块配置项的模块， 不能一概而论， 但块配置项一定会用大括号把一系列所属的配置项全包含进来， 表示大括号内的配置项同时生效。 所有的事件类配置都要在events块中， http、 server等配置也遵循这个规定。

块配置项可以嵌套。 内层块直接继承外层块， 例如， 上例中， server块里的任意配置都是基于http块里的已有配置的。 当内外层块中的配置发生冲突时， 究竟是以内层块还是外层块的配置为准， 取决于解析这个配置项的模块， 例如， 上例在http模块中已经打开了“gzip on;”， 但其下的location/webstatic又把gzip关闭了： gzip off;， 最终， 在/webstatic的处理模块中， gzip模块是按照gzip off来处理请求的。
（2）配置项的语法格式

配置项名

    配置项值
        
        1. 配置项值
        2.
        ...
    

首先， 在行首的是配置项名， 这些配置项名必须是Nginx的某一个模块想要处理的， 否则Nginx会认为配置文件出现了非法的配置项名。 配置项名输入结束后， 将以空格作为分隔符。其次是配置项值， 它可以是数字或字符串（当然也包括正则表达式） 。 针对一个配置项， 既可以只有一个值， 也可以包含多个值， 配置项值之间仍然由空格符来分隔。 当然， 一个配置项对应的值究竟有多少个， 取决于解析这个配置项的模块。 我们必须根据某个Nginx模块对一个配置项的约定来更改配置项。

最后， 每行配置的结尾需要加上分号。
注意 如果配置项值中包括语法符号， 比如空格符， 那么需要使用单引号或双引号括住配置项值， 否则Nginx会报语法错误。 例如：
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' ;

（3）配置项的注释

注意 如果配置项值中包括语法符号， 比如空格符， 那么需要使用单引号或双引号括住配置项值， 否则Nginx会报语法错误。 

（4）配置项的单位

大部分模块遵循一些通用的规定， 如指定空间大小时不用每次都定义到字节、 指定时间时不用精确到毫秒。
当指定空间大小时， 可以使用的单位包括：
·K或者k千字节（KiloByte， KB） 。
·M或者m兆字节（MegaByte， MB） 。

gzip_buffers 48k;
client_max_body_size 64M;

当指定时间时， 可以使用的单位包括：
·ms（毫秒） ， s（秒） ， m（分钟） ， h（小时） ， d（天） ， w（周， 包含7天） ，M（月， 包含30天） ， y（年， 包含365天）。

expires 10y;
proxy_read_timeout 600;
client_body_timeout 2m;

注意 配置项后的值究竟是否可以使用这些单位， 取决于解析该配置项的模块。 如果这个模块使用了Nginx框架提供的相应解析配置项方法， 那么配置项值才可以携带单位。

（5）在配置中使用变量

些模块允许在配置项中使用变量， 如在日志记录部分， 具体示例如下。
 

log_format main '$remote_addr - $remote_user [$time_local] "$request"'
                    '$status $bytes_send "$http_referer" '
                    '"$http_user_agent" "http_x_forwarded_for" '
    

其中， remote_addr是一个变量， 使用它的时候前面要加上$符号。 需要注意的是， 这种变量只有少数模块支持， 并不是通用的。
许多模块在解析请求时都会提供多个变量（如本章后面提到的http core module、 http proxy module、 http upstream module等） ， 以使其他模块的配置可以即时使用。 我们在学习某个模块提供的配置说明时可以关注它是否提供变量。

提示 在执行configure命令时， 我们已经把许多模块编译进Nginx中， 但是否启用这些模块， 一般取决于配置文件中相应的配置项。 换句话说， 每个Nginx模块都有自己感兴趣的配置项， 大部分模块都必须在nginx.conf中读取某个配置项后才会在运行时启用。 例如， 只有当配置http{...}这个配置项时， ngx_http_module模块才会在Nginx中启用， 其他依赖ngx_http_module的模块也才能正常使用。
 

3. Nginx服务的基本配置