在我們現有的架構中通常是已經成熟穩定的架構，如何将高性能的緩存伺服器部署在已有的環境上呢，同時部署容易，如何始終讓使用者看到的是最新的内容，即便是緩存命中的狀态？
是以，我們直接解決上面兩個問題！
通過實際使用情況，将varnish部署上線通常有兩種拓撲圖:
or
對于如何安裝varnish，請參考官方文檔或者之前的blog。兩種方式無外乎在于如何排程網站流量，以及配置源server而已。
有了上面的兩種結構，我們來說如何更新緩存的問題，這也是基本所有問題的所在。
舉個實際例子，通常作為一個cms站點，都會有通路域名(www)和管理域名(console)，這裡我們簡稱前台（客服妹子）和背景（diaosi chengxuyuan）,并且使用上面的第二種架構。 那麼我們的架構就是這樣的:
前台使用者通過internet通路您的網站，首先經過varnish的處理，如果cache中hit，ok，返給使用者，通路結束，如果miss，進行和之前沒有使用varnish的通路流程。（注：此處隻畫出必要的部分。當然像redis緩存等其他元件這些東西包含在上面的架構也是沒有任何問題的。）
背景編輯使用者，通過背景釋出更新，操作資料，并且更新到資料庫中。
現在問題來了(wa jue ji shu na jia qiang?!)：
解決這個問題通常有兩種方式：
可以衡量二者的優劣，
實際上我們通過背景管理系統可以向varnish發送更新某資源的請求即可，如下圖：
具體到配置：我們的前背景web伺服器均使用openresty，具體就不多介紹了，引用一句話"春哥是我見過開源精神最強的人"
首先對于我們需要修改的文章都是有對應的文章id，在背景編輯更新都會發起post請求，或者get請求。通過背景openresty在收到更新文章請求時，發送一個同步的非阻塞的子請求到前台varnish，并在varnish中配置用于接收該請求，執行varnish的ban操作。
我們來看配置檔案。
背景的openresty：
當然這隻是最核心能說明問題的代碼，不了解的可以查閱ngx.location.capture ，通過在該location中加入rewritebylua，具體它和proxy_pass的執行順序是rewrite在前。筆者在實際測試中發現，nginx的第三方子產品echo也提供發起了子請求的功能，但實際始終在proxy_pass之後，并不能實作需要的功能。
前台的varnish，同樣取核心部分：
這裡主語clint.ip當然你可以設定為一個叢集,這個參考官方文檔。
這樣後端更新時會通知varnish更新相關的資源，主動更新功能實作。 由于設定了return(pass),在前端的web中最好配置一段location來比對該請求，可以簡單的return 200即可。
前端web：
對于有需要更新圖檔等靜态資源的情況。可以編寫一個通用的ban或者purge接口。具體可參考官方文章。
配置檔案基于varnish4，建議需要上生成環境的，多閱讀官方文檔。當然也可以瞅瞅我的部分部落格，總之，多測試！！word is cheap ，show me your code。