ehcache支援兩種拓撲結構，一種是distributed caching，另一種是replicated caching
distributed caching
一方面：l1是客戶端結點，基於terracotta server array的ehcache集群是由l1和l2共同組成的，它們一起共享應用程式的狀態和資料。l1相當於一級快取，儲存當前應用結點上的「hot-set」資料。l1各結點上資料可能是不一樣的。
另一方面：l2作為二級快取，將儲存所有l1結點上的資料，作為所有快取資料的乙份完整拷貝。在l2上，所有資料會均勻雜湊到mirrorgroup上，從而成為典型的「分布式」快取，同時，每個mirrorgroup會有乙個active結點和0到多個standby(passive)結點，standby結點是active結點的備份，一單active結點當機，standby結點就將自動成為active節點，從而確保乙個mirrorgroup的可靠性，也即所謂的「分割槽容錯性」（partition tolerance） 。
應該說，terracotta server array的拓撲結構在水平伸縮和可靠性上都是非常理想的，但是非常遺憾的是，terracotta server array只在商業版的ehcache中提供，換言之，開源版本的ehcache是無法實現標準意義上的「分布式快取」的。
replicated caching
和distributed cacheing相比，replicated caching並不具有太多的優勢，特別是在scale out方面。replicated caching和應用伺服器集群的session複製非常類似，其作用僅限於確保在集群環境下各應用結點的快取資料保持一致。ehcache的快取複製支援rmi,jms，cache server等多種方式。
初步結論
如果你需要在開源產品範圍內尋找真正的分布式快取，echache可能不是你想要到的，memcached可能是乙個不錯的選擇。當然，限於時間問題，我對ehcache，特別是replicated拓撲結構的caching研究地不是很深入，如果讀者有關於如何基於開源版本的ehcache實現分布式集群的經驗，歡迎指正。
分布式ehcache快取
今天在這裡了記錄一下學習ehcache分布式集群的過程。ehcache的三種最為常用集群方式，分別是 rmi jgroups 以及 jms ehcache的集群，是在每台快取伺服器上都複製儲存相同的內容，而是不是像redis3.0集群一樣，進行分開儲存。當一台服務啟動時，會把其它節點已快取的資料同步...
ehcache分布式快取不是那麼簡單的
系統因為一些原因分成了2部分。其中部分表共用。開始加上分布式快取之後問題開始來了。1 因為其中乙個系統不能支援lazy所以調整結構以提高效能，結果照成2邊實體不一致，當然快取會出問題，可以理解。2 另外開啟查詢快取之後發現通過createsqlquery方式建立query開啟查詢快取查也會有問題。理...
選擇Redis作為分布式快取
高校平台專案中分布式快取使用的是 redis,在以前也曾經使用過 memcached 但使用 memcached 和mysql 配合遇到過一些問題。當然實際中 mysql 是適合海量資料儲存的，然後通過 memcached 將一些常用的資料進行快取，加快訪問速度。似乎是比較完美的，但是隨著資料，訪問...