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默認就是不存的。對於故障信息的存儲根據實際業務處理，有些故障信息是有必要存儲的，還有任何資源如果源站出問題，要設置吐過期資源給用戶，做到起碼用戶可以訪問，保護一下源站。個別資源的緩存處理根據業務需要個別設置。
本文出自 “奔跑的linux” 博客，請務必保留此出處http://benpaozhe.blog.51cto.com/10239098/1763897