ATS通过header头重写解决HIT/502故障
来源:互联网 发布:java强制类型转换性能 编辑:程序博客网 时间:2024/05/22 14:22
某局点的ats经常出现HIT/502的故障,客户一旦发飙,这是个扯不清的问题,如果是MISS/502那可以说是源站错误,但HIT/502就与ats业务系统有关系了。
经过手动测试,同一个url直接回源连续访问,偶尔就有502,问题很明显了,源站是不稳定的。分析后发现源站使用某厂家的CDN做的分发,造成了源站不稳定,我们拿到的是CDN的内容,而且返回的502信息中还有明确的max-age,ats按照max-age的信息把故障信息存下来了,真是害死人的节奏。
ats对于故障信息是有配置参数的,我们已经对没有max-age头的故障信息设置为不缓存,有max-age头故障信息是要看情况缓存的,因为有可能碰到源站改版等问题,也就是说有些故障信息是有必要缓存的。
经过研究,发现header头重写可以解决这个故障,思路就是劫持399到599状态码的响应header头,强行将cache-control标记删除,同时加上Cache-Control no-cache,那样的话故障信息就不会存储了,我们就在线上测试,又发现配置后只对新的请求生效,对老的信息是不起作用的,一查缓存,5.7T的存储已经写满,不敢轻易操作了,后想办法配置缓存规则,采用保守的方式将5.7T的信息通过7天的刷新,502/HIT彻底解决,把header头的操作分享出来,供大家一起研究。
header_rewrite.so是ats编译时自带的模块,只是默认没有打开,所以需要在ats里注册添加,然后编写规则,header模块注册方法是:
在plugin.config 中加入 header_rewrite.so header.config,指定了header的配置文件是header.config
然后就是在header.config中添加规则,添加如下(测试的时候又发现带max-age的故障信息是不好伪造的,没折又想了对正常信息进行测试来看功能是否可行,走了一些弯路):
cond %{STATUS} >399 [AND]
cond %{STATUS} <599
rm-header Cache-Control
add-header Cache-Control no-cache
添加好后重新加载配置文件traffic_line -x
对于刷新资源,ats默认带了对单条url强制刷新的规则,不过不适合我们当前的场景,于是利用cache.config编写缓存规则,让资源的保鲜期设置为5分钟刷新一次,ims缓存规则的设置就不多介绍了,之前有写。
本文出自 “奔跑的linux” 博客,请务必保留此出处http://benpaozhe.blog.51cto.com/10239098/1747620
- ATS通过header头重写解决HIT/502故障
- 通过Nginx定义Header头信息
- 通过Nginx定义Header头信息
- 解决nginx https下 ATS检测未通过 的思路
- header头解决跨域请求
- header 头
- 通过域名解决服务器故障自动转移
- PHP通过发送header头实现文件下载
- 获取header头及获取乱码网页的解决
- File Header文件头,通过检查文件头来判断文件类型
- File Header文件头,通过检查文件头来判断文件类型
- File Header文件头,通过检查文件头来判断文件类型
- (转)File Header文件头,通过检查文件头来判断文件类型
- Header annotation 头注解
- HTTP 请求头 Header
- 关于header(发送头)
- http header 头信息
- header 头参数详解
- shell脚本——linux主机监控
- shell脚本——爬取域名一级页面元素并判断其可缓存性
- linux下PXE无人值守环境自动安装脚本
- 栈输入月份输出月份
- mysql互主自动化配置脚本
- ATS通过header头重写解决HIT/502故障
- 深入浅出剖析内容分发网络CDN业务架构
- CDN的cache节点(http)结构及工作原理总结(图自画)
- 大并发下TCP内存消耗优化小记(86万并发业务正常服务)
- 十几万连接几M的流量,吓死“宝宝”了
- Nginx/Tengine服务启动管理脚本(未使用系统funtions函数)
- 【JVM实用参数】(三)打印所有XX参数及值
- Nginx/tengine里的那些timeout时间
- Nginx/tengine做cache时缓存机制—存不存、存多久、用不用方法论