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)，新的博文会在网咖社更新，欢迎浏览。