Nginx入门
简介
Nginx由俄罗斯人Igor Sysoev编写的一款高性能的HTTP和反向代理服务器。能够选择高效的epoll、kqueue、eventport作为网络 IO模型，支持高连接并发情况下内存、CPU等系统资源消耗都非常低。
淘宝Tengine: 基于nginx，添加了很多高级功能和特性。
优点
- 支持高并发
- 支持热部署
- 稳定性高
- 耗内存少
特性
- 异步非阻塞，事件驱动
- 单线程多进程，绑定CPU，减少上下文切换
- 模块化，官方、第三方模块多，易扩充
- 静态编译，不能动态加载(1.9版本已支持动态加载)
- 支持热部署：升级Nginx，更新配置
Nginx信号控制
支持以下几种信号
- TERM, INT快速关闭
- QUIT 从容关闭
- HUP 平滑重启，重新加载配置文件
- USR1 重新打开日志文件，在切割日志时用途较大
- USR2 平滑升级可执行程序
- WINCH 从容关闭工作进程
几种命令
启动Nginx
nginx [-c filename] [-p prefix] [-g directives]
会创建一个master进程和多个worker进程停止Nginx
nginx -s stop：立即停止
nginx -s quit：从容停止，先关闭监听socket，但处理完已连接socket再停重新加载配置文件
nginx -s reload
master进程重新读取配置文件、重新打开日志文件
master进程fork创建新的worker进程，worker进程马上处理客户端请求
master进程给所有老的worker进程发NGX_CMD_QUIT命令
收到NGX_CMD_QUIT命令的老的worker进程会退出
Nginx平滑升级
当需要将正在运行中的Nginx升级、添加、删除服务器模块时，可以在不中断服务的情况下，使用新版本、重编译的nginx可执行程序替换旧版本的可执行程序。步骤如下：
1 . 使用新的可执行程序替换旧的可执行程序，对于编译安装的nginx，可以将新版本编译安装到旧版本nginx的安装路径中，替换之前，最好备份一下旧的可执行文件
2 . 发送以下指令：
kill -USR2 旧版本nginx主进程号
旧版本nginx主进行将重命名它的.pid文件为.oldbin， 然后执行新版本nginx可执行程序，依次启动新的主进程和新的工作进程
新、旧版本的nginx实例会同时运行，共同处理输入的请求。
3 . kill -WINCH 旧版本nginx主进程号： 从容关闭旧的工作进程，此时会通知旧worker进程从容退出，但旧master进程不退出且没关闭监听socket， 这时有老master进程、新master进程、新worker进程
4 . 一段时间后，旧工作进程处理了所有已连接的请求后退出，仅由新的工作进程来处理输入的请求。
5 . 如果新版本没有问题：kill -QUIT 旧master进程PID：给旧master进程发QUIT信号， 这时旧master会退出，只有新master和新worker进程，升级成功
6 . 如果需要恢复到旧版本：
A) kill -HUP 旧的主进程号： nginx将在不重载配置文件 的情况下启动它的工作进程，相当于回滚，旧master进程会fork出旧版本的worker进程，然后kill -QUIT 新master进程PID：停止新版本的Nginx
B) kill -TERM 新master进程PID：会立即停止新版Nginx(包括master和worker)， 旧master会自动fork出老版本的worker进程
新的主进程退出后，旧的主进程会移除.oldbin后缀，恢复为它的.pid文件，一切就都恢复至升级之前了。如果尝试升级成功，而你也希望保留新的服务器时，可发送QUIT信号给旧的主进程，使其退出只留下新的服务器运行。
Nginx进程管理
Nginx由一个master进程和多个worker进程组成 ， master用于管理、监控worker进程，worker进程处理客户端请求， master和每个worker之间有unix socket连接，用于给worker发送命令 如果worker进程异常退出，master会重新fork一个worker进程
一般情况下，work进程的数量与服务器CPU数相等，Nginx还可以设置每个work进程绑定特定的CPU。
配置格式
nginx.conf文件的配置格式如下：
注意几点：
- 由简单配置项和块配置组成
- 块配置项由块配置项名和一对大括号组成
- 可以嵌套，内层块直接继承外层块
- 内外配置项冲突时，以解析些配置项的模块为准。
- 简单配置项格式 ： 配置项名 配置项1 配置项2 ….. ；
- 配置项可以是数据或字符串多个配置项以空格分隔
- 每行结尾必须要加上分号;
- 如果配置项中包括语法符号，如空格符，需要用单引号或双引号括住配置项值
- 允许使用变量值 ，但需要加$符号
- 配置项单位可以为： K或者k (kb)、M或者m(MB)、ms（毫秒）、s（秒）、m（分钟）、h（小时）、d（天）、w（周）、M（月）、y（年），如expires 10y; 配置项后的值是否可以使用单位，取决于解析该配置项的模块 。
nginx服务的基本配置
调试用
(1) daemon on|off;
是否以守护进程方式运行Nginx，默认为on
daemon是脱离终端运行于后台的进程。
(2) master_process on|off;
是否以master/worker方式工作，默认为master_process on。 如果选择off，则不会fork出work子进程，而是用master进程自身来处理请求。
(3) error_log /path/file level;
error日志的设置，默认为error_log logs/error.log error， 日志级别可以为： debug , info , notice, warn, error, crit, alert, emerg
(4) debug_points [stop | abort]
是否处理几个特殊的调试点，nginx在一些关键的错误逻辑中设置了调试点，如果设置debug_points为stop，nginx代码执行到这些调试点时会发出SIGSTOP信号以用于调试。如果设置为abort，则会产生一个coredump文件，可以使用gdb来查看nginx当时的各种信息。
通常不会使用这个配置项。
(5) debug_connection [IP |CIDR]
仅对指定的客户端输出debug级别的日志。 属于事件类配置，必须放在events {…. }中才有效。值可以为IP地址或者 CIDR地址 。
注： 使用debug_connection时，需要确保在执行configure时已经加入了–with-debug参数，否则不会生效。
(6) work_rlimit_core size
限制coredump核心转储文件大小 。
(7) working_directory path;
指定coredump文件生成目录 。
负载均衡基本配置
负载均衡即，通过配置的策略，将请求平均的转发到每一台上游服务器上。
格式
upstream name {
[ip_hash]
server address [weight=num] [max_fails=num] [fail_timeout=time] [back] [down];
server …
server …
}
例子
upstream backend {
server 192.168.174.136:1111 weight=2;
server 192.168.174.136:2222;
server 192.168.174.136:3333;
}
其中：
- address 为上游服务器的名字，可以为域名、IP地址端口、UNIX句柄等。
- weight=num: 设置权重，默认为1
- max_fails=num: 与fail_timeout配合使用，指在fail_timeout时间段内，如果向当前的上游服务器转发失败次数超过num，则认为在当前的fail_timeout时间内上游服务器不可用，max_fails默认为1，如果设置为0，表明不检查失败次数。
- fail_timeout=time: 表示该时间段转发失败多少次就认为服务器不可用，用于优化反向代理功能。与上游服务器建立连接的超时时间、读取上游服务器的响应超时时间无关。默认为10秒
- down: 表示所在的上游服务器永久下线，只在使用ip_hash配置项才有用
- backup: 使用ip_hash时无效，表示所在的上游服务器只是备份服务器，只有在所有非备份服务器都失效后，才会向所在的上游服务器转发请求。
ip_hash: 根据客户端的IP地址计算出key，将key按照upstrem集群里的上游服务器数量进行取模，以取模后的结果把请求转发到相应的上游服务器中。以此确保同一个客户端的请求只会转发到指定的上游服务器中。
ip_hash与weigth（权重）不可同时使用。如果upstream集群中有一台上游服务器暂时不可用，不能直接删除该配置，添加down标识即可，确保转发策略的一致性，如：
upstream backend{
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com
}
如果需要将负载均衡时一些信息记录到access_log日志中，在定义日志格式时可以使用负载均衡功能提供的变量
| 变量名 | 意义 |
|---|---|
| $upstream_addr | 处理请求的上游服务器地址 |
| $upstream_cache_status | 表示是否命中缓存，取值范围：MISS, EXPIRED,UPDATING,STALE,HIT |
| $upstream_status | 上游服务器返回的响应中的http响应码 |
| $upstream_response_time | 上游服务器的响应时间，精度为毫秒 |
| upstream_http_HEADER | HTTP头部，如upstream_http_host |
Nginx反向代理服务器
反向代理： 代理服务器接收Internet上的连接请求，然后将请求转发给内部网络中的上游服务器，从上游服务器上得到的结果返回给Internet上请求的客户端。
Nginx作为反向代理 服务器，可以直接向客户端提供静态文件服务，复杂的、动态的内容则必须为Apache、Tomcat等服务器来处理。
Nginx与Squid等其他反向代理 服务器相比，有自己的特点：
- 客户端发来的请求(包括完整HTTP包体)，先缓存在自己的服务器，再转发给上游服务器；Squid等代理 服务器则采用一边接收客户端请求，一边转发到上游服务器的方式
- Nginx这种方式，缺点延长了请求处理的时间，优点降低了上游服务器的负载，由于一个请求可能需要很久，如果即时向上游服务器转发，上游服务器必须要长时间维持这个连接，采用先缓存后转发的方式，由于是nginx与上游服务器之间是内网，转发过程会很快。一定程序上降低了上游服务器的压力
反向代理服务器基本配置
格式 ：
proxy_pass URL
配置块： location , if
此配置可以将当前请求反向代理到URL参数指定的服务器上。URL可以是主机名或IP:port形式，也可以是UNIX句柄形式
例子：proxy_pass http://localhost:8000/uri/ ;
其他 配置
(1) proxy_pass
语法 ： proxy_pass URL ;
配置块：location , if
将请求反向代理至URL上,如
server
{
location /
{
proxy_pass http://backend;
}
}
(2) proxy_method
语法 ： proxy_method method;
配置块： http, server, location
转发时的协议方法名，如果设置为POST，则客户端发来的GET请求在转发时也会改为POST，如proxy_method POST;
(3) proxy_hide_header
语法： proxy_hide_header header ;
配置块： http, server, location
指定哪些HTTP头段不转发，如 proxy_hide_header Cache-Control;
(4) proxy_pass_header
语法： proxy_pass_header header ;
配置块： http, server, location
与proxy_hide_header相反，指定哪些禁止转发的header设置为允许转发，如proxy_pass_header X-Accel-Redirect;
(5) proxy_pass_request_body
语法： proxy_pass_request_body on|off ;
配置块： http, server, location
默认为on,是否向上游服务器发送HTTP包体部分
(6) proxy_pass_request_headers
语法： proxy_pass_request_headers on|off ;
配置块： http, server, location
默认为on,是否转发HTTP头
(7) proxy_redirect
语法： proxy_redirect [default | off | redirect | replacement] ;
配置块： http, server, location
默认为default, 当上游响应为302重定向时，修改其location ，如proxy_redirect http://localhost:8000/two/ http://frontend/one/;
(8) proxy_next-upstream
语法： proxy_next-upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 |http_504 | http_404 | off] ;
配置块： http, server, location
默认为proxy_next-upstream error timeout,表示当向一台上游服务器转发请求出现错误时，继续换一台上游服务器处理这个请求。
参考：张宴 《实战Nginx：取代Apache的高性能web服务器》
《深入理解Nginx模块开发与架构解析》