ATS的目录推送刷新功能
1 概述
ATS推送刷新目录，这个是我们梦寐以求的功能，之前都是强制他们加版本号来控制版本，但是如果是对商用来说，刷新目录这个功能肯定是必须的。
最近看到豪哥的博客里面写到了可以参考regex revalidate插件来做这个功能，在github上面找到了源码https://github.com/apache/trafficserver/tree/master/plugins/experimental/regex_revalidate
但是里面没有任何配置文件和说明文件，估计开发者都比较忙，我们也需要努力做出点共享啊。这次为广大ats初学者带来小小的使用帮助，算是对ATS的开源奉献出自己一份薄力吧（向作者致敬）。
2 分析思路
把源码下载下来之后，进行模块编译：
tsxs -c regex_revalidate.c -I /data/src/trafficserver-4.2.1/lib/ts -o regex_revalidate.o -i编译好之后进行配置，都知道ats的插件是在plugin.config这里定义，但是格式怎么写呢，我们参考源码，看看有没什么头绪。
先打开debug模式：
找到TSDebug函数，前缀是LOG_PREFIX，他的定义是regex_revalidate，所以我们在records.config里面配置：
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING regex_revalidate.*搜索option关键词，发现有定义参数：
{ "config", required_argument, NULL, 'c' },
{ "log", required_argument, NULL, 'l' },通过搜索TSError相关的报错日志，发现有这个：
TSError("Plugin requires a --config option along with a config file name.");所以，我们认为这个插件的配置文件写法可以是这样，读配置，写log：
regex_revalidate.o --config regex_revalidate.conf --log regex_revalidate.log然后，这个配置文件该怎么写呢？我们先启动再说，看看日志
发现日志里面是正常加载插件，但是插件的配置文件是EMPTY，Skipping line 1，跳过了第一行，所以第一行格式肯定有问题。
我们找到load_config这个函数，发现里面有pcre_compile的匹配，我们可以大概猜想一下他的逻辑：
对”^([^#].+?)\\s+(\\d+)\\s*$“这个匹配模式来进行行搜索：
这个匹配大概就是一些字符串和数字组合起来的，具体可以参考网页: http://blog.csdn.net/sulliy/article/details/6247155 下面有个c的程序来进行pcre的匹配测试。
如果配置文件里面匹配了，然后进行处理，里面有个判断是否过期的逻辑，用到了time_t类型的now变量，估计配置文件里面也有相关的时间戳定义，我们先在里面加些字符串和时间戳，然后启动看看日志之类的。
可以在第一次进行pcre_exec匹配的时候打一些log出来：
rc = pcre_exec(config_re, NULL, line, strlen(line), 0, 0, ovector, OVECTOR_SIZE);
TSDebug(LOG_PREFIX, "rc is %d", rc);重新编译，然后重启
不知道如何继续的时候，可以先多猜想下，随便写点配置，然后看日志，rc是3的时候会继续进行配置匹配，所以当rc的输出不是3的时候，我们可以继续重试。或许多重试几次就会有感觉了。
我们的插件名字叫做regex revalidate，所以在里面搜索相关revalidate的字眼，发现有个最关键的地方，打日志的时候：
TSDebug(LOG_PREFIX, "Forced revalidate - %.*s", url_len, url);我们上下文看下，发现有个if判断:
if (pcre_exec(iptr->regex, iptr->regex_extra, url, url_len, 0, 0, NULL, 0) >= 0)如果url和iptr里面的regex匹配了就进行url的刷新，所以这个regex应该是关键的东西，我们到加载配置文件那里查看：
pcre_get_substring(line, ovector, rc, 1, &i->regex_text);
i->regex = pcre_compile(i->regex_text, 0, &errptr, &erroffset, NULL);虽然不懂，但是可以大概猜想对regex的赋值是与之前的匹配有关，因为line变量就是配置文件里面的行，如果url匹配了上面那个匹配的第二个值，就对这个url进行推送，所以我们猜想第二个match的值是我们需要刷新的url。
我们把上面那个csdn里面c语言的pcre测试程序拿下来修改下，把里面的匹配加进去，把/n里面的斜线改为linux里面的换行符： \n ，上面说了，里面有个url相关的匹配，然后有时间戳，所以我们进行下面的猜想测试：
char src [] = "http://cacti.4399.com 1404213161 "; // 要被用来匹配的字符串
char pattern [] = "^([^#].+?)\\s+(\\d+)\\s*$"; // 将要被编译的字符串形式的正则表达式编译： gcc 2.c –lpcre
发现输出结果：
String : http://cacti.4399.com 1404213161
Pattern: ^([^#].+?)\s+(\d+)\s*$
OK, has matched ... rc is 3
$ 0: http://cacti.4399.com 1404213161
$ 1: http://cacti.4399.com
$ 2: 1404213161这个匹配和程序里面的逻辑大概相似了，我们把这个加入到配置文件：
http://cacti.4399.com 1404213161重启之后发现这次报的日志是Rule is already expired，这个来源于一个和现在时间戳的比较，我们把配置文件的时间戳加大：
这次成功了，日志显示：
Current config:
http://cacti.4399.com epoch: 1404213639 expiry: 1404214161
Plugin registration succeeded.Epoch表示当前的时间戳，expiry就是我们配置的时间戳，联想下，大概的意思可能是匹配前面这个url，他的过期时间是后面这个时间戳，我们进行wget –S的测试和源日志的查看，发现在后面这个时间戳前进行wget会进行回源校对，过了这个时间戳之后有Removing XXX之类的日志，大概知道了，在后面这个时间戳之前，ats认为匹配到前面这个url会是已经刷新的url，我们进行加目录的测试。。。。测试通过
查看日志的时候发现有
File mod time is not newer: 1404182941 >= 1404182941的字眼，这个意思是说配置文件现在的时间戳和他上次读他的时候没有更新，所以认为配置没有更新过，就跳过了读配置，当我们进行配置修改之后，在CONFIG_TMOUT这个间隔时间之后会进行定期扫描和读取配置。
总的很简单啦，需要刷新哪些目录，直接在regex_revalidate.conf里面写类似这样的：
http://cacti.4399.com/dir/ 1404214161
后面这个时间戳因为我们是每天会进行自动刷新，进行304的校对，所以后面就写当前时间起一天内即可。
需要刷新新的目录直接追加内容即可，默认是每分钟会进行配置文件的扫描。
过程有些啰嗦，主要是对c不够了解，大家一笑而过就好了。
发现居然整整一年没有更新这个博客了 