ehcache更新緩存
『壹』 刷新ehcache緩存怎麼刷新
spring 配置文件 <bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"> <property name="configLocation"> <value>classpath:config/ehcache.xml </value> </property> </bean> <bean id="baseCache" class="org.springframework.cache.ehcache.EhCacheFactoryBean"> <property name="cacheManager" ref="cacheManager" /> <property name="cacheName"> <value>cacheNameXXXX</value> </property> </bean> 在代碼中使用的時候從springContext中取到baseCache 存： baseCache.put(new Element(key,value)); 取：baseCache.get(key); 緩存自動刷新：可以在執行更新、刪除資料庫操作的時候同時對緩存進行更新，也可以直接清除緩存，下一次查詢時再載入，畢竟緩存中的數據不是經常更改的數據。
『貳』 hibernate二級緩存 和 spring整合的緩存(就是用哪個Cacheable註解的)有什麼區別么
二級緩存配置（spring+hibernate）
說明：本人不建議使用查詢緩存，因為查詢緩存要求完全相同的查詢sql語句才會起作用，所說的查詢緩存是針對第二次查詢時 sql語句與第一次sql語句完全相同 那麼就可以從緩存中取數據而不去資料庫中取數據了，在不啟用查詢緩存的情況下 每次的查詢數據也會緩存到二級緩存的 只不過每次查詢都會去查詢資料庫（不包括根據ID查詢），啟用查詢緩存很麻煩 需要每次查詢時 調用Query.setCacheable(true)方法才可以，如：List<OrgiData> orgiDatas = (List<OrgiData>) s.createQuery("from OrgiData").setCacheable(true).list();
因此建議將查詢緩存設置為如下：
hibernate.cache.use_query_cache=false
還有就是最重要的一點：對於經常修改或重要的數據不宜進行緩存，因為多並發時會造成數據不同步的情況。
首先增加ehcache-1.4.1.jar和backport-util-concurrent-3.1.jar或oscache-2.1.jar
一、spring配置
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="mappingResources">
<list>
<value>com/handpay/core/merchant/bean/MerchGroupBuy.hbm.xml
</value>
</list>
</property>
<property name="hibernateProperties">
<value>
hibernate.dialect=org.hibernate.dialect.SQLServerDialect
hibernate.show_sql=true
hibernate.format_sql=true
hibernate.hbm2ddl.auto=update
hibernate.cache.use_second_level_cache=true
hibernate.cache.use_query_cache=false
hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider </value>
</property>
</bean>
<!---紅色字體是二級緩存相關的設置->
二、hbm.xml文件示例
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="com.handpay.core.merchant.bean">
<class name="MerchGroupBuy" table="merch_group_buy">
<cache usage="read-write" region="com.handpay.core.merchant.bean.MerchGroupBuy"/>
<id name="id">
<generator class="native" />
</id>
<property name="code" />
<property name="createTime"/>
<property name="minNum"/>
<property name="status">
</property>
<property name="title"/>
<property name="typeCode"/>
<property name="updateTime"/>
</class>
</hibernate-mapping>
三、註解示例
@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_ONLY)
@Table(name = "alcor_t_countries", catalog = "alcorweb")
public class AlcorTCountries implements java.io.Serializable{。。。。}
四、配置文件參數詳解
ehcache.xml是ehcache的配置文件，並且存放在應用的classpath中。下面是對該XML文件中的一些元素及其屬性的相關說明：
<diskStore>元素：指定一個文件目錄，當EHCache把數據寫到硬碟上時，將把數據寫到這個文件目錄下。 下面的參數這樣解釋：
user.home – 用戶主目錄
user.dir – 用戶當前工作目錄
java.io.tmpdir – 默認臨時文件路徑
<defaultCache>元素：設定緩存的默認數據過期策略。
<cache>元素：設定具體的命名緩存的數據過期策略。
<cache>元素的屬性
name：緩存名稱。通常為緩存對象的類名（非嚴格標准）。
maxElementsInMemory：設置基於內存的緩存可存放對象的最大數目。
maxElementsOnDisk：設置基於硬碟的緩存可存放對象的最大數目。
eternal：如果為true，表示對象永遠不會過期，此時會忽略timeToIdleSeconds和timeToLiveSeconds屬性，默認為false;
timeToIdleSeconds： 設定允許對象處於空閑狀態的最長時間，以秒為單位。當對象自從最近一次被訪問後，如果處於空閑狀態的時間超過了timeToIdleSeconds屬性值，這個對象就會過期。當對象過期，EHCache將把它從緩存中清空。只有當eternal屬性為false，該屬性才有效。如果該屬性值為0，則表示對象可以無限期地處於空閑狀態。
timeToLiveSeconds：設定對象允許存在於緩存中的最長時間，以秒為單位。當對象自從被存放到緩存中後，如果處於緩存中的時間超過了 timeToLiveSeconds屬性值，這個對象就會過期。當對象過期，EHCache將把它從緩存中清除。只有當eternal屬性為false，該屬性才有效。如果該屬性值為0，則表示對象可以無限期地存在於緩存中。timeToLiveSeconds必須大於timeToIdleSeconds屬性，才有意義。
overflowToDisk：如果為true,表示當基於內存的緩存中的對象數目達到了maxElementsInMemory界限後，會把益出的對象寫到基於硬碟的緩存中。注意：如果緩存的對象要寫入到硬碟中的話，則該對象必須實現了Serializable介面才行。
memoryStoreEvictionPolicy：緩存對象清除策略。有三種：
1 FIFO ，first in first out ，這個是大家最熟的，先進先出，不多講了
2 LFU ， Less Frequently Used ，就是上面例子中使用的策略，直白一點就是講一直以來最少被使用的。如上面所講，緩存的元素有一個hit 屬性，hit 值最小的將會被清出緩存。
2 LRU ，Least Recently Used ，最近最少使用的，緩存的元素有一個時間戳，當緩存容量滿了，而又需要騰出地方來緩存新的元素的時候，那麼現有緩存元素中時間戳離當前時間最遠的元素將被清出緩存。
五 、查看 二級緩存數據
1、使用sessionFactory直接獲取
Map cacheEntries = sessionFactory().getStatistics()
.getSecondLevelCacheStatistics("cacheRegionName")
.getEntries();
其中 cacheRegionName 既是 ehcache.xml配置中的<cache 標簽的name屬性值
2、讓log4j列印緩存信息（生成環境下請注釋掉，以免影響性能）
log4j.logger.org.hibernate.cache=debug
『叄』 EhCache、OsCache、JBossCache性能上的差別：
在開發高並發量，高性唯改歷能的網站應用系統時，緩存Cache起到了非常重要的作用。本文主要介紹EHCache的使用，以及使用EHCache的實踐經驗。筆者使用過多種基於Java的開源Cache組件，其中包括OSCache、JBossCache、EHCache。OSCache功能強大，使用靈活，可用於對象緩存、Filter緩存以及在JSP中直接使用cache標簽。筆者在最近的使用過程中發現，在並發量較高時，OSCache會出現線程阻塞和數據錯誤，通過分析源代碼發現是其內部實現的缺陷。JBossCache最大的優點是支持基於對象屬性的集群同步，不過JBossCache的配置使用都較復雜，在並發量較指搜高的情況下，對象屬性數據在集群中同步也會加大系統的開銷。以上兩種Cache本文僅作簡單介紹，不做深入探討。EHCache是來自sourceforge（通過manager可以生成指定名稱的Cache對象Cachecache=cache=manager.getCache("demoCache");//使用manager移除指定名稱的Cache對象manager.removeCache("demoCache");可以通過調用manager.removalAll()來移除所有的Cache。通過調用manager的shutdown()方法可以關閉CacheManager。有了Cache對象之後就可以進行一些基本的Cache操作，例如：//往cache中添加元素Elementelement=newElement("key","value");cache.put(element);//從cache中取回元素Elementelement=cache.get("key");element.getValue();//從Cache中移除一個元素cache.remove("key");可以直接使用上面殲銷的API進行數據對象的緩存，這里需要注意的是對於緩存的對象都是必須可序列化的。在下面的篇幅中筆者還會介紹EHCache和Spring、Hibernate的整合使用。
『肆』 常用的緩存技術
第一章 常用的緩存技術
1、常見的兩種緩存
本地緩存：不需要序列化，速度快，緩存的數量與大小受限於本機內存
分布式緩存：需要序列化，速度相較於本地緩存較慢，但是理論上緩存的數量與大小無限（因為緩存機器可以不斷擴展）
2、本地緩存
Google guava cache：當下最好用的本地緩存
Ehcache：spring默認集成的一個緩存，以spring cache的底層緩存實現類形式去操作緩存的話，非常方便，但是欠缺靈活，如果想要靈活使用，還是要單獨使用Ehcache
Oscache：最經典簡單的頁面緩存
3、分布式緩存
memcached：分布式緩存的標配
Redis：新一代的分布式緩存，有替代memcached的趨勢
3.1、memcached
經典的一致性hash演算法
基於slab的內存模型有效防止內存碎片的產生（但同時也需要估計好啟動參數，否則會浪費很多的內存）
集群中機器之間互不通信（相較於Jboss cache等集群中機器之間的相互通信的緩存，速度更快<--因為少了同步更新緩存的開銷，且更適合於大型分布式系統中使用）
使用方便（這一點是相較於Redis在構建客戶端的時候而言的，盡管redis的使用也不困難）
很專一（專做緩存，這一點也是相較於Redis而言的）
3.2、Redis
可以存儲復雜的數據結構（5種）
strings-->即簡單的key-value，就是memcached可以存儲的唯一的一種形式，接下來的四種是memcached不能直接存儲的四種格式（當然理論上可以先將下面的一些數據結構中的東西封裝成對象，然後存入memcached，但是不推薦將大對象存入memcached，因為memcached的單一value的最大存儲為1M，可能即使採用了壓縮演算法也不夠，即使夠，可能存取的效率也不高，而redis的value最大為1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事實上底層是一個hashTable
sorted sets-->底層是一個skipList
有兩種方式可以對緩存數據進行持久化
RDB
AOF
事件調度
發布訂閱等
4、集成緩存
專指spring cache，spring cache自己繼承了ehcache作為了緩存的實現類，我們也可以使用guava cache、memcached、redis自己來實現spring cache的底層。當然，spring cache可以根據實現類來將緩存存在本地還是存在遠程機器上。
5、頁面緩存
在使用jsp的時候，我們會將一些復雜的頁面使用Oscache進行頁面緩存，使用非常簡單，就是幾個標簽的事兒；但是，現在一般的企業，前台都會使用velocity、freemaker這兩種模板引擎，本身速度就已經很快了，頁面緩存使用的也就很少了。
總結：
在實際生產中，我們通常會使用guava cache做本地緩存+redis做分布式緩存+spring cache就集成緩存（底層使用redis來實現）的形式
guava cache使用在更快的獲取緩存數據，同時緩存的數據量並不大的情況
spring cache集成緩存是為了簡單便捷的去使用緩存（以註解的方式即可），使用redis做其實現類是為了可以存更多的數據在機器上
redis緩存單獨使用是為了彌補spring cache集成緩存的不靈活
就我個人而言，如果需要使用分布式緩存，那麼首先redis是必選的，因為在實際開發中，我們會緩存各種各樣的數據類型，在使用了redis的同時，memcached就完全可以舍棄了，但是現在還有很多公司在同時使用memcached和redis兩種緩存。
『伍』 EhCache 分布式緩存/緩存集群
一 緩存系統簡介 EhCache 是一個純 Java 的進程內緩存框架 具有快速 精乾等特點 是 Hibernate 中默認的 CacheProvider 鍵源 EhCache 應用架構圖 下圖是 EhCache 在應用程序中的位置
EhCache 的主要特性有 快速 精幹 簡單 多種緩存策略 緩存數據有兩級 內存和磁碟 因此無需擔心容量問題 緩存數據會在虛稿亮態擬機重啟的過程中寫入磁碟 可以通過 RMI 可插入 API 等方式進行分布式緩存 具有緩存和緩存管理器的偵聽介面 支持多緩存管理器實例 以及一個實例的多個緩存區域 提供 Hibernate 的緩存實現 由於 EhCache 是進程中的緩存系統 一旦將應用部署在集群環境中 每一個節點維護各自的緩存數據 當某個節點對緩存數據進行更新 這些更新的數據無法在其它節點 *** 享 這不僅會降低節點運行的效率 而且會導致數據不同步的情況發生 例如某個網站採用 A B 兩個節點作為集群部署 當 A 節點的緩存更新後 而 B 節點緩存尚未更新就可能出現用戶在瀏覽頁面的時候 一會是更新後的數據 一會是尚未更新的數據 盡管我們也可以通過 Session Sticky 技術來將用戶鎖定在某個節點上 但對於一些交互性比較強或者是非 Web 方式的系統來說 Session Sticky 顯然不太適合 所以就需要用到 EhCache 的集群解決方案 從 版本開始 Ehcache可以使用分布式的緩存了 EhCache 從 版本開始 支持五種集群方案 分別是 ? 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的配置文件中指定元素的class屬性為 net sf ehcache distribution 自動的成員發現 自動的發現方式用TCP廣播機制來確定和維持一個廣播組 它只需要一個簡單的配置可以自動的在組中添加和移除成員 在集群中也不需要什麼優化伺服器的知識 這是默認推薦的 成員每秒向群組發送一個 心跳 如果一個成員 秒種都沒有發出信號它將被群組移除 如果一個新的成員發送了一個 心跳 它將被添加進群組 任何一個用這個配置安裝了復制功能的cache都將被其他的成員發現並標識為可用狀態 要設置自動的成員發現 需要指定ehcache配置文件中元素的properties屬性 就像下面這樣 peerDiscovery=automatic multicastGroupAddress=multicast address | multicast host name multicastGroupPort=port timeToLive= （timeToLive屬性詳見常見問題部分的描述） 示例 假設你在集群中有兩台伺服器 你希望同步sampleCache 和sampleCache 每台獨立的伺服器都要有這樣的配置 配置server 和server <class= net sf ehcache distribution properties= peerDiscovery=automatic multicastGroupAddress= />multicastGroupPort= timeToLive= 手動進行成員發現 進行手動成員配置要知道每個監聽器的IP地址和埠 成員不能在運行時動態地添加和移除 在技術上很難使用廣播的情況下就可以手動成員發現 例如在集群的伺服器之間有一個不能傳送廣播報文的路由器 你也可以用手動成員發現進行單向的數據復制 只讓server 知道server 而server 不知道server 配置手動成員發現 需要指定ehcache配置文件中的properties屬性 像下面這樣 peerDiscovery=manual rmiUrls=//server:port/cacheName //server:port/cacheName … rmiUrls配置的是伺服器cache peers的列表 注意不要重復配置 示例 假設你在集群中有兩台伺服器 你要同步sampleCache 和sampleCache 下面是每個伺服器需要的配置 配置server <class= net sf ehcache distribution properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置server <class= net sf ehcache distribution properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置CacheManagerPeerListener 每個CacheManagerPeerListener監聽從成員們發向當前CacheManager的消息 配置CacheManagerPeerListener需要指定一個 它以插件的機制實現 用來創建CacheManagerPeerListener 的屬性有 class – 一個完整的工廠類名 properties – 只對這個工廠有意義的屬性 使用逗號分隔 Ehcache有一個內置的基於RMI的分布系統 它的監聽器是RMICacheManagerPeerListener 這個監聽器可以用 RMI來配置 <class= net sf ehcache distribution RMI properties= hostName=localhost port= />socketTimeoutMillis= 有效的屬性是 hostname （可選） – 運行監聽器的伺服器名稱 標明了做為集群群組的成員的地址 同時也是你想要控制的從集群中接收消息的介面在CacheManager初始化的時候會檢查hostname是否可用 如果hostName不可用 CacheManager將拒絕啟動並拋出一個連接被拒絕的異常 如果指定 hostname將使用InetAddress getLocalHost（） getHostAddress（）來得到 警告 不要將localhost配置為本地地址 因為它在網路中不可見將會導致不能從遠程伺服器接收信息從而不能復制 在同一台機器上有多個CacheManager的時候 你應該只用localhost來配置 port – 監聽器監聽的埠 socketTimeoutMillis （可選） – Socket超時的時間 默認是 ms 當你socket同步緩存請求地址比較遠 不是本地區域網 你可能需要把這個時間配置大些 不然很可能延時導致同步緩存失敗 配置CacheReplicators 每個要進行同步的cache都需要設置一個用來向CacheManagerr的成員復制消息的緩存事件監聽器 這個工作要通過為每個cache的配置增加一個cacheEventListenerFactory元素來完成 <! Sample cache named sampleCache ><cache name= sampleCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= 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 sampleCache All missing RMICacheReplicatorFactory properties default to true ><cache name= sampleCache maxElementsInMemory= eternal= true overflowToDisk= false memoryStoreEvictionPolicy= LFU ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory /></cache> 常見的問題 Windows上的Tomcat 有一個Tomcat或者是JDK的bug 在tomcat啟動時如果tomcat的安裝路徑中有空格的話 在啟動時RMI監聽器會失敗 參見 bin/wa?A =ind &L=rmi users&P= 和 doc/faq howto bugs/l 由於在Windows上安裝Tomcat默認是裝在 Program Files 文件夾里的 所以這個問題經常發生 廣播阻斷 自動的peer discovery與廣播息息相關 廣播可能被路由阻攔 像Xen和VMWare這種虛擬化的技術也可以阻攔廣播 如果這些都打開了 你可能還在要將你的網卡的相關配置打開 一個簡單的辦法可以告訴廣播是否有效 那就是使用ehcache remote debugger來看 心跳 是否可用 廣播傳播的不夠遠或是傳得太遠 你可以通過設置badly misnamed time to live來控制廣播傳播的距離 用廣播IP協議時 timeToLive的值指的是數據包可以傳遞的域或是范圍 約定如下 是限制在同一個伺服器 是限制在同一個子網 是限制在同一個網站 是限制在同一個region 是限制在同一個大洲 是不限制 譯者按 上面這些資料翻譯的不夠准確 請讀者自行尋找原文理解吧 在Java實現中默認值是 也就是在同一個子網中傳播 改變timeToLive屬性可以限制或是擴展傳播的范圍
三 RMI方式緩存集群/配置分布式緩存 RMI 是 Java 的一種遠程方法調用技術 是一種點對點的基於 Java 對象的通訊方式 EhCache 從 版本開始就支持 RMI 方式的緩存集群 在集群環境中 EhCache 所有緩存對象的鍵和值都必須是可序列化的 也就是必須實現 java io Serializable 介面 這點在其它集群方式下也是需要遵守的 下圖是 RMI 集群模式的結構圖
採用 RMI 集群模式時 集群中的每個節點都是對等關系 並不存在主節點或者從節點的概念 因此節點間必須有一個機制能夠互相認識對方 必須知道其它節點的信息 包括主機地址 埠號等 EhCache 提供兩種節點的發現方式 手工配置和自動發現 手工配置方式要求在每個節點中配置其它所有節點的連接信息 一旦集群中的節點發生變化時 需要對緩存進行重新配置 由於 RMI 是 Java 中內置支持的技術 因此使用 RMI 集群模式時 無需引入其它的 Jar 包 EhCache 本身就帶有支持 RMI 集群的功能 使用 RMI 集群模式需要在 ehcache xml 配置文件中定義 節點 分布式同步緩存要讓這邊的cache知道對方的cache 叫做Peer Discovery（成員發現） EHCache實現成員發現的方式有兩種 手動查找 A 在ehcache xml中配置PeerDiscovery成員發現對象 Server 配置 配置本地hostName port是 分別監聽 : 的mobileCache和 : 的mobileCache 注意這里的mobileCache是緩存的名稱 分別對應著server server 的cache的配置 <?xml version= encoding= gbk ?><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd > <diskStore path= java io tmpdir /> <! 集群多台伺服器中的緩存 這里是要同步一些伺服器的緩存 server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache 注意 每台要同步緩存的伺服器的RMI通信socket埠都不一樣 在配置的時候注意設置 > <! server 的配置 > < class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache /></ehcache>以上注意元素出現的位置在diskStore下
同樣在你的另外 台伺服器上增加配置 Server 配置本地host port為 分別同步 : 的mobileCache和 : 的mobileCache <! server 的配置 >< class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache />Server 配置本地host port為 分別同步 : 的mobileCache緩存和 : 的mobileCache緩存 <! server 的配置 >< class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache />這樣就在三台不同的伺服器上配置了手動查找cache的PeerProvider成員發現的配置了 值得注意的是你在配置rmiUrls的時候要特別注意url不能重復出現 並且埠 地址都是對的 如果指定 hostname將使用InetAddress getLocalHost（） getHostAddress（）來得到 警告 不要將localhost配置為本地地址 因為它在網路中不可見將會導致不能從遠程伺服器接收信息從而不能復制 在同一台機器上有多個CacheManager的時候 你應該只用localhost來配置 B 下面配置緩存和緩存同步監聽 需要在每台伺服器中的ehcache xml文件中增加cache配置和cacheEventListenerFactory cacheLoaderFactory的配置 <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /><! 配置自定義緩存 maxElementsInMemory:緩存中允許創建的最大對象數 eternal:緩存中對象是否為永久的 如果是 超時設置將被忽略 對象從不過期 timeToIdleSeconds:緩存數據空閑的最大時間 也就是說如果有一個緩存有多久沒有被訪問就會被銷毀 如果該值是 就意味著元素可以停頓無窮長的時間 timeToLiveSeconds:緩存數據存活的時間 緩存對象最大的的存活時間 超過這個時間就會被銷毀 這只能在元素不是永久駐留時有效 如果該值是 就意味著元素可以停頓無窮長的時間 overflowToDisk:內存不足時 是否啟用磁碟緩存 memoryStoreEvictionPolicy:緩存滿了之後的淘汰演算法 每一個小時更新一次緩存（ 小時過期） ><cache name= mobileCache maxElementsInMemory= eternal= false overflowToDisk= true timeToIdleSeconds= timeToLiveSeconds= 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 = > <! 監聽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 這樣就完成了 台伺服器的配置 下面給出server 的完整的ehcache xml的配置 <?xml version= encoding= gbk ?><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd > <diskStore path= java io tmpdir /> <!集群多台伺服器中的緩存 這里是要同步一些伺服器的緩存 server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache 注意每台要同步緩存的伺服器的RMI通信socket埠都不一樣 在配置的時候注意設置 > <! server 的配置 > < class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache /> <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /> <! 配置自定義緩存 maxElementsInMemory:緩存中允許創建的最大對象數 eternal:緩存中對象是否為永久的 如果是 超時設置將被忽略 對象從不過期 timeToIdleSeconds:緩存數據空閑的最大時間 也就是說如果有一個緩存有多久沒有被訪問就會被銷毀 如果該值是 就意味著元素可以停頓無窮長的時間 timeToLiveSeconds:緩存數據存活的時間 緩存對象最大的的存活時間 超過這個時間就會被銷毀 這只能在元素不是永久駐留時有效 如果該值是 就意味著元素可以停頓無窮長的時間 overflowToDisk:內存不足時 是否啟用磁碟緩存 memoryStoreEvictionPolicy:緩存滿了之後的淘汰演算法 每一個小時更新一次緩存（ 小時過期） > <cache name= mobileCache maxElementsInMemory= eternal= false overflowToDisk= true timeToIdleSeconds= timeToLiveSeconds= 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 = > <! 監聽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> 自動發現 自動發現配置和手動查找的方式有一點不同 其他的地方都基本是一樣的 同樣在ehcache xml中增加配置 配置如下 <! 搜索某個網段上的緩存timeToLive 是限制在同一個伺服器 是限制在同一個子網 是限制在同一個網站 是限制在同一個region 是限制在同一個大洲 是不限制 >< class= net sf ehcache distribution properties= peerDiscovery=automatic multicastGroupAddress= multicastGroupPort= timeToLive= /> lishixin/Article/program/Java/hx/201311/25706
『陸』 Java本地緩存有哪些
下面給你介紹幾個常見的java緩存框架：
1、OSCache
OSCache是個一個廣泛採用的高性能的J2EE緩存框架，OSCache能用於任何Java應用程序的普通的緩存解決方案。
OSCache有以下特點：
緩存任何對象，你可以不受限制的緩存部分jsp頁面或HTTP請求，任何java對象都可以緩存。
擁有全面的API--OSCache API給你全面的程序來控制所有的OSCache特性。
永久緩存--緩存能隨意的寫入硬碟，因此允許昂貴的創建（expensive-to-create）數據來保持緩存，甚至能讓應用重啟。
支持集群--集群緩存數據能被單個的進行參數配置，不需要修改代碼。
緩存記錄的過期--你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略（如果默認性能不需要時）。
2、Java Caching System
JSC(Java Caching System)是一個用分布式的緩存系統，是基於伺服器的java應用程序。它是通過提供管理各種動態緩存數據來加速動態web應用。
JCS和其他緩存系統一樣，也是一個用於高速讀取，低速寫入的應用程序。
動態內容和報表系統能夠獲得更好的性能。
如果一個網站，有重復的網站結構，使用間歇性更新方式的資料庫（而不是連續不斷的更新資料庫），被重復搜索出相同結果的，就能夠通過執行緩存方式改進其性能和伸縮性。
3、EHCache
EHCache 是一個純java的在進程中的緩存，它具有以下特性：快速，簡單，為Hibernate2.1充當可插入的緩存，最小的依賴性，全面的文檔和測試。
4、JCache
JCache是個開源程序，正在努力成為JSR-107開源規范，JSR-107規范已經很多年沒改變了。這個版本仍然是構建在最初的功能定義上。
5、ShiftOne
ShiftOne Java Object Cache是一個執行一系列嚴格的對象緩存策略的Java lib，就像一個輕量級的配置緩存工作狀態的框架。
6、SwarmCache
SwarmCache是一個簡單且有效的分布式緩存，它使用IP multicast與同一個區域網的其他主機進行通訊，是特別為集群和數據驅動web應用程序而設計的。SwarmCache能夠讓典型的讀操作大大超過寫操作的這類應用提供更好的性能支持。
SwarmCache使用JavaGroups來管理從屬關系和分布式緩存的通訊。
『柒』 hibernate緩存的詳細配置
很多人對二級緩存都不太了解，或者是有錯誤的認識，我一直想寫一篇文章介紹一下hibernate的二級緩存的，今天終於忍不住了。
我的經驗主要來自hibernate2.1版本，基本原理和3.0、3.1是一樣的，請原諒我的頑固不化。
hibernate的session提供了一級緩存，每個session，對同一個id進行兩次load，不會發送兩條sql給資料庫，但是session關閉的時候，一級緩存就失效了。
二級緩存是SessionFactory級別的全局緩存，它底下可以使用不同的緩存類庫，比如ehcache、oscache等，需要設置hibernate.cache.provider_class，我們這里用ehcache，在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查詢緩存，加上
hibernate.cache.use_query_cache=true
緩存可以簡單的看成一個Map，通過key在緩存裡面找value。
Class的緩存
對於一條記錄，也就是一個PO來說，是根據ID來找的，緩存的key就是ID，value是POJO。無論list，load還是iterate，只要讀出一個對象，都會填充緩存。但是list不會使用緩存，而iterate會先取資料庫select id出來，然後一個id一個id的load，如果在緩存裡面有，就從緩存取，沒有的話就去資料庫load。假設是讀寫緩存，需要設置：
<cache usage="read-write"/>
如果你使用的二級緩存實現是ehcache的話，需要配置ehcache.xml
<cache name="com.xxx.pojo.Foo" maxElementsInMemory="500" eternal="false" timeToLiveSeconds="7200" timeToIdleSeconds="3600" overflowToDisk="true" />
其中eternal表示緩存是不是永遠不超時，timeToLiveSeconds是緩存中每個元素（這里也就是一個POJO）的超時時間，如果eternal="false"，超過指定的時間，這個元素就被移走了。timeToIdleSeconds是發呆時間，是可選的。當往緩存裡面put的元素超過500個時，如果overflowToDisk="true"，就會把緩存中的部分數據保存在硬碟上的臨時文件裡面。
每個需要緩存的class都要這樣配置。如果你沒有配置，hibernate會在啟動的時候警告你，然後使用defaultCache的配置，這樣多個class會共享一個配置。
當某個ID通過hibernate修改時，hibernate會知道，於是移除緩存。
這樣大家可能會想，同樣的查詢條件，第一次先list，第二次再iterate，就可以使用到緩存了。實際上這是很難的，因為你無法判斷什麼時候是第一次，而且每次查詢的條件通常是不一樣的，假如資料庫裡面有100條記錄，id從1到100，第一次list的時候出了前50個id，第二次iterate的時候卻查詢到30至70號id，那麼30-50是從緩存裡面取的，51到70是從資料庫取的，共發送1+20條sql。所以我一直認為iterate沒有什麼用，總是會有1+N的問題。
（題外話：有說法說大型查詢用list會把整個結果集裝入內存，很慢，而iterate只select id比較好，但是大型查詢總是要分頁查的，誰也不會真的把整個結果集裝進來，假如一頁20條的話，iterate共需要執行21條語句，list雖然選擇若干欄位，比iterate第一條select id語句慢一些，但只有一條語句，不裝入整個結果集hibernate還會根據資料庫方言做優化，比如使用mysql的limit，整體看來應該還是list快。）
如果想要對list或者iterate查詢的結果緩存，就要用到查詢緩存了
查詢緩存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache，配置ehcache.xml，注意hibernate3.0以後不是net.sf的包名了
<cache name="net.sf.hibernate.cache.StandardQueryCache"
maxElementsInMemory="50" eternal="false" timeToIdleSeconds="3600"
timeToLiveSeconds="7200" overflowToDisk="true"/>
<cache name="net.sf.hibernate.cache.UpdateTimestampsCache"
maxElementsInMemory="5000" eternal="true" overflowToDisk="true"/>
然後
query.setCacheable(true);//激活查詢緩存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可選
第二行指定要使用的cacheRegion是myCacheRegion，即你可以給每個查詢緩存做一個單獨的配置，使用setCacheRegion來做這個指定，需要在ehcache.xml裡面配置它：
<cache name="myCacheRegion" maxElementsInMemory="10" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200" overflowToDisk="true" />
如果省略第二行，不設置cacheRegion的話，那麼會使用上面提到的標准查詢緩存的配置，也就是net.sf.hibernate.cache.StandardQueryCache
對於查詢緩存來說，緩存的key是根據hql生成的sql，再加上參數，分頁等信息（可以通過日誌輸出看到，不過它的輸出不是很可讀，最好改一下它的代碼）。
比如hql：
from Cat c where c.name like ?
生成大致如下的sql：
select * from cat c where c.name like ?
參數是"tiger%"，那麼查詢緩存的key*大約*是這樣的字元串（我是憑記憶寫的，並不精確，不過看了也該明白了）：
select * from cat c where c.name like ? , parameter:tiger%
這樣，保證了同樣的查詢、同樣的參數等條件下具有一樣的key。
現在說說緩存的value，如果是list方式的話，value在這里並不是整個結果集，而是查詢出來的這一串ID。也就是說，不管是list方法還是iterate方法，第一次查詢的時候，它們的查詢方式很它們平時的方式是一樣的，list執行一條sql，iterate執行1+N條，多出來的行為是它們填充了緩存。但是到同樣條件第二次查詢的時候，就都和iterate的行為一樣了，根據緩存的key去緩存裡面查到了value，value是一串id，然後在到class的緩存裡面去一個一個的load出來。這樣做是為了節約內存。
可以看出來，查詢緩存需要打開相關類的class緩存。list和iterate方法第一次執行的時候，都是既填充查詢緩存又填充class緩存的。
這里還有一個很容易被忽視的重要問題，即打開查詢緩存以後，即使是list方法也可能遇到1+N的問題！相同條件第一次list的時候，因為查詢緩存中找不到，不管class緩存是否存在數據，總是發送一條sql語句到資料庫獲取全部數據，然後填充查詢緩存和class緩存。但是第二次執行的時候，問題就來了，如果你的class緩存的超時時間比較短，現在class緩存都超時了，但是查詢緩存還在，那麼list方法在獲取id串以後，將會一個一個去資料庫load！因此，class緩存的超時時間一定不能短於查詢緩存設置的超時時間！如果還設置了發呆時間的話，保證class緩存的發呆時間也大於查詢的緩存的生存時間。這里還有其他情況，比如class緩存被程序強制evict了，這種情況就請自己注意了。
另外，如果hql查詢包含select字句，那麼查詢緩存裡面的value就是整個結果集了。
當hibernate更新資料庫的時候，它怎麼知道更新哪些查詢緩存呢？
hibernate在一個地方維護每個表的最後更新時間，其實也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的緩存配置裡面。
當通過hibernate更新的時候，hibernate會知道這次更新影響了哪些表。然後它更新這些表的最後更新時間。每個緩存都有一個生成時間和這個緩存所查詢的表，當hibernate查詢一個緩存是否存在的時候，如果緩存存在，它還要取出緩存的生成時間和這個緩存所查詢的表，然後去查找這些表的最後更新時間，如果有一個表在生成時間後更新過了，那麼這個緩存是無效的。
可以看出，只要更新過一個表，那麼凡是涉及到這個表的查詢緩存就失效了，因此查詢緩存的命中率可能會比較低。
Collection緩存
需要在hbm的collection裡面設置
<cache usage="read-write"/>
假如class是Cat，collection叫children，那麼ehcache裡面配置
<cache name="com.xxx.pojo.Cat.children"
maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />
Collection的緩存和前面查詢緩存的list一樣，也是只保持一串id，但它不會因為這個表更新過就失效，一個collection緩存僅在這個collection裡面的元素有增刪時才失效。
這樣有一個問題，如果你的collection是根據某個欄位排序的，當其中一個元素更新了該欄位時，導致順序改變時，collection緩存裡面的順序沒有做更新。
緩存策略
只讀緩存（read-only）：沒有什麼好說的
讀/寫緩存（read-write）:程序可能要的更新數據
不嚴格的讀/寫緩存（nonstrict-read-write）：需要更新數據，但是兩個事務更新同一條記錄的可能性很小，性能比讀寫緩存好
事務緩存（transactional）：緩存支持事務，發生異常的時候，緩存也能夠回滾，只支持jta環境，這個我沒有怎麼研究過
讀寫緩存和不嚴格讀寫緩存在實現上的區別在於，讀寫緩存更新緩存的時候會把緩存裡面的數據換成一個鎖，其他事務如果去取相應的緩存數據，發現被鎖住了，然後就直接取資料庫查詢。
在hibernate2.1的ehcache實現中，如果鎖住部分緩存的事務發生了異常，那麼緩存會一直被鎖住，直到60秒後超時。
不嚴格讀寫緩存不鎖定緩存中的數據。
使用二級緩存的前置條件
你的hibernate程序對資料庫有獨占的寫訪問權，其他的進程更新了資料庫，hibernate是不可能知道的。你操作資料庫必需直接通過hibernate，如果你調用存儲過程，或者自己使用jdbc更新資料庫，hibernate也是不知道的。hibernate3.0的大批量更新和刪除是不更新二級緩存的，但是據說3.1已經解決了這個問題。
這個限制相當的棘手，有時候hibernate做批量更新、刪除很慢，但是你卻不能自己寫jdbc來優化，很郁悶吧。
SessionFactory也提供了移除緩存的方法，你一定要自己寫一些JDBC的話，可以調用這些方法移除緩存，這些方法是：
void evict(Class persistentClass)
Evict all entries from the second-level cache.
void evict(Class persistentClass, Serializable id)
Evict an entry from the second-level cache.
void evictCollection(String roleName)
Evict all entries from the second-level cache.
void evictCollection(String roleName, Serializable id)
Evict an entry from the second-level cache.
void evictQueries()
Evict any query result sets cached in the default query cache region.
void evictQueries(String cacheRegion)
Evict any query result sets cached in the named query cache region.
不過我不建議這樣做，因為這樣很難維護。比如你現在用JDBC批量更新了某個表，有3個查詢緩存會用到這個表，用evictQueries(String cacheRegion)移除了3個查詢緩存，然後用evict(Class persistentClass)移除了class緩存，看上去好像完整了。不過哪天你添加了一個相關查詢緩存，可能會忘記更新這里的移除代碼。如果你的jdbc代碼到處都是，在你添加一個查詢緩存的時候，還知道其他什麼地方也要做相應的改動嗎？
----------------------------------------------------
總結：
不要想當然的以為緩存一定能提高性能，僅僅在你能夠駕馭它並且條件合適的情況下才是這樣的。hibernate的二級緩存限制還是比較多的，不方便用jdbc可能會大大的降低更新性能。在不了解原理的情況下亂用，可能會有1+N的問題。不當的使用還可能導致讀出臟數據。
如果受不了hibernate的諸多限制，那麼還是自己在應用程序的層面上做緩存吧。
在越高的層面上做緩存，效果就會越好。就好像盡管磁碟有緩存，資料庫還是要實現自己的緩存，盡管資料庫有緩存，咱們的應用程序還是要做緩存。因為底層的緩存它並不知道高層要用這些數據干什麼，只能做的比較通用，而高層可以有針對性的實現緩存，所以在更高的級別上做緩存，效果也要好些吧。