nginx应用及性能调优

1. Nginx 反向代理实现

说反向代理之前 先说什么是正向代理,

正向代理是指客户端通过 代理服务器访问目标服务器，客户端直接访问代理服务器，在由代理服务器访问目标服务器并返回客户端并返回 。

例如vpn, 客户端无法直接访问服务端,所有由 代理服务器访问, 此时代理服务器 代理的对象为客户端

正向代理示意图:

反向代理是指 客户端访问目标服务器，在目标服务内部有一个统一接入的服务器,并由此服务去访问内部的真实服务,这个过程当中客户端对代理服务器是无感的,此时 代理服务器的对象是后端的真实服务

例如负载均衡,可能我们部署了连个tomcat,但是用户是无感的,由代理服务器去选择

反向代理示意图:

总结: 正反向代理只是业务的场景 , 结构不同,但是其技术实现都是一样的

​ 正向代理 代理的是客户端,

​ 反向代理 代理的服务端.

基本配置,使用proxy_pass 属性即可

# 拦截/test 反向代理至 本机的8010服务
# http://127.0.0.1:8010 后面如果不加斜杠,则会将拦截的url拼接到后面http://127.0.0.1:8010/test
location /test/ {
     proxy_pass http://127.0.0.1:8010;  
}

相关参数,(相关时间参数都是秒)

ngx_http_proxy_module模块文档:

http://nginx.org/en/docs/http/ngx_http_proxy_module.html

proxy_pass  http://127.0.0.1:8010;   # 代理服务
proxy_redirect off;   # 是否允许重定向
proxy_set_header Host $host; # 向代理的后端传 header
proxy_set_header X-Forwarded-For $remote_addr; # 传客户端ip
proxy_connect_timeout 90; # 连接代理服务超时时间(发起握手的超时时间)
proxy_send_timeout 90; # 后端处理完成后,nginx 发送消息的最大时间
proxy_read_timeout 90;  # 连接成功后,等候后端服务器响应时间
proxy_buffer_size 4k; # 设置缓冲区大小(缓存后端响应的响应头信息)，
proxy_buffers 4 32k; #设置缓冲区的数量和大小(缓存响应体)。四个32k的缓存 不够才开辟新的
proxy_busy_buffers_size 64k; # 设置 专门划出一部分buffer 向客户端传送数据,其他部分的buffer继续读取后端响应,建议为proxy_buffers中单个缓冲区的2倍,这个缓存 是proxy_buffers和proxy_buffer_size的一部分。
proxy_temp_file_write_size 64k;# 当proxy_buffers和proxy_buffer_size的buffer满时,会将额外的数据存到临时文件,这个值指定临时文件的大小

2. 负载均衡

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

master进程会将我么配置的待负载服务进行监控,当有服务挂掉时,会自动剔除出去,当服务又恢复时,则会重新添加进去

ngx_http_upstream_module模块

http://nginx.org/en/docs/http/ngx_http_upstream_module.html

基本实现:

# 待负载的 服务端地址列表,默认为轮询的方式负载
upstream backend {     
   server 127.0.0.1:8010;
   server 127.0.0.1:8080;
}
#拦截请求 并转到负载地址
location / {
    proxy_pass http://backend;
}

加权重的方式(不加权重默认都为1):

# 8080 的访问量是 8081的二倍
upstream backend {     
   server 127.0.0.1:8010 weight=1;
   server 127.0.0.1:8080 weight=2;
}

upstream 相关参数:

upstream dynamic {
	# weight 加权重
    server backend1.example.com      weight=5;
    # 设置这个服务的 在五秒内 三次失败 则剔除该服务,并且下次检测时间为3秒后,即禁用3s
    server backend2.example.com:8080 fail_timeout=5s max_fails=3;
    # 该服务同时最多连接数量,默认为0 没有限制
    server 192.0.2.1                 max_conns=200;
    # 权重负载均衡模式下,当服务重新可用时,权重在多少时间内恢复,默认为0
    server backend3.example.com      slow_start=5s;

    # 设置该服务为备胎,如果上面几个都挂了 才访问这个
    server backup2.example.com:8080  backup;
}

upstream 负载均衡算法

1. weight： 轮询加权重 (默认)

2. ip_hash : 基于Hash 计算 ,用于保持session 一致性,确保了来自同一客户端的请求将始终传递到同一服务器

   除非该服务器不可用

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
}

1. url_hash: 对url进行hash算法,固定的url访问固定的服务器,(静态资源缓存,节约存储)

upstream backend {
    hash $request_uri;

    server backend1.example.com;
    server backend2.example.com;
}

1. least_conn: 将请求传递到活跃连接数最少的服务器。如果有多个这样的服务器，则依次使用加权循环平衡方法进行尝试。

upstream backend {
    least_conn;

    server backend1.example.com weight=5;
    server backend2.example.com weight=3;
    server backend3.example.com;
}

1. least_time : 将请求传递到服务器的平均响应时间最短且活动连接数最少，如果有多个这样的服务器，则依次使用加权循环平衡方法进行尝试。

3. nginx缓存

将后端的js 图片 等静态资源缓存在nginx服务器上 减少后端局域网的压力

配置 缓存:

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;
}

# 在http跟节点中配置
# proxy_cache_path 缓存文件存放路径
# levels 缓存层级及目录位数,用于分散缓存文件 1:2 代表 如果生成的缓存文件为jiojndong481lj,那么存放的路# # 径就为 j/1l/jiojndong481lj,也可以继续像下分 1:2:1 则为: j/1l/8/jiojndong481lj
# keys_zone 指定缓存区名称及缓存区内存大小
# inactive 有效期,20天 缓存数据没有使用 就清除
# max_size 最大存放硬盘的数据
proxy_cache_path /data/nginx/cache_test levels=1:2 keys_zone=cache_test:500m inactive=20d max_size=1g;

location / {
    proxy_pass http://backend;
    # 指定缓存区
	proxy_cache cache_test;
	#指定以什么作为编码md5值做为Key (本案例为全路径 www.test.com/user/config)
	proxy_cache_key $host$uri$is_args$args;
	#对不同的HTTP状态码设置不同的缓存时间(200 和 304 的有效期为12小时)
	proxy_cache_valid 200 304 12h;
}

通过 www.test.com/user/config访问后端的js文件 ,则会在 e/1b文件夹下生成b1490d97f2b90b9fe92a0f6e949b91be文件

清除缓存

1. 手动删除缓存文件夹

2. 采用第三方模块 ngx_cache_purge 实现。(需要在安装时指定)

官网:http://labs.frickle.com/nginx_ngx_cache_purge/

下载解压后重新编译nginx,进入nginx安装包目录 重新安装 --add-module为模块解压的全路径,(需要依赖http_stub_status_module和http_ssl_module) ,具体安装方法 参考上一篇nginx文章

./configure --with-http_stub_status_module --with-http_ssl_module  --add-module=/root/svr/packages/ngx_cache_purge-2.3

配置: 使用正则匹配 ,/clear/(正则), 使用$1 取得正则匹配到的第一个参数,即为 clear后面的url

例如: /clear/user/config 则 $1 为/user/config

location ~ /clear(/.*) {
  	#允许访问的IP
   allow           127.0.0.1;
   #禁止访问的IP
   deny            all;
   #配置清除指定缓存区和路径(与proxy_cache_key一至)
   proxy_cache_purge    cache_test $host$1$is_args$args;
}

使用:如果清除的缓存不存在 则404

# 访问清除路径
http://www.test.com/clear/user/config?a=1
# 清除的缓存key
www.test.com/user/config?a=1

4. nginx性能调优

1. worker_processes number;

   每个worker进程都是单线程的进程，默认为一个,虽然异步非阻塞的模型可以充分使用这个线程.

   但是如果有可能出现阻塞式调用，或者请求量过大,那么需要配置稍多一些的worker进程。

   # 一般配置为 CPU核心数,充分使用cpu
   worker_processes  4;
   

   但是 每个线程选择CPU核 处理时 是不固定的 有可能使某一个CPU核心负载过大,如果是linux系统,可以固定每个线程的CPU

   # 例如 CPU核心数为4的情况
   worker_processes  4;
   worker_cpu_affinity 1000 0100 0010 0001;
   

   同样 我们也可以 配置 每个worker线程最大的连接数

   #默认的配置为 1024 可以根据需要调大一些
   events {
       worker_connections  1024;
   }
   

   那么 一个nginx 最大的连接数就为 worker_connections*worker_processes

2. worker_priority number;

   Linux系统中,进程占用CPU执行任务的优先级由静态优先级和系统内核的调整共同决定,

   静态优先级 为用户自定义 ,-20 ~ +19,-20为最高优先级,19位最低,默认为0,

   内核会根据进程的实际执行情况 去调整优先级 一般为 ±5

   worker_processes  4;
   worker_cpu_affinity 1000 0100 0010 0001;
   #调整优先级 为-5 ,一般不建议低于这个值
   worker_priority -5;
   

3. worker_rlimit_nofile limit;

   更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制“ulimit -a”，“too many open files”这个错误就可以调大这个值

   worker_processes  4;
   worker_cpu_affinity 1000 0100 0010 0001;
   worker_priority -5;
   #worker线程最大打开文件数
   worker_rlimit_nofile 65535;
   

4. accept_mutex[on|off]

   跨进程锁

   worker进程 的负载均衡锁,如果accept_mutex启用，则当有新的连接时,只有获取到锁的worker线程 会被唤醒,并处理新的连接,并将锁依次向下传递(worker当前处理连接数大于worker_connections的7/8时,将不会再去争抢锁),

   如果关闭,则当有新的连接时 则会唤醒所有的worker ,最后只交给一个进程执行 (惊群问题),造成资源的浪费,所以为了解决这个问题,在1.11.3版之前，默认值为on。之后因为linux epool的实现 本身解决了这个问题 默认为off.

   #配置在events中 所有进程共享
   events{
       accept_mutex on;
   }