CDN缓存 2014-04-16

 

前端压力测试结果： 单屏请求 | 响应4S | 日均PV-5W

结果不能满足电商网站要求，分析确定服务器带宽是瓶颈（服务器带宽仅10M）。

 

为了解决问题，公司决定购买CDN服务(Content Delivery Network，即内容分发网络 - 建立在互联网基础之上的缓存服务节点)。

我们的初衷是将网站静态资源（如:JS,CSS,IMG）缓存到CDN服务节点，CDN节点直接返回静态资源，从而缓解服务器带宽压力同时提高响应速度，从而提升用户体验。

CDN服务加上了，但结果似乎并不像我们想要的这么简单：

生产环境验证发现用户A登录后看到的是其他用户的登录信息,这可不是小问题，严重生产故障！

 

预发布环境的web容器和数据库环境都是一样的，预发布验证并未暴露上述问题，排除session缓存，redis缓存等原因，问题自然锁定到CDN缓存上。

运维同事给出建议：在每个请求后加动态参数，这样可以避免CND对动态请求（action请求）进行缓存。

目的可以达到，但工作量太大，涉及链接太多，很可能出现遗漏，而且极不易于维护。

当时本人提出问题：缓存是否可以区分请求后缀，有所缓存有所不缓存。运维同事表示CDN的缓存策略没有配置权限。

如果不能配置，难道所有使用CDN的站点都会存在同样问题？（51cdn）

这似乎不太可能。

查询CDN缓存策略发现CDN对资源的缓存确实是有区分的，缓存只针对静态文件如.js .css .image .html等。对于.do .action等动态请求是不会缓存的。

到了这里，几乎可以确定我们的动态请求被当成静态请求缓存起来了。

 

这并不奇怪，因为我们action请求的后缀全是.htm。

要知道htm和html是等同看待的，.htm结尾的请求被CDN当成html缓存起来，再次请求是同一路径时

请求直接命中CDN缓存，并未经过我们的Tomcat实例，所以才出现这次故障。

问题根蒂找出来了，要解决很简单，将后缀改成.do或.action或者其他动态请求后缀。

 

总结: 使用CDN或者其他网络缓存技术一定要弄清楚它的缓存策略，避免不需要缓存的资源被缓存。