某局点的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缓存规则的设置就不多介绍了,之前有写。
自建个人原创站运维网咖社(www.net-add.com),新的博文会在网咖社更新,欢迎浏览。
标题名称:ATS通过header头重写解决HIT/502故障
网页路径:https://www.cdcxhl.com/article0/iicdoo.html
成都网站建设公司_创新互联,为您提供网站制作、ChatGPT、静态网站、关键词优化、手机网站建设、用户体验
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联