A B C
浏览器------------------------->nginx(proxy)------------------------------------>tomcat
1、A:发出requset请求到B(proxy),然后在request到C(tomcat)
C:tomcat返回response到B(proxy),然后再到A(浏览器)
2、A处有缓存,B出有缓存,C出也有缓存(而且是request和response缓存)
3、此处主要说B出的request和responser缓存配置和使用
4、B处的request缓存:主要是缓存A的,A发起请求,对请求A的缓存
http://www.nginx.cn/doc/standard/httpcore.html
5、B处的response缓存:主要是对C的,C处理好结果封装到response对象返回给B,此时B就对C的response进行缓存,不缓存的话就实时传给A进行展示
http://www.nginx.cn/doc/standard/httpproxy.html
https://blog.tanteng.me/2016/03/nginx-buffer-params/
=========================================================
https://www.cnblogs.com/zlingh/p/5879988.html
在http出设置,定义缓存
proxy_cache_path /usr/local/nginx/app_static levels=1:2 keys_zone=cache_app:200m inactive=1d max_size=30g;
proxy_cache_path /usr/local/nginx/public_static levels=1:2 keys_zone=cache_public:200m inactive=1d max_size=30g;
不可以在localhost处设置定义。
使用 proxy_cache
在localhost处使用
server{
listen port;
server_name ip;
location ^~ /jettech { #houtai fuwi app ziji de static style
proxy_cache cache_app;
proxy_ignore_headers Set-Cookie Cache-Control;#这句代码很关键,尤其要忽略set-cookie
#proxy_cache_valid 200 206 304 301 302 10d;
proxy_cache_valid 200 206 304 301 302 50s;#此处控制的是nginx服务器缓存时间,过期后去源服务器重新取数据。
proxy_cache_key $http_range$uri;
#proxy_cache_key $uri;
proxy_pass http://10.30.30.126:8787;
#expires 50s; #此时控制的是浏览器客户端缓存时间。(-1)是客户端不缓存。
}
location ^~ /public-style { #houtai public style
proxy_cache cache_public;
proxy_ignore_headers Set-Cookie Cache-Control;#这句代码很关键,尤其要忽略set-cookie
proxy_cache_valid 200 206 304 301 302 50s;#此处控制的是nginx服务器缓存时间,过期后去源服务器重新取数据
proxy_cache_key $http_range$uri;
#proxy_cache_key $uri;
proxy_pass http://10.30.30.131:8080;
#expires 50s; #chrome cache shixiao time
}
location ~* \.(gif|jpg|jpeg|png|bmp|swf|js|css)$ { #nginx of style
#location /wuqi/chunsheng/ { #alias
#alias /usr/local/nginx/wubo/;
root /usr/local/nginx/wubo;
}
}
http://www.cnblogs.com/dudu/p/4597351.html
http块:
proxy_cache_path /tmp/cache levels=1:2 keys_zone=nuget-cache:20m max_size=50g inactive=168h;
server块:
proxy_cache nuget-cache;
proxy_cache_valid 168h;
proxy_ignore_headers Set-Cookie Cache-Control; #这句代码很关键,尤其要忽略set-cookie
proxy_hide_header Cache-Control;
proxy_hide_header Set-Cookie;
下附nginx缓存优先级
接触nginx的兄弟或多或少都有遇到缓存问题,要么是nginx为什么不缓存,要么就是nginx缓存很快就失效等等问题,在网上找了一遍nginx缓存优先级的文章,大家可以参考下。
架构图
client端 <------------------> nginx cache <------------------>源服务器
经过大量测试发现:nginx的过期顺序是有一个优先级的。下面首先说明各个影响缓存过期的因素:
(1)inactive:在proxy_cache_path配置项中进行配置,说明某个缓存在inactive指定的时间内如果不访问,将会从缓存中删除。
(2)源服务器php页面中生成的响应头中的Expires,生成语句为:
header("Expires: Fri, 07 Sep 2013 08:05:18 GMT");
(3)源服务器php页面生成的max-age,生成语句为:
header("Cache-Control: max-age=60");
(4)nginx的配置项 proxy_cache_valid:配置nginx cache中的缓存文件的缓存时间,如果配置项为:proxy_cache_valid 200 304 2m;说明对于状态为200和304的缓存文件的缓存时间是2分钟,两分钟之后再访问该缓存文件时,文件会过期,从而去源服务器重新取数据。
其次对需要注意的一点:源服务器的expires和nginx cache的expires配置项的冲突进行说明,场景如下
(1)源服务器端有php文件ta1.php内容如下:
1 2 3 4 5 6 |
header("Expires: Fri, 07 Sep 2013 08:05:18 GMT"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=60"); echo "ta1"; ?> |
(2)在nginx cache服务器端的配置信息如下:
…….
proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=5s max_size=30g;
……..
location ~ .*\.(php|jsp|cgi)$
{
proxy_read_timeout 10s;
proxy_connect_timeout 10s;
proxy_set_header Host $host;
proxy_cache_use_stale updating;
proxy_cache_key $host$uri$is_args$args;
proxy_cache cache_one;
#proxy_ignore_headers "Cache-Control";
#proxy_hide_header "Cache-Control";
#proxy_ignore_headers "Expires";
#proxy_hide_header "Expires";
proxy_hide_header "Set-Cookie";
proxy_ignore_headers "Set-Cookie";
#add_header Cache-Control max-age=60;
add_header X-Cache '$upstream_cache_status from $server_addr';
proxy_cache_valid 200 304 2m;
#proxy_cache_valid any 0m;
proxy_pass http://backend_server;
expires 30s;
}
………….
这时client端的max-age与expires的值按照nginx cache中的expires配置项的设置,即:从上面两项可以看出nginx cache 服务器中expires的配置是30s,该expires的值直接决定了在浏览器端看到的max-age以及expires的值。而源服务器断的代码中设置的响应头中的max-age为60,expires为Fri, 07 Sep 2013 08:05:18 GMT。这是源服务器的设置于nginx-cache的设置冲突了,那么着两个属性应该怎么设置呢?
1 2 |
Expires Fri, 07 Sep 2012 08:59:16 GMT Cache-Controlmax-age=30 |
而nginx cache端的缓存的max-age与expire的值按照源服务器上的代码的设置。即:
1 2 |
Expires Fri, 07 Sep 2013 08:05:18 GMT Cache-Controlmax-age=60 |
现在步入正题:
经过大量测试发现:对缓存的过期与清除起作用的因素的优先级从高到低一次为:
inactive配置项、源服务器设置的Expires、源服务器设置的Max-Age、proxy_cache_valid配置项
下面通过几个实例对这几个优先级进行说明
实例1:
服务器端php代码:
1 2 3 4 5 6 7 |
header("Expires: Fri, 07 Sep 2012 08:03:18 GMT");//其实是3分钟之后 header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=180");//2分钟 //header("Cache-Control: post-check=0, pre-check=0", false); echo "ta1"; ?> |
nginx cache 配置项
inactive 4m//4分钟
proxy_cache_valid 1m//1分钟
现象:第一次访问页面ta1.php之后,各个时间的访问结果:
1分钟之后 :HIT//这说明valid没有起作用
2分钟之后 :HIT//这说明 源服务器设置的max-age没有起作用
3分钟之后:MISS//这说明源服务器设置的Expires起作用了
4分钟之后:MISS//这说明inactive起作用了
实例2:
服务器端php代码:
1 2 3 4 5 6 7 |
header("Expires: Fri, 07 Sep 2012 08:03:18 GMT");//3分钟之后 header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=180");//2分钟 //header("Cache-Control: post-check=0, pre-check=0", false); echo "ta1"; ?> |
nginx cache 配置项
inactive 10s//10秒钟
proxy_cache_valid 1m//1分钟
现象:第一次访问页面ta1.php之后,各个时间的访问结果:
5秒后访问:HIT
10秒后访问: MISS
15秒后访问:HIT
20秒后访问:MISS
通过实例1和实例2综合分析:如果inactive已经进行了设置,则缓存的过期时间以inactive设置的值为准
实例3:
服务器端php代码:
1 2 3 4 5 6 7 |
header("Expires: Fri, 07 Sep 1977 08:03:18 GMT");//直接过期 header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=120");//2分钟 //header("Cache-Control: post-check=0, pre-check=0", false); echo "ta1"; ?> |
nginx cache 配置项
inactive 4m//4分钟
proxy_cache_valid 1m//1分钟
现象:第一次访问页面ta1.php之后,各个时间的访问结果:
每隔一秒访问一次:MISS//这说明源服务器端设置的Expires屏蔽了nginx的valide和源服务器端设置的max-age的作用
实例4:
服务器端php代码:
1 2 3 4 5 6 7 |
header("Expires: Fri, 07 Sep 2012 08:03:18 GMT");//3分钟之后 header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=120");//2分钟 //header("Cache-Control: post-check=0, pre-check=0", false); echo "ta1"; ?> |
nginx cache 配置项
inactive 4m//4分钟
proxy_cache_valid 1m//1分钟
现象:第一次访问页面ta1.php之后,各个时间的访问结果:
1分钟之后 : HIT//这说明valid没有起作用,因为源服务器设置的Expires将valid的效果屏蔽了
2分钟之后 : HIT//这说明 源服务器设置的max-age没有起作用,因为源服务器设置的Expires将max-age屏蔽了
3分钟之后: MISS//这说明服务器端设置的expires起作用了
通过实例2和实例3的现象说明:如果inactive设置的比较大,在inactive到期之前,如果valid、服务器端设置的expires、服务器端设置的max-age都进行了设置,则以服务器端设置的expires为准。
实例5:
服务器端php代码:
1 2 3 4 5 6 7 |
header("Expires: Fri, 07 Sep 2012 08:03:18 GMT");//3分钟之后 header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=120");//2分钟 //header("Cache-Control: post-check=0, pre-check=0", false); echo "ta1"; ?> |
nginx cache 配置项
inactive 4m//4分钟
#下面两行用于消除服务器端配置的Expires响应头的影响
proxy_ignore_headers "Expires";
proxy_hide_header "Expires";
proxy_cache_valid 1m//1分钟
现象:第一次访问页面ta1.php之后,各个时间的访问结果:
1分钟之后 HIT //这说明valid的作用已经被服务器端的max-age屏蔽
2分钟之后 MISS//服务器端设置的max-age起作用
实例6:
服务器端php代码:
1 2 3 4 5 6 7 |
header("Expires: Fri, 07 Sep 2012 08:03:18 GMT");//3分钟之后 header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: max-age=50");//50秒钟 //header("Cache-Control: post-check=0, pre-check=0", false); echo "ta1"; ?> |
nginx cache 配置项
inactive 4m//4分钟
#下面两行用于消除服务器端配置的Expires响应头的影响
proxy_ignore_headers "Expires";
proxy_hide_header "Expires";
proxy_cache_valid 2m//2分钟
现象:第一次访问页面ta1.php之后,各个时间的访问结果:
50秒钟之后 : MISS//这说明服务器端配置的max-age起作用
1分钟之后 : HIT//
100秒钟之后: MISS//这说明服务器端设置的max-age起作用了
通过实例5和实例6的现象说明:如果inactive设置的比较大,而且在nginx配置文件中取消服务器端Expires对缓存的影响。在同时设置了proxy_cache_valid和服务器端设置了max-age响应头字段的情况下,以服务器端设置的max-age的值为标准进行缓存过期处理。
综上所述:
(1)在同时设置了源服务器端Expires、源服务器端max-age和nginx cahe端的proxy_cache_valid的情况下,以源服务器端设置的Expires的值为标准进行缓存的过期处理
(2)若在nginx中配置了相关配置项,取消原服务器端Expires对缓存的影响,在同时设置了源服务器端Expires、源服务器端max-age和nginx cahe端的proxy_cache_valid的情况下,以源服务器端max-age的值为标准进行缓存的过期处理
(3)若同时取消源服务器端Expires和源服务器端max-age对缓存的影响,则以proxy_cache_valid设置的值为标准进行缓存的过期处理
(4) Inactive的值不受上述三个因素的影响,即第一次请求页面之后,每经过inactvie指定的时间,都要强制进行相应的缓存清理。因此inactive的优先级最高。
(5)所以对缓存过期影响的优先级进行排序为:inactvie、源服务器端Expires、源服务器端max-age、proxy_cache_valid
==========================================================
https://blog.csdn.net/dengjiexian123/article/details/53386586
由于本人工作原因,涉及到网络直播领域,其中视频的回放下载,涉及到了一些视频下载方面的技术。针对于一个完整视频的下载,目前市面上的主流做法是,先将整个视频流切片,存储到文件服务器中,在用户需要观看回放视频时。通过一个视频回源服务器,去文件服务器中逐个请求切片,返回给用户播放。
今天着重探讨的是关于回源服务器缓存的配置以及合理的缓存策略。
通过给回源服务器配置缓存的案例,详细讲解一整套缓存配置机制,并且可沿用到其他任何缓存配置场景中。
今天的讲解分为四点:
回源服务器在下面叙述中简称:源站
如图所示,在文件下载的过程中,横跨在cdn与文件服务器之间,作为下载枢纽。
源站架构:源站是nginx+php的webserver架构,如图所示:
但如果源站只是简单的收到请求,然后下载资源,再返回,势必会存在以下几点不够优化的问题:
1、cdn可能存在多次回源现象
2、源站对同一资源的多次下载,存在网络流量带宽浪费,以及不必要的耗时。
所以为了优化这些问题,需要给源站做一层缓存。缓存策略采用nginx自带的proxy_cache模块。
proxy_cache模块的工作原理如图所示:
在nginx.conf文件中添加如下代码:
http{
......
proxy_cache_path/data/nginx/tmp-test levels=1:2 keys_zone=tmp-test:100m inactive=7d max_size=1000g;
}
代码说明:
proxy_cache_path 缓存文件路径
levels 设置缓存文件目录层次;levels=1:2 表示两级目录
keys_zone 设置缓存名字和共享内存大小
inactive 在指定时间内没人访问则被删除
max_size 最大缓存空间,如果缓存空间满,默认覆盖掉缓存时间最长的资源。
当配置好之后,重启nginx,如果不报错,则配置的proxy_cache会生效
查看 proxy_cache_path /data/nginx/目录,
会发现生成了tmp-test文件夹。
在你对应的nginx vhost server配置文件中添加如下代码:
location /tmp-test/ {
proxy_cache tmp-test;
proxy_cache_valid 200 206 304 301 302 10d;
proxy_cache_key $uri;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_passhttp://127.0.0.1:8081/media_store.php/tmp-test/;
}
配置项介绍:
Proxy_cache tmp-test 使用名为tmp-test的对应缓存配置
proxy_cache_valid 200 206 304 301 302 10d; 对httpcode为200…的缓存10天
proxy_cache_key $uri 定义缓存唯一key,通过唯一key来进行hash存取
proxy_set_header 自定义http header头,用于发送给后端真实服务器。
proxy_pass 指代理后转发的路径,注意是否需要最后的/
到这里,最基本的proxy_cache功能就配置成功了。当uri成功匹配到该location,则proxy_cache就会生效。
1、第一次访问:
第一次访问,proxy_cache并没有找到对应的缓存文件(未命中缓存MISS),所以当第一次请求完成的同时,proxy_cache会保持缓存:
2、保存缓存,如图所示:
3、同一个url第二次访问,当同一个文件再次到达源站,proxy_cache就会找到其对应的缓存文件(命中缓存HIT)直接返回给请求端,无需再执行php程序,如图所示:
到此,就完成了最基本的proxy_cache配置和访问过程介绍,但是最基本的配置,往往无法满足我们的业务需求,我们往往会提出以下几点疑问和需求:
面对以上疑问,我们一个一个解决。
采用:nginx proxy_cache_purge 模块 ,该模块与proxy_cache成对出现,功能正好相反。
设计方法:在nginx中,另启一个server,当需要清理响应资源的缓存时,在本机访问这个server。
例如:
访问 127.0.0.1:8083/tmp-test/TL39ef7ea6d8e8d48e87a30c43b8f75e30.txt 即可清理该资源的缓存文件。
配置方法:
location /tmp-test/ {
allow 127.0.0.1; //只允许本机访问
deny all; //禁止其他所有ip
proxy_cache_purge tmp-test $uri; //清理缓存
}
proxy_cache_purge:缓存清理模块
tmp-test:指定的key_zone
$uri:指定的生成key的参数
proxy_cache_purge缓存清理过程,如图所示:
由于写入路径为一个单一目录,只能写入一块磁盘。一块磁盘很快就会被打满,解决该问题有如下两种方法:
1、将多块磁盘做磁盘阵列? 缺点是:减小了实际的存储空间。
2、巧妙得运用proxy_cache_path的目录结构,由于levels=1:2,这导致缓存文件的目录结构为两层,每层目录名,都是由hash函数生成。如图所示:
总共含有16*16*16=4096个文件目录。对该一级目录进行软连接,分别将0-f软连接到你所需要的指定磁盘目录上,如图所示:
通过软链的方法,实现:将不同盘下的目录作为真正存放数据的路径,解决了多盘利用,单盘被打满的问题。
添加上缓存代理之后,客户端发起的range请求将会失效,如下图所示:
导致range参数无法传递到下一级的原因如下:
当缓存代理转发http请求到后端服务器时,http header会改变,header中的部分参数,会被取消掉。其中range参数被取消,导致,后端nginx服务器没有收到range参数,最终导致这个分片下载不成功。所以需要对代理转发的header进行配置。
例如:
location /tmp-test/ {
proxy_cache tmp-test;
proxy_cache_valid 200 206 304 301 302 10d;
proxy_cache_key $uri;
proxy_set_header Range $http_range;
proxy_pass http://127.0.0.1:8081/media_store.php/tmp-test/;
}
红色部分的含义:将http请求中的range值($http_range)放到代理转发的http请求头中作为参数range的值。
如果请求端 Range请求(分片下载)一个大资源,同样的uri,proxy cache如何识别资源对应的key。
由于nginx配置为:proxy_cache_key $uri,用uri作为key
所以当请求为普通请求和range请求时,都是同样的uri作为key。proxy_cache将有可能导致错误返回。如下图所示:
解决方法如下:
修改proxy_cache_key ,配置proxy_cache_key $http_range$uri;
这样就能解决:key唯一性。可以避免不管是正常请求还是不同的range请求,第一次获取的内容和之后获取的缓存内容都不会出现异常。
需要通过返回过期时间来指定请求端,哪些资源需要缓存,哪些资源不缓存,
参数 | 正常请求 | range请求 |
返回过期时间 | 返回 | 不返回 |
为了防止请求端将分片资源当做完整资源缓存起来,我们需要对正常请求,返回过期时间;对range请求, 不返回过期时间。
解决该问题,通过对nginx配置即可解决:
location /media_store.php {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index media_store.php;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
include fastcgi_params;
if ( $http_range = ''){
expires 2592000s;
}
}
在proxy_pass代理之后的location中加入对$http_range的判断,expires 表示过期时间。 2592000s指缓存过期时间。
解决方法:
利用nginx $upstream_cache_status变量:该变量代表缓存命中的状态,
如果命中,为HIT;如果未命中,为MISS
在返回nginx server配置中添加:
add_header Nginx-Cache "$upstream_cache_status";
在nginxlog中添加:
log_format combinedio …$upstream_cache_status;
http返回head截图:
nginx log日志截图:
整个一套完备的缓存策略就介绍到此,这套方案中不仅实现了基本的缓存配置,还解决了实际场景应用中会遇到的,磁盘扩展,缓存清理,断点续传,缓存过期时间,缓存命中提示等问题,只要将这套方案灵活运用,不管是再复杂的场景,基本都能满足需求。以上都是我在工作中爬过的坑,不断完善总结出的结果,希望对读者能有帮助。