Ehcache（09）——缓存Web页面

http://haohaoxuexi.iteye.com/blog/2121782

 

 

页面缓存

目录

1       SimplePageCachingFilter

1.1      calculateKey

1.2      可配置的初始化参数

1.2.1     cacheName

1.2.2     blockingTimeoutMillis

2       SimpleCachingHeadersPageCachingFilter

3       SimplePageFragmentCachingFilter

 

       Ehcache除了支持对象的缓存之外，还可以对Web页面进行缓存。这是通过ehcache-web模块下的Filter支持的。Ehcache会自动对Response进行gzip压缩，并且将压缩后的内容保存在缓存中。如果客户端是支持gzip的，那么服务端将直接返回gzip之后的Response，否则将从缓存中提取出来对应的Response进行解压缩，然后再返回给客户端。如果客户端是支持gzip的，那么它必须在请求的Header中包含“Accept-Encoding: gzip”。

 

1       SimplePageCachingFilter

       这是ehcache-web模块下页面缓存Filter的一个简单实现，适用于可以压缩的Http响应（response），如HTML、XML、JSON等。它会使用通过CacheManager的静态方法create创建的单例CacheManager，这样如果之前已经存在CacheManager的实例了的话，这里就会直接拿来用，而不会再创建了。所以这里一般默认情况下会取类根路径下的ehcache.xml文件或ehcache-failsafe.xml文件来创建CacheManager，但如果我们的项目中整合了Ehcache和Spring，且在Spring配置文件中指定的Ehcache的配置文件不是默认位置的话，Spring将使用指定的配置文件优先初始化CacheManager，这样SimplePageCachingFilter中要使用CacheManager时就不会再初始化了，而是直接使用Spring初始化的。

       SimplePageCachingFilter适用于缓存整个页面的情况，如果只需要缓存某一个片段，如使用jsp:include包含的部分，请使用SimplePageFragmentCachingFilter。

1.1     calculateKey

       我们都知道，Ehcache是以键值对的形式保存元素的，对于页面的缓存也不例外。页面缓存使用的key是通过SimplePageCachingFilter的calculateKey()方法获取的。其内部逻辑是获取请求时的URI及后面的查询字符串作为key进行返回，如“/user/index.jsp?name=abc”，这使得它的应用范围非常广。它不依赖于主机名和端口号，这将使得它同样适用于有多个域或多个端口请求同样内容的情况。如果有需要，我们可以对calculateKey方法进行重写，从而实现我们自己的计算key的逻辑。

 

1.2     可配置的初始化参数

       对于SimplePageCachingFilter而言，可配置的初始化参数有两个，cacheName和blockingTimeoutMillis。

1.2.1  cacheName

       在使用SimplePageCachingFilter时，我们需要通过初始化参数cacheName（init-param）指定当前Filter用于缓存的Cache的名称，对应于Ehcache配置文件中Cache的名称，默认为SimplePageCachingFilter。

<filter>  
   <filter-name>ehcacheFilter</filter-name>  
<filter-class>net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter</filter-class>  
   <init-param>  
      <param-name>cacheName</param-name>  
      <param-value>webPageCache</param-value>  
   </init-param>  
</filter>  
<filter-mapping>  
   <filter-name>ehcacheFilter</filter-name>  
   <url-pattern>/index.jsp</url-pattern>  
   <dispatcher>FORWARD</dispatcher>  
   <dispatcher>INCLUDE</dispatcher>  
   <dispatcher>REQUEST</dispatcher>  
</filter-mapping> 

 

1.2.2  blockingTimeoutMillis

       在多线程并发的情况下，为了避免多个线程请求同一个key而做重复的无用的工作， CachingFilter底层使用的是BlockingCache，如果提供的Cache不是BlockingCache，那么Ehcache将使用BlockingCache对当前Cache进行封装。BlockingCache允许并发读已经存在于cache中元素，但是如果进行读操作的时候对应的元素是不存在的，那么除第一个获取到锁（Lock）的线程之外的线程都会被阻塞起来，直到有线程往里面放置了对应的元素为止。默认情况下，如果第一个线程没有往Cache里面put对应的元素的话，这些线程会一直处于等待状态，这样时间长了之后服务端会因为拥有太多请求的连接没有返回而难堪重负。为此，我们可以在定义CachingFilter时通过初始化参数blockingTimeoutMillis来解决这一问题。通过设置blockingTimeoutMillis参数，BlockingCache最多只会阻塞指定的时间，即被阻塞的线程只会最多阻塞给定的时间，之后如果超时的话会抛出LockTimeoutException。

 

2       SimpleCachingHeadersPageCachingFilter

       SimpleCachingHeadersPageCachingFilter继承自SimplePageCachingFilter，以提供HTTP缓存头信息。也就是说使用SimpleCachingHeadersPageCachingFilter与使用SimplePageCachingFilter几乎是一样的。所不同的是前者在构建返回信息的时候会设置“Last-Modified、Expires、Cache-Control、ETag”这四个缓存头信息，如果在设置之前这些信息已经存在的话，那么它们将会被忽略，而直接使用SimpleCachingHeadersPageCachingFilter重新生成过的。

       由于浏览器和其它HTTP客户端都拥有包含在返回信息头中的过期信息，以至于在信息未过期前，它们不需要再次请求对应的页面。SimplePageCachingFilter是没有设置这些头信息的，那也就意味着使用SimplePageCachingFilter时每次客户端都需要向服务端请求页面。那你为什么还要用SimplePageCachingFilter呢？考虑这样一种场景，我们有一个页面包含了动态数据，我们对它进行了缓存，如果使用SimpleCachingHeadersPageCachingFilter的话，返回头信息中会包括过期信息，这也就意味着在客户端本地缓存的页面过期之前它不会再向服务端请求对应的页面，而如果此时服务端更新了这个页面的缓存，或者是移除了这个缓存，之前在本地缓存过该页面的客户端只能等到其本地的信息正常超时后才能得到服务端更新的页面。而此时如果我们使用的是SimplePageCachingFilter的话，由于没有过期等缓存头信息，客户端每次都会向服务端发起请求，这样服务端页面有变化时客户端都能即时获取到更新。在这种情况下，缓存的作用是减少服务端的负载，而不是减少浏览器的请求。

       SimpleCachingHeadersPageCachingFilter缓存的页面信息是包含“Last-Modified、Expires、Cache-Control、ETag”这四个头信息的。这样当缓存中存在对应的页面时，所有的请求获取到的页面的头信息都会是一样的。

 

3       SimplePageFragmentCachingFilter

       SimplePageFragmentCachingFilter适用于对使用jsp:include包含的页面的缓存。除了不对Response进行gzip之外，SimplePageFragmentCachingFilter能做所有SimplePageCachingFilter能做的事情，这里就不对SimplePageFragmentCachingFilter做过多重复的介绍了。

 

（注：本文是基于ehcache2.8.1和ehcache-web2.0.4所写）