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的轮询策略并不适用