咱們究竟何時可使用Ehcache緩存

1、Ehcache是什麼

EhCache是Hibernate的二級緩存技術之一，能夠把查詢出來的數據存儲在內存或者磁盤，節省下次一樣查詢語句再次查詢數據庫，大幅減輕數據庫壓力。

2、Ehcache的使用場景是什麼

一、首先最主要就是頁面緩存。
網站頁面的數據來源很是普遍的，大多數來自不一樣的對象，並且有可能來自不一樣的db，因此給頁面作緩存是一個不錯的主意。

二、經常使用數據的緩存
一些配置信息，如後臺的某些不常常改變的設置均可以緩存起來。

3、Ehcache使用的注意點

一、比較少的更新數據表的狀況
二、對併發要求不是很嚴格的狀況
多臺應用服務器中的緩存是不能進行實時同步的。
三、對一致性要求不高的狀況下
由於Ehcache本地緩存的特性，目前沒法很好的解決不一樣服務器間緩存同步的問題，因此咱們在一致性要求很是高的場合下，儘可能使用Redis、Memcached等集中式緩存。

4、Ehcache在集羣、分佈式的狀況下表現如何

在分佈式狀況下有二種同步方式：
一、RMI組播方式

示例：

<cacheManagerPeerProviderFactory
        class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
        properties="peerDiscovery=automatic, multicastGroupAddress=localhost,
        multicastGroupPort=4446,timeToLive=255"/>

原理：當緩存改變時,ehcache會向組播IP地址和端口號發送RMI UDP組播包。
缺陷：Ehcache的組播作得比較初級,功能只是基本實現(好比簡單的一個HUB,接兩臺單網卡的服務器,互相之間組播同步就沒問題)，對一些複雜的環境(好比多臺服務器,每臺服務器上多地址，尤爲是集羣，存在一個集羣地址帶多個物理機，每臺物理機又帶多個虛擬站的子地址)，就容易出現問題。

二、P2P方式
原理：P2P要求每一個節點的Ehcache都要指向其餘的N-1個節點。

三、JMS消息模式

原理：這種模式的核心就是一個消息隊列，每一個應用節點都訂閱預先定義好的主題，同時，節點有元素更新時，也會發布更新元素到主題中去。各個應用服務器節點經過偵聽MQ獲取到最新的數據，而後分別更新本身的Ehcache緩存，Ehcache默認支持ActiveMQ，咱們也能夠經過自定義組件的方式實現相似Kafka，RabbitMQ。

四、Cache Server模式
原理：這種模式會存在主從節點。

缺陷：緩存容易出現數據不一致的問題，

5、使用Ehcache的瓶頸是什麼

一、緩存漂移（Cache Drift）：每一個應用節點只管理本身的緩存，在更新某個節點的時候，不會影響到其餘的節點，這樣數據之間可能就不一樣步了。

二、數據庫瓶頸（Database Bottlenecks ）：對於單實例的應用來講，緩存能夠保護數據庫的讀風暴；可是，在集羣的環境下，每個應用節點都要按期保持數據最新，節點越多，要維持這樣的狀況對數據庫的開銷也越大。

6、實際工做中如何使用Ehcache

在實際工做中，我更可能是將Ehcache做爲與Redis配合的二級緩存。
第一種方式：

注：
這種方式經過應用服務器的Ehcache定時輪詢Redis緩存服務器更同步更新本地緩存，缺點是由於每臺服務器定時Ehcache的時間不同，那麼不一樣服務器刷新最新緩存的時間也不同，會產生數據不一致問題，對一致性要求不高可使用。

第二種方式：

注：
經過引入了MQ隊列，使每臺應用服務器的Ehcache同步偵聽MQ消息，這樣在必定程度上能夠達到準同步更新數據，經過MQ推送或者拉取的方式，可是由於不一樣服務器之間的網絡速度的緣由，因此也不能徹底達到強一致性。基於此原理使用Zookeeper等分佈式協調通知組件也是如此。

總結：
一、使用二級緩存的好處是減小緩存數據的網絡傳輸開銷，當集中式緩存出現故障的時候，Ehcache等本地緩存依然可以支撐應用程序正常使用，增長了程序的健壯性。另外使用二級緩存策略能夠在必定程度上阻止緩存穿透問題。

二、根據CAP原理咱們能夠知道，若是要使用強一致性緩存（根據自身業務決定），集中式緩存是最佳選擇，如（Redis，Memcached等）。

 

文／小程故事多（簡書做者） 原文連接：http://www.jianshu.com/p/2cd6ad416a5a 著做權歸做者全部，轉載請聯繫做者得到受權，並標註「簡書做者」。