nginx配置详解和原理
1.nginx的配置文件
nginx 配置文件的整体结构
<pre>user nobody nobody; # 指定Nginx Worker进程运行用户以及用户组，默认由nobody账号运行,nobody 是系统用户,是一个不能登陆的帐号，一个特殊用途的用户 ID #启动进程,通常设置成和cpu的数量相等
worker_processes 1; #指定了Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存。建议指定和CPU的数量一致即可。 #全局错误日志及PID文件 用来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择，其中，debug输出日志最为最详细，而crit输出日志最少 #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info;
#pid logs/nginx.pid; # pid是个主模块指令，用来指定进程pid的存储文件位置
worker_rlimit_nofile 65535; #用于绑定worker进程和CPU， Linux内核2.4以上可用
#工作模式及连接数上限
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;# default_type属于HTTP核心模块指令，这里设定默认类型为二进制流，也就是当文件类型未定义时使用这种方式，例如在没有配置PHP环境时，Nginx是不予解析的，此时，用浏览器访问PHP文件就会出现下载窗口。 #设定日志格式
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;</pre>
upstream cszhi.com{
ip_hash;
server 192.168.8.11:80;
server 192.168.8.12:80 down;
server 192.168.8.13:8009 max_fails=3 fail_timeout=20s;
server 192.168.8.146:8080;
}; 负载均衡的设置
<pre>#设定虚拟主机配置
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;
}</pre>
location /proxy {
proxy_pass http://192.168.33.10;
} # 设置方向代理<pre>#禁止访问 .htxxx 文件 location ~ /.ht { deny all; } } }</pre>
1.1 关于nobody用户
<pre>关于linux下的nobody用户
nobody 是系统用户,是一个不能登陆的帐号，一个特殊用途的用户 ID ,一些服务进程如apache，aquid等都采用一些特殊的帐号来运行，比如nobody,news,games等等。一般来说 uid < 500 的都是系统 ID 。
Linux 系统为了安全，很多操作和服务的运行都不是运行在 root 用户下面的，而是一个专用的 ID ，这个 ID 一般就是 nobody ，这样就可以把每个服务运行的情况隔离出来。
保证不会因为服务器程序的问题而让服务器程序成了***的直接操作源（***拿下了服务器程序，也仅仅是 nobody 用户而不是 root 用户）。同时也不会影响其他用户的数据。
服务器程序提权有专用的办法来防止恶意使用的。
除了 nobody ，常见的还有 ftp 、ssh 什么的。有的不是用来跑服务，而是用来占坑，主要是用用户组的权限管理进行权限设置，这个时候会有一个占坑用的同名 ID 加入到用户组。这种情况好像主要是为了兼容。
问题描述：
上午据反映，系统响应很慢，界面要刷新很久才出得来。查后台也没有报什么错，我们系统是用nginx做负载均衡。惯性地不走负载均衡而直接访 问单节点应用，发现响应很快，很正常。初步定位问题出在nginx上，
然后查nginx日志，发现有很多错误，错误中有“13: Permission denied”这个信息，明显是权限问题，很奇怪，之前运行都很正常啊。后来一问才知道，维护人员做了操作。
系统上nginx安装时使用的是root用户，也是用root用户启动的，所以要修改配置的时候需要使用root用户，管理上不方便，所以维护人员 心血来潮修改了nginx的权限（后来知道他是使用这个命令修改的权限chown -R user:group $nginxdir）。
就是将nginx的用户和组都换掉了，但是这样为什么会造成“响应慢”呢？</pre>
1.2 负载均衡设置
Nginx的负载均衡模块目前支持4种调度算法，下面进行分别介绍，其中后两项属于第三方的调度方法。
- 轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器宕机，故障系统被自动剔除，使用户访问不受影响；
- Weight：指定轮询权值，Weight值越大，分配到的访问机率越高，主要用于后端每个服务器性能不均的情况下；
- ip_hash：每个请求按访问IP的hash结果分配，这样来自同一个IP的访客固定访问一个后端服务器，有效解决了动态网页存在的session共享问题；
- fair：比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair的，如果需要使用这种调度算法，必须下载Nginx的upstream_fair模块；
- url_hash：按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身是不支持url_hash的，如果需要使用这种调度算法，必须安装Nginx 的hash软件包。
在HTTP Upstream模块中，可以通过server指令指定后端服务器的IP地址和端口，同时还可以设定每个后端服务器在负载均衡调度中的状态。常用的状态有：
- down：表示当前的server暂时不参与负载均衡；
- backup：预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻；
- max_fails：允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误；
- fail_timeout：在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用。
注意，当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能是weight和backup。
2.
参考资料：https://blog.csdn.net/wangbin_0729/article/details/82109693
http://baijiahao.baidu.com/s?id=1604485941272024493&wfr=spider&for=pc