本文包含内容
（１）配置文件
（２）配置文件的语法格式
（３）运行服务需要具备的基础配置
（４）使用http核心模块配置静态web服务器的方法
（５）反向代理服务器
part 1 运行进程的关系
part 2 配置的语法
块配置项：一个块配置项名 和 一对大括号组成
配置项的语法格式
Ａ 如果配置项值中包括语法符号，例如空格符，需要使用单引号或者双引号包括配置项目值，每行配置的结尾需要加上分号
配置项名 配置项值１ 配置项值２ ．．．；
Ｂ 配置项的注释 ＃
Ｃ 配置项的单位
千字节 Ｋ 兆字节 Ｍ
时间单位 ms毫秒 s m分钟 h d天 w周 M月 y年
Ｄ 使用变量
只有少数模块支持变量的使用 ， 使用时候在变量的前面加上 $
注：大部分的模块都必须在nginx.conf中读取某个配置项后，才会在运行时候启用
part 3 基本配置
至少必须加载几个核心模块和一个事件类模块，这些模块运行时候所支持的配置项目称为基本配置－所有其他的模块执行时都依赖的配置项
Ａ 用于调试进程和定位问题的配置项
ａ 是否以守护进程方式运行ｎｇｉｎｘ
默认是daemon on;
守护进程表示脱离终端并且在后台运行的进程
ｂ 是否以master/worker方式工作
默认是master_process on;
是以一个master进程管理多个worker进程的方式运行
ｃ error日志的设置
ｅｒｒｏｒ日志是定位nginx问题的最佳工具，可以根据需求设置ｅｒｒｏｒ日志的路径和级别
默认的路径是 error_log logs/error.log error;
默认情况下是/logs/error.log文件，需要讲文件放在一个磁盘空间足够大的位置
关闭日志文件的唯一方式：将log路径设置为/dev/null
level 是日志的输出级别，取值范围是
debug info notice warn error crit alert emerg 从左到右依次增大
当设定为一个级别时候，大于或者等于该级别的日志都会被输出到日志文件中
注意：如果日志级别设定到debug,必须在configure 时候加入--with-debug配置项
ｄ 是否处理几个特殊的调试点
用于帮助用户跟踪调试，
如果设置为debug_points stop ,nginx的代码执行到调试点后，会发出SIGSTOP信号，用于调试；如果设置为debug_points abort,会产生一个coredump 文件，通常不使用此选项
ｅ 仅对指定的客户端输出debug级别的日志
这个配置项属于事件类配置，需要放在events{...}
举例：
events {
debug_connection 192.168.1.1;
}
仅仅来自192.168.1.1的请求才会输出debug级别的日志，其他请求仍然使用error_log中配置的日志级别，上面配置对于修复bug很有用，特别是高并发请求下，会发生的问题
ｆ 限制coredump 核心转储文件的大小
当进程发生错误或者收到信号而终止时候，系统会将进程执行时候的内存内容写入一个文件，ｃｏｒｅ文件，作为调试用－核心转储core dumps
当nginx进程出现一些非法操作时候，导致进程直接被操作系统强制结束时候，会生成核心转储core文件，可以从core文件中获取当时的堆栈和寄存器信息，帮助定位
worker_rlimit_core size;
可以限制core文件的大小，有效帮助用户定位问题
ｇ 指定coredump 文件生成目录
working_directory path;
ｗｏｒｋｅｒ进程的工作目录，设置coredump文件所放置的目录，协助定位问题
Ｂ 正常运行的配置项
ａ 定义环境变量 env VAR|VAR=VALUE
举例： env TESTPATH = /tmp/;
用户直接设置操作系统上的环境变量
ｂ 配置其他的配置文件
include /path/file
举例：
include mime.types;
include vhost/*.conf;
可以将其他的配置文件通过include配置项嵌入到当前的nginx.conf文件中
参数既可以是绝对路径，也可以是相对nginx.conf所在目录的相对路径，参数的值可以是一个明确的文件名，也可以是含有通配符的文件名，可以一次嵌入多个配置文件
ｃ ｐｉｄ文件的路径
默认路径是 pid logs/nginx.pid;
保存master进程ＩＤ的ｐｉｄ文件存放的路径，默认和configure执行的参数所指定的路径是相同的，也可以随时修改，文件直接影响ｎｇｉｎｘ是否可以运行
可以从ｎｇｉｎｘ．ｐｉｄ中直接查看pid,使用sudo kill pid 停止ｎｇｉｎｘ服务
ｄ nginx worker进程运行的用户和用户组
默认是 user nobody nobody;
user 用于设置master进程启动后，fork(生成子进程)出的ｗｏｒｋｅｒ进程运行在哪个用户和用户组下面，如果没有指定groupname ，默认和用户名相同
若是在configure 命令执行时候，使用了参数
--user=username --group=groupname
此时在nginx运行的时候，将使用参数中指定的用户和用户组
ｅ 指定nginx worker进程可以打开的最大文件句柄数
设置一个进程可以打开的最大的文件的句柄数
worker_rlimit_nofile limit;
f 限制信号队列
设置每个用户发往nginx的信号队列的大小，当某个用户的信号队列满了，再发送信号将被丢掉
worker_rlimit_sigpending limit;
C 优化性能的配置项
ａ 进程个数
默认是 work_processes 1;
worker进程的数量直接影响性能，每个worker进程都是单线程的进程，会调用各个模块实现多种多样的功能，如果这些模块确定不会出现阻塞式调用，进程个数等于内核个数，但是如果会出现阻塞式调用，需要配置稍多一些的worker进程
进程少：业务方面致使用户请求大量读取本地磁盘上的静态资源文件，服务器的内存较小，大部分的请求访问静态资源文件必须读取磁盘，不是内存中的磁盘缓存，磁盘Ｉ／Ｏ调用会阻塞ｗｏｒｋｅｒ进程少量时间，导致性能下降
进程多：多ｗｏｒｋｅｒ进程可以充分利用多核系统架构，若是ｗｏｒｋｅｒ进程数量大于内核数量，会增大进程之间切换带来的消耗
ｂ 绑定nginx worker进程到指定的ｃｐｕ内核
举例：如果有四颗ｃｐｕ内核
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
每一个ｗｏｒｋｅｒ进程都是非常繁忙的，如果多个ｗｏｒｋｅｒ进程抢同一个ｃｐｕ，就会出现同步问题，如果每个ｗｏｒｋｅｒ进程独享一个ｃｐｕ，在内核的调度策略中实现了完全的并发
ｃ ＳＳＬ硬件加速
ｄ 系统调用gettimeofday的执行效率
ｅ 进程优先级设置
D 事件类配置项
ａ 是否打开accept 锁
默认是 accept_mutext on;
accept_mutex 是nginx的负载均衡锁，这把锁可以让多个worker 进程轮流的 序列化 和新的用户建立 ｔｃｐ连接
当ｗｏｒｋｅｒ建立的连接数量达到最大连接数的７／８时候，将大大减小ｗｏｒｋｅｒ进程试图建立新的ｔｃｐ连接的机会，实现所有的ｗｏｒｋｅｒ进程上的处理的用户请求的数量尽量接近
ａｃｃｅｐｔ锁默认是打开的，如果关闭，建立ｔｃｐ连接的耗时将会更短，但ｗｏｒｋｅｒ进程之间的负载将会非常不均衡，因此不建议关闭它
ｂ lock文件的路径
默认路径是 lock_file logs/nginx.lock;
ａｃｃｅｐｔ锁可能需要ｌｏｃｋ文件，如果ａｃｃｅｐｔ锁关闭，ｌｏｃｋ_file配置完全不生效，如果打开了accept锁，由于元素导致ｎｇｉｎｘ不支持原子锁，这时候才会用文件锁实现ａｃｃｅｐｔ锁，ｌｏｃｋ文件才会生效
ｃ 使用accept锁后到真正建立连接之间的延迟时间
在使用accept锁后，同一时间只有一个ｗｏｒｋｅｒ进程可以取到ａｃｃｅｐｔ锁，如果取不到会立刻返回，至少再等定义时间间隔后才能再次试图取锁
举例：
accept_mutex_delay 500ms;
ｄ 批量建立新的连接
默认是 multi_accept off;
当事件模型通知有新的连接时候，尽可能对本次调度中的客户端发起的所有ｔｃｐ请求都建立连接
ｅ 选择事件模型
默认是 ｎｇｉｎｘ会自动使用最适合的事件模型
可供选择的事件驱动模型有 poll select epoll 三种，epoll 是性能最高的一种
ｆ 每个ｗｏｒｋｅｒ的最大连接数
worker_connections number;
定义每个进程可以同事处理的最大连接数
