nginx一些重要配置说明

1.nginx系统配置详细说明

#nginx的运行用户
user nobody;
#启动进程,通常设置成和cpu的数量相等
worker_processes  1;

#全局错误日志及PID文件
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

#工作模式及连接数上限
events {
#epoll是多路复用IO(I/O Multiplexing)中的一种方式,
#仅用于linux2.6以上内核,可以大大提高nginx的性能
use   epoll;

#单个后台worker process进程的最大并发链接数
worker_connections  1024;

# 并发总数是 worker_processes 和 worker_connections 的乘积
# 即 max_clients = worker_processes * worker_connections
# 在设置了反向代理的情况下，max_clients = worker_processes * worker_connections / 4  为什么
# 为什么上面反向代理要除以4，应该说是一个经验值
# 根据以上条件，正常情况下的Nginx Server可以应付的最大连接数为：4 * 8000 = 32000
# worker_connections 值的设置跟物理内存大小有关
# 因为并发受IO约束，max_clients的值须小于系统可以打开的最大文件数
# 而系统可以打开的最大文件数和内存大小成正比，一般1GB内存的机器上可以打开的文件数大约是10万左右
# 我们来看看360M内存的VPS可以打开的文件句柄数是多少：
# $ cat /proc/sys/fs/file-max
# 输出 34336
# 32000 < 34336，即并发连接总数小于系统可以打开的文件句柄总数，这样就在操作系统可以承受的范围之内
# 所以，worker_connections 的值需根据 worker_processes 进程数目和系统可以打开的最大文件总数进行适当地进行设置
# 使得并发总数小于操作系统可以打开的最大文件数目
# 其实质也就是根据主机的物理CPU和内存进行配置
# 当然，理论上的并发总数可能会和实际有所偏差，因为主机还有其他的工作进程需要消耗系统资源。
# ulimit -SHn 65535

}

http {
#设定mime类型,类型由mime.type文件定义
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  logs/access.log  main;

#sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，
#对于普通应用，必须设为 on,
#如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，
#以平衡磁盘与网络I/O处理速度，降低系统的uptime.
sendfile     on;
#tcp_nopush     on;

#连接超时时间
#keepalive_timeout  0;
keepalive_timeout  65;
tcp_nodelay     on;

#开启gzip压缩
gzip  on;
gzip_disable "MSIE [1-6].";

#设定请求缓冲
client_header_buffer_size    128k;
large_client_header_buffers  4 128k;

#设定虚拟主机配置
server {
#侦听80端口
listen    80;
#定义使用 www.nginx.cn访问
server_name  www.nginx.cn;

#定义服务器的默认网站根目录位置
root html;

#设定本虚拟主机的访问日志
access_log  logs/nginx.access.log  main;

#默认请求
location / {

#定义首页索引文件的名称
index index.php index.html index.htm;

}

# 定义错误提示页面
error_page   500 502 503 504 /50x.html;
location = /50x.html {
}

#静态文件，nginx自己处理
location ~ ^/(images|javascript|js|css|flash|media|static)/ {

#过期30天，静态文件不怎么更新，过期可以设大一点，
#如果频繁更新，则可以设置得小一点。
expires 30d;
}

#PHP 脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置.
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
include fastcgi_params;
}

#禁止访问 .htxxx 文件
location ~ /.ht {
deny all;
}

}
}

2.nginx中location匹配规则详解

nginx是用C开发的，C语音中的location相当于java中的controller。

一个请求过来，nginx服务器具体会交给哪个或哪些location处理，将根据正则的匹配规则确定

2.1 nginx的匹配规则如下

没有修饰符 表示：必须以指定模式开始

~ 表示执行一个正则匹配，区分大小写

~* 表示执行一个正则匹配，不区分大小写

^~ 表示普通字符匹配。使用前缀匹配。如果匹配成功，则不再匹配其他location。

= 进行普通字符精确匹配。也就是完全匹配。

@ 它定义一个命名的 location，使用在内部定向时，例如 error_page, try_files

2.2 nginx的匹配规则按优先级排列

nginx的location匹配和配置中location的顺序没有太大关系。与location表达式的类型有关。相同类型的表达式，字符串长的会优先匹配。

等号类型（=）的优先级最高。一旦匹配成功，则不再查找其他匹配项。

^~类型表达式。一旦匹配成功，则不再查找其他匹配项。

正则表达式类型（~ ~*）的优先级次之。如果有多个location的正则能匹配的话，则使用正则表达式最长的那个。

常规字符串匹配类型。按前缀匹配。

以下是location匹配的优先级示例

location = / {

# 仅仅匹配请求 /

[ configuration A ]

}

location / {

# 匹配所有以 / 开头的请求。

# 但是如果有更长的同类型的表达式，则选择更长的表达式。

# 如果有正则表达式可以匹配，则优先匹配正则表达式。

[ configuration B ]

}

location /documents/ {

# 匹配所有以 /documents/ 开头的请求。

# 但是如果有更长的同类型的表达式，则选择更长的表达式。

# 如果有正则表达式可以匹配，则优先匹配正则表达式。

[ configuration C ]

}

location ^~ /images/ {

# 匹配所有以 /images/ 开头的表达式，如果匹配成功，则停止匹配查找。

# 所以，即便有符合的正则表达式location，也不会被使用

[ configuration D ]

}

location ~* \.(gif|jpg|jpeg)$ {

# 匹配所有以 gif jpg jpeg结尾的请求。

# 但是 以 /images/开头的请求，将使用 Configuration D

[ configuration E ]

}

请求匹配示例

/ -> configuration A

/index.html -> configuration B

/documents/document.html -> configuration C

/images/1.gif -> configuration D

/documents/1.jpg -> configuration E

注意，以上的匹配和在配置文件中定义的顺序无关。

3.nginx中负载均衡轮询策略

nginx负载均衡模块的轮询策略主要有以下4中

ip_hash:根据用户的ip地址，nginx会根据hash算法将该地址传来的请求发送给固定的服务器处理，配置了该属性则权重将不生效（理论上可以用来处理session共享）

轮询：nginx将接收到的请求按顺序分配给不同的服务器进行处理

权重：可以根据各服务器的配置及请求的响应情况来配置权重，使得nginx处理请求达到一个负载均衡的效果

备用：备用服务器一般不处理请求，只有当所有在正在处理请求的服务器都挂了，才会启用该备用服务器确保系统能够正常执行

其实在具体的生产环境中，一般是不采用设置ip_hash来处理session共享的，原因是生产环境中ip地址很多是动态获取的，并不固定。所以根据hash算法算出来的结果不一样，因此ip_hash的轮询策略并不适用

另附nginx快速入手开发文档下载地址：http://pan.baidu.com/s/1pLi86wz

本文参考自以下文章:

http://www.nginx.cn/76.html

https://my.oschina.net/u/1266221/blog/877208