第二讲 Nginx模块详解

本章要点

Nginx 配置文件结构
各个模块的详解

2.1 Nginx配置文件结构

Nginx的配置文件nginx.conf位于其安装目录的conf目录下。
nginx.conf由多个块组成，最外面的块是main，main包含Events和HTTP，HTTP包含upstream和多个Server，Server又包含多个location，如图：

nginxconf.png

main（全局设置）、server（主机设置）、upstream（负载均衡服务器设置）和 location（URL匹配特定位置的设置）。
● main块设置的指令将影响其他所有设置；
● server块的指令主要用于指定主机和端口；
● upstream指令主要用于负载均衡，设置一系列的后端服务器；
● location块用于匹配网页位置。
这四者之间的关系式：server继承main，location继承server，upstream既不会继承其他设置也不会被继承。
在这四个部分当中，每个部分都包含若干指令，这些指令主要包含Nginx的主模块指令、事件模块指令、HTTP核心模块指令，同时每个部分还可以使用其他HTTP模块指令，例如Http SSL模块、HttpGzip Static模块和Http Addition模块等。
上面提到过nginx配置文件中主要包括六块：main，events，http，server，location，upstream
main块：主要控制nginx子进程的所属用户/用户组、派生子进程数、错误日志位置/级别、pid位置、子进程优先级、进程对应cpu、进程能够打开的文件描述符数目等
events块：控制nginx处理连接的方式
http块：是nginx处理http请求的主要配置模块，大多数配置都在这里面进行
server块：是nginx中主机的配置块，可以配置多个虚拟主机
location块：是server中对应的目录级别的控制块，可以有多个
upstream块：是nginx做反向代理和负载均衡的配置块，可以有多个

2.2 各个模块详解

下面复制一下最原始配置文件ngin.conf中的内容：

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    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        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

}

2.2.1 main 模块

main.png

user zhaosc zhaoscgroup;：nginx的用户，用户组
worker_processes 1; #启动进程数，根据硬件调整，通常等于CPU数量或者2倍于CPU。
worker_cpu_affinity 00000001 00000010 00000100 00001000; #CPU逻辑数，为每个进程分别绑在CPU上面，为每个进程分配一个CPU。
注释：它用的是二进制表示，0001表示启用第一个CPU内核，0010表示启用第二个CPU内核，依此类推；worker_processes最多开启8个，8个以上性能提升不会再提升了，而且稳定性变得更低，所以8个进程够用了。
worker_rlimit_nofile 102400; #这个指令当一个进程打开的最大文件数目，与NGINX并发连接有关系
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;#错误日志：存放路径，[ debug | info | notice | warn | error | crit ] ，默认值是error
pid logs/nginx.pid; #pid（进程标识符）：存放路径

2.2.2 events模块

events.png

use epoll; #多路复用IO 基于LINUX2.6以上内核，可以大大提高NGINX的性能，可选值有：use [ kqueue | rtsig | epoll | /dev/poll | select | poll | eventport ]
worker_connections 2000;#工作进程的最大连接数量理论上每台nginx服务器的最大连接数为worker_processes*worker_connections worker_processes为我们再main中开启的进程数
client_header_buffer_size 4k;客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为系统分页大小。查看系统分页可以使用 getconf PAGESIZ。在这里容量4K，如果header头信息请求超过了，nginx会直接返回400错误，先根据client_header_buffer_size配置的值分配一个buffer，如果分配的buffer无法容纳 request_line/request_header，那么就会再次根据large_client_header_buffers配置的参数分配large_buffer，如果large_buffer还是无法容纳，那么就会返回414（处理request_line）/400（处理request_header）错误。
open_file_cache max=2000 inactive=60s;
为打开文件指定缓存，默认是没有启用的，max指定缓存最大数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存打开文件最大数量为我们再main配置的worker_rlimit_nofile参数
open_file_cache_valid 60s;这个是指多长时间检查一次缓存的有效信息。如果有一个文件在inactive时间内一次没被使用，它将被移除
open_file_cache_min_uses 1;open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如果有一个文件在inactive时间内一次没被使用，它将被移除。
accept_mutex语法：accept_mutex [ on | off ] 默认值：on Nginx使用连接互斥锁进行顺序的accept()系统调用
accept_mutex_delay 语法：accept_mutex_delay Nms; 默认值：500ms 如果一个进程没有互斥锁，它将至少在这个值的时间后被回收

2.2.3 http模块

http.png

include mime.types;#引用mime.types,这个类型定义了很多，当web服务器收到静态的资源文件请求时，依据请求文件的后缀名在服务器的MIME配置文件中找到对应的MIME Type，根据MIMETYPE设置并response响应类型（Content-type），指定默认类型为二进制流，也就是当文件类型未定义时使用这种方式，此时，用浏览器访问JSP文件就会出现下载窗口
default_type application/octet-stream;#定义的数据流，有的时候默认类型可以指定为text,这跟我们的网页发布还是资源下载是有关系的
fastcgi_intercept_errors on; #表示接收fastcgi输出的http1.0 response code
server_names_hash_bucket_size 128; #保存服务器名字的hash表 #could not build the server_names_hash, you should increase server_names_hash_bucket_size: 64
client_header_buffer_size 4k;#用来缓存请求头信息的，容量4K
large_client_header_buffers 4 32k;，如果header头信息请求超过了，nginx会直接返回400错误，先根据client_header_buffer_size配置的值分配一个buffer，如果分配的buffer无法容纳request_line/request_header，那么就会再次根据large_client_header_buffers配置的参数分配large_buffer，如果large_buffer还是无法容纳，那么就会返回414（处理request_line）/400（处理request_header）错误。
client_max_body_size 300m; #允许客户端请求的最大单文件字节数
sendfile on; #指定NGINX是否调用这个函数来输出文件，对于普通的文件我们必须设置为ON，如果NGINX专门做为一个下载端的话可以关掉，好处是降低磁盘与网络的IO处理数及系统的UPTIME
autoindex on;开启目录列表访问，适合下载服务器
tcp_nopush on; #防止网络阻塞
keepalive_timeout 60;#非常重要，根据实际情况设置值，超时时间，客户端到服务端的连接持续有效时间，60秒内可避免重新建立连接，时间也不能设太长，太长的话，若请求数10000，都占用连接会把服务托死
tcp_nodelay on;#提高数据的实时响应性
client_body_buffer_size 512k; #缓冲区代理缓冲用户端请求的最大字节数（请求多）
proxy_connect_timeout 5; #nginx跟后端服务器连接超时时间（代理连接超时）
proxy_read_timeout 60; #连接成功后，后端服务器响应时间(代理接收超时)
proxy_send_timeout 5; #后端服务器数据回传时间(代理发送超时)
proxy_buffer_size 16k; #设置代理服务器（nginx）保存用户头信息的缓冲区大小
proxy_buffers 4 64k;#proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
proxy_busy_buffers_size 128k; #高负荷下缓冲大小
proxy_temp_file_write_size 128k; #设定缓存文件夹大小，大于这个值，将从upstream服务器传
gzip on; #NGINX可以压缩静态资源，比例我的静态资源有10M，压缩后只有2M，那么浏览器下载的就少了
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2;#压缩级别大小，最小1，最大9，值越小，压缩后比例越小，CPU处理更快，为1时，原10M压缩完后8M，但设为9时，压缩完可能只有2M了
gzip_types text/plain application/x-javascript text/css application/xml; 压缩类型:text,js css xml 都会被压缩
gzip_vary on; #作用是在http响应中增加一行目的是改变反向代理服务器的缓存策略

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $request_time';
日志格式 "$request" ' #ip 远程用户当地时间请求URL
'$status $body_bytes_sent "$http_referer" ' #状态发送的大小响应的头
'"$http_user_agent" $request_time'; #客户端使用的

2.2.4 server模块

server.png

listen ：所监听的端口
server_name 配置访问域名，可以有多个直接用空格隔开，也可以用正则表达式
charset：编码集
access_log :正常访问日志所在的目录

2.2.5 upatream 模块
upstream 比较简单,用于处理服务器的负载均衡，实例如下：
先配置upstream 模块

upstream zhaosc { 
      server 192.168.1.100:8080; 
      server 192.168.1.200:8080; 
}

然后,配置location，将 proxy_pass配置为：http:// + upstream名称

location / { 
            root  html; 
            index  index.html index.htm; 
            proxy_pass http://zhaosc; 
}

nginx 负载均衡的算法是轮询，同时还支持权重(weight)机制，如下：

upstream zhaosc{ 
      server 192.168.1.100:8080  weight=5; 
      server 192.168.1.200:8080  weight=10; 
}

ip_hash如下：

upstream zhaosc{ 
      ip_hash; 
      server 192.168.1.100:8080; 
      server 192.168.1.200:8080; 
}

fair: 按后端服务器的响应时间来分配请求。响应时间短的优先分配。
与weight分配策略相似。

 upstream zhaosc{      
      server 192.168.1.100:8080; 
      server 192.168.1.200:8080; 
      fair; 
}

url_hash:按訪问url的hash结果来分配请求，使每一个url定向到同一个后端服务器。后端服务器为缓存时比較有效。
注意：在upstream中加入hash语句。server语句中不能写入weight等其他的參数，hash_method是使用的hash算法。

 upstream zhaosc{ 
      server 192.168.1.100:8080; 
      server 192.168.1.200:8080;  
      hash $request_uri; 
      hash_method crc32; 
}

upstream还可以为每个设备设置状态值，这些状态值的含义分别如下：

down 表示单前的server暂时不参与负载.
weight 默认为1.weight越大，负载的权重就越大。
max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.
fail_timeout : max_fails次失败后，暂停的时间。
backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

upstream zhaosc{ #定义负载均衡设备的Ip及设备状态 
      ip_hash; 
      server 192.168.1.100:9090 down; 
      server 192.168.1.100:8080 weight=2; 
      server 192.168.1.100:6060; 
      server 192.168.1.100:7070 backup; 
}

由于location模块内容比较多，所以重开一篇，下一节详细介绍。

第二讲 Nginx模块详解

本章要点

2.1 Nginx配置文件结构

2.2 各个模块详解

你可能感兴趣的:(第二讲 Nginx模块详解)