Nginxtengine做cache时缓存机制—存不存、存多久、用不用方法论

Nginx/tengine做cache时缓存机制—存不存、存多久、用不用方法论

Nginx/tengine(后面名字里只写了Nginx)只是单纯的提高了缓存的性能，但是ats，尤其是硬盘解决方案层面的，综合能力来说是大不了的。nginx集web服务器、三层交换机、缓存三种工作能力于一身，可谓是非常全面的选手。比如一个中小型网站的场景模型选择，前端开发是负载，后端开发是一堆apacheweb服务器支撑。现在是时候选择前端开发负载模型了。虽然lvs和ha在简单负载方面比nginx好，但我还是会选择nginx。由于nginx在做负载，可以一次缓存网络热点的静态数据内容，加快速度，无形中减轻了后端开发web服务器的一些工作压力，促进了客户。使用NGX作为缓存设备非常方便。里面有各种缓存命令，刚开始接触不到，所以用了一段时间。现在我总结一下Nginx做缓存时我认为的三大问题——是否保存，保存多久，是否使用？

nginx的资源是否缓存由nginx的移动客户端、源站和缓存设备决定。如果nginx没有配备缓存对策，则默认根据请求request头和headerresponse头信息设置http缓存解析系统(见cache-control、expiration和cookie的特性)。只有当一个资源没有被设置为不能缓存的信用黑名单，并且其生存期超过0存储时间时，才缓存该资源。我花精力画了nginx缓存解析步骤的框架图，分享如下:

例如，默认设置是200ok资源(http://www.haixiano.com/member/login.php)只有cookie信息，没有最大年龄。

第一次测试的主要参数:

Proxy_cache_valid20010m

#proxy_ignore_headersSet-Cookie；给…作注解

报头信息及其检测如下:

浏览几次实际 *** 作如下:

浏览以下日志几次(全部错过):

总结:虽然200ok信息的缓存时间设置为10分钟，但是cookie信息的第一判别是保存不了，所以根本不容易看你200ok资源的缓存时间，最后的结果是保存不了。

第二次测试的主要参数:

#proxy_cache_valid200十米；给…作注解

proxy_ignore_headersSet-Cookie；

浏览以下日志几次(全部错过):

总结:虽然忽略了cookie信息的判别，但是告诉nginx有cookie的信息是可以保存的，但是对于200ok的信息，缓存时间设置为0，所以最后的资源无法保存。

第三次测试的主要参数:

Proxy_cache_valid20010m

proxy_ignore_headersSet-Cookie；

浏览日志以下次数(浏览错过一次以后都是命中):

总结:一开始我忽略了cookie信息的辨别，告诉nginxcookie信息是可以存储的。在检查没有过期和最大年龄之后，我必须找到默认的缓存时间。我发现200ok默认的缓存时间是10米，所以最后判断是可以缓存的，合理的缓存时间是10分钟。

综上所述，一个资源只有具备可缓存和具有缓存时间超过0的生存期的双向特性，才能真正被缓存。保存后不需要进行下一步的判别。所以nginx要通过两步来区分资源是否缓存，第一步是是否存储，第二步是存储多长时间，下一步是区分缓存的资源是否用于为客户开展服务项目。详细标识的主要参数见我的图纸。

推广建议:为了更好地保证缓存提速且不伤害业务流程，最好遵循缓存顶部信息的规定，同时也不要忽略nocache等强制存储的字。换句话说，proxy_ignore_headers命令要谨慎使用，比如一些图形验证码和一些php、jsp等。还有一类资源没有生存期缓存头(无缓存控制或过期)，即没有缓存规则。建议选择传统的不存储的方式，主要是用proxy_cache_valid命令，不存在nginx带cookie的默认设置。对于常见故障信息的存储，根据具体业务流程解决。一些常见的故障信息必须存储，资源都有。如果源站出现问题，需要将过期的资源设置给客户，保证至少客户可以浏览和维护源站。某些资源的缓存解决方案必须根据业务流程进行设置。

建立自己的原创站运维网吧(www.net-add.com)，新博客在网吧升级。热烈欢迎参观。