一、Ehcache是什么
EhCache是Hibernate的二級緩存技術之一，可以把查詢出來的數據存儲在內存或者磁盤，節省下次同樣查詢語句再次查詢數據庫，大幅減輕數據庫壓力。
二、Ehcache的使用場景是什么
1、首先最主要就是頁面緩存。
網站頁面的數據來源非常廣泛的，大多數來自不同的對象，而且有可能來自不同的db，所以給頁面做緩存是一個不錯的主意。
2、常用數據的緩存
一些配置信息，如后台的某些不經常改變的設置都可以緩存起來。
三、Ehcache使用的注意點
1、比較少的更新數據表的情況
2、對並發要求不是很嚴格的情況
多台應用服務器中的緩存是不能進行實時同步的。
3、對一致性要求不高的情況下
因為Ehcache本地緩存的特性，目前無法很好的解決不同服務器間緩存同步的問題，所以我們在一致性要求非常高的場合下，盡量使用Redis、Memcached等集中式緩存。
四、Ehcache在集群、分布式的情況下表現如何
在分布式情況下有二種同步方式：
1、RMI組播方式
示例：
<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" properties="peerDiscovery=automatic, multicastGroupAddress=localhost, multicastGroupPort=4446,timeToLive=255"/>原理：當緩存改變時,ehcache會向組播IP地址和端口號發送RMI UDP組播包。
缺陷：Ehcache的組播做得比較初級,功能只是基本實現(比如簡單的一個HUB,接兩台單網卡的服務器,互相之間組播同步就沒問題)，對一些復雜的環境(比如多台服務器,每台服務器上多地址，尤其是集群，存在一個集群地址帶多個物理機，每台物理機又帶多個虛擬站的子地址)，就容易出現問題。
2、P2P方式
原理：P2P要求每個節點的Ehcache都要指向其他的N-1個節點。
3、JMS消息模式
原理：這種模式的核心就是一個消息隊列，每個應用節點都訂閱預先定義好的主題，同時，節點有元素更新時，也會發布更新元素到主題中去。各個應用服務器節點通過偵聽MQ獲取到最新的數據，然后分別更新自己的Ehcache緩存，Ehcache默認支持ActiveMQ，我們也可以通過自定義組件的方式實現類似Kafka，RabbitMQ。
4、Cache Server模式
原理：這種模式會存在主從節點。
缺陷：緩存容易出現數據不一致的問題，
五、使用Ehcache的瓶頸是什么
1、緩存漂移（Cache Drift）：每個應用節點只管理自己的緩存，在更新某個節點的時候，不會影響到其他的節點，這樣數據之間可能就不同步了。
2、數據庫瓶頸（Database Bottlenecks ）：對於單實例的應用來說，緩存可以保護數據庫的讀風暴；但是，在集群的環境下，每一個應用節點都要定期保持數據最新，節點越多，要維持這樣的情況對數據庫的開銷也越大。
六、實際工作中如何使用Ehcache
在實際工作中，我更多是將Ehcache作為與Redis配合的二級緩存。
第一種方式：
注：
這種方式通過應用服務器的Ehcache定時輪詢Redis緩存服務器更同步更新本地緩存，缺點是因為每台服務器定時Ehcache的時間不一樣，那么不同服務器刷新最新緩存的時間也不一樣，會產生數據不一致問題，對一致性要求不高可以使用。
第二種方式：
注：
通過引入了MQ隊列，使每台應用服務器的Ehcache同步偵聽MQ消息，這樣在一定程度上可以達到准同步更新數據，通過MQ推送或者拉取的方式，但是因為不同服務器之間的網絡速度的原因，所以也不能完全達到強一致性。基於此原理使用Zookeeper等分布式協調通知組件也是如此。
總結：
1、使用二級緩存的好處是減少緩存數據的網絡傳輸開銷，當集中式緩存出現故障的時候，Ehcache等本地緩存依然能夠支撐應用程序正常使用，增加了程序的健壯性。另外使用二級緩存策略可以在一定程度上阻止緩存穿透問題。
2、根據CAP原理我們可以知道，如果要使用強一致性緩存（根據自身業務決定），集中式緩存是最佳選擇，如（Redis，Memcached等）。
原文鏈接：http://www.jianshu.com/p/2cd6ad416a5a
著作權歸作者所有，轉載請聯系作者獲得授權，並標注“簡書作者”。
分布式領域CAP理論，
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取舍。
關系數據庫的ACID模型擁有 高一致性 + 可用性 很難進行分區：
Atomicity原子性：一個事務中所有操作都必須全部完成，要么全部不完成。
Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。
Isolation隔離層. 事務將假定只有它自己在操作數據庫，彼此不知曉。
Durability. 一旦事務完成，就不能返回。
跨數據庫事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支持2PC。因為2PC是反模式，盡量不要使用2PC，使用BASE來回避。
BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性：
Basically Available基本可用。支持分區失敗(e.g. sharding碎片划分數據庫)
Soft state軟狀態 狀態可以有一段時間不同步，異步。
Eventually consistent最終一致，最終數據是一致的就可以了，而不是時時高一致。
BASE思想的主要實現有
1.按功能划分數據庫
2.sharding碎片
BASE思想主要強調基本的可用性，如果你需要High 可用性，也就是純粹的高性能，那么就要以一致性或容錯性為犧牲，BASE思想的方案在性能上還是有潛力可挖的。
現在NoSQL運動豐富了拓展了BASE思想，可按照具體情況定制特別方案，比如忽視一致性，獲得高可用性等等，NOSQL應該有下面兩個流派：
1. Key-Value存儲，如Amaze Dynamo等，可根據CAP三原則靈活選擇不同傾向的數據庫產品。
2. 領域模型 + 分布式緩存 + 存儲 （Qi4j和NoSQL運動），可根據CAP三原則結合自己項目定制靈活的分布式方案，難度高。
這兩者共同點：都是關系數據庫SQL以外的可選方案，邏輯隨着數據分布，任何模型都可以自己持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲可以是異步或同步，取決於對一致性的要求程度。
不同點：NOSQL之類的Key-Value存儲產品是和關系數據庫頭碰頭的產品BOX，可以適合非Java如PHP RUBY等領域，是一種可以拿來就用的產品，而領域模型 + 分布式緩存 + 存儲是一種復雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。
BASE講究soft state,這種狀態是一種非即時性的狀態，是一種無連接，或者說是盡量短連接的狀態，而ACID是講究強的一致性，要求即時性的事務hard state,這是一種完全面向連接的狀態。強的一致性就以犧牲性能和高可用性為代價，目前 JDON的風格是一種符合BASE策略的架構風格。
http://www.jdon.com/37625