HTTP协商缓存实践

2017-09-18

从浏览器的缓存类型上来讲分为强缓存和协商缓存，之前写过一篇文章《HTTP缓存详解》做了详细的整理。

目前做的知识管理产品，为了首页能够更快的加载，需要对首页请求的资源做缓存整理。通过整理分析，决定对css、js做强缓存处理；对个人头像的请求做协商缓存处理；

为什么要头像不做强缓存处理呢？原因为目前的头像都是通过人员的ID来获取，而不是通过头像ID来获取。这样做的好处为在后台获取相关数据时，比如排行榜以人员ID作为主键，如果要带出该人员的头像信息，还得去头像表里面联查一下来获取头像ID。因此，由于后端部分的设计造成头像做协商缓存才是最优解。

目前的逻辑为，当用户第一次进入知识管理系统，请求个人头像的URL会返回200并从服务器下载个人头像，此时服务器会在response里面设置ETAG值为头像的最后修改日期；当刷新页面时，服务器会判断请求头中的If-None-Match是否与当前的最后更新日期匹配，如果匹配则直接返回304（不返回数据），如果不匹配则从磁盘中取出头像。

相关代码如下：

/**
 * 协商缓存控制
 * @param request
 * @param response
 * @param etag
 * @return
 */
private boolean cacheControl(HttpServletRequest request,HttpServletResponse response,String etag){
	String ifNoneMatch = request.getHeader("If-None-Match");
	if(etag.equals(ifNoneMatch)){
		response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
		return false;
	}
	response.addHeader("ETag", etag);
	return true;
}