第四节：Nginx负载均衡配置、缓存配置、性能调优

一. 负载均衡

1. 用法

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

负载均衡的算法有：

ll：轮询
ll+weight： 轮询加权重
ip_hash : 基于Hash 计算，用于保持session 一至性 该算法下权重失效
url_hash: 静态资源缓存，节约存储，加快速度（第三方） 该算法下权重配置失效
least_conn ：最少链接（第三方）
least_time ：最小的响应时间,计算节点平均响应时间，然后取响应最快的那个，分配更高权重（第三方）

2. 参数

upstream 相关参数如下：

server 反向服务地址加端口
weight 权重，默认是1，越大权重就越大
max_fails 失败多少次认为主机已挂掉则，踢出 （默认配置10s，即服务器宕掉，会自动剔除）
fail_timeout 踢出后重新探测时间
backup 备用服务，当其他非backup的机器全部宕机或者繁忙的时候，才会启动这台机器。
down 表示当前Server不参与负载
max_conns 允许最大连接数
slow_start 当节点恢复，不立即加入,而是等待 slow_start 后加入服务对列。

3. 案例

事先准备：

　有三个同样的api服务，分别部署在9001、9002、9003端口下，比如：访问 http://localhost:9001/Home/GetMsg，会返回【获取成功，当前端口为：9001】，其它端口类似。

要求：

　Nginx监听8080端口，接收到8080端口的请求，按照响应的算法进行转发到9001-9003端口。　

(1). 轮询

　访问地址：http://localhost:8080/Home/GetMsg ，会依次转发到9001、9002、9003端口上。

配置如下：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          server localhost:9001;
          server localhost:9002;
          server localhost:9003;
    }
    server {
        listen       8080;
        server_name   xxx;    #随意配置一个即可，优先走代理地址
        location / {
            proxy_pass http://myApiTest;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

补充其他参数说明：

　下面配置，当请求 http://localhost:8080/Home/GetMsg 时候，只会被转发到9003端口上，此时把9003端口的服务关掉，再次请求，则会被转发到9001端口上，其中9002端口，全程不参与负载。

upstream myApiTest {
    server localhost:9001 backup;
    server localhost:9002 down;
    server localhost:9003;
}

(2).轮询+权重

　下面配置，被转发到9001 9002端口的概率要大于9003端口。

配置如下：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          server localhost:9001 weight=10;
          server localhost:9002 weight=5;
          server localhost:9003;
    }
    server {
        listen       8080;
        server_name   xxx;    #随意配置一个即可，优先走代理地址
        location / {
            proxy_pass http://myApiTest;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

(3). ip_hash

　同一个ip永远会被分配到同一个Server上，主要用来解决Session不一致的问题，但该策略也有弊端，weight权重无效，所以该方案会导致某个Server压力可能过大，请求分配不均匀问题。

配置如下：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          ip_hash;   #开启ip_hash策略
          server localhost:9001;
          server localhost:9002;
          server localhost:9003;
    }
    server {
        listen       8080;
        server_name   xxx;    #随意配置一个即可，优先走代理地址
        location / {
            proxy_pass http://myApiTest;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

(4). url_hash

　主要用于节省空间，比如我有9G的图片资源，服务器集群有三台，因为不确定请求会被转发到哪一台上，所以每台服务器都存放9G，显然这样是不合理的。

　我们可以在存储的时候，将图片进行urlhash算法，分别存放到三台服务器上，这样请求的时候也是用urlhash，去指定服务器请求即可，节省了服务器空间，也就是3台服务器总共用了9G。

PS：上面只是举例方便理解，生产中，大量图片资源存放cdn第三方，然后在自己的服务器上做一层临时缓存，为了提高缓存的命中率，通常用urlhash算法。

二. 缓存配置

1. 背景

　分析一个电商网站的详情页面，如下图，设计到很多微服务：商品详情页HTML页面渲染、价格服务、促销服务、库存状态/配送至服务、广告词服务、预售/秒杀服务、评价服务、试用服务、推荐服务、商品介绍服务、各品类相关的一些特殊服务。

常规解决方案：

　前端通过ajax动态加载，服务端则把这些文案以html的形式缓存到Redis中，如下图：

解剖：

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

2. Nginx缓存

　针对上面占满内网带宽的情况，可以在Ngxin这一层做静态文件缓存，然后后台维护商品的时候删除缓存（修改商品→删除缓存），架构图如下：

3. 配置说明

代码配置：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          server localhost:9001;
          server localhost:9002;
          server localhost:9003;
    }
    #缓存模块配置
    proxy_cache_path /data/nginx/cache_ypf levels=1:2 keys_zone=cache_ypf:500m inactive=20d max_size=1g;
    server {
        listen       8080;
        server_name   xxx;    #随意配置一个即可，优先走代理地址
        location / {
            proxy_pass http://myApiTest;
            #缓存配置
            # 指定缓存区(和上面的keys_zone对应)
            proxy_cache cache_ypf;
            #以全路径md5值做做为Key 
            proxy_cache_key $host$uri$is_args$args;
            #对不同的HTTP状态码设置不同的缓存时间
            proxy_cache_valid 200 304 12h;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

4. 如何清除缓存

需要借助第三方模块ngx_cache_purge来清除。

(1). 安装模块

#下载ngx_cache_purge 模块包 ,这里nginx 版本为1.6.2 purge 对应2.0版
wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
#查看已安装模块
./sbin/nginx -V
#进入nginx安装包目录 重新安装 --add-module为模块解压的全路径
./configure --prefix=/root/svr/nginx --with-http_stub_status_module --with-http_ssl_module  --add-module=/root/svr/packages/ngx_cache_purge-2.3
#重新编译
make
#拷贝 安装目录/objs/nginx 文件用于替换原nginx 文件
#检测查看安装是否成功
nginx -t

(2). 进行配置

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

(3). 配置好后进行访问。

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

5. 实战演示

windows下演示如下：

　https://blog.csdn.net/weixin_34289744/article/details/91639502

Linux下演示：

　后续补充

三. 性能调优

1. worker_processes number

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

2. 每个worker 进程的最大连接数

　语法：worker_connections number; 默认：worker_connections 1024

3. 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操作系统有效。

4. Nginx worker 进程优先级设置

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

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

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

6. 是否打开accept锁

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

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

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

作者 : Yaopengfei(姚鹏飞)
博客地址 : http://www.cnblogs.com/yaopengfei/
声明1 : 如有错误，欢迎讨论，请勿谩骂^_^。
声明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。

24-微服务

第四节：Nginx负载均衡配置、缓存配置、性能调优

相关

标签