EHCACHE简介

两个最著名的开源java 缓存解决方案的厂商现在由于 Terracotta 对 Ehcache 的收购联合到一起了。Terracotta，目前唯一的提供JVM级别的“POJO clustering集群”的厂商，能够提供多线程单一JVM应用，并且能让它们跨JVMs运行而不需要修改任何代码。Ehcache是目前部署使用最广泛的缓存应用，它提供了标准的HashMap类型接口，类似Oracle Coherence。这个合并对Java缓存领域将产生深远的影响。



http://ehcache.org/documentation/architecture.html

一. 几种成熟的缓存解决方案

1：EHCache是一个快速的、轻量级的、易于使用的、进程内的缓存。它支持read-only和read/write缓存，内存和磁盘缓存。是一个非常轻量级的缓存实现，而且从1.2 之后就支持了集群，目前的最新版本是1.4 。

2：OSCache是另外一个开源的缓存方案。它同时还支持JSP页面或任意对象的缓存。OSCache功能强大、灵活，和EHCache一样支持read-only和read/write缓存、支持内存和磁盘缓存。同时，它还提供通过JGroups或JMS进行集群的基本支持。

3：SwarmCache 是一个简单的、基于JavaGroups提供集群的缓存方案。支持read-only和nonstrict read/write缓存。这种缓存适用于读操作远远高于写操作频率的应用。

4：JBoss TreeCache 是一个强大的、可复制（同步或异步）和支持事务的缓存。如果你需要一个真正的支持事务的缓存架构，使用这个方案吧


二. EHCache的使用场合

1：比较少更新表数据
EhCache一般要使用在比较少执行write操作的表(包括update,insert,delete)[Hibernate的二级缓存也都是这样]；

2：对并发要求不是很严格的情况
两台机子中的缓存是不能实时同步的；

三. Ehcache的类层次模型

主要为三层，最上层的是CacheManager，他是操作Ehcache的入口。我们可以通过CacheManager.getInstance()获得一个单子的CacheManger，或者通过CacheManger的构造函数创建  一个新的CacheManger。每个CacheManager都管理着多个Cache。而每个Cache都以一种类Hash的方式，关联着多个Element。Element则是我们用于存放要缓存内容的地方。







四. Ehcache的jar包与配置文件

1：ehcache-1.4.0.jar:需要将它放置到WEB-INF/lib下

2：ehcache-1.4.0-remote-debugger.jar：不要发布到工程中，是用来调试和监控你的cache状况的

3：ehcache-1.4.0-sources.jar:源代码

4：ehcache.xml ：重要的配置文件，需要复制到classpath下 。

五. 配置文件ehcach.xml

1：DiskStore 配置，cache文件的存放目录 ，主要的值有：
* user.home - 用户主目录
* user.dir - 用户当前的工作目录
* java.io.tmpdir - Default temp file path默认的temp文件目录
* ehcache.disk.store.dir - A system property you would normally specify on the command line
          e.g. java -Dehcache.disk.store.dir=/u01/myapp/diskdir ...


2：defaultCache



3：Ehcache的三种清空策略  

3.1:FIFO(first in first out) :
这个是大家最熟的，先进先出。

3.2:LFU（ Less Frequently Used）：
就是上面例子中使用的策略，也是默认策略，直白一点就是讲一直以来最少被使用的。如上面所讲，缓存的元素有一个hit属性，hit值最小的将会被清出缓存。

3.3:LRU（Least Recently Used） ：
最近最少使用的，缓存的元素有一个时间戳，当缓存容量满了，而又需要腾出地方来缓存新的元素的时候，那么现有缓存元素中时间戳离当前时间最远的元素将被清出缓存。

六. 首页的页面缓存
一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存

1：缓存策略：
我认为应该是某个固定时间之内不变的，比如说2分钟更新一次。

2：位置：
以应用结构page-filter-action-service-dao-db为例，页面缓存做到尽量靠近客户的地方，就是在page和filter之间 ，这样的优点就是第一个用户请求之后，页面被缓存，第二个用户再来请求的时候，走到filter这个请求就结束了，无需再走后面的action-service-dao-db。带来的好处是服务器压力的减低和客户段页面响应速度的加快。

3：timeToLiveSeconds 与 timeToIdleSeconds ：
首页的页面缓存的存活时间，我们定的是2 分钟，那么也就是说我们的timeToLiveSeconds 应该设置为120 ，同时我们的timeToIdleSeconds 最好也设置为2 分钟，或者小于2 分钟。

4：具体配置:

4.1：ehcache.xml中：

<cache name = "SimplePageCachingFilter"
           maxElementsInMemory = "10"
           maxElementsOnDisk = "100"
           timeToIdleSeconds = "119"
           timeToLiveSeconds = "120"
           eternal = "false"
           overflowToDisk = "true"
           diskSpoolBufferSizeMB = "20"
           memoryStoreEvictionPolicy = "LFU"
            />

SimplePageCachingFilter 是缓存的名字

4.2：web.xml中：

<filter> 
    <filter-name>indexCacheFilter<filter-name> 
    <filter-class>
	   net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter
    <filter-class> 
  <filter> 
  
<filter-mapping> 
    <filter-name>indexCacheFilter<filter-name> 
    <url-pattern>*index.action<url-pattern> 
<filter-mapping>

七.  对gzip的支持

cachefilter中还有一个特性，就是gzip，也就是说缓存中的元素是被压缩过的，如果客户浏览器支持压缩的话，filter会直接返回压缩过的流，这样节省了带宽，把解压的工作交给了客户浏览器，如果客户的浏览器不支持gzip，那么filter会把缓存的元素拿出来解压后再返回给客户浏览器（大多数爬虫是不支持gzip的，所以filter也会解压后再返回流），这样做的优点是节省带宽，缺点就是增加了客户浏览器的负担。

补充：
如果一个应用中80% 的时间内都在访问20% 的数据，那么，这时候就应该使用缓存了(这个和长尾理论正好相悖)。

但即使是这样，缓存也有不同的用法，
举个例子：

1：一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存。

2：某个页面上，某个区域的record 访问频繁，那么我们就可以考虑给这个record 做二级缓存，因为二级缓存中是按照对象的id 来保存的，所以应该来说这几个区域使用的对象会一直存在于缓存之中（参见hibernate 的二级缓存）。

由此可见不同的页面的缓存策略有可能有天壤之别。