nginx配置详解和原理

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

https://www.jianshu.com/p/6215e5d24553