两个最著名的开源java 缓存解决方案的厂商现在由于 Terracotta 对 Ehcache 的收购联合到一起了。Terracotta，目前唯一的提供JVM级别的“POJO clustering集群”的厂商，能够提供多线程单一JVM应用，并且能让它们跨JVMs运行而不需要修改任何代码。Ehcache是目前部署使用最广泛的缓存应用，它提供了标准的HashMap类型接口，类似Oracle Coherence。这个合并对Java缓存领域将产生深远的影响。
[img]http://dl.iteye.com/upload/attachment/212200/00d84a93-287d-3ef6-9286-c4797cca46bf.png[/img]
http://ehcache.org/documentation/architecture.html
[b]一. 几种成熟的缓存解决方案[/b]
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 是一个强大的、可复制（同步或异步）和支持事务的缓存。如果你需要一个真正的支持事务的缓存架构，使用这个方案吧
[b]二. EHCache的使用场合[/b]
1：比较少更新表数据
EhCache一般要使用在比较少执行write操作的表(包括update,insert,delete)[Hibernate的二级缓存也都是这样]；
2：对并发要求不是很严格的情况
两台机子中的缓存是不能实时同步的；
[b]三. Ehcache的类层次模型[/b]
主要为三层，最上层的是CacheManager，他是操作Ehcache的入口。我们可以通过CacheManager.getInstance()获得一个单子的CacheManger，或者通过CacheManger的构造函数创建 一个新的CacheManger。每个CacheManager都管理着多个Cache。而每个Cache都以一种类Hash的方式，关联着多个Element。Element则是我们用于存放要缓存内容的地方。
[img]http://dl.iteye.com/upload/attachment/212189/c22e0a13-a878-3a4c-941f-fd3c8f29dc55.jpg[/img]
[img]http://dl.iteye.com/upload/attachment/212204/ec0ec219-80cf-39f3-ab10-95c375a0315c.png[/img]
[b]四. Ehcache的jar包与配置文件[/b]
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下 。
[b]五. 配置文件ehcach.xml[/b]
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
[img]http://dl.iteye.com/upload/attachment/212216/63f9e1c5-1f16-3a8a-b1d4-6b35d76025cb.png[/img]
3：Ehcache的三种清空策略
3.1:FIFO(first in first out) :
这个是大家最熟的，先进先出。
3.2:LFU（ Less Frequently Used）：
就是上面例子中使用的策略，也是默认策略，直白一点就是讲一直以来最少被使用的。如上面所讲，缓存的元素有一个hit属性，hit值最小的将会被清出缓存。
3.3:LRU（Least Recently Used） ：
最近最少使用的，缓存的元素有一个时间戳，当缓存容量满了，而又需要腾出地方来缓存新的元素的时候，那么现有缓存元素中时间戳离当前时间最远的元素将被清出缓存。
[b]六. 首页的页面缓存[/b]
一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存
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中：
SimplePageCachingFilter 是缓存的名字
4.2：web.xml中：
七. 对gzip的支持
cachefilter中还有一个特性，就是gzip，也就是说缓存中的元素是被压缩过的，如果客户浏览器支持压缩的话，filter会直接返回压缩过的流，这样节省了带宽，把解压的工作交给了客户浏览器，如果客户的浏览器不支持gzip，那么filter会把缓存的元素拿出来解压后再返回给客户浏览器（大多数爬虫是不支持gzip的，所以filter也会解压后再返回流），这样做的优点是节省带宽，缺点就是增加了客户浏览器的负担。
补充：
如果一个应用中80% 的时间内都在访问20% 的数据，那么，这时候就应该使用缓存了(这个和长尾理论正好相悖)。
但即使是这样，缓存也有不同的用法，
举个例子：
1：一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存。
2：某个页面上，某个区域的record 访问频繁，那么我们就可以考虑给这个record 做二级缓存，因为二级缓存中是按照对象的id 来保存的，所以应该来说这几个区域使用的对象会一直存在于缓存之中（参见hibernate 的二级缓存）。
由此可见不同的页面的缓存策略有可能有天壤之别。
[img]http://dl.iteye.com/upload/attachment/212200/00d84a93-287d-3ef6-9286-c4797cca46bf.png[/img]
http://ehcache.org/documentation/architecture.html
[b]一. 几种成熟的缓存解决方案[/b]
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 是一个强大的、可复制（同步或异步）和支持事务的缓存。如果你需要一个真正的支持事务的缓存架构，使用这个方案吧
[b]二. EHCache的使用场合[/b]
1：比较少更新表数据
EhCache一般要使用在比较少执行write操作的表(包括update,insert,delete)[Hibernate的二级缓存也都是这样]；
2：对并发要求不是很严格的情况
两台机子中的缓存是不能实时同步的；
[b]三. Ehcache的类层次模型[/b]
主要为三层，最上层的是CacheManager，他是操作Ehcache的入口。我们可以通过CacheManager.getInstance()获得一个单子的CacheManger，或者通过CacheManger的构造函数创建 一个新的CacheManger。每个CacheManager都管理着多个Cache。而每个Cache都以一种类Hash的方式，关联着多个Element。Element则是我们用于存放要缓存内容的地方。
[img]http://dl.iteye.com/upload/attachment/212189/c22e0a13-a878-3a4c-941f-fd3c8f29dc55.jpg[/img]
[img]http://dl.iteye.com/upload/attachment/212204/ec0ec219-80cf-39f3-ab10-95c375a0315c.png[/img]
[b]四. Ehcache的jar包与配置文件[/b]
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下 。
[b]五. 配置文件ehcach.xml[/b]
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
[img]http://dl.iteye.com/upload/attachment/212216/63f9e1c5-1f16-3a8a-b1d4-6b35d76025cb.png[/img]
3：Ehcache的三种清空策略
3.1:FIFO(first in first out) :
这个是大家最熟的，先进先出。
3.2:LFU（ Less Frequently Used）：
就是上面例子中使用的策略，也是默认策略，直白一点就是讲一直以来最少被使用的。如上面所讲，缓存的元素有一个hit属性，hit值最小的将会被清出缓存。
3.3:LRU（Least Recently Used） ：
最近最少使用的，缓存的元素有一个时间戳，当缓存容量满了，而又需要腾出地方来缓存新的元素的时候，那么现有缓存元素中时间戳离当前时间最远的元素将被清出缓存。
[b]六. 首页的页面缓存[/b]
一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存
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 的二级缓存）。
由此可见不同的页面的缓存策略有可能有天壤之别。
250
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
