性能调优06Nginx核心模块与实战

Nginx

1、Nginx 简介

​ Nginx是一个高性能WEB服务器,除它之外ApacheTomcatJettyIIS,它们都是Web服务器,或者叫做WWW(World Wide Web)服务器,相应地也都具备Web服务器的基本功能。Nginx 相对基它WEB服务有什么优势呢?

  1. Tomcat、Jetty 面向java语言,先天就是重量级的WEB服务器,其性能与Nginx没有可比性。
  2. IIS只能在Windows操作系统上运行。Windows作为服务器在稳定性与其他一些性能上都不如类UNIX操作系统,因此,在需要高性能Web服务器的场合下IIS并不占优。
  3. Apache(一个线程处理一个请求)的发展时期很长,而且是目前毫无争议的世界第一大Web服务器,其有许多优点,如稳定、开源、跨平台等,但它出现的时间太长了,在它兴起的年代,互联网的产业规模远远比不上今天,所以它被设计成了一个重量级的、不支持高并发的Web服务器。在Apache服务器上,如果有数以万计的并发HTTP请求同时访问,就会导致服务器上消耗大量内存,操作系统内核对成百上千的Apache进程做进程间切换也会消耗大量CPU资源,并导致HTTP请求的平均响应速度降低,这些都决定了Apache不可能成为高性能Web服务器,这也促使了Lighttpd和Nginx的出现。

2、编译安装与基本命令

​ 略

控制命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#查看命令帮助
./sbin/nginx -?
#默认方式启动:
./sbin/nginx
#指定配置文件启动
./sbing/nginx -c /tmp/nginx.conf
#指定nginx程序目录启动
./sbin/nginx -p /usr/local/nginx/

#快速停止
./sbin/nginx -s stop
#优雅停止
./sbin/nginx -s quit

# 热装载配置文件 
./sbin/nginx -s reload
# 重新打开日志文件
./sbin/nginx -s reopen
# 设置全局命令,如下表示设置启动用户为root
./sbin/nginx -g "user root;"

3、Nginx 架构说明

image-20211004150428318

架构说明:

1)nginx启动时,master进程启动,不处理网络请求,主要负责调度工作进程,也就是图示的三项:加载配置、启动工作进程及非停升级。所以,nginx启动以后,查看操作系统的进程列表,我们就能看到至少有两个nginx进程。
2)服务器实际处理网络请求及响应的是工作进程(worker),在类unix系统上,nginx可以配置多个worker,而每个worker进程都可以同时处理数以千计的网络请求。
3)模块化设计。nginx的worker,包括核心和功能性模块,核心模块负责维持一个运行循环(run-loop),执行网络请求处理的不同阶段的模块功能,如网络读写、存储读写、内容传输、外出过滤,以及将请求发往上游服务器等。而其代码的模块化设计,也使得我们可以根据需要对功能模块进行适当的选择和修改,编译成具有特定功能的服务器。
4)事件驱动、异步及非阻塞,可以说是nginx得以获得高并发、高性能的关键因素,同时也得益于对Linux、Solaris及类BSD等操作系统内核中事件通知及I/O性能增强功能的采用,如kqueue、epoll及event ports。

nginx核心模块

image-20221016095857685

4、Nginx 配置与使用

1、配置文件语法格式

先来看一个简单的nginx 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;
        location / {
            root   html;
            index  index.html index.htm;
        }
location /nginx_status {
       stub_status on;
       access_log   off;
}
}
}

​ 上述配置中的events、http、server、location、upstream等属于配置项块。而worker_processes 、worker_connections、include、listen 属于配置项块中的属性。 /nginx_status 属于配置块的特定参数参数。其中server块嵌套于http块,其可以直接继承访问Http块当中的参数。

**配置块 ** 名称开头用大括号包裹其对应属性
属性 基于空格切分属性名与属性值,属性值可能有多个项 都以空格进行切分 如: access_log logs/host.access.log main
参数 其配置在块名称与大括号间,其值如果有多个也是通过空格进行拆

​ 注意 如果配置项值中包括语法符号,比如空格符,那么需要使用单引号或双引号括住配置项值,否则Nginx会报语法错误。例如:
​ log_format main ‘$remote_addr - $remote_user [$time_local] “$request” ‘
​ ‘$status $body_bytes_sent “$http_referer” ‘
​ ‘“$http_user_agent” “$http_x_forwarded_for”‘;

2、配置第一个静态WEB服务

  • 基础站点演示:
  • 创建站点目录 mkdir -p /usr/www/luban
  • 编写静态文件
  • 配置 nginx.conf
    • 配置server
    • 配置location

基本配置介绍说明:
(1)监听端口

​ 语法:listen address:
​ 默认:listen 80;
​ 配置块:server

(2)主机名称

​ 语法:server_name name[……];
​ 默认:server_name “”;
​ 配置块:server
​ server_name后可以跟多个主机名称,如server_name www.testweb.com、download.testweb.com;。 支持通配符与正则

(3)location

​ 语法:location[=|~|~*|^~|@]/uri/{……}
​ 配置块:server

  1. =表示把URI作为字符串,以便与参数中的uri做完全匹配。
  2. / 基于uri目录匹配
  3. ~表示正则匹配URI时是字母大小写敏感的。
  4. ~*表示正则匹配URI时忽略字母大小写问题。
  5. ~^表示正则匹配URI时只需要其前半部分与uri参数匹配即可。

3、匹配优先规则:

  1.     精确匹配优先 =
  2.     正则匹配优先 ^~
  3.     前缀最大匹配优先。
  4.     配置靠前优先

(4)root 指定站点根目录

可配置在 server与location中,基于ROOT路径+URL中路径去寻找指定文件。

(5)alias 指定站点别名

只能配置location 中。基于alias 路径+ URL移除location 前缀后的路径来寻找文件。

image-20211004160702044

如下示例:

1
2
3
4
5
6
7
location /V1 {
      alias  /www/old_site;
      index  index.html index.htm;
}
#访问规则如下
URL:http://xxx:xx/V1/a.html
最终寻址:/www/old_site/a.thml

4、动静分离演示:

​ 创建静态站点

​ 配置 location /static

​ 配置 ~* .(gif|png|css|js)$

分离2种方式可以实现资源动静分离

1、基于目录动静资源分离

1
2
3
4
5
6
7
8
9
10
11
   server {
        listen 80;
        server_name *.luban.com;
        root /usr/www/luban;
        location / {
                index luban.html;
        }
        location /static {
         alias /usr/www/static;
        }
 }

2、基于正则动静分离

1
2
3
location ~* \.(gif|jpg|png|css|js)$ {  
      root /usr/www/static;
}

5、防盗链配置演示:

1
2
3
4
5
# 加入至指定location 即可实现
valid_referers none blocked *.luban.com;
 if ($invalid_referer) {
       return 403;
}

6、下载限速:

1
2
3
4
5
location /download {
    limit_rate 1m; //限制每S下载速度
limit_rate_after 30m; // 超过30m之后再限速
}

7、创建IP黑名单

1
2
3
4
5
6
7
8
9
10
11
12
13
#封禁指定IP
deny 192.168.0.1;
allow 192.168.0.1;
#开放指定IP 段
allow 192.168.0.0/24;
#封禁所有
deny all;
#开放所有
allow all;
# 创建黑名单文件
echo 'deny 192.168.0.132;' >> balck.ip
#http 配置块中引入 黑名单文件
include       black.ip;

5、日志配置

日志格式:

1
2
3
4
5
6
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;
#基于域名打印日志
access_log logs/$host.access.log main;

error日志的设置
语法:error_log /path/file level;
默认:error_log logs/error.log error;
level是日志的输出级别,取值范围是debug、info、notice、warn、error、crit、alert、emerg,
针对指定的客户端输出debug级别的日志
语法:debug_connection[IP|CIDR]
events {
debug_connection 192.168.0.147; 
debug_connection 10.224.57.0/200;
}
注意:debug 日志开启 必须在安装时 添加 –with-debug (允许debug)

6、正向代理与反向代理

正向代理

​ 正向代理是指客户端与目标服务器之间增加一个代理服务器,客户端直接访问代理服务器,在由代理服务器访问目标服务器并返回客户端并返回 。这个过程当中客户端需要知道代理服务器地址,并配置连接。

image-20211227222908381

反向代理

​ 反向代理是指客户端访问目标服务器,在目标服务内部有一个统一接入网关将请求转发至后端真正处理的服务器并返回结果。这个过程当中客户端不需要知道代理服务器地址,代理对客户端而言是透明的。

​ 技术实现与正向代理没有区别,最大的区别是应用场景,主要目的是屏蔽服务端的内部实现

image-20211227223047489

反向代理:技术实现与正向代理没有区别,最大的区别是应用场景,主要目的是屏蔽服务端的内部实现

正向代理:

正向代理 反向代理
代理服务器位置 客户端与服务都能连接的们位置 目标服务器内部
主要作用 屏蔽客户端IP、集中式缓存、解决客户端不能直连服务端的问题。 屏蔽服务端内部实现、负载均衡、缓存。
应用场景 爬虫、翻墙、maven 的nexus 服务 Nginx 、Apache负载均衡应用

Nginx代理基本配置

​ Nginx 代理只需要配置 location 中配置proxy_pass 属性即可。其指向代理的服务器地址。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 正向代理到baidu 服务
location = /baidu.html {
         proxy_pass http://www.baidu.com;
}
# 反向代理至 本机的8010服务
location /luban/ {
     proxy_pass http://127.0.0.1:8010;  
}
# 代理相关参数:
proxy_pass           # 代理服务
proxy_redirect off;   # 是否允许重定向
proxy_set_header Host $host; # 传 header 参数至后端服务
proxy_set_header X-Forwarded-For $remote_addr; # 设置request header 即客户端IP 地址
proxy_connect_timeout 90; # 连接代理服务超时时间
proxy_send_timeout 90; # 请求发送最大时间
proxy_read_timeout 90;  # 读取最大时间
proxy_buffer_size 4k; 
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k; 
proxy_temp_file_write_size 64k;

7、负载均衡

​ 通过proxy_pass 可以把请求代理至后端服务,但是为了实现更高的负载及性能, 我们的后端服务通常是多个, 这个是时候可以通过upstream 模块实现负载均衡。

upstream示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
upstream backend {     
server 127.0.0.1:8010 weight=1;
   server 127.0.0.1:8080 weight=2;

server 127.0.0.1:8030 weight=1 backup;
}
location / {
    proxy_pass http://backend;
}

# upstream 相关参数:
server 反向服务地址 加端口
weight 权重
max_fails 失败多少次 认为主机已挂掉则,踢出
fail_timeout 踢出后重新探测时间
backup 备用服务
max_conns 允许最大连接数
slow_start 当节点恢复,不立即加入,而是等待 slow_start 后加入服务对列。

upstream 负载均衡算法介绍

  • **ll+weight: **轮询加权重 (默认)
  • **ip_hash : **基于Hash 计算 ,用于保持session 一至性
  • url_hash: 静态资源缓存,节约存储,加快速度(第三方)
  • **least_conn **:最少链接(第三方)
  • **least_time  **:最小的响应时间,计算节点平均响应时间,然后取响应最快的那个,分配更高权重(第三方)

8、Nginx 高速缓存

1、案例分析

​ 某电商平台商品详情页需要实现 700+ QPS,如何着手去做?

image-20211228205614945

⾸先为分析⼀下⼀个商品详情⻚有哪些信息

**对于商品详情页涉及了如下主要服务: **

  • 商品详情页HTML页面渲染

  • 价格服务

  • 促销服务

  • 库存状态/配送至服务

  • 广告词服务

  • 预售/秒杀服务

  • 评价服务

  • 试用服务

  • 推荐服务

  • 商品介绍服务

  • 各品类相关的一些特殊服务

  • 解决方案:*

  1. 采用Ajax 动态加载 价格、广告、库存等服务
  2. 采用key value 缓存详情页主体html。

1、后台采用缓存

image-20211228210221149

问题:
当达到500QPS 的时候很难继续压测上去。
分析原因

​ 一个详情页html 主体达平均150 kb 那么在500QPS 已接近千M局域网宽带极限。必须减少内网通信。

2、基于Nginx 静态缓存

image-20211228210706401

Nginx 静态缓存基本配置

一、在http元素下添加缓存区声明

1
2
3
4
5
6
#proxy_cache_path 缓存路径
#levels 缓存层级及目录位数
#keys_zone 缓存区内存大小
#inactive 有效期
#max_size 硬盘大小
proxy_cache_path /data/nginx/cache_luban levels=1:2 keys_zone=cache_luban:500m inactive=20d max_size=1g;

⼆、为指定location设定缓存策略

1
2
3
4
5
6
# 指定缓存区
proxy_cache cache_luban;
#以全路径md5值做做为Key 
proxy_cache_key $host$uri$is_args$args;
#对不同的HTTP状态码设置不同的缓存时间
proxy_cache_valid 200 304 12h;
父元素 名称 描述
http proxy_cache_path 指定缓存区的根路径
levels 缓存目录层级最高三层,每层1~2个字符表示。如1:1:2 表示三层。
keys_zone 缓存块名称 及内存块大小。如 cache_item:500m 。表示声明一个名为cache_item 大小为500m。超出大小后最早的数据将会被清除。
inactive 最长闲置时间 如:10d 如果一个数据被闲置10天将会被清除
max_size 缓存区硬盘最大值。超出闲置数据将会被清除
location proxy_cache 指定缓存区,对应keys_zone 中设置的值
proxy_cache_key 通过参数拼装缓存key 如:$host$uri$is_args$args 则会以全路径md5值做做为Key
proxy_cache_valid 为不同的状态码设置缓存有效期

三、缓存的清除

该功能可以采用第三方模块 ngx_cache_purge 实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
location ~ /clear(/.*) {
  #允许访问的IP
   allow           127.0.0.1;
   #禁止访问的IP
   deny            all;
   #配置清除指定缓存区和路径(与proxy_cache_key一至)
   proxy_cache_purge    cache_luban $host$1$is_args$args;
}

# 访问生成缓存文件
http://www.luban.com/?a=1
# 清除生成的缓存,如果指定缓存不存在 则会报404 错误。
http://www.luban.com/clear/?a=1

9、Nginx 性能参数调优

worker_processes number;

每个worker进程都是单线程的进程
它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用,那么,有多少CPU内核就应该配置多少个进程;反之,如果有可能出现阻塞式调用,那么需要配置稍多一些的worker进程。例如,如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件,而且服务器上的内存较小,以至于大部分的请求访问静态资源文件时都必须读取磁盘(磁头的寻址是缓慢的),而不是内存中的磁盘缓存,那么磁盘I/O调用可能会阻塞住worker进程少量时间,进而导致服务整体性能下降。

worker_connections number;

每个worker 进程的最大连接数
语法:worker_connections number;
默认:worker_connections 1024

worker_cpu_affinity cpumask[cpumask……]

绑定Nginx worker进程到指定的CPU内核
为什么要绑定worker进程到指定的CPU内核呢?假定每一个worker进程都是非常繁忙的,如果多个worker进程都在抢同一个CPU,那么这就会出现同步问题。反之,如果每一个worker进程都独享一个CPU,就在内核的调度策略上实现了完全的并发。
例如,如果有4颗CPU内核,就可以进行如下配置:
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
注意 worker_cpu_affinity配置仅对Linux操作系统有效。

Nginx worker 进程优先级设置

语法:worker_priority nice;
默认:worker_priority 0;
优先级由静态优先级和内核根据进程执行情况所做的动态调整(目前只有±5的调整)共同决定。nice值是进程的静态优先级,它的取值范围是–20~+19,–20是最高优先级,+19是最低优先级。因此,如果用户希望Nginx占有更多的系统资源,那么可以把nice值配置得更小一些,但不建议比内核进程的nice值(通常为–5)还要小

Nginx worker进程可以打开的最大句柄描述符个数

语法: worker_rlimit_nofile limit;
默认:空
更改worker进程的最大打开文件数限制。如果没设置的话,这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件,所以把这个值设高,这样nginx就不会有“too many open files”问题了。

是否打开accept锁

语法:accept_mutex[on|off]
默认:accept_mutext on;
accept_mutex是Nginx的负载均衡锁,当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时,会大大地减小该worker进程试图建立新TCP连接的机会,accept锁默认是打开的,如果关闭它,那么建立TCP连接的耗时会更短,但worker进程之间的负载会非常不均衡,因此不建议关闭它。

使用accept锁后到真正建立连接之间的延迟时间

语法:accept_mutex_delay Nms; 
默认:accept_mutex_delay 500ms; 
在使用accept锁后,同一时间只有一个worker进程能够取到accept锁。这个accept锁不是堵塞锁,如果取不到会立刻返回。如果只有一个worker进程试图取锁而没有取到,他至少要等待accept_mutex_delay定义的时间才能再次试图取锁。