Ehcache的优缺点以及分布式详解

Ehcache的介绍

EhCache是一个纯Java的进程内缓存框架，具有快速、精干、等特点，是hibernate中默认的CacheProvider.Ehcache是一种广泛使用的开源java分布式缓存。主要面向通用缓存，JavaEE和轻量级容器。它具有内存和磁盘存储，缓存加载器，缓存扩展，缓存异常处理程序，一个gzip缓存servlet过滤器，支持REST和SAOP api等特点。
EhCache应用架构图，下图是Ehcache在应用程序中的位置

ehcache的优点

1.快速
2.简单
3.缓存数据有两级：内存和磁盘，因此无需担心容量问题
4.缓存数据会在虚拟机重启的过程中写入磁盘
5可以通过RMI、可插入API等方式进行分布式缓存
6.具有缓存和缓存管理器的侦听接口
7.支持多缓存管理器实例，以及一个实例的多个缓存区域
8.提供Hibernate的缓存实现
9.多种缓存策略，Ehcache提供了对大数据的内存和硬盘的存储，最近版本允许多实例、保存对象高灵10.活性、提供LRU、LFU、FIFO淘汰算法，基础属性支持热配置、支持的插件多

ehcahe的缺点

使用磁盘Cache的时候非常占用磁盘空间：这是因为DiskCache的算法简单，该算法简单也导致Cache的效率非常高。它只是对元素直接追加存储。因此搜索元素的时候非常的快。如果使用DiskCache的，在很频繁的应用中，很快磁盘会满。
不能保证数据的安全：当突然kill掉java的时候，可能会产生冲突，EhCache的解决方法是如果文件冲突了，则重建cache。这对于Cache数据需要保存的时候可能不利。当然，Cache只是简单的加速，而不能保证数据的安全。如果想保证数据的存储安全，可以使用Bekeley DB Java Edition版本。这是个嵌入式数据库。可以确保存储安全和空间的利用率。

ehcache参数配置

参数配置点击

ehcach本地缓存配置

配置实现(ehcache-local.xml)

<?xml version="1.0" encoding="UTF-8"?>
<ehcache updateCheck="false" name="defaultCache">
    <!-- 本地缓存-->
    <diskStore path="java.io.tmpdir" />
    <!--timeToIdleSeconds=y：缓存创建以后，最后一次访问缓存的日期至失效之时的时间间隔y;timeToLiveSeconds=x：缓存自创建日期起至失效时的间隔时间x;-->
    <defaultCache maxElementsInMemory="1000" eternal="false" timeToIdleSeconds="300" timeToLiveSeconds="600"
        overflowToDisk="true" maxElementsOnDisk="10000000" />
        
    <!-- 系统缓存 -->
    <cache name="sysCache" maxElementsInMemory="1000" eternal="true" overflowToDisk="true"/>
    
    <cache name="shiro-activeSessionCache"  
           maxElementsInMemory="1000"  
           overflowToDisk="true"  
           timeToLiveSeconds="0"  
           timeToIdleSeconds="0"  
           diskPersistent="true"  
           diskExpiryThreadIntervalSeconds="600"/>  
</ehcache>

ehcahe分布式集群.

EhCache的分布式缓存有传统的RMI，1.5版的JGroups，1.6版的JMS。分布式缓存主要解决集群环境中不同的服务器间的数据的同步问题。

RMI方式实现分布式缓存

方式一： RMI组播方式

ehcache-rmi.xml配置

<?xml version="1.0" encoding="UTF-8"?>
<ehcache updateCheck="false" name="defaultCache">
    <!-- 分布式缓存RMI同步(大规模集群、复杂环境慎用) -->
    <diskStore path="java.io.tmpdir" />
        
    <cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
        properties="peerDiscovery=automatic,multicastGroupAddress=230.0.0.1, multicastGroupPort=4446" />
    <cacheManagerPeerListenerFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" />

    <!-- 默认缓存配置. -->
    <defaultCache maxEntriesLocalHeap="100" eternal="false" timeToIdleSeconds="300" timeToLiveSeconds="600"
        overflowToDisk="true" maxEntriesLocalDisk="100000" >
        <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
            properties="replicatePuts=false,replicateUpdatesViaCopy=false"/>
    </defaultCache>
    
    <!-- 系统缓存 -->
    <cache name="sysCache" maxEntriesLocalHeap="100" eternal="true" overflowToDisk="true">
        <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/>
    </cache>
    
    <!-- 系统活动会话缓存 -->
    <cache name="shiro-activeSessionCache" maxEntriesLocalHeap="10000" overflowToDisk="true"
            eternal="true" timeToLiveSeconds="0" timeToIdleSeconds="0"
            diskPersistent="true" diskExpiryThreadIntervalSeconds="600">
        <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
            properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true,
                replicateUpdatesViaCopy=false, replicateRemovals=true "/>
    </cache>
        
</ehcache>

实现原理

这样当缓存改变时,ehcache会向230.0.0.1端口4446发RMI UDP组播包。

缺陷

EHCACHE的组播做得比较初级,功能只是基本实现(比如简单的一个HUB,接两台单网卡的服务器,互相之间组播同步就没问题),对一些复杂的环境(比如多台服务器,每台服务器上多地址,尤其是集群,存在一个集群地址带多个物理机,每台物理机又带多个虚拟站的子地址),就容易出现问题。

究其原因, 组播/广播转发是一个很复杂的过程. 简单的说, 一个组播缺省只能在一个网段内传输,不能跨网段。

举个简单的例子, PC机网卡的自动获取地址,还有WINDOWS里的网上邻居,都属于典型的广播服务,所以这些服务都是不能跨网段(跨路由)的,当然也不是完全不行,借助一些工具,比如CISCO路由器上的udp-broadcast helper,或者微软的netBIOS on Tcp/ip,就可以实现。

我们自己安装一些软件时,也经常遇到比如"将网卡的广播转发打开"之类的操作。

而在多网卡的主机,或同一网卡多IP的主机上,尽管地址可能是一个网段内的,但其实地址间已经存在跳数了(hop),其实就是从一个地址向另一个地址跳. 这时广播/组播就容易被阻断。

比如: 我们自己的WINDOWS上装一个VMWARE虚拟机,尽管IP地址是一个网段的,但因为虚拟机采用的桥模式不是标准的网桥模式(也可能是需要配置一下,但说实话懒得研究VMWARE了),所以广播/组播也经常出现不通的情况。

更何况在一些云计算的环境,集群的分布往往是跨网段的,甚至是跨地域的.这时更难以依赖这种初级的组播同步.
总之,分布式集群架构,建议使用Redis或者Memcache缓存实现。

方式二:p2p方式

其实就是每个节点和其他n-1个节点都建立TCP的P2P PEER。

方式三:JMS消息模式

原理：这种模式的核心就是一个消息队列，每个应用节点都订阅预先定义好的主题，同时，节点有元素更新时，也会发布更新元素到主题中去。各个应用服务器节点通过侦听MQ获取到最新的数据，然后分别更新自己的Ehcache缓存，Ehcache默认支持ActiveMQ，我们也可以通过自定义组件的方式实现类似Kafka，RabbitMQ。