CentOS 6.3 64bit上测试ATS 5.3.0中的正则刷新插件regex_revalidate

注意到ATS源码目录plugin/experimental/下面有regex_revalidate插件目录，我们在编译时添加--enable-experimental-plugins配置项就可以将其编译安装到动态库安装目录/libexec/trafficserver中去。如果是ATS 4.x版本中没有源码的话，我们需要先将regex_revalidate单独复制出来，利用tsxs编译出动态库，并安装到动态库安装目录中去就可以，这里不再阐述。这里主要谈如何使用该插件实现目录文件的正则刷新。

一、如何配置？

以刷新凤凰网某个域名下面的资源为例，在plugin.config中添加一行

regex_revalidate.so -c rr.config -l regex_revalidate.log

将配置规则rr.config放入配置文件目录/opt/ats/etc/trafficserver下面(假设ats安装prefix为/opt/ats)，其内容如下：
http://y2.ifengimg.com/ 1432650630

该配置文件中每行表示一个正则刷新的目录，后面是过期的时间戳。从当前时间到过期时间这段时间内，正则匹配上上面某行配置的url将不会缓存，而是直接回源验证再发送回源响应。

过期时间戳的计算采用下面的方法，在命令行输入

date -d "20150526 22:30:30" +%s



得到设定的时间戳。这里暂且设置过期时间是当前时间的一天之后的时间戳就可以了，根据业务需求，你也可以适当修改。

如果超过过期时间戳，相应的配置行将从内存中删除，该行配置也会失效。必要时请及时刷新配置文件。

-l选项给出了日志文件名，它默认会存放在/opt/ats/var/log/trafficserver/regex_revalidate.log中，因为它调用的日志文件接口是TSTextLogObjectCreate()，和其它插件是一样的。

二、如何开启插件日志？

在plugin.config中配置时指定-l参数就可以，写日志的地方只有在list_config中的TSTextLogObjectWrite()，其他地方都是使用的TSDebug函数，要查找这部分的日志是在records.config中的配置。

CONFIG proxy.config.diags.debug.enabled INT 1

CONFIG proxy.config.diags.debug.tags STRING regex_revalidate.*

然后就在traffic.out中看到打印日志信息了。



三、测试方法：

使用wget来进行ATS本机测试

直接回源

wget -SO /dev/null "http://y2.ifengimg.com/xingzhao/JS/otherCouplet.js"

wget -SO /dev/null "http://y2.ifengimg.com/mappa/2015/05/06/e8a0212acf42d11e33338373b83b92e0.swf"



使用代理刷新

wget -SO /dev/null -e 'http_proxy=127.0.0.1:8081' "http://y2.ifengimg.com/xingzhao/JS/otherCouplet.js"

wget -SO /dev/null -e 'http_proxy=127.0.0.1:8081' "http://y2.ifengimg.com/mappa/2015/05/06/e8a0212acf42d11e33338373b83b92e0.swf"

对上面的url反复执行多次，我们只能得到缓存的状态是[cMsSfW]或是[cMsSf ]，也就是响应并不会缓存，它只会在指定的过期时间内每次都回源。



作为对比，我们测试下面的url

wget -SO /dev/null -e 'http_proxy=127.0.0.1:8081' "http://y1.ifengimg.com/auto/image/2015/0416/023115190.jpg"

我们发现它并不受影响，响应会缓存，缓存的状态从[cMsSfW]=>[cHs f ]=>[cRs f ]



同时查看插件日志：



查看访问日志access.log中发现同一个请求并不会缓存，都会每次回源请求，这是我们需要的结果



但是不在正则刷新范围的url却可以正常缓存



四、测试中出现的问题

使用wget测试时，我发现ATS会发生段错误并重启，traffic_crashlog给出的部分崩溃日志如下：

FATAL: HttpTransact.cc:391: failed assert `s->pending_work == NULL`



这个bug已经得到ATS官方修复，参见JIRA
https://issues.apache.org/jira/browse/TS-3455
五、Patch之后继续测试

考虑到ats 6.1.1目前还是不稳定，我决定仍然在ats 5.3.2上做path，主要是修改3个地方，都在proxy/http/HttpTransact.cc中，截图如下：





手动修改后，直接安装，继续使用上面的url测试，发现首次刷新后，会缓存新数据，以后直接命中。由于我这里举例的源站文件内容没有改变，每次会返回206，但是正常情况下会返回200





从traffic.out中可以看到

Forced revalidate - http://y2.ifengimg.com/xingzhao/JS/otherCouplet.js
以自己可以修改的网站测试为例,我们发现对缓存的内存执行强制刷新的行为是这样的，对正则匹配上的资源，在缓存中HIT_FRESH的情况下，并且其Date时间戳在规则添加时间戳之前，执行强制刷新，向源站发送304查询，如果源站内容没有变，还是返回旧的缓存内容，否则，返回更新后的内容，但是ats的缓存响应状态码仍然是[cSsSfU]，不同的是文件内容有变化。

下面是刷新前后效果对比图，刷新只会执行一次，以后都从缓存读。即使匹配上，对刷新规则之后缓存的内容没有作用，对未缓存的规则也没有作用。





注意文件长度的变化。

备注：本文得到参考文献的启发，特别感谢4399运维军团等的无私分享。

参考文献

[1].http://ju.outofmemory.cn/entry/89153

[2].http://qingchunranzhi.blog.163.com/blog/static/23728612020153174434608