WEB緩存系統之varnish狀態引擎

　　前文咱們聊了下varnish的VCL配置以及語法特色，怎樣去編譯加載varnish的vcl配置，以及命令行管理工具varnishadm怎麼去鏈接varnish管理接口進行管理varnish，回顧請參考http://www.javashuo.com/article/p-kurdszjv-mk.html；今天咱們來講一下varnish的狀態引擎；首先咱們來回顧下iptables報文的走向，在iptables裏報文的走向有三種，第一種是從別的主機發送過來的報文，首先它會到達網卡，而後進入prerouting鏈，而後通過路由決策後，若是是發往本機的，則就走input鏈，從而把報文送給本機上的應用程序；第二種是從prerouting鏈經過路由決策後，不是發往本機的報文而是發往其餘主機，經過本機轉發的，它會從prerouting鏈到forward鏈，而後從postrouting鏈把報文發送給其餘主機；第三種是從本機發往其餘主機的報文，它的報文走向是從output鏈到postrouting鏈，而後從網卡發送出去；咱們說iptables的緣由是類比varnish的狀態引擎；varnish的狀態引擎就相似iptables裏的這5鏈；咱們寫的vcl配置就至關於iptables裏的規則；他倆有個共同點就是在每一個鏈上的規則只對當前鏈上的表或者被自定義鏈引用纔會生效，而varnish裏的狀態引擎也是一樣的邏輯，咱們寫的vcl配置只對當前狀態引擎生效，不一樣的狀態引擎處有着不一樣的意義，對其餘狀態引擎互不干擾；這樣描述相信你們對varnish的狀態引擎有了初步的概念，這也是咱們在上一篇文中說到的，發送給客戶端的響應報文，爲何要配置在vcl_deliver裏，而不是其餘位置；接下來咱們看看varnish的狀態引擎；

 　　提示：以上這張圖上varnish4.0的狀態引擎圖，每一個狀態引擎彼此的關係，以及varnish內部緩存處理邏輯；首先當varnish服務器收到來自客戶端的請求報文，最早到達的狀態引擎是vcl_recv，咱們能夠在vcl_recv裏面對客戶端的請求報文作修改，或者其餘操做，而後交給vcl_hash這個狀態引擎，這個狀態引擎主要是看是否可查緩存，若是能夠查緩存，會判斷是否命中，命中就交給vcl_hit處理，vcl_hit處理後，就直接交給vcl_deliver處理，最後響應給客戶端，固然緩存命中後也能夠將請求交給vcl_pass處理；若是vcl_hash處理後不能查緩存，就把報文發送給vcl_miss處理，意思是不能查緩存，或者緩存未能命中；固然咱們也能夠直接把報文交給vcl_pass處理；即使它能夠被緩存命中，咱們也是能夠強行讓該請求不查緩存，直接交給vcl_pass處理或者vcl_miss直接交給vcl_backend_fatch處理；vcl_backend_fetch就是去後端真正的服務器上取對應資源，而後它會對後端服務器的響應報文頭部進行讀的操做，若是沒有什麼錯誤，就把響應報文發送給vcl_backend_response，vcl_backend_response在處理響應報文時，會判斷是否可緩存，若是能夠緩存，就在本地緩存一份，而後經過vcl_deliver響應給客戶端，若是不可緩存，在本地就不緩存，直接將響應報文發送給vcl_deliver響應給客戶端；若是vcl_backend_fetch讀後端服務器發來的響應報文是錯誤響應（或者vcl_backend_fatch未取到對應資源，或者後端主機宕機等等），它就會把該處理邏輯交給vcl_backend_error處理；若是用戶的請求通過vcl_hash處理後，發現緩存內容變了或者說緩存過時了須要修剪緩存，它會把請求發往vcl_purge，vcl_purge主要處理緩存修剪相關的操做，而後把請求報文發送給vcl_synth處理，合成一響應發送給客戶端；若是經過vcl_hash處理後發現用戶請求的方法咱們壓根就不認識，這個時候會將請求報文交給vcl_pipe處理；

　　從上面的圖來看，咱們大概能夠總結爲兩點，varnish的狀態引擎分前端工做線程或者客戶端狀態引擎和後端工做線程或者服務端狀態引擎；客戶端狀態引擎，主要處理客戶端請求和響應相關的處理，好比是否可查緩存，是否命中，是否修剪緩存，是否識別用戶請求的方法有或者直接交給vcl_pass，又或者說怎樣響應客戶端等等，能夠看到客戶端狀態引擎vcl_pass，是一個額外處理機制，不論是否可查緩存，是否命中，均可以交給它處理；對於服務端狀態引擎主要是處理和後端服務器請求和響應相關操做，好比怎樣去後端服務器取資源，對服務器的響應報文是否可緩存，怎麼緩存，對後端服務器的響應報文錯誤怎麼處理等；

　　varnish的前端狀態引擎有vcl_recv,vcl_pass, vcl_hit, vcl_miss, vcl_pipe, vcl_purge, vcl_synth, vcl_deliver;vcl_recv處理後能夠經過return來指定下一跳處理的狀態引擎是那個，若是是return（hash）就表示交給vcl_hash處理；return（pass）就表示交給vcl_pass處理；return（pipe）就表示交給vcl_pipe處理；return(synth)就表示交給vcl_synth處理；return(purge)就表示交給vcl_purge處理；對於vcl_hash來講，return（hit）就表示緩存命中交給vcl_hit處理，return（miss）表示緩存未能命中交給vcl_miss處理，return（pass）或者return(hit_for_pass)就表示即使緩存命中也交給vcl_pass處理，return（purge）就表示交給vcl_purge處理；

　　varnish的後端狀態引擎有vcl_backend_fetch, vcl_backend_response, vcl_backend_error；vcl_backend_fetch處理去後端取資源的操做，vcl_backend_response處理後端服務器響應回來的報文，vcl_backend_error處理後端服務器錯誤；除此之外varinsh4.0還有兩個特殊的狀態引擎，分別是vcl_init和vcl_fini；vcl_init：在處理任何請求以前要執行的vcl代碼：主要用於初始化VMODs；vcl_fini：全部的請求都已經結束，在vcl配置被丟棄時調用；主要用於清理VMODs；

　　瞭解了上面的狀態引擎，咱們在說一說varnish的變量，在前文咱們大概說了下varnish的變量大概能夠分5類，一類是客戶端請求報文相關的，req.*；一類是varnish服務器請求後端服務器報文，bereq.*；一類是後端服務器響應varnish服務器的beresp.*；一類是varnish服務器響應客戶端的resp.*；還有一類是obj.*，這類變量主要是儲存緩存空間中的緩存對象的屬性；結合上面說的狀態引擎，不難裏接在不一樣的狀態引擎裏，對應變量是有限的，好比bereq.*這類變量就不能用於vcl_recv，由於vcl_recv是接收用戶請求相關的，而bereq.* 是varnish請求後端服務器的變量，這二者很明顯是再也不一個級別的，因此一般不一樣類的變量對應可以用於哪些狀態引擎中是有限制的；而對應變量的屬性也是有要求的，好比obj.hit這個變量是存儲緩存項命中次數的，一般可用在vcl_hit和vcl_deliver狀態引擎中，表示應用緩存命中次數，相對於這個變量來講，咱們是不能修改的，因此obj.hits這個變量在vcl_hit和vcl_deliver狀態引擎中只可讀，不可修改；而對於obj.ttl這個值就不同了；obj.ttl記錄緩存項可緩存的時間；很顯然obj.ttl這個變量只能用於可緩存的狀態引擎上，好比vcl_hit，對於告訴客戶端可緩存的時間，很明顯它不能是一個不可修改的值；因此對於obj.ttl這個變量在vcl_hit狀態引擎中就具備可讀可寫權限（即咱們能夠修改該變量的值）；說這麼多無外乎就是表達一個意思，不一樣類型的變量受限狀態引擎，不一樣變量在不一樣的狀態引擎上不是均可讀可寫，有的變量只可讀；以下圖

 　　說明：以上這張表就是對於不一樣類型的變量對應varnish的狀態引擎是否可讀寫的，沒有讀寫就表示該類型變量不能用於對應狀態引擎中；好比resp.*只能在error和deliver狀態引擎中使用；beresp.*這類變量只能用於後端主機響應varnish服務器的過程當中使用，好比fetch這個狀態引擎就是處理後端服務器響應varnish服務器請求的；因此beresp.*這類變量只能用於fetch;固然這裏的fetch是早期狀態引擎的名稱。在varnish4.0它不叫fetch，而叫vcl_backend_fatch；

　　瞭解了以上內容，咱們接下來看幾個示例

　　示例：強制對某類資源的請求不檢查緩存

 　　提示：以上配置表示對客戶端請求的url進行判斷，若是可以被.jpg、.jpeg、.png、.gif、.js、.css、.html匹配到，那麼就把用戶請求交給pass狀態引擎處理；pass狀態引擎處理就是不查緩存；因此對於客戶端請求.jpg的資源，其對應obj.hits的值會一直爲0；由於咱們明確指定了不查緩存；

　　測試：用瀏覽器訪問服務器上的.jpg資源，看看響應報文中咱們自定義的X-Cache 首部是不是 miss via 192.168.0.99；

 　　提示：能夠看到咱們訪問/day.jpg這個資源時，無論怎麼刷新瀏覽器，對應響應首部X-Cache的值都是 miss via 192.168.0.99，說明咱們請求.jpg的資源的確沒有查緩存；

　　示例：把客戶端IP傳到後端服務器

 　　提示：以上vcl表示判斷客戶端請求首部X-Forwarded-For是否爲空，若是不爲空就把它的值在原有的值的基礎上和客戶端ip地址作字符串鏈接，並用逗號隔開；若是該首部爲空或者沒有這個首部就把這個首部的值設置成客戶端ip地址；

　　更改後端web 服務的日誌格式

 　　提示：以上配置表示在日誌格式中應用X-Forwarded-For這個首部的值；

　　測試：從新編譯加載vcl，而後用瀏覽器訪問，看看是否可以把瀏覽器所在主機的ip地址傳到後端httpd服務器日誌中作記錄？

 　　提示：從上面的日誌結果看，咱們分別用不一樣的瀏覽器去訪問，在日誌中能夠看到不一樣瀏覽器所在主機的IP地址，說明咱們經過判斷用戶請求報文X-Forwarded-For首部是否爲空，從而實現對於非空和空值對應設置該首部值，繼而實現把對應請求首部值記錄到後端服務器日誌中的目的；

　　示例：對於特定類型的資源，例如公開的圖片等，取消其私有標識，並強行設定其能夠由varnish緩存的時長；

 　　提示：首先咱們要清楚在那個位置去對報文操做，取消私有標識，是須要在後端服務器響應varnish這個過程當中把對應響應首部的值給撤銷了；因此咱們須要在vcl_backend_response這個狀態引擎中來設置，取消set-cookie首部，這個首部主要是給對應客戶端設置一個cookie;以上配置表示判斷後端服務器響應varnish服務器的響應報文首部cache-control的值是否匹配「s-maxage」，若是不匹配說明該資源不容許被共有緩存系統所緩存，若是匹配，則說明該資源容許被公有緩存系統所緩存；若是不匹配再繼續判斷varnish向後端請求的首部url的值是否匹配.jpg|jpeg|png|gif|css|js結尾的資源，若是匹配則取消後端服務器響應varnish服務器的響應首部set-cookie的值，並設置後端服務器響應varnish的資源緩存時長爲1小時；簡單講就是判斷後端服務器響應首部的cache-control的值是否匹配到「s-maxage」，若是不能匹配到在判斷向後端服務器請求的首部url是不是匹配指定結尾的資源，若是是，就取消後端服務器響應首部set-cookie這個首部，同時把後端服務器響應資源的緩存時長設定爲1小時；

　　測試：爲了驗證以上vcl配置正確性，咱們把beresp.ttl的值經過cache-control這個首部傳遞到瀏覽器響應首部，從而來判斷set-cookie首部是被撤銷了；

 　　提示：在上面的配置中加入了set beresp.http.cache-control = beresp.ttl;表示把後端響應給varnish的響應首部beresp.ttl的值 經過beresp.http.cache-control首部保存；這樣客戶端訪問.jpg的資源就會在響應首部中把cache-control的值給顯示出來，若是該值是咱們設置的3600s，就說明咱們撤銷set-cookie這個首部的vcl語句是生效的；

 　　提示：從上面的結果看，cache-control的值爲3600是咱們設置beresp.ttl的值；說明撤銷set-cookie的vcl配置生效了；同時這也告訴咱們若是後端服務器響應varnish的報文中沒有的首部，在varnish響應客戶端中就沒有；簡單說就是varnish會把後端服務器響應給varnish中首部的值經過響應客戶端首部傳遞出來；好比我在後端響應報文中自定義一個aaa的報文首部，其值爲bbb，那麼在客戶端的響應報文首部中就會有對應aaa首部和對應的值；以下

 　　測試：

 　　提示：作以上測試須要考慮varnish上的緩存，若是你始終訪問同一個url可能會看到對應首部的值不會發生變化，須要重啓varnish或者換個其餘符合vcl定義的url去訪問試試看；