varnish緩存清除的問題和陷阱

dickwen

今天遇到一個問題，
一個靜態(tài)頁面xx.com/path_x1/a.html部署在xx.com靜態(tài)集群【browse----->靜態(tài)集群varnish------>靜態(tài)集群apache】
另外一個應(yīng)用又通過apache代理訪問xx.com,配置如下 ：
RewriteRule ^/$ http://xx.com/path_x1/a.html [L,P]  
訪問的url是 yy.com 【browse----->應(yīng)用集群apache----->靜態(tài)集群varnish------>靜態(tài)集群apache】


運營修改了這個頁面，需要立即更新，及希望能通過yy.com看到最新的，于是將 yy.com傳入到我們開發(fā)的一個varnish清除工具中，結(jié)果沒效果
后來將xx.com/path_x1/a.html傳入也沒效果，而且發(fā)現(xiàn)yy.com和xx.com/path_x1/a.html返回的居然是兩個不同的版本


接下來看看varnish緩存基本原理

    通常情況下varnish會根據(jù)訪問的host和url作為key, 但varnish 也提供了callback即配置文件中的vcl_hash，可以定制這個key
    除此之外還有一個陷阱就是被代理服務(wù)器的vary頭，通常情況下會返回Vary:Accept-Encoding，varnish會根據(jù)瀏覽器傳過來的這個頭（Accept-Encoding）的值，為同一個url緩存不同的版本，比如不支持壓縮，或者不同類型的壓縮（gzip?deflate?...?）
    可能某些被代理服務(wù)器返回的vary頭是Vary:Accept-Encoding，User-Agent，那就更悲摧了，版本會更加多

我排查了varnish后端的被代理服務(wù)排除了vary這個原因，
然后同過varnishlog仔細(xì)比對通過訪問yy.com和xx.com/path_x1/a.html時的日志，發(fā)現(xiàn)了問題


如果通過xx.com/path_x1/a.html訪問，那么varnish識別的host和url分別是xx.com和/path_x1/a.html
如果通過yy.com訪問，那么varnish識別的host和url分別是yy.com和/path_x1/a.html ,竟然不是我們通常認(rèn)為的yy.com和/ ，顯然是apache在proxy到varnish時做了變化


按照上面的情況，當(dāng)然是兩個不同的版本
如果要清除yy.com，需要將yy.com/path_x1/a.html傳入我們清除工具即可

看來我們的清除工具需要更自智能一些，遇到外站過來的代理，在了解映射規(guī)則的前提下智能清除緩存