Ehcache是現在最流行的純Java開源快取框架，配置簡單、結構清晰、功能強大，最初知道它，是從hibernate的快取開始的。網上中文的EhCache材料以簡單介紹和配置方法居多，如果你有這方面的問題，請自行google；對於API，官網上介紹已經非常清楚，請參見官網；但是很少見到特性說明和對實現原理的分析，因此在這篇文章裡面，我會詳細介紹和分析EhCache的特性，加上一些自己的理解和思考，希望對快取感興趣的朋友有所收穫。

一、特性一覽，來自官網，簡單翻譯一下：

1、快速輕量
過去幾年，諸多測試表明Ehcache是最快的Java快取之一。
Ehcache的執行緒機制是為大型高併發系統設計的。
大量效能測試用例保證Ehcache在不同版本間效能表現得一致性。
很多使用者都不知道他們正在用Ehcache，因為不需要什麼特別的配置。
API易於使用，這就很容易部署上線和執行。
很小的jar包，Ehcache 2.2.3才668kb。
最小的依賴：唯一的依賴就是SLF4J了。

2、伸縮性

快取在記憶體和磁碟儲存可以伸縮到數G，Ehcache為大資料儲存做過優化。
大記憶體的情況下，所有程序可以支援數百G的吞吐。
為高併發和大型多CPU伺服器做優化。
執行緒安全和效能總是一對矛盾，Ehcache的執行緒機制設計採用了Doug Lea的想法來獲得較高的效能。
單臺虛擬機器上支援多快取管理器。
通過Terracotta伺服器矩陣，可以伸縮到數百個節點。

3、靈活性
Ehcache 1.2具備物件API介面和可序列化API介面。
不能序列化的物件可以使用除磁碟儲存外Ehcache的所有功能。
除了元素的返回方法以外，API都是統一的。只有這兩個方法不一致：getObjectValue和getKeyValue。這就使得快取物件、序列化物件來獲取新的特性這個過程很簡單。
支援基於Cache和基於Element的過期策略，每個Cache的存活時間都是可以設定和控制的。
提供了LRU、LFU和FIFO快取淘汰

演算法，Ehcache 1.2引入了最少使用和先進先出快取淘汰演算法，構成了完整的快取淘汰演算法。
提供記憶體和磁碟儲存，Ehcache和大多數快取解決方案一樣，提供高效能的記憶體和磁碟儲存。
動態、執行時快取配置，存活時間、空閒時間、記憶體和磁碟存放快取的最大數目都是可以在執行時修改的。

4、標準支援
Ehcache提供了對JSR107 JCACHE API最完整的實現。因為JCACHE在釋出以前，Ehcache的實現（如net.sf.jsr107cache）已經發布了。
實現JCACHE API有利於到未來其他快取解決方案的可移植性。
Ehcache的維護者Greg Luck，正是JSR107的專家委員會委員。

5、可擴充套件性
監聽器可以外掛化。Ehcache 1.2提供了CacheManagerEventListener和CacheEventListener介面，實現可以外掛化，並且可以在ehcache.xml裡配置。
節點發現，冗餘器和監聽器都可以外掛化。
分散式快取，從Ehcache 1.2開始引入，包含了一些權衡的選項。Ehcache的團隊相信沒有什麼是萬能的配置。
實現者可以使用內建的機制或者完全自己實現，因為有完整的外掛開發指南。
快取的可擴充套件性可以外掛化。建立你自己的快取擴充套件，它可以持有一個快取的引用，並且繫結在快取的生命週期內。
快取載入器可以外掛化。建立你自己的快取載入器，可以使用一些非同步方法來載入資料到快取裡面。
快取異常處理器可以外掛化。建立一個異常處理器，在異常發生的時候，可以執行某些特定操作。

6、應用持久化
在VM重啟後，持久化到磁碟的儲存可以復原資料。
Ehcache是第一個引入快取資料持久化儲存的開源Java快取框架。快取的資料可以在機器重啟後從磁碟上重新獲得。
根據需要將快取刷到磁碟。將快取條目刷到磁碟的操作可以通過cache.flush()方法來執行，這大大方便了Ehcache的使用。

7、監聽器
快取管理器監聽器。允許註冊實現了CacheManagerEventListener介面的監聽器：
notifyCacheAdded()
notifyCacheRemoved()
快取事件監聽器。允許註冊實現了CacheEventListener介面的監聽器，它提供了許多對快取事件發生後的處理機制：
notifyElementRemoved/Put/Updated/Expired 

8、開啟JMX
Ehcache的JMX功能是預設開啟的，你可以監控和管理如下的MBean：
CacheManager、Cache、CacheConfiguration、CacheStatistics 

9、分散式快取
從Ehcache 1.2開始，支援高效能的分散式快取，兼具靈活性和擴充套件性。
分散式快取的選項包括：
通過Terracotta的快取叢集：設定和使用Terracotta模式的Ehcache快取。快取發現是自動完成的，並且有很多選項可以用來除錯快取行為和效能。
使用RMI、JGroups或者JMS來冗餘快取資料：節點可以通過多播或發現者手動配置。狀態更新可以通過RMI連線來非同步或者同步完成。
Custom：一個綜合的外掛機制，支援發現和複製的能力。
可用的快取複製選項。支援的通過RMI、JGroups或JMS進行的非同步或同步的快取複製。
可靠的分發：使用TCP的內建分發機制。
節點發現：節點可以手動配置或者使用多播自動發現，並且可以自動新增和移除節點。對於多播阻塞的情況下，手動配置可以很好地控制。
分散式快取可以任意時間加入或者離開叢集。快取可以配置在初始化的時候執行載入程式員。
BootstrapCacheLoaderFactory抽象工廠，實現了BootstrapCacheLoader介面（RMI實現）。
快取服務端。Ehcache提供了一個Cache Server，一個war包，為絕大多數web容器或者是獨立的伺服器提供支援。
快取服務端有兩組API：面向資源的RESTful，還有就是SOAP。客戶端沒有實現語言的限制。
RESTful快取伺服器：Ehcached的實現嚴格遵循RESTful面向資源的架構風格。
SOAP快取服務端：Ehcache RESTFul Web Services API暴露了單例的CacheManager，他能在ehcache.xml或者IoC容器裡面配置。
標準服務端包含了內嵌的Glassfish web容器。它被打成了war包，可以任意部署到支援Servlet 2.5的web容器內。Glassfish V2/3、Tomcat 6和Jetty 6都已經經過了測試。

10、搜尋
標準分散式搜尋使用了流式查詢介面的方式，請參閱文件。


為普通快取場景和模式提供高質量的實現。
阻塞快取：它的機制避免了複製程序併發操作的問題。
SelfPopulatingCache在快取一些開銷昂貴操作時顯得特別有用，它是一種針對讀優化的快取。它不需要呼叫者知道快取元素怎樣被返回，也支援在不阻塞讀的情況下重新整理快取條目。
CachingFilter：一個抽象、可擴充套件的cache filter。
SimplePageCachingFilter：用於快取基於request URI和Query String的頁面。它可以根據HTTP request header的值來選擇採用或者不採用gzip壓縮方式將頁面發到瀏覽器端。你可以用它來快取整個Servlet頁面，無論你採用的是JSP、velocity，或者其他的頁面渲染技術。
SimplePageFragmentCachingFilter：快取頁面片段，基於request URI和Query String。在JSP中使用jsp:include標籤包含。
已經使用Orion和Tomcat測試過，相容Servlet 2.3、Servlet 2.4規範。
Cacheable命令：這是一種老的命令列模式，支援非同步行為、容錯。
相容Hibernate，相容Google App Engine。
基於JTA的事務支援，支援事務資源管理，二階段提交和回滾，以及本地事務。

12、開源協議
Apache 2.0 license

二、Ehcache的載入模組列表，他們都是獨立的庫，每個都為Ehcache新增新的功能，可以在此下載：

• ehcache-core：API，標準快取引擎，RMI複製和Hibernate支援
• ehcache：分散式Ehcache，包括Ehcache的核心和Terracotta的庫
• ehcache-monitor：企業級監控和管理
• ehcache-web：為Java Servlet Container提供快取、gzip壓縮支援的filters
• ehcache-jcache：JSR107 JCACHE的實現
• ehcache-jgroupsreplication：使用JGroup的複製
• ehcache-jmsreplication：使用JMS的複製
• ehcache-openjpa：OpenJPA外掛
• ehcache-server：war內部署或者單獨部署的RESTful cache server
• ehcache-unlockedreadsview：允許Terracotta cache的無鎖讀
• ehcache-debugger：記錄RMI分散式呼叫事件
• Ehcache for Ruby：Jruby and Rails支援

Ehcache的結構設計概覽：

三、核心定義：

cache manager：快取管理器，以前是隻允許單例的，不過現在也可以多例項了

cache：快取管理器內可以放置若干cache，存放資料的實質，所有cache都實現了Ehcache介面

element：單條快取資料的組成單位

system of record（SOR）：可以取到真實資料的元件，可以是真正的業務邏輯、外部介面呼叫、存放真實資料的資料庫等等，快取就是從SOR中讀取或者寫入到SOR中去的。

CacheManager manager = CacheManager.newInstance("src/config/ehcache.xml");  
manager.addCache("testCache");  
Cache test = singletonManager.getCache("testCache");  
test.put(new Element("key1", "value1"));  
manager.shutdown();  

當然，也支援這種類似DSL的配置方式，配置都是可以在執行時動態修改的：

Cache testCache = new Cache(  
  new CacheConfiguration("testCache", maxElements)  
    .memoryStoreEvictionPolicy(MemoryStoreEvictionPolicy.LFU)  
    .overflowToDisk(true)  
    .eternal(false)  
    .timeToLiveSeconds(60)  
    .timeToIdleSeconds(30)  
    .diskPersistent(false)  
    .diskExpiryThreadIntervalSeconds(0));  

事務的例子：

Ehcache cache = cacheManager.getEhcache("xaCache");  
transactionManager.begin();  
try {  
    Element e = cache.get(key);  
    Object result = complexService.doStuff(element.getValue());  
    cache.put(new Element(key, result));  
    complexService.doMoreStuff(result);  
    transactionManager.commit();  
} catch (Exception e) {  
    transactionManager.rollback();  
}  

四、一致性模型：

說到一致性，資料庫的一致性是怎樣的？不妨先來回顧一下資料庫的幾個隔離級別：

未提交讀（Read Uncommitted）：在讀資料時不會檢查或使用任何鎖。因此，在這種隔離級別中可能讀取到沒有提交的資料。會出現髒讀、不可重複讀、幻象讀。
已提交讀（Read Committed）：只讀取提交的資料並等待其他事務釋放排他鎖。讀資料的共享鎖在讀操作完成後立即釋放。已提交讀是資料庫的預設隔離級別。會出現不可重複讀、幻象讀。
可重複讀（Repeatable Read）：像已提交讀級別那樣讀資料，但會保持共享鎖直到事務結束。會出現幻象讀。
可序列化（Serializable）：工作方式類似於可重複讀。但它不僅會鎖定受影響的資料，還會鎖定這個範圍，這就阻止了新資料插入查詢所涉及的範圍。

基於以上，再來對比思考下面的一致性模型：

1、強一致性模型：系統中的某個資料被成功更新(事務成功返回)後，後續任何對該資料的讀取操作都得到更新後的值。這是傳統關係資料庫提供的一致性模型，也是關係資料庫深受人們喜愛的原因之一。強一致性模型下的效能消耗通常是最大的。

2、弱一致性模型：系統中的某個資料被更新後，後續對該資料的讀取操作得到的不一定是更新後的值，這種情況下通常有個“不一致性時間視窗”存在：即資料更新完成後在經過這個時間視窗，後續讀取操作就能夠得到更新後的值。

3、最終一致性模型：屬於弱一致性的一種，即某個資料被更新後，如果該資料後續沒有被再次更新，那麼最終所有的讀取操作都會返回更新後的值。

最終一致性模型包含如下幾個必要屬性，都比較好理解：

• 讀寫一致：某執行緒A，更新某條資料以後，後續的訪問全部都能取得更新後的資料。
• 會話內一致：它本質上和上面那一條是一致的，某使用者更改了資料，只要會話還存在，後續他取得的所有資料都必須是更改後的資料。
• 單調讀一致：如果一個程序可以看到當前的值，那麼後續的訪問不能返回之前的值。
• 單調寫一致：對同一程序內的寫行為必須是保序的，否則，寫完畢的結果就是不可預期的了。

4、Bulk Load：這種模型是基於批量載入資料到快取裡面的場景而優化的，沒有引入鎖和常規的淘汰演算法這些降低效能的東西，它和最終一致性模型很像，但是有批量、高速寫和弱一致性保證的機制。

這樣幾個API也會影響到一致性的結果：

：如果我們本身就配置為強一致性，那麼自然所有的快取操作都具備事務性質。而如果我們配置成最終一致性時，再在外部使用顯式鎖API，也可以達到事務的效果。當然這樣的鎖可以控制得更細粒度，但是依然可能存在競爭和執行緒阻塞。

2、無鎖可讀取檢視（UnlockedReadsView）：一個允許髒讀的decorator，它只能用在強一致性的配置下，它通過申請一個特殊的寫鎖來比完全的強一致性配置提升效能。

舉例如下，xml配置為強一致性模型：

<cache name="myCache"  
     maxElementsInMemory="500"  
     eternal="false"  
     overflowToDisk="false"  
   <terracotta clustered="true" consistency="strong" />  
</cache>  

但是使用UnlockedReadsView：

Cache cache = cacheManager.getEhcache("myCache");  
UnlockedReadsView unlockedReadsView = new UnlockedReadsView(cache, "myUnlockedCache");  

3、原子方法（Atomic methods）：方法執行是原子化的，即CAS操作（Compare and Swap）。CAS最終也實現了強一致性的效果，但不同的是，它是採用樂觀鎖而不是悲觀鎖來實現的。在樂觀鎖機制下，更新的操作可能不成功，因為在這過程中可能會有其他執行緒對同一條資料進行變更，那麼在失敗後需要重新執行更新操作。現代的CPU都支援CAS原語了。

cache.putIfAbsent(Element element);  
cache.replace(Element oldOne, Element newOne);  
cache.remove(Element);  

五、快取拓撲型別：

1、獨立快取（Standalone Ehcache）：這樣的快取應用節點都是獨立的，互相不通訊。

2、分散式快取（Distributed Ehcache）：資料儲存在Terracotta的伺服器陣列（Terracotta Server Array，TSA）中，但是最近使用的資料，可以儲存在各個應用節點中。

邏輯視角：

L1快取就在各個應用節點上，而L2快取則放在Cache Server陣列中。

組網視角：

模型儲存視角：

L1級快取是沒有持久化儲存的。另外，從快取資料量上看，server端遠大於應用節點。

3、複製式快取（Replicated Ehcache）：快取資料時同時存放在多個應用節點的，資料複製和失效的事件以同步或者非同步的形式在各個叢集節點間傳播。上述事件到來時，會阻塞寫執行緒的操作。在這種模式下，只有弱一致性模型。

它有如下幾種事件傳播機制：RMI、JGroups、JMS和Cache Server。

RMI模式下，所有節點全部對等：

JGroup模式：可以配置單播或者多播，協議棧和配置都非常靈活。

<cacheManagerPeerProviderFactory  
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"  
properties="connect=UDP(mcast_addr=231.12.21.132;mcast_port=45566;):PING:  
MERGE2:FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK:UNICAST:pbcast.STABLE:FRAG:pbcast.GMS"  
propertySeparator="::"  
/> 

JMS模式：這種模式的核心就是一個訊息佇列，每個應用節點都訂閱預先定義好的主題，同時，節點有元素更新時，也會發布更新元素到主題中去。JMS規範實現者上，Open MQ和Active MQ這兩個，Ehcache的相容性都已經測試過。

Cache Server模式：這種模式下存在主從節點，通訊可以通過RESTful的API或者SOAP。

無論上面哪個模式，更新事件又可以分為updateViaCopy或updateViaInvalidate，後者只是傳送一個過期訊息，效率要高得多。

複製式快取容易出現數據不一致的問題，如果這成為一個問題，可以考慮使用資料同步分發的機制。

即便不採用分散式快取和複製式快取，依然會出現一些不好的行為，比如：

快取漂移（Cache Drift）：每個應用節點只管理自己的快取，在更新某個節點的時候，不會影響到其他的節點，這樣資料之間可能就不同步了。這在web會話資料快取中情況尤甚。

資料庫瓶頸（Database Bottlenecks ）：對於單例項的應用來說，快取可以保護資料庫的讀風暴；但是，在叢集的環境下，每一個應用節點都要定期保持資料最新，節點越多，要維持這樣的情況對資料庫的開銷也越大。

六、儲存方式：

1、堆記憶體儲：速度快，但是容量有限。

2、堆外（OffHeapStore）儲存：被稱為BigMemory，只在企業版本的Ehcache中提供，原理是利用nio的DirectByteBuffers實現，比儲存到磁碟上快，而且完全不受GC的影響，可以保證響應時間的穩定性；但是direct buffer的在分配上的開銷要比heap buffer大，而且要求必須以位元組陣列方式儲存，因此物件必須在儲存過程中進行序列化，讀取則進行反序列化操作，它的速度大約比堆記憶體儲慢一個數量級。

（注：direct buffer不受GC影響，但是direct buffer歸屬的的JAVA物件是在堆上且能夠被GC回收的，一旦它被回收，JVM將釋放direct buffer的堆外空間。）

3、磁碟儲存。

七、快取使用模式：

cache-aside：直接操作。先詢問cache某條快取資料是否存在，存在的話直接從cache中返回資料，繞過SOR；如果不存在，從SOR中取得資料，然後再放入cache中。

public V readSomeData(K key)   
{  
   Element element;  
   if ((element = cache.get(key)) != null) {  
       return element.getValue();  
   }  
   if (value = readDataFromDataStore(key)) != null) {  
       cache.put(new Element(key, value));  
   }   
   return value;  
}  

cache-as-sor：結合了read-through、write-through或write-behind操作，通過給SOR增加了一層代理，對外部應用訪問來說，它不用區別資料是從快取中還是從SOR中取得的。

read-through。

write-through。

write-behind（write-back）：既將寫的過程變為非同步的，又進一步延遲寫入資料的過程。

Copy Cache的兩個模式：CopyOnRead和CopyOnWrite。

CopyOnRead指的是在讀快取資料的請求到達時，如果發現數據已經過期，需要重新從源處獲取，發起的copy element的操作（pull）；

CopyOnWrite則是發生在真實資料寫入快取時，發起的更新其他節點的copy element的操作（push）。

前者適合在不允許多個執行緒訪問同一個element的時候使用，後者則允許你自由控制快取更新通知的時機。

更多push和pull的變化和不同，也可參見這裡。

八、多種配置方式：

包括配置檔案、宣告式配置、程式設計式配置，甚至通過指定構造器的引數來完成配置，配置設計的原則包括：

所有配置要放到一起

快取的配置可以很容易在開發階段、執行時修改

錯誤的配置能夠在程式啟動時發現，在執行時修改出錯則需要丟擲執行時異常

提供預設配置，幾乎所有的配置都是可選的，都有預設值

九、自動資源控制（Automatic Resource Control，ARC）：

它是提供了一種智慧途徑來控制快取，調優效能。特性包括：

記憶體內快取物件大小的控制，避免OOM出現

池化（cache manager級別）的快取大小獲取，避免單獨計算快取大小的消耗

靈活的獨立基於層的大小計算能力，下圖中可以看到，不同層的大小都是可以單獨控制的

可以統計位元組大小、快取條目數和百分比

優化高命中資料的獲取，以提升效能，參見下面對快取資料在不同層之間的流轉的介紹

快取資料的流轉包括了這樣幾種行為：

Flush：快取條目向低層次移動。

Fault：從低層拷貝一個物件到高層。在獲取快取的過程中，某一層發現自己的該快取條目已經失效，就觸發了Fault行為。

Eviction：把快取條目除去。

Expiration：失效狀態。

Pinning：強制快取條目保持在某一層。

下面的圖反映了資料在各個層之間的流轉，也反映了資料的生命週期：

十、監控功能：

監控的拓撲：

每個應用節點部署一個監控探針，通過TCP協議與監控伺服器聯絡，最終將資料提供給富文字客戶端或者監控操作伺服器。

十一、廣域網複製：

快取資料複製方面，Ehcache允許兩個地理位置各異的節點在廣域網下維持資料一致性，同時它提供了這樣幾種方案（注：下面的示例都只繪製了兩個節點的情形，實際可以推廣到N個節點）：

第一種方案：Terracotta Active/Mirror Replication。

這種方案下，服務端包含一個活躍節點，一個備份節點；各個應用節點全部靠該活躍節點提供讀寫服務。這種方式最簡單，管理容易；但是，需要寄希望於理想的網路狀況，伺服器之間和客戶端到伺服器之間都存在走WAN的情況，這樣的方案其實最不穩定。

第二種方案：Transactional Cache Manager Replication。

這種方案下，資料讀取不需要經過WAN，寫入資料時寫入兩份，分別由兩個cache manager處理，一份在本地Server，一份到其他Server去。這種方案下讀的吞吐量較高而且延遲較低；但是需要引入一個XA事務管理器，兩個cache manager寫兩份資料導致寫開銷較大，而且過WAN的寫延遲依然可能導致系統響應的瓶頸。

第三種方案：Messaging based (AMQ) replication。

這種方案下，引入了批量處理和佇列，用以減緩WAN的瓶頸出現，同時，把處理讀請求和複製邏輯從Server Array物理上就剝離開，避免了WAN情況惡化對節點讀取業務的影響。這種方案要較高的吞吐量和較低的延遲，讀/複製的分離保證了可以提供完備的訊息分發保證、衝突處理等特性；但是它較為複雜，而且還需要一個訊息匯流排。

有一些Ehcache特性應用較少或者比較邊緣化，沒有提到，例如對於JMX的支援；還有一些則是有類似的特性和介紹了，例如對於WEB的支援，請參見我這篇關於OSCache的解讀，其中的“web支援”一節有詳細的原理分析。

最後，關於Ehcache的效能比對，下面這張圖來自Ehcache的創始人Greg Luck的blog：

 

put/get上Ehcache要500-1000倍快過Memcached。原因何在？他自己分析道：“In-process caching and asynchronous replication are a clear performance winner”。有關它詳細的內容還是請參閱他的blog吧。

http://blog.csdn.net/huaweitman/article/details/42078901