ehcache 的使用

http://my.oschina.net/chengjiansunboy/blog/70974

在开发高并发量，高性能的网站应用系统时，缓存Cache起到了非常重要的作用。本文主要介绍EHCache的使用，以及使用EHCache的实践经验。
笔者使用过多种基于Java的开源Cache组件，其中包括OSCache、JBossCache、EHCache。OSCache功能强大，使用灵活，可用于对象缓存、Filter缓存以及在JSP中直接使用cache标签。笔者在最近的使用过程中发现，在并发量较高时，OSCache会出现线程阻塞和数据错误，通过分析源代码发现是其内部实现的缺陷。JBossCache最大的优点是支持基于对象属性的集群同步，不过JBossCache的配置使用都较复杂，在并发量较高的情况下，对象属性数据在集群中同步也会加大系统的开销。以上两种Cache本文仅作简单介绍，不做深入探讨。

EHCache是来自sourceforge（http://ehcache.sourceforge.net/）的开源项目，也是纯Java实现的简单、快速的Cache组件。EHCache支持内存和磁盘的缓存，支持LRU、LFU和FIFO多种淘汰算法，支持分布式的Cache，可以作为Hibernate的缓存插件。同时它也能提供基于Filter的Cache，该Filter可以缓存响应的内容并采用Gzip压缩提高响应速度。

EHCache API的基本用法. 首先介绍CacheManager类。它主要负责读取配置文件，默认读取CLASSPATH下的ehcache.xml，根据配置文件创建并管理Cache对象。

view source
print?
 01// 使用默认配置文件创建CacheManager  
 
 02CacheManager manager = CacheManager.create(); 
 
 03// 通过manager可以生成指定名称的Cache对象  
 
 04Cache cache = cache = manager.getCache("demoCache"); 
 
 05// 使用manager移除指定名称的Cache对象  
 
 06manager.removeCache("demoCache"); 
 
 07可以通过调用manager.removalAll()来移除所有的Cache。通过调用manager的shutdown()方法可以关闭CacheManager。 
 
 08有了Cache对象之后就可以进行一些基本的Cache操作，例如：  
 
 09//往cache中添加元素 
 
 10Element element = new Element("key", "value");  
 
 11cache.put(element); 
 
 12//从cache中取回元素 
 
 13Element element = cache.get("key"); 
 
 14element.getValue(); 
 
 15//从Cache中移除一个元素 
 
 16cache.remove("key"); 
 
 17可以直接使用上面的API进行数据对象的缓存，这里需要注意的是对于缓存的对象都是必须可序列化的。在下面的篇幅中笔者还会介绍EHCache和Spring、Hibernate的整合使用。

2.配置文件

view source
print?
 01配置文件ehcache.xml中命名为demoCache的缓存配置：  
 
 02<cache name="demoCache"
 
 03maxElementsInMemory="10000"
 
 04eternal="false"
 
 05overflowToDisk="true"
 
 06timeToIdleSeconds="300"
 
 07timeToLiveSeconds="600"
 
 08memoryStoreEvictionPolicy="LFU" /> 
 
 09各配置参数的含义： 
 
 10maxElementsInMemory：缓存中允许创建的最大对象数  
 
 11eternal：缓存中对象是否为永久的，如果是，超时设置将被忽略，对象从不过期。 
 
 12timeToIdleSeconds：缓存数据的钝化时间，也就是在一个元素消亡之前，两次访问时间的最大时间间隔值，这只能在元素不是永久驻留时有效，如果该值是 0 就意味着元素可以停顿无穷长的时间。 
 
 13timeToLiveSeconds：缓存数据的生存时间，也就是一个元素从构建到消亡的最大时间间隔值，这只能在元素不是永久驻留时有效，如果该值是0就意味着元素可以停顿无穷长的时间。 
 
 14overflowToDisk：内存不足时，是否启用磁盘缓存。  
 
 15memoryStoreEvictionPolicy：缓存满了之后的淘汰算法。LRU和FIFO算法这里就不做介绍。LFU算法直接淘汰使用比较少的对象，在内存保留的都是一些经常访问的对象。对于大部分网站项目，该算法比较适用。 
 
 16如果应用需要配置多个不同命名并采用不同参数的Cache，可以相应修改配置文件，增加需要的Cache配置即可。

3.利用Spring APO整合EHCache

view source
print?
 01首先，在CLASSPATH下面放置ehcache.xml配置文件。在Spring的配置文件中先添加如下cacheManager配置： 
 
 02<bean id="cacheManager"
 
 03class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"> 
 
 04</bean> 
 
 05配置demoCache： 
 
 06<bean id="demoCache" class="org.springframework.cache.ehcache.EhCacheFactoryBean"> 
 
 07<property name="cacheManager" ref="cacheManager" /> 
 
 08<property name="cacheName"> 
 
 09<value>demoCache</value> 
 
 10</property> 
 
 11</bean>

接下来，写一个实现org.aopalliance.intercept.MethodInterceptor接口的拦截器类。有了拦截器就可以有选择性的配置想要缓存的 bean 方法。如果被调用的方法配置为可缓存，拦截器将为该方法生成 cache key 并检查该方法返回的结果是否已缓存。如果已缓存，就返回缓存的结果，否则再次执行被拦截的方法，并缓存结果供下次调用。具体代码如下：
public class MethodCacheInterceptor implements MethodInterceptor

view source
print?
 01public  class MethodCacheInterceptor implements MethodInterceptor, 
 
 02InitializingBean { 
 
 03private  Cache cache; 
 
 04  
 
 05public  void setCache(Cache cache) { 
 
 06  this.cache = cache; 
 
 07} 
 
 08  
 
 09public  void afterPropertiesSet() throws Exception { 
 
 10Assert.notNull(cache, 
 
 11"A cache is required. Use setCache(Cache) to provide one."); 
 
 12} 
 
 13  
 
 14public  Object invoke(MethodInvocation invocation) throws Throwable { 
 
 15 String targetName = invocation.getThis().getClass().getName(); 
 
 16 String methodName = invocation.getMethod().getName(); 
 
 17 Object[] arguments = invocation.getArguments(); 
 
 18 Object result; 
 
 19 String cacheKey = getCacheKey(targetName, methodName, arguments); 
 
 20 Element element = null; 
 
 21synchronized  (this){  
 
 22 element = cache.get(cacheKey); 
 
 23 if (element == null) { 
 
 24 //调用实际的方法 
 
 25  result = invocation.proceed(); 
 
 26  element = new Element(cacheKey, (Serializable) result); 
 
 27  cache.put(element); 
 
 28  }  
 
 29 }  
 
 30 return element.getValue(); 
 
 31} 
 
 32  
 
 33private  String getCacheKey(String targetName, String methodName, 
 
 34Object[] arguments) { 
 
 35  StringBuffer sb = new StringBuffer(); 
 
 36  sb.append(targetName).append(".").append(methodName); 
 
 37  if ((arguments != null) && (arguments.length != 0)) { 
 
 38  for (int  i = 0; i < arguments.length; i++) { 
 
 39  sb.append(".").append(arguments[i]); 
 
 40  }  
 
 41 }  
 
 42 return sb.toString(); 
 
 43 }  
 
 44}

synchronized (this)这段代码实现了同步功能。为什么一定要同步？Cache对象本身的get和put操作是同步的。如果我们缓存的数据来自数据库查询，在没有这段同步代码时，当key不存在或者key对应的对象已经过期时，在多线程并发访问的情况下，许多线程都会重新执行该方法，由于对数据库进行重新查询代价是比较昂贵的，而在瞬间大量的并发查询，会对数据库服务器造成非常大的压力。所以这里的同步代码是很重要的。

接下来，继续完成拦截器和Bean的配置：

view source
print?
 01<bean id="methodCacheInterceptor" class="com.xiebing.utils.interceptor.MethodCacheInterceptor"> 
 
 02<property name="cache"> 
 
 03<ref local="demoCache" /> 
 
 04</property> 
 
 05</bean> 
 
 06<bean id="methodCachePointCut" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor"> 
 
 07<property name="advice"> 
 
 08<ref local="methodCacheInterceptor" /> 
 
 09</property> 
 
 10<property name="patterns"> 
 
 11<list> 
 
 12<value>.*myMethod</value> 
 
 13</list> 
 
 14</property> 
 
 15</bean> 
 
 16  
 
 17<bean id="myServiceBean"
 
 18class="com.xiebing.ehcache.spring.MyServiceBean"> 
 
 19</bean> 
 
 20<bean id="myService" class="org.springframework.aop.framework.ProxyFactoryBean"> 
 
 21<property name="target"> 
 
 22<ref local="myServiceBean" /> 
 
 23</property> 
 
 24<property name="interceptorNames"> 
 
 25<list> 
 
 26<value>methodCachePointCut</value> 
 
 27</list> 
 
 28</property> 
 
 29</bean>

其中myServiceBean是实现了业务逻辑的Bean，里面的方法myMethod()的返回结果需要被缓存。这样每次对myServiceBean的myMethod()方法进行调用,都会首先从缓存中查找,其次才会查询数据库。使用AOP的方式极大地提高了系统的灵活性，通过修改配置文件就可以实现对方法结果的缓存，所有的对Cache的操作都封装在了拦截器的实现中。

3.CachingFilter功能

使用Spring的AOP进行整合，可以灵活的对方法的的返回结果对象进行缓存。CachingFilter功能可以对HTTP响应的内容进行缓存。这种方式缓存数据的粒度比较粗，例如缓存整张页面。它的优点是使用简单、效率高，缺点是不够灵活，可重用程度不高。
EHCache使用SimplePageCachingFilter类实现Filter缓存。该类继承自CachingFilter，有默认产生cache key的calculateKey()方法，该方法使用HTTP请求的URI和查询条件来组成key。也可以自己实现一个Filter，同样继承CachingFilter类,然后覆写calculateKey()方法，生成自定义的key。
在笔者参与的项目中很多页面都使用AJAX，为保证JS请求的数据不被浏览器缓存，每次请求都会带有一个随机数参数i。如果使用SimplePageCachingFilter，那么每次生成的key都不一样，缓存就没有意义了。这种情况下，我们就会覆写calculateKey()方法。

要使用SimplePageCachingFilter，首先在配置文件ehcache.xml中，增加下面的配置：
<cache name="SimplePageCachingFilter" maxElementsInMemory="10000" eternal="false"
overflowToDisk="false" timeToIdleSeconds="300" timeToLiveSeconds="600"
memoryStoreEvictionPolicy="LFU" />
其中name属性必须为SimplePageCachingFilter，修改web.xml文件，增加一个Filter的配置：

view source
print?
 1<filter> 
 
 2<filter-name>SimplePageCachingFilter</filter-name> 
 
 3<filter-class>net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter</filter-class> 
 
 4</filter> 
 
 5<filter-mapping> 
 
 6<filter-name>SimplePageCachingFilter</filter-name> 
 
 7<url-pattern>/test.jsp</url-pattern> 
 
 8</filter-mapping>

下面我们写一个简单的test.jsp文件进行测试，缓存后的页面每次刷新，在600秒内显示的时间都不会发生变化的。代码如下：
<%
out.println(new Date());
%>

CachingFilter输出的数据会根据浏览器发送的Accept-Encoding头信息进行Gzip压缩。经过笔者测试，Gzip压缩后的数据量是原来的1/4，速度是原来的4-5倍，所以缓存加上压缩，效果非常明显。
在使用Gzip压缩时，需注意两个问题：
1. Filter在进行Gzip压缩时，采用系统默认编码，对于使用GBK编码的中文网页来说，需要将操作系统的语言设置为：zh_CN.GBK，否则会出现乱码的问题。
2.默认情况下CachingFilter会根据浏览器发送的请求头部所包含的Accept-Encoding参数值来判断是否进行Gzip压缩。虽然IE6/7浏览器是支持Gzip压缩的，但是在发送请求的时候却不带该参数。为了对IE6/7也能进行Gzip压缩，可以通过继承CachingFilter，实现自己的Filter，然后在具体的实现中覆写方法acceptsGzipEncoding。

具体实现参考：
protected boolean acceptsGzipEncoding(HttpServletRequest request) {
final boolean ie6 = headerContains(request, "User-Agent", "MSIE 6.0");
final boolean ie7 = headerContains(request, "User-Agent", "MSIE 7.0");
return acceptsEncoding(request, "gzip") || ie6 || ie7;
}

4. EHCache在Hibernate中的使用

EHCache可以作为Hibernate的二级缓存使用。在hibernate.cfg.xml中需增加如下设置：
<prop key="hibernate.cache.provider_class">
org.hibernate.cache.EhCacheProvider
</prop>
然后在Hibernate映射文件的每个需要Cache的Domain中，加入类似如下格式信息：
<cache usage="read-write|nonstrict-read-write|read-only" />
比如：
<cache usage="read-write" />
最后在配置文件ehcache.xml中增加一段cache的配置，其中name为该domain的类名。
<cache name="domain.class.name"
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
overflowToDisk="false"
/>

 EHCache的监控
对于Cache的使用，除了功能，在实际的系统运营过程中，我们会比较关注每个Cache对象占用的内存大小和Cache的命中率。有了这些数据，我们就可以对Cache的配置参数和系统的配置参数进行优化，使系统的性能达到最优。EHCache提供了方便的API供我们调用以获取监控数据，其中主要的方法有：

//得到缓存中的对象数
cache.getSize();
//得到缓存对象占用内存的大小
cache.getMemoryStoreSize();
//得到缓存读取的命中次数
cache.getStatistics().getCacheHits()
//得到缓存读取的错失次数
cache.getStatistics().getCacheMisses()

 分布式缓存
EHCache从1.2版本开始支持分布式缓存。分布式缓存主要解决集群环境中不同的服务器间的数据的同步问题。具体的配置如下：

在配置文件ehcache.xml中加入
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.1, multicastGroupPort=4446"/>

另外，需要在每个cache属性中加入
<cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/>
例如：
<cache name="demoCache"
maxElementsInMemory="10000"
eternal="true"
overflowToDisk="true">
<cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/>
</cache>

总结
EHCache是一个非常优秀的基于Java的Cache实现。它简单、易用，而且功能齐全，并且非常容易与Spring、Hibernate等流行的开源框架进行整合。通过使用EHCache可以减少网站项目中数据库服务器的访问压力，提高网站的访问速度，改善用户的体验。

ecache的分别是配置：http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/

EhCache 缓存系统简介

EhCache 是一个纯 Java 的进程内缓存框架，具有快速、精干等特点，是 Hibernate 中默认的 CacheProvider。

下图是 EhCache 在应用程序中的位置：

图 1. EhCache 应用架构图

EhCache 的主要特性有：

快速；
简单；
多种缓存策略；
缓存数据有两级：内存和磁盘，因此无需担心容量问题；
缓存数据会在虚拟机重启的过程中写入磁盘；
可以通过 RMI、可插入 API 等方式进行分布式缓存；
具有缓存和缓存管理器的侦听接口；
支持多缓存管理器实例，以及一个实例的多个缓存区域；
提供 Hibernate 的缓存实现；
等等 …

由于 EhCache 是进程中的缓存系统，一旦将应用部署在集群环境中，每一个节点维护各自的缓存数据，当某个节点对缓存数据进行更新，这些更新的数据无法在其它节点中共享，这不仅会降低节点运行的效率，而且会导致数据不同步的情况发生。例如某个网站采用 A、B 两个节点作为集群部署，当 A 节点的缓存更新后，而 B 节点缓存尚未更新就可能出现用户在浏览页面的时候，一会是更新后的数据，一会是尚未更新的数据，尽管我们也可以通过 Session Sticky 技术来将用户锁定在某个节点上，但对于一些交互性比较强或者是非 Web 方式的系统来说，Session Sticky 显然不太适合。所以就需要用到 EhCache 的集群解决方案。

EhCache 从 1.7 版本开始，支持五种集群方案，分别是：

Terracotta
RMI
JMS
JGroups
EhCache Server

本文主要介绍其中的三种最为常用集群方式，分别是 RMI、JGroups 以及 EhCache Server 。

回页首

RMI 集群模式

RMI 是 Java 的一种远程方法调用技术，是一种点对点的基于 Java 对象的通讯方式。EhCache 从 1.2 版本开始就支持 RMI 方式的缓存集群。在集群环境中 EhCache 所有缓存对象的键和值都必须是可序列化的，也就是必须实现 java.io.Serializable 接口，这点在其它集群方式下也是需要遵守的。

下图是 RMI 集群模式的结构图：

图 2. RMI 集群模式结构图

采用 RMI 集群模式时，集群中的每个节点都是对等关系，并不存在主节点或者从节点的概念，因此节点间必须有一个机制能够互相认识对方，必须知道其它节点的信息，包括主机地址、端口号等。EhCache 提供两种节点的发现方式：手工配置和自动发现。手工配置方式要求在每个节点中配置其它所有节点的连接信息，一旦集群中的节点发生变化时，需要对缓存进行重新配置。

由于 RMI 是 Java 中内置支持的技术，因此使用 RMI 集群模式时，无需引入其它的 Jar 包，EhCache 本身就带有支持 RMI 集群的功能。使用 RMI 集群模式需要在 ehcache.xml 配置文件中定义 cacheManagerPeerProviderFactory 节点。假设集群中有两个节点，分别对应的 RMI 绑定信息是：

节点 1	192.168.0.11	4567	/oschina_cache
节点 2	192.168.0.12	4567	/oschina_cache
节点 3	192.168.0.13	4567	/oschina_cache

那么对应的手工配置信息如下：

<cacheManagerPeerProviderFactory 
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" 
properties="hostName=localhost,
port=4567,
socketTimeoutMillis=2000,
peerDiscovery=manual,
rmiUrls=//192.168.0.12:4567/oschina_cache|//192.168.0.13:4567/oschina_cache"
/>

其它节点配置类似，只需把 rmiUrls 中的两个 IP 地址换成另外两个节点对应的 IP 地址即可。

接下来在需要进行缓存数据复制的区域（Region）上配置如下即可：

<cache name="sampleCache2"
maxElementsInMemory="10"
eternal="false"
timeToIdleSeconds="100"
timeToLiveSeconds="100"
overflowToDisk="false">
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicateAsynchronously=true, 
replicatePuts=true, 
replicateUpdates=true,
replicateUpdatesViaCopy=false, 
replicateRemovals=true "/>
</cache>

具体每个参数代表的意义请参考 EhCache 的手册，此处不再详细说明。

EhCache 的 RMI 集群模式还有另外一种节点发现方式，就是通过多播（ multicast ）来维护集群中的所有有效节点。这也是最为简单而且灵活的方式，与手工模式不同的是，每个节点上的配置信息都相同，大大方便了节点的部署，避免人为的错漏出现。

在上述三个节点的例子中，配置如下：

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.1,
multicastGroupPort=4446, timeToLive=32"
/>

其中需要指定节点发现模式 peerDiscovery 值为 automatic 自动；同时组播地址可以指定 D 类 IP 地址空间，范围从 224.0.1.0 到 238.255.255.255 中的任何一个地址。

回页首

JGroups 集群模式

EhCache 从 1.5. 版本开始增加了 JGroups 的分布式集群模式。与 RMI 方式相比较， JGroups 提供了一个非常灵活的协议栈、可靠的单播和多播消息传输，主要的缺点是配置复杂以及一些协议栈对第三方包的依赖。

JGroups 也提供了基于 TCP 的单播 ( Unicast ) 和基于 UDP 的多播 ( Multicast ) ，对应 RMI 的手工配置和自动发现。使用单播方式需要指定其它节点的主机地址和端口，下面是两个节点，并使用了单播方式的配置：

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
properties="connect=TCP(start_port=7800):
TCPPING(initial_hosts=host1[7800],host2[7800];port_range=10;timeout=3000;
num_initial_members=3;up_thread=true;down_thread=true):
VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;
retransmit_timeout=3000):
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;
print_local_addr=false;down_thread=true;up_thread=true)"
propertySeparator="::" />

使用多播方式配置如下：

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
properties="connect=UDP(mcast_addr=231.12.21.132;mcast_port=45566;):PING:
MERGE2:FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK:UNICAST:pbcast.STABLE:FRAG:pbcast.GMS"
propertySeparator="::"
/>

从上面的配置来看，JGroups 的配置要比 RMI 复杂得多，但也提供更多的微调参数，有助于提升缓存数据复制的性能。详细的 JGroups 配置参数的具体意义可参考 JGroups 的配置手册。

JGroups 方式对应缓存节点的配置信息如下：

<cache name="sampleCache2"
maxElementsInMemory="10"
eternal="false"
timeToIdleSeconds="100"
timeToLiveSeconds="100"
overflowToDisk="false">
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheReplicatorFactory"
properties="replicateAsynchronously=true, replicatePuts=true,
replicateUpdates=true, replicateUpdatesViaCopy=false, replicateRemovals=true" />
</cache>

使用组播方式的注意事项

使用 JGroups 需要引入 JGroups 的 Jar 包以及 EhCache 对 JGroups 的封装包 ehcache-jgroupsreplication-xxx.jar 。

在一些启用了 IPv6 的电脑中，经常启动的时候报如下错误信息：

java.lang.RuntimeException: the type of the stack (IPv6) and the user supplied addresses (IPv4) don't match: /231.12.21.132.

解决的办法是增加 JVM 参数：-Djava.net.preferIPv4Stack=true。如果是 Tomcat 服务器，可在 catalina.bat 或者 catalina.sh 中增加如下环境变量即可：

 SET CATALINA_OPTS=-Djava.net.preferIPv4Stack=true

经过实际测试发现，集群方式下的缓存数据都可以在 1 秒钟之内完成到其节点的复制。

回页首

EhCache Server

与前面介绍的两种集群方案不同的是， EhCache Server 是一个独立的缓存服务器，其内部使用 EhCache 做为缓存系统，可利用前面提到的两种方式进行内部集群。对外提供编程语言无关的基于 HTTP 的 RESTful 或者是 SOAP 的数据缓存操作接口。

下面是 EhCache Server 提供的对缓存数据进行操作的方法：

OPTIONS /{cache}}

获取某个缓存的可用操作的信息。

HEAD /{cache}/{element}

获取缓存中某个元素的 HTTP 头信息，例如：

curl --head  http://localhost:8080/ehcache/rest/sampleCache2/2

EhCache Server 返回的信息如下：

HTTP/1.1 200 OK 
X-Powered-By: Servlet/2.5 
Server: GlassFish/v3 
Last-Modified: Sun, 27 Jul 2008 08:08:49 GMT 
ETag: "1217146129490"
Content-Type: text/plain; charset=iso-8859-1 
Content-Length: 157 
Date: Sun, 27 Jul 2008 08:17:09 GMT

GET /{cache}/{element}

读取缓存中某个数据的值。

PUT /{cache}/{element}

写缓存。

由于这些操作都是基于 HTTP 协议的，因此你可以在任何一种编程语言中使用它，例如 Perl、PHP 和 Ruby 等等。

下图是 EhCache Server 在应用中的架构：

图 3. EhCache Server 应用架构图

EhCache Server 同时也提供强大的安全机制、监控功能。在数据存储方面，最大的 Ehcache 单实例在内存中可以缓存 20GB。最大的磁盘可以缓存 100GB。通过将节点整合在一起，这样缓存数据就可以跨越节点，以此获得更大的容量。将缓存 20GB 的 50 个节点整合在一起就是 1TB 了。

回页首

总结

以上我们介绍了三种 EhCache 的集群方案，除了第三种跨编程语言的方案外，EhCache 的集群对应用程序的代码编写都是透明的，程序人员无需考虑缓存数据是如何复制到其它节点上。既保持了代码的轻量级，同时又支持庞大的数据集群。EhCache 可谓是深入人心。

2009 年年中，Terracotta 宣布收购 EhCache 产品。Terracotta 公司的产品 Terracotta 是一个 JVM 级的开源群集框架，提供 HTTP Session 复制、分布式缓存、POJO 群集、跨越集群的 JVM 来实现分布式应用程序协调。最近 EhCache 主要的改进都集中在跟 Terracotta 框架的集成上，这是一个真正意义上的企业级缓存解决方案。

参考资料

学习