Nginx 之生产环境应用

通过nginx高速缓存来演示

在这之前可以了解$host变量的含义 http://blog.51cto.com/gyj110/2079981

案例分析

某电商平台商品详情页需要实现 700+ QPS（query操作，TPS提交操作），如何着手去做？
1. 首先为分析一下一个商品详情页有哪些信息

从中得出商品详情页依懒了

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

这么多数据不可能一起一下子就加载，不然会非常的卡，那么该怎么办呢？？

商品详情页HTML页面渲染
价格服务促销服务
库存状态/配送至服务
广告词服务
预售/秒杀服务
评价服务
试用服务
推荐服务
商品介绍服务
各品类相关的一些特殊服务

解决方案核心：

1. 采用Ajax 动态加载价格、广告、库存等服务

2. 采用key value 缓存详情页主体html。

方案架构：

请求不大时，我们一般把数据缓存在redis中，这样可以不用再去服务拿去数据，响应速度更快了，但是当请求更多时，会出现瓶颈

问题：

当达到500QPS 的时候很难继续压测上去。

分析原因：

一个详情页html 主体达平均150 kb 那么在500QPS 已接近局域网宽带极限。必须减少内网通信。
比如，一个详情页面150kb，500QPS*150/1024=73M，一秒就发生73多M的网络传输，这已经非常接近宽带峰值128M

所以，我们可以把缓存放在通过nginx放在本地上

基于Nginx 静态缓存的解决方案：

如图：我们通过ngnx配置把数据缓存在本地，这样用户的访问请求就不用经过商品详情页服务返回数据，除非当运维人员修改商品信息时要清除缓存，这时可以通过第三方来清除nginx配置的缓存，这样用户就可看到最新数据

该方案nginx配置实现

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

proxy_cache_path  /data/nginx/cache_item  levels=1:1:2 keys_zone=cache_item:500m inactive=30d max_size=10g;

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

proxy_cache cache_item;
proxy_cache_key $host$uri$is_args$args;#以全路径md5值做做为Key 
proxy_cache_valid 200 304 12h; #对不同的HTTP状态码设置不同的缓存时间 
expires 7d; #总体缓存时间

缓存参数详细说明

父元素	名称	描述
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	为不同的状态码设置缓存有效期

（有一篇博客挺好的：https://blog.csdn.net/dengjiexian123/article/details/53386586）

现在我们开始演示

修改nginx配置，如图：

配置好后，./sbin/nginx -t 检测一下，这是注意不能用 ./sbin/nginx -s reload 热部署方式重启，必须用 ./sbin/nginx -s stop停止

然后 ./sbin/nginx 开启nginx

接着，我们在web1 服务的webapps/Root 创建 hello.html，写上

浏览器访问该页面

然后我们在修改hello.html文件该 V.1.0 ----> V.2.0,清除浏览器缓存，在访问该页面，可以发现页面还是 V.1.0

所以，我们配置的缓存是有效的

我们也可以看缓存文件

缓存的清除：

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

为nginx 添加 ngx_cache_purge 模块

#下载ngx_cache_purge 模块包 ,这⾥nginx 版本为1.6.2 purge 对应2.0版

wget http://labs.frickle.com/files/ngx_cache_purge-2.0.tar.gz
#解压文件

#查看已安装模块
./sbin/nginx -V

#进⼊nginx安装包⽬录重新安装 --add-module为模块解压的全路径

./configure --prefix=/root/svr/nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre=/usr/local/src/pakcages/pcre-8.35 --add-module=/usr/local/src/pakcages/ngx_cache_purge-2.0

#重新编译 make #make之后会在objs/nginx中生成新的nginx

#拷⻉安装⽬录/objs/nginx ⽂件⽤于替换原nginx ⽂件 #在这之前最好先备份之前的nginx

#检测查看安装是否成功

nginx -t 或者 ./sbin/nginx -V

清除配置：

location ~ /purge(/.*) {
    #允许访问的IP
    allow 127.0.0.1;
    allow 192.168.0.193;
    #禁⽌访问的IP
    deny all;
    #配置清除指定缓存区和路径(与proxy_cache_key⼀⾄)
    proxy_cache_purge cache_item $host$uri$is_args$args;
}

这个必须放在 location缓存上面

重启nginx，访问 tl.com/purge/hello.html 清除nginx缓存

访问hello.html页面

现在，演示成功！！！

Nginx 性能参数调优

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

每个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定义的时间才能再次试图取锁。