nginx配置详解和原理

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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

以上是关于nginx配置详解和原理的主要内容,如果未能解决你的问题,请参考以下文章

Nginx运行原理和配置详解(个人总结笔记)

Nginx原理详解

nginx工作原理与配置

Nginx原理详解

Nginx 反向代理工作原理简介与配置详解

nginx安装和常见的配置