Nginx介绍以及常用配置

ゞ浴缸里的玫瑰 2021-09-21 14:48 373阅读 0赞

### 1，nginx入门 ###

**1. Nginx背景**

Nginx同Apache一样都是一种WEB服务器。基于REST架构风格，以统一资源描述符(UniformResources ldentifier)URl或者统一资源定位符(Uniform Resources Locator)URL作为沟通依据，通过HTTP协议提供各种网络服务。  
然而，这些服务器在设计之初受到当时环境的局限，例如当时的用户规模，网络带宽，产品特点等局限并且各自的定位和发展都不尽相同。这也使得各个WEB服务器有着各自鲜明的特点。Apache的发展时期很长，而且是毫无争议的世界第一大服务器。它有着很多优点:稳定、开源、跨平台等等。它出现的时间太长了，它兴起的年代，互联网产业远远比不上现在。所以它被设计为一个重量级的。它不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低这些都决定了Apache不可能成为高性能WEB服务器，轻量级高并发服务器Nginx就应运而生了。

**2.Nginx概述**

是一个高性能的HTTP和反向代理web服务器，轻量级。

提供了IMAP/POP3/SMTP服务

发布于2004年10月4日(第一个公开版本0.1.0 )

Nginx的1.4.0稳定版已经于2013年4月24日发布

C语言编写

Nginx是一个跨平台服务器

Nginx有自己的函数库，并且除了zlib、PCRE和OpenSSL之外，标准模块只使用系统C库函数。而且，如果不需要或者考虑到潜在的授权冲突，可以不使用这些第三方库。

**3. Nginx优势**

占有内存少(在3W并发连接中，开启的10个nginx进程消耗内存大约150M)

高并发能力强(官方测试能够支撑5W并发连接，在实际生产环境中能到2-3W并发连接数)

简单(配置文件通俗易懂)

价格(免费、开源)

支持Rewriter重写(能够根据域名、URL的不同，将HTTP请求分到不同的后端服务器群组)

内置健康检查(如果nginx后端有几个服务宕机了，不会影响前端访问，能自动检测服务状态)

节省带宽(支持GZIP压缩，可以添加浏览器本地缓存的Header头)

稳定性高，反向代理，很少宕机

中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等

**4. Nginx功能**

• web服务器、轻量级  
• 负载、均衡  
• 缓存  
• 高并发  
• 代理服务器  
• IP负载、静态负载  
• 动静分离  
• 限流、健康监控

**5. Linux下Nginx安装**

yum install gcc-c++
    yum -y install pcre pcre-devel
    yum -y install zlib zlib-devel
    yum install -y openssl openssl-devel
    wget http://nginx.org/download/nginx-1.13.11.tar.gz
    tar zxvf nginx-1.13.11.tar.gz
    ./configure --prefix=/opt/nginx
    make
    make install

**6. Linux下Nginx命令**

cd sbin/
    ./nginx
    ./nginx -s stop
    ./nginx -s quit
    ./nginx -s reload
    ./nginx -s quit #此方式停止步骤是待nginx进程处理任务完毕进行停止。
    ./nginx -s stop #此方式相当于先查出nginx进程id再使用kill命令强制杀掉进程。

> 注意：  
> 开启端口： /sbin/iptables -I INPUT -p tcp --dport 80 -j ACCEPT  
> 如果本地访问不到端口，则需要开启  
> 如果开启之后，还访问不到，则需要关闭本地防火墙

### 2，nginx实战应用 ###

**1.Nginx配置文件详解**

**\#模块结构**

核心模块  
1. HTTP 模块(代理、缓存、日志定义和第三方模块)  
2. EVENTS 模块(网络连接)  
3. 全局 模块(全局指令，日志路径、PID路径、用户信息等)  
基础模块  
1. HTTP 全局 模块  
2. HTTP FastCGI 模块  
3. HTTP Gzip模块  
4. HTTP server模块(虚拟主机，一个http，可以有多个server)  
5. HTTP location 模块(请求的路由，各种页面的处理)  
6. HTTP Rewrite模块  
第三方模块  
1. HTTP Upstream Request Hash 模块  
2. Notice 模块  
3. HTTP Access Key模块

**\#配置文件详解**

#定义Nginx运行的用户和用户组
    # user nobady nobady;
    
    #nginx进程数，建议设置为等于CPU总核心数,默认为1。
    worker_processes 8;
    
    #全局错误日志定义类型，[ debug | info | notice | warn | error | crit ]
    error_log /usr/local/nginx/logs/error.log info;
    
    #进程pid文件,指定nginx进程运行文件存放地址
    pid /usr/local/nginx/logs/nginx.pid;
    
    #指定进程可以打开的最大描述符：数目
    #工作模式与连接数上限
    #这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n
    的值保持一致。
    #现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。
    #这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。
    
    worker_rlimit_nofile 65535;
    
    events
    {
    
     #参考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll]; epoll模型
     #是Linux 2.6以上版本内核中的高性能网络I/O模型，linux建议epoll，如果跑在FreeBSD上面，就用kqueue模型。
     #补充说明：
     #与apache相类，nginx针对不同的操作系统，有不同的事件模型
     #A）标准事件模型
     #Select、poll属于标准事件模型，如果当前系统不存在更有效的方法，nginx会选择select或poll
     #B）高效事件模型
     #Kqueue：使用于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。
     #Epoll：使用于Linux内核2.6版本及以后的系统。
     #/dev/poll：使用于Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX6.5.15+ 和 Tru64 UNIX 5.1A+。
     #Eventport：使用于Solaris 10。 为了防止出现内核崩溃的问题， 有必要安装安全补丁。
    
     use epoll;
    
     #单个进程最大连接数（最大连接数=连接数*进程数）
     #根据硬件调整，和前面工作进程配合起来用，尽量大，但是别把cpu跑到100%就行。每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为。
    
     worker_connections 65535;
    
     #keepalive超时时间，默认是60s，切记这个参数也不能设置过大！否则会导致许多无效的http连接占据着nginx的连接数，终nginx崩溃！
    
     keepalive_timeout 60;
    
     #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。
     #分页大小可以用命令getconf PAGESIZE 取得。
     #[root@web001 ~]# getconf PAGESIZE
     #4096
     #但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。
    
     client_header_buffer_size 4k;
    
     #这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。
    
     open_file_cache max=65535 inactive=60s;
    
     #这个是指多长时间检查一次缓存的有效信息。
     #语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息.
    
     open_file_cache_valid 60s;
    
     #open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。
     #语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如果使用更大的值,文件描述符在cache中总是打开状态.
    
     open_file_cache_min_uses 1;
    
    #语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误.
    
     open_file_cache_errors on;
    
    }
    
    #设定http服务器，利用它的反向代理功能提供负载均衡支持
    
    http
    {
    
     #文件扩展名与文件类型映射表
    
     include mime.types;
    
     #默认文件类型
    
     default_type application/octet-stream;
    
     #默认编码
    
     #charset utf-8;
    
     #服务器名字的hash表大小
     #保存服务器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。参数hash bucket size总是等于hash表的大小，并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后，使在处理器中加速查找hash表键值成为可能。如果hash bucket size等于一路处理器缓存的大小，那么在查找键的时候，最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址，第二次是在存储单元中查找键 值。因此，如果Nginx给出需要增大hash max size 或 hash bucket size的提示，那么首要的是增大前一个参数的大小.
    
     server_names_hash_bucket_size 128;
    
     #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。
    
     client_header_buffer_size 32k;
    
     #客户请求头缓冲大小。nginx默认会用client_header_buffer_size这个buffer来读取header值，如果header过大，它会使用large_client_header_buffers来读取。
    
     large_client_header_buffers 4 64k;
    
     #设定通过nginx上传文件的大小
    
     client_max_body_size 8m;
    
     #开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件，对于普通应用设为 on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常把这个改成off。
     #sendfile指令指定 nginx 是否调用sendfile 函数（zero copy 方式）来输出文件，对于普通应用，必须设为on。如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络IO处理速度，降低系统uptime。
    
     sendfile on;
    
     #开启目录列表访问，合适下载服务器，默认关闭。
    
     autoindex on;
    
     #此选项允许或禁止使用socke的TCP_CORK的选项，此选项仅在使用sendfile的时候使用,告诉nginx在一个数据包里发送所有头文件，而不一个接一个的发送。就是说数据包不会马上传送出去，等到数据包最大时，一次性的传输出去，这样有助于解决网络堵塞
    
     tcp_nopush on;
    
    #告诉nginx不要缓存数据，而是一段一段的发送--当需要及时发送数据时，就应该给应用设置这个属性，这样发送一小块数据信息时就不能立即得到返回值
    
     tcp_nodelay on;
    
     #长连接超时时间，单位是秒
    
     keepalive_timeout 120;
    
     #FastCGI相关参数是为了改善网站的性能：减少资源占用，提高访问速度。下面参数看字面意思都能理解。
     #这个指令为FastCGI缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间
    
     fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;
    
     #指定连接到后端FastCGI的超时时间
    
     fastcgi_connect_timeout 300;
    
     #向FastCGI传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI传送请求的超时时间
    
     fastcgi_send_timeout 300;
    
     #接收FastCGI应答的超时时间，这个值是指已经完成两次握手后接收FastCGI应答的超时时间
    
     fastcgi_read_timeout 300;
    
     #指定读取FastCGI应答第一部分 需要用多大的缓冲区,这里可以设置为fastcgi_buffers指令指定的缓冲区大小，上面的指令指定它将使用1个 16k的缓冲区去读取应答的第一部分，即应答头，其实这个应答头一般情况下都很小（不会超过1k），但是你如果在fastcgi_buffers指令中指定了缓冲区的大小，那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存
    
     fastcgi_buffer_size 64k;
    
     #指定本地需要用多少和多大的缓冲区来 缓冲FastCGI的应答，如上所示，如果一个php脚本所产生的页面大小为256k，则会为其分配16个16k的缓冲区来缓存，如果大于256k，增大 于256k的部分会缓存fastcgi_temp指定的路径中， 当然这对服务器负载来说是不明智的方案，因为内存中处理数据速度要快于硬盘，通常这个值 的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值，比如你的站点大部分脚本所产生的页面大小为 256k就可以把这个值设置为16 16k，或者464k 或者64 4k，但很显然，后两种并不是好的设置方法，因为如果产生的页面只有32k，如果用464k它会分配1个64k的缓冲区去缓存，而如果使用64 4k它会分配8个4k的缓冲区去缓存，而如果使用16 16k则它会分配2个16k去缓存页面，这样看起来似乎更加合理•
    
     fastcgi_buffers 4 64k;
    
     #这个指令我也不知道是做什么用，只知道默认值是fastcgi_buffers的两倍
    
     fastcgi_busy_buffers_size 128k;
    
     #在写入fastcgi_temp_path时将用多大的数据块，默认值是fastcgi_buffers的两倍
    
     fastcgi_temp_file_write_size 128k;
    
     #开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU负载，并且防止502错误。但是这个缓存会引起很多问题，因为它缓存的是动态页面。具体使用还需根据自己的需求
    
     fastcgi_cache TEST
    
     #为指定的应答代码指定缓存时间，如上例中将200，302应答缓存一小时，301应答缓存1天，其他为1分钟
    
     fastcgi_cache_valid 200 302 1h;
     fastcgi_cache_valid 301 1d;
     fastcgi_cache_valid any 1m;
    
     #缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数，如上例，如果在5分钟内某文件1次也没有被使用，那么这个文件将被移除
    
     fastcgi_cache_min_uses 1;
    
     #gzip模块设置
     #开启压缩 
    
     gzip  on;
    
     # 设置允许压缩的页面最小字节数，页面字节数从header头得content-length中进行获取。默认值是0，不管页面多大都压缩。建议设置成大于2k的字节数，小于2k可能会越压越大。
    
    gzip_min_length 2k;
    
     # 设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流。 例如 4 4k 代表以4k为单位，按照原始数据大小以4k为单位的4倍申请内存。 4 8k 代表以8k为单位，按照原始数据大小以8k为单位的4倍申请内存。 
     # 如果没有设置，默认值是申请跟原始数据相同大小的内存空间去存储gzip压缩结果。 
    
     gzip_buffers 4 16k;
    
     #压缩级别，1-10，数字越大压缩的越好，也越占用CPU时间 
    
     gzip_comp_level 5;
    
     # 默认值: gzip_types text/html (默认不对js/css文件进行压缩)
     # 压缩类型，匹配MIME类型进行压缩
     # 不能用通配符 text/*
     # (无论是否指定)text/html默认已经压缩
     # 设置哪压缩种文本文件可参考 conf/mime.types 
    
     gzip_types text/plain application/x-javascript text/css application/xml;
    
     # 值为1.0和1.1 代表是否压缩http协议1.0，选择1.0则1.0和1.1都可以压缩 
    
     gzip_http_version 1.0
    
     # IE6及以下禁止压缩
    
     gzip_disable "MSIE [1-6]\.";
    
     # 默认值：off
     # Nginx作为反向代理的时候启用，开启或者关闭后端服务器返回的结果，匹配的前提是后端服务器必须要返回包含"Via"的 header头。 
     # off - 关闭所有的代理结果数据的压缩 
     # expired - 启用压缩，如果header头中包含 "Expires" 头信息 
     # no-cache - 启用压缩，如果header头中包含 "Cache-Control:no-cache" 头信息 
     # no-store - 启用压缩，如果header头中包含 "Cache-Control:no-store" 头信息 
     # private - 启用压缩，如果header头中包含 "Cache-Control:private" 头信息 
     # no_last_modified - 启用压缩,如果header头中不包含 "Last-Modified" 头信息 
     # no_etag - 启用压缩 ,如果header头中不包含 "ETag" 头信息 
     # auth - 启用压缩 , 如果header头中包含 "Authorization" 头信息 
     # any - 无条件启用压缩 
    
     gzip_proxied expired no-cache no-store private auth; 
    
     # 给CDN和代理服务器使用，针对相同url，可以根据头信息返回压缩和非压缩副本 
    
     gzip_vary on; 
    
     #开启限制IP连接数的时候需要使用
    
     #limit_zone crawler $binary_remote_addr 10m;
    
     #负载均衡配置
    
     upstream www.xx.com {
     
       #upstream的负载均衡，weight是权重，可以根据机器配置定义权重。weigth参数表示权值，权值越高被分配到的几率越大。
    
       server 192.168.80.121:80 weight=3;
       server 192.168.80.122:80 weight=2;
       server 192.168.80.123:80 weight=3;
    
       #nginx的upstream目前支持4种方式的分配
       #1、轮询（默认）
       #每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
       #2、weight
       #指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
       #例如：
       #upstream bakend {
       #  server 192.168.0.14 weight=10;
       #  server 192.168.0.15 weight=10;
       #}
       #2、ip_hash
       #每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
       #例如：
       #upstream bakend {
       #  ip_hash;
       #  server 192.168.0.14:88;
       #  server 192.168.0.15:80;
       #}
       #3、fair（第三方）
       #按后端服务器的响应时间来分配请求，响应时间短的优先分配。
       #upstream backend {
       #  server server1;
       #  server server2;
       #  fair;
       #}
       #4、url_hash（第三方）
       #按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
       #例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法
       #upstream backend {
       #  server squid1:3128;
       #  server squid2:3128;
       #  hash $request_uri;
       #  hash_method crc32;
       #}
       #tips:
       #upstream bakend{#定义负载均衡设备的Ip及设备状态}{
       #  ip_hash;
       #  server 127.0.0.1:9090 down;
       #  server 127.0.0.1:8080 weight=2;
       #  server 127.0.0.1:6060;
       #  server 127.0.0.1:7070 backup;
       #}
       #在需要使用负载均衡的server中增加 proxy_pass http://bakend/;
       #每个设备的状态设置为:
       #1.down表示单前的server暂时不参与负载
       #2.weight为weight越大，负载的权重就越大。
       #3.max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream模块定义的错误
       #4.fail_timeout:max_fails次失败后，暂停的时间。
       #5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
       #nginx支持同时设置多组的负载均衡，用来给不用的server来使用。
       #client_body_in_file_only设置为On 可以讲client post过来的数据记录到文件中用来做debug
       #client_body_temp_path设置记录文件的目录 可以设置最多3层目录
       #location对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡
     }
    #虚拟主机的配置
     server
     {
    
       #监听端口
    
       listen 80;
    
       #域名可以有多个，用空格隔开
    
       server_name www.xx.com xx.com;
       index index.html index.htm index.php;
       root /data/www/xx;
    
       #对******进行负载均衡
    
       location ~ .*.(php|php5)?$
    
       {
         fastcgi_pass 127.0.0.1:9000;
         fastcgi_index index.php;
         include fastcgi.conf;
       }
       
       #图片缓存时间设置
    
       location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
       {
         expires 10d;
       }
       
       #JS和CSS缓存时间设置
    
       location ~ .*.(js|css)?$
       {
         expires 1h;
       }
       
       #日志格式设定
       #$remote_addr与$http_x_forwarded_for用以记录客户端的ip地址；
       #$remote_user：用来记录客户端用户名称；
       #$time_local： 用来记录访问时间与时区；
       #$request： 用来记录请求的url与http协议；
       #$status： 用来记录请求状态；成功是200，
       #$body_bytes_sent ：记录发送给客户端文件主体内容大小；
       #$http_referer：用来记录从那个页面链接访问过来的；
       #$http_user_agent：记录客户浏览器的相关信息；
       #通常web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。
       #反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。
    
       log_format access '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" $http_x_forwarded_for';
       
       #定义本虚拟主机的访问日志
    
       access_log /usr/local/nginx/logs/host.access.log main;
       access_log /usr/local/nginx/logs/host.access.404.log log404;
       
       #对 "/" 启用反向代理
    
       location / {
         proxy_pass http://127.0.0.1:88;
         proxy_redirect off;
         proxy_set_header X-Real-IP $remote_addr;
         
         #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
    
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         
         #以下是一些反向代理的配置，可选。
    
         proxy_set_header Host $host;
    
         #允许客户端请求的最大单文件字节数
    
         client_max_body_size 10m;
    
         #缓冲区代理缓冲用户端请求的最大字节数，
         #如果把它设置为比较大的数值，例如256k，那么，无论使用firefox还是IE浏览器，来提交任意小于256k的图片，都很正常。如果注释该指令，使用默认的client_body_buffer_size设置，也就是操作系统页面大小的两倍，8k或者16k，问题就出现了。
         #无论使用firefox4.0还是IE8.0，提交一个比较大，200k左右的图片，都返回500 Internal Server Error错误
    
         client_body_buffer_size 128k;
    
         #表示使nginx阻止HTTP应答代码为400或者更高的应答。
    
         proxy_intercept_errors on;
    
         #后端服务器连接的超时时间_发起握手等候响应超时时间
         #nginx跟后端服务器连接超时时间(代理连接超时)
    
         proxy_connect_timeout 90;
    
         #后端服务器数据回传时间(代理发送超时)
         #后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
    
         proxy_send_timeout 90;
    
         #连接成功后，后端服务器响应时间(代理接收超时)
         #连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）
    
         proxy_read_timeout 90;
    
         #设置代理服务器（nginx）保存用户头信息的缓冲区大小
         #设置从被代理服务器读取的第一部分应答的缓冲区大小，通常情况下这部分应答中包含一个小的应答头，默认情况下这个值的大小为指令proxy_buffers中指定的一个缓冲区的大小，不过可以将其设置为更小
    
         proxy_buffer_size 4k;
    
         #proxy_buffers缓冲区，网页平均在32k以下的设置
         #设置用于读取应答（来自被代理服务器）的缓冲区数目和大小，默认情况也为分页大小，根据操作系统的不同可能是4k或者8k
    
         proxy_buffers 4 32k;
    
         #高负荷下缓冲大小（proxy_buffers*2）
    
         proxy_busy_buffers_size 64k;
    
         #设置在写入proxy_temp_path时数据的大小，预防一个工作进程在传递文件时阻塞
    太长
         #设定缓存文件夹大小，大于这个值，将从upstream服务器传
    
         proxy_temp_file_write_size 64k;
    
       }
       
       
       #设定查看Nginx状态的地址
    
       location /NginxStatus {
         stub_status on;
         access_log on;
         auth_basic "NginxStatus";
         auth_basic_user_file confpasswd;
         #htpasswd 文件的内容可以用apache提供的htpasswd工具来产生。
       }
       
       #本地动静分离反向代理配置
       #所有jsp的页面均交由tomcat或resin处理
    
       location ~ .(jsp|jspx|do)?$ {
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_pass http://127.0.0.1:8080;
       }
       
       #所有静态文件由nginx直接读取不经过tomcat或resin
    
       location ~ .*.
    (htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|
       pdf|xls|mp3|wma)$
       {
         expires 15d;
       }
       
       location ~ .*.(js|css)?$
       {
         expires 1h;
       }
     }
    }

**\#语法说明**

Location

语法规则：

location [=|~|~*|^~] /uri/ {… }

符号含义：

#表示精确匹配
    =
    #表示uri以某个常规字符串开头，理解为匹配 url路径即可
    #nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注
    意是空格）
    ^~
    #表示区分大小写的正则匹配
    ~
    #表示不区分大小写的正则匹配
    ~*
    #!~和!~*分别为区分大小写不匹配及不区分大小写不匹配的正则
    !~和!~*
    #用户所使用的代理（一般为浏览器）
    /
    #可以记录客户端IP，通过代理服务器来记录客户端的ip地址
    $http_x_forwarded_for
    #可以记录用户是从哪个链接访问过来的
    $http_referer

常用规则

直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理

第一个必选规则

location = / {
       proxy_pass http://tomcat:8080/index
     }

第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项  
有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用

location ^~ /static/ {
       # 请求/static/a.txt 将被映射到实际目录文
    件:/webroot/res/static/a.txt
       root /webroot/res/;
    }
    location ~* \.(gif|jpg|jpeg|png|css|js|ico)${
       root /webroot/res/;
    }

第三个规则就是通用规则，用来转发动态请求到后端应用服务器

location / {
       proxy_pass http://tomcat:8080/
    }

> 总结：  
> 先判断精准命中，如果命中，立即返回结果并结束解析过程  
> 判断普通命中，如果有多个命中，“记录”下来“最长”的命中结果（记录但不结束，最长的为准）  
> 继续判断正则表达式的解析结果，按配置里的正则表达式顺序为准，由上至下开始匹配，一旦匹配成功1个，立即返回结果，并结束解析过程  
> 普通命中顺序无所谓，是因为按命中的长短来确定。正则命中，顺序有所谓，因为是从前入往后命中的

ReWrite

rewrite只能放在server\{\},location\{\},if\{\}中 ，并且只能对域名后边的除去传递的参数外的字符串起作用  
Nginx提供的全局变量或自己设置的变量，结合正则表达式和标志位实现url重写以及重定向  
Rewrite主要的功能就是实现URL的重写  
Nginx的Rewrite规则采用Pcre，perl兼容正则表达式的语法规则匹配，如果需要Nginx的Rewrite功能，在编译Nginx之前，需要编译安装PCRE库  
通过Rewrite规则，可以实现规范的URL、根据变量来做URL转向及选择配置

相关指令：

break ：

*  默认值 ：none
 *  使用范围 ：if，server，location
 *  作用 ：完成当前的规则集，不再处理rewrite指令，需要和last加以区分

if ( condition ) \{....\}

*  默认值 ：none
 *  使用范围 ：server，location
 *  作用：用于检测一个条件是否符合，符合则执行大括号内的语句。不支持嵌套，不支持多个
 *  条件&&或||处理

return

*  默认值 ：none
 *  使用范围 ：server，if，location
 *  作用：用于结束规则的执行和返回状态码给客户端

rewrite regex replacement flag

*  使用范围 ：server，if，location
 *  作用：该指令根据表达式来重定向URI，或者修改字符串。指令根据配置文件中的顺序来执行。注意重写表达式只对相对路径有效

uninitialized\_variable\_warn on|off

*  默认值 ：on
 *  使用范围：http,server,location,if
 *  作用：该指令用于开启和关闭未初始化变量的警告信息，默认值为开启

set variable value

*  默认值 ：none
 *  作用：该指令用于定义一个变量，并且给变量进行赋值。变量的值可以是文本、一个变量或者变量和文本的联合，文本需要用引号引起来

rewrite全局变量表 ：

变量 含义  
$args 这个变量等于请求行中的参数，同$query\_string  
$content length 请求头中的Content-length字段。  
$content\_type 请求头中的Content-Type字段。  
$document\_root 当前请求在root指令中指定的值。  
$host 请求主机头字段，否则为服务器名称。  
$http\_user\_agent 客户端agent信息  
$http\_cookie 客户端cookie信息  
$limit\_rate 这个变量可以限制连接速率。  
$request\_method 客户端请求的动作，通常为GET或POST。  
$remote\_addr 客户端的IP地址。  
$remote\_port 客户端的端口。  
$remote\_user 已经经过Auth Basic Module验证的用户名。  
$request\_filename 当前请求的文件路径，由root或alias指令与URI请求生成。  
$scheme HTTP方法（如http，https）。  
$server\_protocol 请求使用的协议，通常是HTTP/1.0或HTTP/1.1。  
$server\_addr 服务器地址，在完成一次系统调用后可以确定这个值。  
$server\_name 服务器名称。  
$server\_port 请求到达服务器的端口号。  
$request\_uri 包含请求参数的原始URI，不包含主机名，如”/foo/bar.php?arg=baz”。  
$uri 不带请求参数的当前URI，$uri不包含主机名，如”/foo/bar.html”。  
$document\_uri 与$uri相同。

语法规则：

= ,!=  比较的一个变量和字符串  
~， ~\*  
与正则表达式匹配的变量，如果这个正则表达式中包含\}，;则整个表达式需要用"或'包  
围  
\-f，!-f 检查一个文件是否存在  
\-d, !-d 检查一个目录是否存在  
\-e，!-e 检查一个文件、目录、符号链接是否存在  
\-x， !-  
x  
检查一个文件是否可执行

IF指令

if 语法格式
      if 空格 (条件) {
       重写模式
      }
       # 限制浏览器访问
     if ($http_user_agent ~ Firefox) {
      rewrite ^(.*)$ /firefox/$1 break;
     }   
     if ($http_user_agent ~ MSIE) {
       rewrite ^(.*)$ /msie/$1 break;
     }   
     if ($http_user_agent ~ Chrome) {
       rewrite ^(.*)$ /chrome/$1 break;
     }

return指令：

# 限制IP访问
     if ($remote_addr = 192.168.197.142) {
       return 403;
     }

> 首先从日志查出ip  
> 修改conf配置文件  
> 重启配置

rewrite指令：

判断目录是否存在  
服务器内部的rewrite和302跳转不一样.跳转的话URL都变了,变成重新http请求index.html,而内部  
rewrite,上下文没变

if (!-e $document_root$fastcgi_script_name) {
       rewrite ^.*$ /index.html break;
     }

set指令：

set指令是设置变量用的,可以用来达到多条件判断时作标志用  
判断IE并重写,且不用break;我们用set变量来达到目的

if ($http_user_agent ~* msie) {
       set $isie 1;
     }
     if ($fastcgi_script_name = ie.html) {
       set $isie 0;
     }
     if ($isie 1) {
       rewrite ^.*$ ie.html;
     }

运行过程  
默认情况下，运行中的Nginx会包含如下进程：  
主进程master process（父进程）  
主进程充当监控进程  
负责整个进程组与管理用户的交互接口，同时对进程进行监护  
它不需要处理网络事件，不负责业务执行，只会通过管理worker进程来实现重启服务、关闭服务、配置文件生效等功能  
子进程worker process（工作进程）  
子进程充当工作进程  
负责完成具体的任务  
完成用户请求接收与返回用户数据，以及与后端应用服务器的数据交互等工作  
原理介绍：  
Nginx 的高并发得益于其采用了 epoll 模型，与传统的服务器程序架构不同，epoll 是linux 内核2.6 以后才出现的  
Nginx 采用 epoll 模型，异步非阻塞，而 Apache 采用的是select 模型  
Select 特点：select 选择句柄的时候，是遍历所有句柄，也就是说句柄有事件响应时，select需要遍历所有句柄才能获取到哪些句柄有事件通知，因此效率是非常低  
epoll 的特点：epoll 对于句柄事件的选择不是遍历的，是事件响应的，就是句柄上事件来就马上选择出来，不需要遍历整个句柄链表，因此效率非常

**2.代理模式**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70][]

**3. Nginx配t置web应用美群搭建**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 1][]

**4. Nginx负载均衡**

负载均衡的目的是为了解决单个节点压力过大，造成Web服务响应过慢，严重的情况下导致服务瘫痪，无法正常提供服务。

我们通常称对某一台机器的访问量称为负载量，如何将一个用户的请求，合理的分配到一台能快速响应用户请求的服务器上，我们就需要用到一些负载策略。也就体现出了文章主题的用意了：负载均衡，将用户的所有HTTP请求均衡的分配到每一台机器上，充分发挥所有机器的性能，提高服务的质量和用户体验。负载均衡可以通过负载均衡网络硬件设备和Web服务器软件来实现，前者设备成本较高，小公司通常负担不起，所以后者一般是我们的首选。实现负载均衡常用的Web服务器软件有Nginx、HAProxy、LVS、Apache

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 2][]

轮询法(默认)

• 将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载  
加权轮询法 (weight )

upstream tomcat_server {
    server 192.168.10.11:8080 weight=1;
    server 192.168.10.12:8080 weight=1;
    }

• 不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同  
• 给配置高、负载低的机器配置更高的权重，让其处理更多的请求  
• 配置低、负载高的机器，给其分配较低的权重，降低其系统负载  
• 加权轮询能很好地将请求顺序且按照权重分配到后端  
• weight的值越大分配到的访问概率越高

upstream tomcat_server {
    server 192.168.10.11:8080 weight=1;
    server 192.168.10.12:8080 weight=2;
    }

源地址哈希法  
• 根据获取客户端的IP地址，通过哈希函数计算得到一个数值  
• 用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号  
• 采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问  
• 可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题

upstream tomcat_server {
    ip_hash;
    server 192.168.10.11:8080 weight=1;
    server 192.168.10.12:8080 weight=1;
    }

最小连接数法（least\_conn）  
• 由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接  
数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器

upstream tomcat_server {
    least_conn;
    server 192.168.10.11:8080 weight=1;
    server 192.168.10.12:8080 weight=1;
    }

Fair  
• 比weight、ip\_hash更智能的负载均衡算法  
• 可以根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配  
• Nginx本身不支持fair，如果需要这种调度算法，则必须安装upsteram\_fair模块

upstream tomcat_server {
    fair;
    server 192.168.10.11:8080 weight=1;
    server 192.168.10.12:8080 weight=1;
    }

>  Fair插件安装  
> • 下载地址：https://github.com/gnosek/nginx-upstream-fair/tree/master  
> • 解压zip：unzip nginx-upstream-fair-master.zip  
> • 增加模块： ./configure --prefix=/opt/nginx --add-module=/opt/nginx-upstream-fair-master  
> • defalut\_port问题修改：cd nginx-upstream-fair-master  
> • sed -i 's/default\_port/no\_port/g' ngx\_http\_upstream\_fair\_module.c  
> • make  
> • make install

url\_hash  
• 按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器  
• 可以进一步提高后端缓存服务器的效率  
• Nginx本身不支持url\_hash，如果需要这种调度算法，则必须安装Nginx的hash软件包

upstream tomcat_server {
    hash $request_uri;
    server 192.168.10.11:8080 weight=1;
    server 192.168.10.12:8080 weight=1;
    }

>  hash插件安装  
> • 下载地址：https://github.com/evanmiller/nginx\_upstream\_hash  
> • 解压zip：unzip nginx\_upstream\_hash-master.zip  
> • 增加模块： ./configure --prefix=/opt/nginx --add-module=/opt/nginx\_upstream\_hash-master  
> • make  
> • make install

**5. Nginx配置日志**

通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息  
通过错误日志，你可以得到系统某个服务或server的性能瓶颈等  
日志生成的到根目录logs/access.log文件，默认使用“main”日志格式，也可以自定义格式  
默认“main”日志格式

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';
    $remote_addr： 客户端的ip地址(代理服务器，显示代理服务ip)
    $remote_user： 用于记录远程客户端的用户名称（一般为“-”）
    $time_local： 用于记录访问时间和时区
    $request： 用于记录请求的url以及请求方法
    $status： 响应状态码，例如：200成功、404页面找不到等。
    $body_bytes_sent： 给客户端发送的文件主体内容字节数
    $http_user_agent： 用户所使用的代理（一般为浏览器）
    $http_x_forwarded_for： 可以记录客户端IP，通过代理服务器来记录客户端的ip地址
    $http_referer： 可以记录用户是从哪个链接访问过来的

nginx的日志文件没有rotate功能  
编写每天生成一个日志，我们可以写一个nginx日志切割脚本来自动切割日志文件  
第一步就是重命名日志文件 （不用担心重命名后nginx找不到日志文件而丢失日志。在你未重新打开原名字的日志文件前，nginx还是会向你重命名的文件写日志，Linux是靠文件描述符而不是文件名定位文件 ）  
第二步向nginx主进程发送USR1信号  
nginx主进程接到信号后会从配置文件中读取日志文件名称重新打开日志文件 (以配置文件中的日志名称命名) ，并以工作进程的用户作为日志文件的所有者重新打开日志文件后，nginx主进程会关闭重名的日志文件并通知工作进程使用新打开的日志文件  
工作进程立刻打开新的日志文件并关闭重名名的日志文件然后你就可以处理旧的日志文件了。\[或者重启nginx服务\]

nginx日志按每分钟自动切割脚本如下 ：

vi  /opt/nginx/nginx_log.sh

#!/bin/bash
    #设置日志文件存放目录
    LOG_HOME="/opt/nginx/logs/"
    #备分文件名称
    LOG_PATH_BAK="$(date -d yesterday +%Y%m%d%H%M)".access.log
    #重命名日志文件
    mv ${LOG_HOME}/access.log ${LOG_HOME}/${LOG_PATH_BAK}.log
    #向nginx主进程发信号重新打开日志
    kill -USR1 `cat /opt/nginx/logs/nginx.pid`

创建crontab设置作业

设置日志文件存放目录crontab -e

*/1 * * * * sh /opt/nginx/nginx_log.sh

**6. Nginx动静分离(缓存**

Nginx 动静分离简单来说就是把动态跟静态请求分开，不能理解成只是单纯的把动态页面和静态  
页面物理分离  
严格意义上说应该是动态请求跟静态请求分开，可以理解成使用Nginx 处理静态页面，Tomcat处  
理动态页面  
动静分离从目前实现角度来讲大致分为两种  
1. 一种是纯粹把静态文件独立成单独的域名，放在独立的服务器上，也是目前主流推崇的方案  
2. 一种是动态跟静态文件混合在一起发布，通过 nginx 来分开

通过 location 指定不同的后缀名实现不同的请求转发  
通过 expires 参数设置，可以使浏览器缓存过期时间，减少与服务器之前的请求和流量  
Expires 定义：是给一个资源设定一个过期时间，也就是说无需去服务端验证，直接通过浏览器自身确认是否过期即可，所以不会产生额外的流量  
此种方法非常适合不经常变动的资源。（如果经常更新的文件，不建议使用 Expires 来缓存）  
这里设置 3d，表示在这 3 天之内访问这个 URL，发送一个请求，比对服务器该文件最后更新时间没有变化，则不会从服务器抓取，返回状态码 304，如果有修改，则直接从服务器重新下载，返回状态码 200

示例：  
新建一个web工程，并设置一张图片  
修改nginx配置文件：

server {
       listen    80;
       server_name a;
       
         
       location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
       { 
       root /opt/apache-tomcat-8.5.31/webapps/;
       expires 30d;
       } 
     }

**7.热部署**

略

### 3，高并发下的nginx优化 ###

**1.高并发架构分析**

什么是高并发?  
• 高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。  
• 高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。  
• 响应时间：系统对请求做出响应的时间  
• 吞吐量：单位时间内处理的请求数量。  
• QPS：每秒响应请求数

如何提升系统的并发能力?  
• 互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（ScaleUp）与水平扩展（Scale Out）。  
• 垂直扩展：提升单机处理能力。垂直扩展的方式又有两种。  
• 增强单机硬件性能  
• 提升单机架构性能  
在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。  
不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。水平扩展：只要增加服务器数量，就能线性扩充系统性能。

**2．高并发下Nginx配置限流**

三种方式实现：  
• limit\_conn\_zone  
• limit\_req\_zone  
• ngx\_http\_upstream\_module  
前两种只能对客户端（即单一ip限流）

Ab工具：

Centos安装：yum install httpd-tools –y  
测试：ab -c 10 -n 1000 http://www.test.com/

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 3][]

limit\_conn\_zone

http{
    limit_conn_zone $binary_remote_addr zone=one:10m;
    server
    {
    ......
    limit_conn one 10;
    ......
    }
    }

> • 其中“limit\_conn one 10”既可以放在server层对整个server有效，也可以放在location中只对单独的location有效  
> • 该配置表明：客户端的并发连接数只能是10个。

limit\_req\_zone

http{
    limit_req_zone $binary_remote_addr zone=req_one:10m rate=1r/s;
    server
    {
    ......
    limit_req zone=req_one burst=120;
    ......
    }
    }

> • 其中“limit\_req zone=req\_one burst=120”既可以放在server层对整个server有效，也可以放在location中只对单独的location有效  
> • rate=1r/s的意思是每个地址每秒只能请求一次，也就是说令牌桶burst=120一共有120块令牌，并且每秒钟只新增1块令牌，120块令牌发完后，多出来的请求就会返回503

ngx\_http\_upstream\_module(推荐)

upstream xxxx{
    server 127.0.0.1:8080 max_conns=10;
    server 127.0.0.1:8081 max_conns=10;
    }

• 该模块是提供了我们需要的后端限流功能的  
• 该模块有一个参数：max\_conns可以对服务端进行限流，可惜在商业版nginx中才能使用  
• 在nginx1.11.5版本以后，官方已经将该参数从商业版中脱离出来了，也就是说只要我们将生产上广泛使用的nginx1.9.12版本和1.10版本升级即可使用

**3．高并发下Nginx安全配置**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 4][]

**4. Nginx配置优化之进程数、并发连接数**

调整Nginx的主配置文件,增加并发量

worker_processes 2; #调整到与CPU数量一致
    events {
    worker_connection 65535; #每个worker最大并发连接数
    }

调整内核参数

[root@proxy ~]# ulimit -a #查看所有的属性值
    [root@proxy ~]# ulimit -Hn 100000 #临时设置硬限制
    [root@proxy ~]# ulimit -Sn 100000 #设置软限制
    [root@proxy ~]# vim /etc/security/limits.conf
    ...
    * soft nofile 100000
    * hard nofile 100000
    用户/组 软/硬限制 需要限制的项目 限制的值

验证

[root@proxy ~]# ab -n 2000 -c 2000 http://192.168.136.131/ #自己访问自己,测试一下配置效果

**5. Nginx配置优化之长连接**

nginx长连接短连接，可以增强服务器的容灾能力  
场景：  
HTTP1.1之后，HTTP协议支持持久连接，也就是长连接，优点在于在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。如果我们使用了nginx去作为反向代理或者负载均衡，从客户端过来的长连接请求就会被转换成短连接发送给服务器端，为了支持长连接，我们需要在nginx服务器上做一些配置  
要求：  
使用nginx时，想要做到长连接，我们必须做到以下两点：  
1：从client到nginx是长连接  
2：从nginx到server是长连接  
对于客户端而言，nginx其实扮演着server的角色，反之，之于server，nginx就是一个client  
配置：  
我们要想做到Client与Nginx之间保持长连接，需要：  
1：Client发送过来的请求携带 "keep-alive "header。  
2：Nginx设置支持keep-alive

**6. Nginx配置优化之压缩**

gzip压缩作用：将响应报⽂发送⾄客户端之前可以启⽤压缩功能，这能够有效地节约带宽，并提⾼响应⾄客户端的速度,压缩会消耗nginx的cpu性能。  
gzip压缩可以配置http,server和location模块下

**7. Nginx配置优化之系统优化**

**略**

**8.Nginx配置优化之状态监控**

配置Nginx的监控选项(配置文件路径：nginx.conf)  
添加如下代码：

#设定Nginx状态访问地址
    location /NginxStatus {
    stub_status on;
    access_log off;
    }

配置完成重启Nginx  
配置完成后在浏览器中输入http://192.168.136.131/NginxStatus查看

> 参数说明：  
> \#活跃的连接数量  
> active connections  
> \#总共处理了n个连接 , 成功创建n次握手, 总共处理了n个请求  
> server accepts handled requests  
> \#每个连接有三种状态waiting、reading、writing  
> reading —读取客户端的Header信息数.这个操作只是读取头部信息，读取完后马上进入writing状态，因此时间很短  
> writing — 响应数据到客户端的Header信息数.这个操作不仅读取头部，还要等待服务响应，因此时间比较长。  
> waiting — 开启keep-alive后等候下一次请求指令的驻留连接.  
> 正常情况下waiting数量是比较多的，并不能说明性能差。反而如果reading+writing数量比较多说明服务并发有问题。  
> 查看Nginx并发进程数：ps -ef|grep nginx | wc -l  
> 查看Web服务器TCP连接状态：netstat -n | awk '/^tcp/ \{++S\[$NF\]\} END \{for(a in S) print a, S\[a\]\}'

> 解析：  
> CLOSED //无连接是活动的或正在进行  
> LISTEN //服务器在等待进入呼叫  
> SYN\_RECV //一个连接请求已经到达，等待确认  
> SYN\_SENT //应用已经开始，打开一个连接  
> ESTABLISHED //正常数据传输状态/当前并发连接数  
> FIN\_WAIT1 //应用说它已经完成  
> FIN\_WAIT2 //另一边已同意释放  
> ITMED\_WAIT //等待所有分组死掉  
> CLOSING //两边同时尝试关闭  
> TIME\_WAIT //另一边已初始化一个释放  
> LAST\_ACK //等待所有分组死掉  
> 查看Web服务器TCP连接状态：netstat -n | awk '/^tcp/ \{++S\[$NF\]\} END \{for(a in S) print a, S\[a\]\}'

**9. Nginx与其它解决方案搭配组合**  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 5][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70]: /images/20210920/817f9da925b3496ca3f28cf3590c8a4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 1]: /images/20210920/47c1a4f23dbc48c885c83d8ecd426577.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 2]: /images/20210920/6d362f57daea474b95467fe12a138232.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 3]: /images/20210920/0c452880c7d644f9b549c220b6186056.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 4]: /images/20210920/455ebfafeb85409298e78210ffdc50bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VjaGl6YW8xODM5_size_16_color_FFFFFF_t_70 5]: /images/20210920/239bb222026b4a2a9cd053401edda470.png