集群环境中使用_EhCache_缓存系统&Ehcache配置文件的详细说明 博客分类： Ehcache 配置管理CacheHibernate框架多线程
程序员文章站
2024-03-07 11:51:27
...
简介： EhCache 是一个纯 Java 的进程内缓存框架，具有快速、精干等特点，是 Hibernate 中默认的 CacheProvider。本文充分的介绍了 EhCache 缓存系统对集群环境的支持以及使用方法。
EhCache 缓存系统简介
EhCache 是一个纯 Java 的进程内缓存框架，具有快速、精干等特点，是 Hibernate 中默认的 CacheProvider。
EhCache 的主要特性有：
1 快速；
2 简单；
3 多种缓存策略；
4 缓存数据有两级：内存和磁盘，因此无需担心容量问题；
5 缓存数据会在虚拟机重启的过程中写入磁盘；
6 可以通过 RMI、可插入 API 等方式进行分布式缓存；
7 具有缓存和缓存管理器的侦听接口；
8 支持多缓存管理器实例，以及一个实例的多个缓存区域；
9 提供 Hibernate 的缓存实现；
10 等等 …
由于 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 集群模式时，集群中的每个节点都是对等关系，并不存在主节点或者从节点的概念，因此节点间必须有一个机制能够互相认识对方，必须知道其它节点的信息，包括主机地址、端口号等。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
那么对应的手工配置信息如下：
其它节点配置类似，只需把 rmiUrls 中的两个 IP 地址换成另外两个节点对应的 IP 地址即可。
接下来在需要进行缓存数据复制的区域（Region）上配置如下即可：
具体每个参数代表的意义请参考 EhCache 的手册，此处不再详细说明。
EhCache 的 RMI 集群模式还有另外一种节点发现方式，就是通过多播（ multicast ）来维护集群中的所有有效节点。这也是最为简单而且灵活的方式，与手工模式不同的是，每个节点上的配置信息都相同，大大方便了节点的部署，避免人为的错漏出现。
在上述三个节点的例子中，配置如下：
其中需要指定节点发现模式 peerDiscovery 值为 automatic 自动；同时组播地址可以指定 D 类 IP 地址空间，范围从 224.0.1.0 到 238.255.255.255 中的任何一个地址。
更详细的资料请参考附件中的“集群环境中使用_EhCache_缓存系统.rar”
http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/
Ehcache配置文件的详细说明
<cache name="CACHE_FUNC" maxElementsInMemory="2" eternal="false" timeToIdleSeconds="10" timeToLiveSeconds="20" overflowToDisk="true" diskPersistent="true" diskExpiryThreadIntervalSeconds="120" />
maxElementsInMemory ：cache 中最多可以存放的元素的数量。如果放入cache中的元素超过这个数值，有两种情况：1、若overflowToDisk的属性值为true，会将cache中多出的元素放入磁盘文件中。2、若overflowToDisk的属性值为false，会根据memoryStoreEvictionPolicy的策略替换cache中原有的元素。
eternal ：意思是是否永驻内存。如果值是true，cache中的元素将一直保存在内存中，不会因为时间超时而丢失，所以在这个值为true的时候，timeToIdleSeconds和timeToLiveSeconds两个属性的值就不起作用了。
timeToIdleSeconds ：就是访问这个cache中元素的最大间隔时间。如果超过这个时间没有访问这个cache中的某个元素，那么这个元素将被从cache中清除。
timeToLiveSeconds : 这是cache中元素的生存时间。意思是从cache中的某个元素从创建到消亡的时间，从创建开始计时，当超过这个时间，这个元素将被从cache中清除。
overflowToDisk ：溢出是否写入磁盘。系统会根据标签<diskStore path="java.io.tmpdir"/> 中path的值查找对应的属性值，如果系统的java.io.tmpdir的值是 D:\temp，写入磁盘的文件就会放在这个文件夹下。文件的名称是cache的名称，后缀名的data。如：CACHE_FUNC.data。这个属性在解释maxElementsInMemory的时候也已经说过了。
diskExpiryThreadIntervalSeconds ：磁盘缓存的清理线程运行间隔
memoryStoreEvictionPolicy ：内存存储与释放策略。有三个值：
LRU －least recently used
LFU －least frequently used
FIFO－first in first out, the oldest element by creation time
diskPersistent ： 是否持久化磁盘缓存。当这个属性的值为true时，系统在初始化的时候会在磁盘中查找文件名为cache名称，后缀名为index的的文件，如CACHE_FUNC.index 。这个文件中存放了已经持久化在磁盘中的cache的index，找到后把cache加载到内存。要想把cache真正持久化到磁盘，写程序时必须注意，在是用net.sf.ehcache.Cache的void put (Element element)方法后要使用void flush()方法。
以上时间值都是以秒作为单位的。
EhCache 缓存系统简介
EhCache 是一个纯 Java 的进程内缓存框架，具有快速、精干等特点，是 Hibernate 中默认的 CacheProvider。
EhCache 的主要特性有：
1 快速；
2 简单；
3 多种缓存策略；
4 缓存数据有两级：内存和磁盘，因此无需担心容量问题；
5 缓存数据会在虚拟机重启的过程中写入磁盘；
6 可以通过 RMI、可插入 API 等方式进行分布式缓存；
7 具有缓存和缓存管理器的侦听接口；
8 支持多缓存管理器实例，以及一个实例的多个缓存区域；
9 提供 Hibernate 的缓存实现；
10 等等 …
由于 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 集群模式时，集群中的每个节点都是对等关系，并不存在主节点或者从节点的概念，因此节点间必须有一个机制能够互相认识对方，必须知道其它节点的信息，包括主机地址、端口号等。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 中的任何一个地址。
更详细的资料请参考附件中的“集群环境中使用_EhCache_缓存系统.rar”
http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/
Ehcache配置文件的详细说明
<cache name="CACHE_FUNC" maxElementsInMemory="2" eternal="false" timeToIdleSeconds="10" timeToLiveSeconds="20" overflowToDisk="true" diskPersistent="true" diskExpiryThreadIntervalSeconds="120" />
maxElementsInMemory ：cache 中最多可以存放的元素的数量。如果放入cache中的元素超过这个数值，有两种情况：1、若overflowToDisk的属性值为true，会将cache中多出的元素放入磁盘文件中。2、若overflowToDisk的属性值为false，会根据memoryStoreEvictionPolicy的策略替换cache中原有的元素。
eternal ：意思是是否永驻内存。如果值是true，cache中的元素将一直保存在内存中，不会因为时间超时而丢失，所以在这个值为true的时候，timeToIdleSeconds和timeToLiveSeconds两个属性的值就不起作用了。
timeToIdleSeconds ：就是访问这个cache中元素的最大间隔时间。如果超过这个时间没有访问这个cache中的某个元素，那么这个元素将被从cache中清除。
timeToLiveSeconds : 这是cache中元素的生存时间。意思是从cache中的某个元素从创建到消亡的时间，从创建开始计时，当超过这个时间，这个元素将被从cache中清除。
overflowToDisk ：溢出是否写入磁盘。系统会根据标签<diskStore path="java.io.tmpdir"/> 中path的值查找对应的属性值，如果系统的java.io.tmpdir的值是 D:\temp，写入磁盘的文件就会放在这个文件夹下。文件的名称是cache的名称，后缀名的data。如：CACHE_FUNC.data。这个属性在解释maxElementsInMemory的时候也已经说过了。
diskExpiryThreadIntervalSeconds ：磁盘缓存的清理线程运行间隔
memoryStoreEvictionPolicy ：内存存储与释放策略。有三个值：
LRU －least recently used
LFU －least frequently used
FIFO－first in first out, the oldest element by creation time
diskPersistent ： 是否持久化磁盘缓存。当这个属性的值为true时，系统在初始化的时候会在磁盘中查找文件名为cache名称，后缀名为index的的文件，如CACHE_FUNC.index 。这个文件中存放了已经持久化在磁盘中的cache的index，找到后把cache加载到内存。要想把cache真正持久化到磁盘，写程序时必须注意，在是用net.sf.ehcache.Cache的void put (Element element)方法后要使用void flush()方法。
以上时间值都是以秒作为单位的。