本文主要是介绍ATS通过header头重写解决HIT/502故障,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
某局点的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故障的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!