Nginx/tengine作cache時緩存機制—存不存、存多久、用不用方法論

    Nginx/tengine(後面名稱只寫nginx了)單純作cache性能比不過ats，特別是在磁盤處理方面，不過論綜合能力nginx就是大拿了，他集web服務器、負載均衡、cache三種能力於一身，能夠說是很是綜合性的選手。好比說一箇中型網站的場景選型，前端是負載，後端託着一堆apache服務器，如今該到前端負載選型的了，雖然lvs和ha單純從負載的性能要比nginx好一些，但我仍是會選nginx，由於nginx在作負載的同時，能夠將熱點的靜態內容cache一遍，作一次加速，無形間減輕了後端web服務器的一些壓力，提升了用戶體驗，一舉兩得。Nginx作cache配置是很靈活的，裏面有各類緩存指令，起初接觸會摸不到北，我用了也有一段時間了，如今總結一下nginx作cache時我認爲的三大症結——存不存、存多久、用不用？

    nginx的資源是否緩存是由客戶端、源站與nginx的緩存配置共同決定，nginx若是沒有緩存策略配置，默認按照request請求頭、header響應頭信息走標準的http緩存判斷機制（看cache-control、expires、cookie這些屬性），僅當一個資源沒有被設爲不能緩存的黑名單，且有大於0的存放時間的生命週期時，資源才被緩存，對於nginx緩存判斷流程我花精力畫了一張結構圖分享以下：

 

   測試舉例，默認配置，一個200ok資源（http://www.haixiano.com/member/login.php）  只有cookie信息沒有max-age。

第一次測試配置參數：

proxy_cache_valid 200 10m;

#proxy_ignore_headers Set-Cookie; 註釋掉

頭信息以及測試以下：

屢次訪問操做以下：

屢次訪問日誌以下（所有MISS）：

小結：雖然有對於200ok的信息設置緩存時間爲10分鐘，可是cookie信息的首先判斷是不能存，因此根本不會看你對200ok資源的緩存時間，最終結論是不能存。

第二次測試配置參數：

#proxy_cache_valid 200 10m;註釋掉

proxy_ignore_headers Set-Cookie; 

屢次訪問日誌以下（所有MISS）：

小結：雖然忽略了對cookie信息的判斷，告訴nginx有cookie的信息是能夠存的，可是對於200ok的信息設置緩存時間爲0，因此最終資源仍是不能存。

第三次測試配置參數：

proxy_cache_valid 200 10m;

proxy_ignore_headers Set-Cookie; 

屢次訪問日誌以下（1次訪問MISS後，以後均爲HIT）：

小結：首先忽略了cookie信息的判斷，告訴nginx說cookie信息是能夠存的，後查詢沒有expires和max-age就去找默認緩存時間，發現對於200ok的默認緩存時間是10m，因此最終斷定能夠緩存，有效緩存時間爲10分鐘。

    綜上，一個資源只有同時具有可緩存和有緩存時間大於0的生命週期的雙重屬性，才能真正被緩存下來，至於存下來以後用不用還得再進行下一步的判斷。因此nginx對於資源是否緩存要通過兩步判斷，第一步存不存，第二步存多久，對因而否用緩存了的資源爲用戶進行服務還得進行下一層用不用的判斷，詳細的走的判斷參數能夠看我畫的那張圖。

    優化建議：爲了作到cache加速的同時，又不影響業務，在緩存策略配置上最好遵循頭部信息的要求，不要忽略nocache等字樣強制存儲，也就是說proxy_ignore_headers指令慎用，好比一些圖片驗證碼和一些php、jsp、asp等動態內容在存儲了後，用戶屢次訪問會返回一樣的信息，致使用戶報障。還有一類資源是沒有明確生命週期緩存頭的（無cache-control或expires），也就是沒有任何緩存要求，建議採用保守方式不要存儲，主要是proxy_cache_valid指令的配置，有cookie的信息nginx默認就是不存的。對於故障信息的存儲根據實際業務處理，有些故障信息是有必要存儲的，還有任何資源若是源站出問題，要設置吐過時資源給用戶，作到起碼用戶能夠訪問，保護一下源站。個別資源的緩存處理根據業務須要個別設置。

自建我的原創站運維網咖社(www.net-add.com)，新的博文會在網咖社更新，歡迎瀏覽。