nginx配置文件讲解（一）

渡人自渡

　　原文：http://www.ibm.com/developerworks/cn/web/wa-lo-nginx/
　　常用的 Nginx 参数和控制
　　程序运行参数
　　Nginx 安装后只有一个程序文件，本身并不提供各种管理程序，它是使用参数和系统信号机制对 Nginx 进程本身进行控制的。 Nginx 的参数包括有如下几个：
　　-c ：使用指定的配置文件而不是 conf 目录下的 nginx.conf 。
　　-t：测试配置文件是否正确，在运行时需要重新加载配置的时候，此命令非常重要，用来检测所修改的配置文件是否有语法错误。
　　-v：显示 nginx 版本号。
　　-V：显示 nginx 的版本号以及编译环境信息以及编译时的参数。
　　例如我们要测试某个配置文件是否书写正确，我们可以使用以下命令
sbin/nginx – t – c conf/nginx2.conf　　通过信号对 Nginx 进行控制
　　Nginx 支持下表中的信号：
信号名作用描述TERM, INT快速关闭程序，中止当前正在处理的请求QUIT处理完当前请求后，关闭程序HUP重新加载配置，并开启新的工作进程，关闭旧的进程，此操作不会中断请求USR1重新打开日志文件，用于切换日志，例如每天生成一个新的日志文件USR2平滑升级可执行程序WINCH从容关闭工作进程　　有两种方式来通过这些信号去控制 Nginx，第一是通过 logs 目录下的 nginx.pid 查看当前运行的 Nginx 的进程>kill – XXX  来控制 Nginx，其中 XXX 就是上表中列出的信号名。如果您的系统中只有一个 Nginx 进程，那您也可以通过 killall 命令来完成，例如运行 killall – s HUP nginx 来让 Nginx 重新加载配置。
　　配置 Nginx
　　先来看一个实际的配置文件：
user  nobody;# 工作进程的属主　　
worker_processes  4;# 工作进程数，一般与 CPU 核数等同
　　

　　
#error_log  logs/error.log;
　　
#error_log  logs/error.log  notice;
　　
#error_log  logs/error.log  info;
　　

　　
#pid        logs/nginx.pid;
　　

　　
events {
　　
use epoll;#Linux 下性能最好的 event 模式
　　
worker_connections  2048;# 每个工作进程允许最大的同时连接数
　　
}
　　

　　
http {
　　
include       mime.types;
　　
default_type  application/octet-stream;
　　

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

　　
#access_log  off;
　　
access_log  logs/access.log;# 日志文件名
　　

　　
sendfile        on;
　　
#tcp_nopush     on;
　　
tcp_nodelay     on;
　　

　　
keepalive_timeout  65;
　　

　　
include  gzip.conf;
　　

　　
# 集群中的所有后台服务器的配置信息
　　
upstream tomcats {
　　
server 192.168.0.11:8080 weight=10;
　　
server 192.168.0.11:8081 weight=10;
　　
server 192.168.0.12:8080 weight=10;
　　
server 192.168.0.12:8081 weight=10;
　　
server 192.168.0.13:8080 weight=10;
　　
server 192.168.0.13:8081 weight=10;
　　
}
　　

　　
server {
　　
listen       80;#HTTP 的端口
　　
server_name  localhost;
　　

　　
charset utf-8;
　　

　　
#access_log  logs/host.access.log  main;
　　

　　
location ~ ^/NginxStatus/ {
　　
stub_status on; #Nginx 状态监控配置
　　
access_log off;
　　
}
　　

　　
location ~ ^/(WEB-INF)/ {
　　
deny all;
　　
}
　　

　　

　　
location ~ \.(htm|html|asp|php|gif|jpg|jpeg|png|bmp|ico|rar|css|js|
　　
zip|java|jar|txt|flv|swf|mid|doc|ppt|xls|pdf|txt|mp3|wma)$ {
　　
root /opt/webapp;
　　
expires 24h;
　　
}
　　

　　
location / {
　　
proxy_pass http://tomcats;# 反向代理
　　
include proxy.conf;
　　
}
　　

　　
error_page 404 /html/404.html;
　　

　　
# redirect server error pages to the static page /50x.html
　　
#
　　
error_page 502 503 /html/502.html;
　　
error_page 500 504 /50x.html;
　　
location = /50x.html {
　　
root   html;
　　
}
　　
}
　　
}
　　

　　Nginx 监控
　　上面是一个实际网站的配置实例，其中灰色文字为配置说明。上述配置中，首先我们定义了一个 location ~ ^/NginxStatus/，这样通过 http://localhost/NginxStatus/ 就可以监控到 Nginx 的运行信息，显示的内容如下：
Active connections: 70　　
server accepts handled requests
　　
14553819 14553819 19239266
　　
Reading: 0 Writing: 3 Waiting: 67
　　

　　NginxStatus 显示的内容意思如下：

• 　　active connections – 当前 Nginx 正处理的活动连接数。
  
• 　　server accepts handled requests -- 总共处理了 14553819 个连接 , 成功创建 14553819 次握手 ( 证明中间没有失败的 ), 总共处理了 19239266 个请求 ( 平均每次握手处理了 1.3 个数据请求 )。
  
• 　　reading -- nginx 读取到客户端的 Header 信息数。
  
• 　　writing -- nginx 返回给客户端的 Header 信息数。
  
• 　　waiting -- 开启 keep-alive 的情况下，这个值等于 active - (reading + writing)，意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。
  

　　官方此功能的文档如下：

• 　　这个模块能够获取Nginx自上次启动以来的工作状态
  
• 　　此模块非核心模块，需要在编译的时候手动添加编译参数 --with-http_stub_status_module
  
• 　　__配置说明__
  
• 　　location /nginx_status {
  
• 　　: # copied from http://blog.kovyrin.net/2006/04/29/monitoring-nginx-with-rrdtool/
  
• 　　: stub_status on;
  
• 　　: access_log   off;
  
• 　　: allow SOME.IP.ADD.RESS;
  
• 　　: deny all;
  
• 　　}
  
• 　　指令
  
• 　　[#stub_status stub_status]
  
• 　　Template:Anchor
  
• 　　stub_status
  
• 　　语法: stub_status on
  
• 　　默认值: None
  
• 　　作用域: location
  
• 　　创建一个 location 区域启用 stub_status
  
• 　　"stub status" 模块返回的状态信息跟 mathopd's 的状态信息很相似. 返回的状态信息如下：
  
• 　　Active connections: 291
  
• 　　server accepts handled requests
  
• 　　: 16630948 16630948 31070465
  
• 　　Reading: 6 Writing: 179 Waiting: 106
  
• 　　active connections -- 对后端发起的活动连接数
  
• 　　server accepts handled requests -- nginx 总共处理了 16630948 个连接, 成功创建 16630948 次握手 (证明中间没有失败的), 总共处理了 31070465 个请求 (平均每次握手处理了 1.8个数据请求)
  
• 　　reading -- nginx 读取到客户端的Header信息数
  
• 　　writing -- nginx 返回给客户端的Header信息数
  
• 　　waiting -- 开启 keep-alive 的情况下，这个值等于 active - (reading + writing)，意思就是Nginx说已经处理完正在等候下一次请求指令的驻留连接
  

　　静态文件处理
　　通过正则表达式，我们可让 Nginx 识别出各种静态文件，例如 images 路径下的所有请求可以写为：
location ~ ^/images/ {　　
root /opt/webapp/images;
　　
}
　　

　　而下面的配置则定义了几种文件类型的请求处理方式。
location ~ \.(htm|html|gif|jpg|jpeg|png|bmp|ico|css|js|txt)$ {　　
root /opt/webapp;
　　
expires 24h;
　　
}
　　

　　对于例如图片、静态 HTML 文件、js 脚本文件和 css 样式文件等，我们希望 Nginx 直接处理并返回给浏览器，这样可以大大的加快网页浏览时的速度。因此对于这类文件我们需要通过 root 指令来指定文件的存放路径，同时因为这类文件并不常修改，通过expires 指令来控制其在浏览器的缓存，以减少不必要的请求。 expires 指令可以控制 HTTP 应答中的“ Expires ”和“ Cache-Control ”的头标（起到控制页面缓存的作用）。您可以使用例如以下的格式来书写 Expires：
expires 1 January, 1970, 00:00:01 GMT;　　
expires 60s;
　　
expires 30m;
　　
expires 24h;
　　
expires 1d;
　　
expires max;
　　
expires off;
　　

　　动态页面请求处理
　　Nginx 本身并不支持现在流行的 JSP、ASP、PHP、PERL 等动态页面，但是它可以通过反向代理将请求发送到后端的服务器，例如 Tomcat、Apache、IIS 等来完成动态页面的请求处理。前面的配置示例中，我们首先定义了由 Nginx 直接处理的一些静态文件请求后，其他所有的请求通过 proxy_pass 指令传送给后端的服务器（在上述例子中是 Tomcat）。最简单的 proxy_pass 用法如下：
location / {　　
proxy_pass        http://localhost:8080;
　　
proxy_set_header  X-Real-IP  $remote_addr;
　　
}
　　

　　这里我们没有使用到集群，而是将请求直接送到运行在 8080 端口的 Tomcat 服务上来完成类似 JSP 和 Servlet 的请求处理。
　　当页面的访问量非常大的时候，往往需要多个应用服务器来共同承担动态页面的执行操作，这时我们就需要使用集群的架构。 Nginx 通过 upstream 指令来定义一个服务器的集群，最前面那个完整的例子中我们定义了一个名为 tomcats 的集群，这个集群中包括了三台服务器共 6 个 Tomcat 服务。而 proxy_pass 指令的写法变成了：
location / {　　
proxy_pass        http://tomcats;
　　
proxy_set_header  X-Real-IP  $remote_addr;
　　
}
　　

　　在 Nginx 的集群配置中，Nginx 使用最简单的平均分配规则给集群中的每个节点分配请求。一旦某个节点失效时，或者重新起效时，Nginx 都会非常及时的处理状态的变化，以保证不会影响到用户的访问。
　　总结
　　尽管整个程序包只有五百多 K，但麻雀虽小、五脏俱全。 Nginx 官方提供的各种功能模块应有尽有，结合这些模块可以完整各种各样的配置要求，例如：压缩、防盗链、集群、FastCGI、流媒体服务器、Memcached 支持、URL 重写等等，更关键的是 Nginx 拥有 Apache 和其他 HTTP 服务器无法比拟的高性能。您甚至可以在不改变原有网站的架构上，通过在前端引入 Nginx 来提升网站的访问速度。
　　本文只是简单介绍了 Nginx 的安装以及常见的基本的配置和使用，更多关于 Nginx 的信息请阅读文章后面的参考资源。在这里要非常感谢我的朋友——陈磊（chanix@msn.com），他一直在做 Nginx 的中文 WIKI（http://wiki.codemongers.com/NginxChs），同时也是他介绍给我这么好的一款软件。
　　如果您的网站是运行在 Linux 下，如果您并没有使用一些非常复杂的而且确定 Nginx 无法完成的功能，那您应该试试 Nginx 。
　　-----------------------------------------------------------------------------------------------------------------------------------------
　　upstream ： nginx支持4种算法，下面一一介绍
　　1、 轮询
　　每个请求按时间顺序分配到不同的后端服务器了，后端服务器down掉，自动切除。
　　2、weight
　　设定服务器权值： weight=2
　　weight=4          服务器性能不均时候使用
　　3、 ip_hash
　　每个请求按访问ip的hash结果分配，每个访客有固定的后端服务器，可以解决session问题
　　4、 fair（第三方）
　　按后端服务器的响应时间来分配，响应时间短的优先分配
　　5、url_hash (第三方)
　　按访问的url的hash结果分配，使每个url定向到同一个后端服务器，后端为缓存服务器比较有效。
　　以往的架构lvs或者dns轮询，这样虽然squid里面的均衡的，但是忽略了一点就是数据量，虽然每台squid是均匀但是都是满载的，重复的请求，会占用很多空间，在前面换上nginx在配上 url_hash，根据url分流后，每一个url会只存在一个squid上，每台squid数据完全不同。http://edu.codepub.com/2010/0202/20282.php
　　upstream http_server {             //定义负载均衡设备的Ip及设备状态
　　ip_hash;
　　server 127.0.0.1:9090 down;
　　server 127.0.0.1:8080 weight=2;
　　server 127.0.0.1:6060;
　　server 127.0.0.1:7070 backup;
　　}
　　down ： 当前的IP server暂时不参与负载，不进行反向代理
　　weight： 默认为1，weight越大，负载的权重越大
　　max_fails： 允许请求失败的次数默认为1，当超过最大次数时，返回proxy_next_upstream模块定义的错误。
　　fail_timeout ： max_fails次失败后，暂停的时间
　　backup：  其它所有非backup机器down或者忙时候，请求backup机器，这台机器压力最轻
　　PS： nginx支持同时设置多组负载均衡，给不同的server使用。