nginx cache现有的几个问题

在我这边现实环境中主要是有三个问题。 第一个问题是当cache过期的时候，nginx会把cache状态设置为updating，但是这个updating却没有设置一个超时，所以导致的情况当一个cache过期的时候好多nginx会连接到源站取数据，而如果源站并发量有限的话，会导致源站突发负载过高，而这个时候导致nginx一直处于updating过程中，如果导致源站挂掉的话，那完蛋了。当然我们也可以设置proxy_cache_use_stale updating;但是这样会导致cache的内容不准确。

解决的方法有2种，一个是我们现在更改nginx源码，使之可以updating设置有超时时间，这样不会导致长时间连接源站造成拥塞。另外一种就是nginx cache分层，分为父节点和子节点，只有父节点才会去源站更新，子节点只从父节点上更新。 第二个问题是upstream中server的状态，我们知道upstream中可以设置proxy_next_upstream当一个服务器挂掉后自动转到其它的服务器上，但是这里有个问题就是让用户访问的时候proxy会每次都会先访问下这个坏的服务器，连接不通了再转到其它服务器上，这每次都要测试会浪费大量的时间。我们需要得到的是proxy会独立一个线程去检查后端服务器，一旦发现后端服务器挂掉的话，那直接从upstream中剔除掉这个服务器就可。而等检测后端服务器又存活了再加进来。 这个现在有ngx_http_healthcheck_module这个第三方模块。具体可以参考http://wiki.nginx.org/HttpHealthcheckModule 第三个问题是nginx proxy连接nginx cache的时候居然使用的是http1.0的，而不是http1.1，就没法使用keepalive连接后端，导致我们小文件的cache服务器连接数过高，而没法进行复用链接。 这个暂时还没有解决，不过看到http://wiki.nginx.org/HttpUpstreamKeepaliveModule这个第三方模块，但是实际还没有测试过，没法做什么结论。 其实大家可以完全查看http://wiki.nginx.org/3rdPartyModules 来看看是否针对自己的应用，有些还是我们国人自己开发的，但是针对第三方模块还是要谨慎使用，上面的healthcheck模块还是经过我们自己的开发重新修改后并进行压力测试后再上线的。开源就是这点好啊。看来我要得学习学习C语言编程来，以后自己也改改增加增加功能啥的。