`
m635674608
  • 浏览: 5091525 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论

缓存-ehcache 集群缓存的同步

 
阅读更多

EhCache 分布式缓存/缓存集群

开发环境:

System:Windows

JavaEE Server:tomcat5.0.2.8、tomcat6

JavaSDK: jdk6+

IDE:eclipse、MyEclipse 6.6

 

开发依赖库:

JDK6、 JavaEE5、ehcache-core-2.5.2.jar

Email:hoojo_@126.com

Blog:http://blog.csdn.net/IBM_hoojo

http://hoojo.cnblogs.com/

http://hoojo.blogjava.net

 

前面2篇文章介绍到Ehcache 整合spring 使用页面、对象缓存http://www.cnblogs.com/hoojo/archive/2012/07/12/2587556.html 

在Spring、hibernate中使用Ehcache缓存 http://www.cnblogs.com/hoojo/archive/2012/07/12/2587941.html

 

一、缓存系统简介

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

EhCache 应用架构图,下图是 EhCache 在应用程序中的位置:

clip_image002

EhCache 的主要特性有:

1. 快速、精干;

2. 简单;

3. 多种缓存策略;

4. 缓存数据有两级:内存和磁盘,因此无需担心容量问题;

5. 缓存数据会在虚拟机重启的过程中写入磁盘;

6. 可以通过 RMI、可插入 API 等方式进行分布式缓存;

7. 具有缓存和缓存管理器的侦听接口;

8. 支持多缓存管理器实例,以及一个实例的多个缓存区域;

9. 提供 Hibernate 的缓存实现;

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

所以就需要用到 EhCache 的集群解决方案。

从1.2版本开始,Ehcache可以使用分布式的缓存了。EhCache 从 1.7 版本开始,支持五种集群方案,分别是:

• Terracotta

• RMI

• JMS

• JGroups

• EhCache Server

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

分布式这个特性是以plugin的方式实现的。Ehcache自带了一些默认的分布式缓存插件实现,这些插件可以满足大部分应用的需要。如果需要使用其他的插件那就需要自己开发了,开发者可以通过查看distribution包里的源代码及JavaDoc来实现它。尽管不是必须的,在使用分布式缓存时理解一些ehcahce的设计思想也是有帮助的。这可以参看分布式缓存设计的页面。以下的部分将展示如何让分布式插件同ehcache一起工作。

下面列出的是一些分布式缓存中比较重要的方面:

• 你如何知道集群环境中的其他缓存?

• 分布式传送的消息是什么形式?

• 什么情况需要进行复制?增加(Puts),更新(Updates)或是失效(Expiries)?

• 采用什么方式进行复制?同步还是异步方式?

为了安装分布式缓存,你需要配置一个PeerProvider、一个CacheManagerPeerListener,

它们对于一个CacheManager来说是全局的。每个进行分布式操作的cache都要添加一个cacheEventListener来传送消息。

 

二、集群缓存概念及其配置

正确的元素类型

只有可序列化的元素可以进行复制。一些操作,比如移除,只需要元素的键值而不用整个元素;在这样的操作中即使元素不是可序列化的但键值是可序列化的也可以被复制。

成员发现(Peer Discovery)

Ehcache进行集群的时候有一个cache组的概念。每个cache都是其他cache的一个peer,没有主cache的存在。刚才我们问了一个问题:你如何知道集群环境中的其他缓存?这个问题可以命名为成员发现(Peer Discovery)。

Ehcache提供了两种机制用来进行成员发现,就像一辆汽车:手动档和自动档。要使用一个内置的成员发现机制要在ehcache的配置文件中指定cacheManagerPeerProviderFactory元素的class属性为

net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory。

自动的成员发现

自动的发现方式用TCP广播机制来确定和维持一个广播组。它只需要一个简单的配置可以自动的在组中添加和移除成员。在集群中也不需要什么优化服务器的知识,这是默认推荐的。

成员每秒向群组发送一个“心跳”。如果一个成员 5秒种都没有发出信号它将被群组移除。如果一个新的成员发送了一个“心跳”它将被添加进群组。

任何一个用这个配置安装了复制功能的cache都将被其他的成员发现并标识为可用状态。

要设置自动的成员发现,需要指定ehcache配置文件中cacheManagerPeerProviderFactory元素的properties属性,就像下面这样:
peerDiscovery=automatic

multicastGroupAddress=multicast address | multicast host name

multicastGroupPort=port

timeToLive=0-255 (timeToLive属性详见常见问题部分的描述)

示例

假设你在集群中有两台服务器。你希望同步sampleCache1和sampleCache2。每台独立的服务器都要有这样的配置:
配置server1和server2

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

手动进行成员发现

进行手动成员配置要知道每个监听器的IP地址和端口。成员不能在运行时动态地添加和移除。在技术上很难使用广播的情况下就可以手动成员发现,例如在集群的服务器之间有一个不能传送广播报文的路由器。你也可以用手动成员发现进行单向的数据复制,只让server2知道server1,而server1不知道server2。

配置手动成员发现,需要指定ehcache配置文件中cacheManagerPeerProviderFactory的properties属性,像下面这样:
peerDiscovery=manual rmiUrls=//server:port/cacheName, //server:port/cacheName ...
rmiUrls配置的是服务器cache peers的列表。注意不要重复配置。

示例

假设你在集群中有两台服务器。你要同步sampleCache1和sampleCache2。下面是每个服务器需要的配置:
配置server1

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=manual,
rmiUrls=//server2:40001/sampleCache11|//server2:40001/sampleCache12"/>

 

配置server2

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=manual,
rmiUrls=//server1:40001/sampleCache11|//server1:40001/sampleCache12"/>

配置CacheManagerPeerListener

每个CacheManagerPeerListener监听从成员们发向当前CacheManager的消息。配置CacheManagerPeerListener需要指定一个CacheManagerPeerListenerFactory,它以插件的机制实现,用来创建CacheManagerPeerListener。

cacheManagerPeerListenerFactory的属性有:
class – 一个完整的工厂类名。
properties – 只对这个工厂有意义的属性,使用逗号分隔。

Ehcache有一个内置的基于RMI的分布系统。它的监听器是RMICacheManagerPeerListener,这个监听器可以用

RMICacheManagerPeerListenerFactory来配置。

<cacheManagerPeerListenerFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
properties="hostName=localhost, port=40001,
socketTimeoutMillis=2000"/>

有效的属性是:
hostname (可选) – 运行监听器的服务器名称。标明了做为集群群组的成员的地址,同时也是你想要控制的从集群中接收消息的接口。

在CacheManager初始化的时候会检查hostname是否可用。

如果hostName不可用,CacheManager将拒绝启动并抛出一个连接被拒绝的异常。

如果指定,hostname将使用InetAddress.getLocalHost().getHostAddress()来得到。

警告:不要将localhost配置为本地地址127.0.0.1,因为它在网络中不可见将会导致不能从远程服务器接收信息从而不能复制。在同一台机器上有多个CacheManager的时候,你应该只用localhost来配置。

port – 监听器监听的端口。
socketTimeoutMillis (可选) – Socket超时的时间。默认是2000ms。当你socket同步缓存请求地址比较远,不是本地局域网。你可能需要把这个时间配置大些,不然很可能延时导致同步缓存失败。

配置CacheReplicators

每个要进行同步的cache都需要设置一个用来向CacheManagerr的成员复制消息的缓存事件监听器。这个工作要通过为每个cache的配置增加一个cacheEventListenerFactory元素来完成。

<!-- Sample cache named sampleCache2. -->
<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>

class – 使用net.sf.ehcache.distribution.RMICacheReplicatorFactory

这个工厂支持以下属性:
replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers. 默认是true。
replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制。默认是true。
replicateRemovals= true | false – 当元素移除的时候是否进行复制。默认是true。
replicateAsynchronously=true | false – 复制方式是异步的(指定为true时)还是同步的(指定为false时)。默认是true。
replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制指定为true时为复制,默认是true。
replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制(指定为true时为复制),默认是true。

你可以使用ehcache的默认行为从而减少配置的工作量,默认的行为是以异步的方式复制每件事;你可以像下面的例子一样减少RMICacheReplicatorFactory的属性配置:

<!-- Sample cache named sampleCache4. All missing RMICacheReplicatorFactory properties default to true -->
<cache name="sampleCache4"
maxElementsInMemory="10"
eternal="true"
overflowToDisk="false"
memoryStoreEvictionPolicy="LFU">
<cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/>
</cache>

 

常见的问题

Windows上的Tomcat

有一个Tomcat或者是JDK的bug,在tomcat启动时如果tomcat的安装路径中有空格的话,在启动时RMI监听器会失败。参见http://archives.java.sun.com/cgi-bin/wa?A2=ind0205&L=rmi-users&P=797和http://www.ontotext.com/kim/doc/sys-doc/faq-howto-bugs/known-bugs.html

由于在Windows上安装Tomcat默认是装在“Program Files”文件夹里的,所以这个问题经常发生。

广播阻断

自动的peer discovery与广播息息相关。广播可能被路由阻拦,像Xen和VMWare这种虚拟化的技术也可以阻拦广播。如果这些都打开了,你可能还在要将你的网卡的相关配置打开。一个简单的办法可以告诉广播是否有效,

那就是使用ehcache remote debugger来看“心跳”是否可用。

广播传播的不够远或是传得太远

你可以通过设置badly misnamed time to live来控制广播传播的距离。用广播IP协议时,timeToLive的值指的是数据包可以传递的域或是范围。约定如下:

0是限制在同一个服务器

1是限制在同一个子网

32是限制在同一个网站

64是限制在同一个region

128是限制在同一个大洲

255是不限制

译者按:上面这些资料翻译的不够准确,请读者自行寻找原文理解吧。

在Java实现中默认值是1,也就是在同一个子网中传播。改变timeToLive属性可以限制或是扩展传播的范围。

 

三、 RMI方式缓存集群/配置分布式缓存

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

 

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

      clip_image004

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

由于 RMI 是 Java 中内置支持的技术,因此使用 RMI 集群模式时,无需引入其它的 Jar 包,EhCache 本身就带有支持 RMI 集群的功能。使用 RMI 集群模式需要在 ehcache.xml 配置文件中定义 cacheManagerPeerProviderFactory 节点。

 

      分布式同步缓存要让这边的cache知道对方的cache,叫做Peer Discovery(成员发现) EHCache实现成员发现的方式有两种:

1、手动查找

A、 在ehcache.xml中配置PeerDiscovery成员发现对象

      Server1配置,配置本地hostName、port是400001,分别监听192.168.8.32:400002的mobileCache和192.168.5.231:400003 的mobileCache。注意这里的mobileCache是缓存的名称,分别对应着server2、server3的cache的配置。

<?xml version="1.0" encoding="gbk"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ehcache.xsd">
    <diskStore path="java.io.tmpdir"/>
 
    <!-- 
        集群多台服务器中的缓存,这里是要同步一些服务器的缓存
        server1 hostName:192.168.8.9 port:400001 cacheName:mobileCache
        server2 hostName:192.168.8.32 port:400002 cacheName:mobileCache
        server3 hostName:192.168.8.231 port:400003 cacheName:mobileCache
        注意:每台要同步缓存的服务器的RMI通信socket端口都不一样,在配置的时候注意设置
    -->
    
    <!-- server1 的cacheManagerPeerProviderFactory配置 -->
    <cacheManagerPeerProviderFactory 
        class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" 
        properties="hostName=localhost,
        port=400001,
        socketTimeoutMillis=2000,
        peerDiscovery=manual,
        rmiUrls=//192.168.8.32:400002/mobileCache|//192.168.5.231:400003/mobileCache"
    />
</ehcache>

以上注意cacheManagerPeerProviderFactory元素出现的位置在diskStore下

 

同样在你的另外2台服务器上增加配置

Server2,配置本地host,port为400002,分别同步192.168.8.9:400001的mobileCache和192.168.5.231:400003的mobileCache

<!-- server2 的cacheManagerPeerProviderFactory配置 -->
<cacheManagerPeerProviderFactory 
    class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" 
    properties="hostName=localhost,
    port=400002,
    socketTimeoutMillis=2000,
    peerDiscovery=manual,
    rmiUrls=//192.168.8.9:400001/mobileCache|//192.168.5.231:400003/mobileCache"
/>

Server3,配置本地host,port为400003,分别同步192.168.8.9:400001的mobileCache缓存和192.168.8.32:400002的mobileCache缓存

<!-- server3 的cacheManagerPeerProviderFactory配置 -->
<cacheManagerPeerProviderFactory 
    class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" 
    properties="hostName=localhost,
    port=400003,
    socketTimeoutMillis=2000,
    peerDiscovery=manual,
    rmiUrls=//192.168.8.9:400001/mobileCache|//192.168.8.32:400002/mobileCache"
/>

这样就在三台不同的服务器上配置了手动查找cache的PeerProvider成员发现的配置了。 值得注意的是你在配置rmiUrls的时候要特别注意url不能重复出现,并且端口、地址都是对的。

如果指定,hostname将使用InetAddress.getLocalHost().getHostAddress()来得到。

警告:不要将localhost配置为本地地址127.0.0.1,因为它在网络中不可见将会导致不能从远程服务器接收信息从而不能复制。在同一台机器上有多个CacheManager的时候,你应该只用localhost来配置。

 

B、 下面配置缓存和缓存同步监听,需要在每台服务器中的ehcache.xml文件中增加cache配置和cacheEventListenerFactory、cacheLoaderFactory的配置

<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="30" timeToLiveSeconds="30" overflowToDisk="false"/>
<!-- 
    配置自定义缓存
    maxElementsInMemory:缓存中允许创建的最大对象数
    eternal:缓存中对象是否为永久的,如果是,超时设置将被忽略,对象从不过期。
    timeToIdleSeconds:缓存数据空闲的最大时间,也就是说如果有一个缓存有多久没有被访问就会被销毁,如果该值是 0 就意味着元素可以停顿无穷长的时间。
    timeToLiveSeconds:缓存数据存活的时间,缓存对象最大的的存活时间,超过这个时间就会被销毁,这只能在元素不是永久驻留时有效,如果该值是0就意味着元素可以停顿无穷长的时间。
    overflowToDisk:内存不足时,是否启用磁盘缓存。
    memoryStoreEvictionPolicy:缓存满了之后的淘汰算法。

    每一个小时更新一次缓存(1小时过期) 
-->
<cache name="mobileCache"
    maxElementsInMemory="10000"
    eternal="false"
    overflowToDisk="true"
    timeToIdleSeconds="1800"
    timeToLiveSeconds="3600"
    memoryStoreEvictionPolicy="LFU">
    <!-- 
        RMI缓存分布同步查找 class使用net.sf.ehcache.distribution.RMICacheReplicatorFactory
        这个工厂支持以下属性:
        replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers。默认是true。
        replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制。默认是true。
        replicateRemovals= true | false – 当元素移除的时候是否进行复制。默认是true。
        replicateAsynchronously=true | false – 复制方式是异步的指定为true时,还是同步的,指定为false时。默认是true。
        replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制指定为true时为复制,默认是true。
        replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制指定为true时为复制,默认是true。
            asynchronousReplicationIntervalMillis=1000
        -->
    <!-- 监听RMI同步缓存对象配置 注册相应的的缓存监听类,用于处理缓存事件,如put,remove,update,和expire -->
    <cacheEventListenerFactory
        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
        properties="replicateAsynchronously=true, 
        replicatePuts=true, 
        replicateUpdates=true,
        replicateUpdatesViaCopy=false, 
        replicateRemovals=true "/>
    <!-- 用于在初始化缓存,以及自动设置 -->
    <bootstrapCacheLoaderFactory class="net.sf.ehcache.bootstrap.BootstrapCacheLoaderFactory"/>
</cache>

 

C、 这样就完成了3台服务器的配置,下面给出server1的完整的ehcache.xml的配置

<?xml version="1.0" encoding="gbk"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ehcache.xsd">
    <diskStore path="java.io.tmpdir"/>
 
    <!-- 
        集群多台服务器中的缓存,这里是要同步一些服务器的缓存
        server1 hostName:192.168.8.9 port:400001 cacheName:mobileCache
        server2 hostName:192.168.8.32 port:400002 cacheName:mobileCache
        server3 hostName:192.168.8.231 port:400003 cacheName:mobileCache
        注意每台要同步缓存的服务器的RMI通信socket端口都不一样,在配置的时候注意设置
    -->
    
    <!-- server1 的cacheManagerPeerProviderFactory配置 -->
    <cacheManagerPeerProviderFactory 
        class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" 
        properties="hostName=localhost,
        port=400001,
        socketTimeoutMillis=2000,
        peerDiscovery=manual,
        rmiUrls=//192.168.8.32:400002/mobileCache|//192.168.5.231:400003/mobileCache"
    />
    
    <defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="30" timeToLiveSeconds="30" overflowToDisk="false"/>
    <!-- 
        配置自定义缓存
        maxElementsInMemory:缓存中允许创建的最大对象数
        eternal:缓存中对象是否为永久的,如果是,超时设置将被忽略,对象从不过期。
        timeToIdleSeconds:缓存数据空闲的最大时间,也就是说如果有一个缓存有多久没有被访问就会被销毁,
                    如果该值是 0 就意味着元素可以停顿无穷长的时间。
        timeToLiveSeconds:缓存数据存活的时间,缓存对象最大的的存活时间,超过这个时间就会被销毁,
                    这只能在元素不是永久驻留时有效,如果该值是0就意味着元素可以停顿无穷长的时间。
        overflowToDisk:内存不足时,是否启用磁盘缓存。
        memoryStoreEvictionPolicy:缓存满了之后的淘汰算法。

        每一个小时更新一次缓存(1小时过期) 
    -->
    <cache name="mobileCache"
        maxElementsInMemory="10000"
        eternal="false"
        overflowToDisk="true"
        timeToIdleSeconds="1800"
        timeToLiveSeconds="3600"
        memoryStoreEvictionPolicy="LFU">
        <!-- 
            RMI缓存分布同步查找 class使用net.sf.ehcache.distribution.RMICacheReplicatorFactory
            这个工厂支持以下属性:
            replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers。默认是true。
            replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制。默认是true。
            replicateRemovals= true | false – 当元素移除的时候是否进行复制。默认是true。
            replicateAsynchronously=true | false – 复制方式是异步的指定为true时,还是同步的,指定为false时。默认是true。
            replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制指定为true时为复制,默认是true。
            replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制指定为true时为复制,默认是true。
                asynchronousReplicationIntervalMillis=1000
            -->
        <!-- 监听RMI同步缓存对象配置 注册相应的的缓存监听类,用于处理缓存事件,如put,remove,update,和expire -->
        <cacheEventListenerFactory
            class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
            properties="replicateAsynchronously=true, 
            replicatePuts=true, 
            replicateUpdates=true,
            replicateUpdatesViaCopy=false, 
            replicateRemovals=true "/>
        <!-- 用于在初始化缓存,以及自动设置 -->
        <bootstrapCacheLoaderFactory class="net.sf.ehcache.bootstrap.BootstrapCacheLoaderFactory"/>
    </cache>
</ehcache>

2、自动发现

自动发现配置和手动查找的方式有一点不同,其他的地方都基本是一样的。同样在ehcache.xml中增加配置,配置如下

<!--
搜索某个网段上的缓存
timeToLive
    0是限制在同一个服务器
    1是限制在同一个子网
    32是限制在同一个网站
    64是限制在同一个region
    128是限制在同一个大洲
    255是不限制
-->
<cacheManagerPeerProviderFactory
    class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
    properties="peerDiscovery=automatic, multicastGroupAddress=192.168.0.1,
    multicastGroupPort=400004, timeToLive=32"
/>

其他的配置和手动查找方式的配置是一样的,这里就不再赘述了。关于ehcache的其他缓存配置方式这里将不再介绍,大家可以自己去研究。可以参考:

官方文档:http://www.ehcache.org/documentation/user-guide/cache-topologies#using-a-cache-server

ibm developerworks文档:http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/index.html

 

http://blog.csdn.net/xcw931924821/article/details/52335696

分享到:
评论

相关推荐

    scratch少儿编程逻辑思维游戏源码-城堡战争.zip

    scratch少儿编程逻辑思维游戏源码-城堡战争.zip

    【Go语言编程】大厂Go工程师面试题集锦:涵盖并发、网络、数据库及算法设计要点

    内容概要:本文档汇集了来自字节跳动、腾讯、金山WPS、跟谁学和百度等大厂的Go工程师面试题,涵盖广泛的技术领域。主要包括Go语言特性(如goroutine调度、channel机制)、操作系统(进程间通信、线程调度)、计算机网络(TCP/IP协议栈、HTTP协议)、数据结构与算法(排序算法、LRU缓存)、数据库(MySQL索引优化、Redis内部机制)、分布式系统(负载均衡、服务发现)等方面的知识点。通过这些问题,不仅考察应聘者的理论基础,还测试其实际项目经验和技术深度。 适合人群:有一定Go语言编程经验和计算机基础知识的开发者,特别是准备应聘互联网大厂的中级及以上水平的后端工程师或全栈工程师。 使用场景及目标:①帮助求职者全面复习Go语言及其相关领域的核心概念;②为面试官提供有价值的参考题目,确保候选人具备解决复杂问题的能力;③指导工程师深入理解并掌握企业级应用开发所需的关键技能。 阅读建议:由于题目覆盖面广且难度较高,建议读者结合自身情况选择重点复习方向,同时配合实际编码练习加深理解。对于每个知识点,不仅要记住答案,更要理解背后的原理,这样才能在面试中灵活应对各种变体问题。

    scratch少儿编程逻辑思维游戏源码-堡垒之夜(吃鸡游戏).zip

    scratch少儿编程逻辑思维游戏源码-堡垒之夜(吃鸡游戏).zip

    少儿编程scratch项目源代码文件案例素材-派.zip

    少儿编程scratch项目源代码文件案例素材-派.zip

    scratch少儿编程逻辑思维游戏源码-Scratch 冒险.zip

    scratch少儿编程逻辑思维游戏源码-Scratch 冒险.zip

    2025 飞特舵机, Arduino版本

    2025 飞特舵机, Arduino版本

    scratch少儿编程逻辑思维游戏源码-躲避.zip

    scratch少儿编程逻辑思维游戏源码-躲避.zip

    PFC5.0纤维混凝土三点弯曲模拟:参数化建模与实验分析

    内容概要:本文详细介绍了利用PFC5.0进行纤维混凝土三点弯曲模拟的方法。首先,作者展示了如何通过定义纤维的体积含量、长度、半径和刚度等关键参数来构建纤维网络。接着,描述了三点弯曲加载的具体实现方式,包括加载速率控制和终止条件设定。最后,提供了后处理方法,如绘制并导出力-位移曲线图,以便于分析材料破坏机制。文中还给出了若干实用建议,如纤维半径的选择范围、加载速率的初始值以及不同类型纤维的接触模型选择。 适合人群:从事材料科学尤其是混凝土材料研究的专业人士,以及对离散元法和数值模拟感兴趣的科研工作者。 使用场景及目标:适用于希望深入了解纤维混凝土力学性能的研究人员,旨在帮助他们掌握PFC5.0软件的操作技巧,优化模拟参数设置,提高实验效率。 其他说明:文中提供的代码片段可以直接应用于实际项目中,同时附带了一些实践经验分享,有助于初学者快速入门并避免常见错误。

    少儿编程scratch项目源代码文件案例素材-生存V1(有BAG).zip

    少儿编程scratch项目源代码文件案例素材-生存V1(有BAG).zip

    少儿编程scratch项目源代码文件案例素材-披萨机器人.zip

    少儿编程scratch项目源代码文件案例素材-披萨机器人.zip

    少儿编程scratch项目源代码文件案例素材-气球滑雪板.zip

    少儿编程scratch项目源代码文件案例素材-气球滑雪板.zip

    少儿编程scratch项目源代码文件案例素材-使命召唤(苏联插旗).zip

    少儿编程scratch项目源代码文件案例素材-使命召唤(苏联插旗).zip

    可跨平台移植的模拟IIC实战项目STM32F407-TestIIC

    1. GPIO模拟I2C 实战项目,根据正点原子 STM32F407ZGT6 进行更改; 2. 可适配STM32、GD32、HC32等MCU;

    scratch少儿编程逻辑思维游戏源码-百米冲刺.zip

    scratch少儿编程逻辑思维游戏源码-百米冲刺.zip

    【蓝桥杯竞赛】历年试题精选与备考资源汇总:编程算法及硬件单片机试题解析与练习指导

    内容概要:本文档汇总了蓝桥杯历年试题及练习资源,涵盖编程类试题精选、硬件与单片机试题、练习资源与题库以及备考建议。编程类试题精选包括基础算法题(如数组求和、质因数分解)、经典算法案例(如最大子序列和、兰顿蚂蚁模拟)和数据结构应用(如字符全排列)。硬件与单片机试题主要涉及客观题考点,如BUCK电路和电源设计。练习资源与题库部分介绍了真题平台(如Dotcpp、CSDN专题)和专项训练包(如Python题库、Java百题集、C++真题解析)。备考建议分为分阶段练习(新手阶段、进阶提升)和模拟实战(如使用Dotcpp估分系统进行限时训练),强调按年份和组别分类练习,强化代码实现与调试能力。; 适合人群:准备参加蓝桥杯竞赛的学生及编程爱好者。; 使用场景及目标:①针对不同编程语言和难度级别的题目进行专项训练;②通过历年真题和模拟实战提高解题速度和准确性;③掌握算法设计、数据结构应用及硬件基础知识。; 阅读建议:此文档提供了丰富的试题和练习资源,建议根据自身水平选择合适的题目进行练习,并结合真题平台的估分系统和社区开源代码进行对比优化,逐步提升编程能力和竞赛水平。

    30kW储能PCS原理图设计:量产设计的关键要素与优化策略

    内容概要:本文详细介绍了30kW储能PCS(电力转换系统)原理图的设计要点及其量产化过程中需要注意的技术细节。首先阐述了储能PCS的基本概念和重要性,接着深入探讨了主拓扑结构的选择,特别是双级式结构的优势以及关键组件如IGBT的驱动时序配置。随后讨论了控制算法的智能化改进,包括加入前馈补偿以提高系统的稳定性。此外,还强调了EMC设计、PCB布局、元件选择等方面的注意事项,并分享了一些实际生产中遇到的问题及解决方案。最后提到了自动化测试方法和散热管理策略,确保产品在各种环境下的可靠运行。 适合人群:从事储能系统设计、电力电子产品研发的工程师和技术人员。 使用场景及目标:帮助读者掌握30kW储能PCS从原理图设计到量产实施的全流程关键技术,提升产品的性能和可靠性,避免常见错误。 其他说明:文中提供了具体的代码片段和实践经验,有助于理解和应用相关理论。

    少儿编程scratch项目源代码文件案例素材-喷气包多德.zip

    少儿编程scratch项目源代码文件案例素材-喷气包多德.zip

    机械工程中基于Python的齿轮啮合性能与动态响应分析

    内容概要:本文深入探讨了齿轮啮合性能及其动态特性,特别是直齿轮的基础参数计算、渐开线绘制以及接触力仿真的具体实现。首先介绍了齿轮的基本参数如模数、齿数、压力角等,并给出了具体的计算实例。接着详细讲解了如何利用Python进行渐开线的数学建模并绘图展示,强调了这种曲线对于确保齿轮平稳传动的重要性。然后讨论了齿轮在啮合过程中接触力的变化规律,提供了简化的Python代码来模拟这一现象。最后指出,在实际工程项目中应当借助专业的软件包如PyDy或ADAMS来进行更加精确的动力学分析,同时肯定了自行编写代码的价值在于能够更好地理解和排查问题。 适合人群:机械工程领域的研究人员、工程师以及相关专业的学生。 使用场景及目标:①帮助读者掌握齿轮基本理论知识;②指导读者运用Python编程技能完成简单的齿轮性能分析任务;③为后续深入研究提供思路和技术支持。 阅读建议:由于文中涉及较多的专业术语和数学公式,建议读者提前复习相关基础知识,并尝试运行提供的代码片段加深理解。此外,对于想要进一步探索该领域的读者来说,可以参考文末提到的专业工具包进行更复杂的研究。

    少儿编程scratch项目源代码文件案例素材-任务.zip

    少儿编程scratch项目源代码文件案例素材-任务.zip

    少儿编程scratch项目源代码文件案例素材-时光大盗.zip

    少儿编程scratch项目源代码文件案例素材-时光大盗.zip

Global site tag (gtag.js) - Google Analytics