EhCache緩存介紹 - 一二級緩存使用 和 mybatis一二級緩存講解

目錄

什麼是Ehcache

項目中使用類圖!

EHCache單體JVM緩存使用流程圖!

redis+EHCache緩存使用流程圖!

springboot整合EHCache代碼地址:https://mp.csdn.net/postedit/101110437

解決db和緩存數據不同步問題!

什麼場景下會發生緩存與db不同步問題!

Ehcache的主要特性

Ehcache使用介紹

Ehcache緩存過期策略

Ehcache的使用場景

Redis和Ehcache緩存的區別

實際工作中使用Ehcache

Ehcache集羣模式

常用集羣模式

RMi集羣模式


什麼是Ehcache

Ehcache是純java寫的開源緩存框架,具有快速、精幹等特點,是Hibernate中默認的CacheProvider。它主要面向通用緩存、Java EE和輕量級容器,具有內存和磁盤存儲、緩存加載器、緩存擴展、緩存異常處理程序。

Ehcache 被廣泛用於在Hibernate、Spring、Cocoon等其他開源系統。

緩存最終的目的是爲減輕服務端壓力,減少網絡傳輸請求。

項目中使用類圖!

EHCache單體JVM緩存使用流程圖!

redis+EHCache緩存使用流程圖!

EhCache作爲一級緩存、redis作爲二級

springboot整合EHCache代碼地址:https://mp.csdn.net/postedit/101110437

解決db和緩存數據不同步問題!

A. 直接重啓服務器(不現實)

B. 主動通知,調用cacheManager.get("需要清除掉的緩存名").coler(); 會清除緩存,再次訪問會首先訪問數據庫再重新進行緩存,

先執行修改或刪除語句,修改成功之後,在主動清理緩存 cacheManager.get("緩存名").coler()

什麼場景下會發生緩存與db不同步問題!

update(修改)或delete(刪除),

先執行修改或刪除語句,修改成功之後,在主動清理緩存 cacheManager.get("緩存名").coler()

問題:改完了再清理緩存,萬一修改失敗呢?

解決:定時JOB健康檢查(對比緩存數據和數據庫已緩存數據是否相同)。

Ehcache的主要特性

1.快速;

2.簡單;

3.多種緩存策略;

4.緩存數據有兩級:內存和磁盤,因此無需擔心容量問題;

5.緩存數據會在虛擬機重啓的過程中寫入磁盤;

6.可以通過 RMI、可插入 API 等方式進行分佈式緩存;

7.具有緩存和緩存管理器的偵聽接口;

8.支持多緩存管理器實例,以及一個實例的多個緩存區域;

9.提供 Hibernate 的緩存實現;

Ehcache使用介紹

Ehcache是用來管理緩存的一個工具,其緩存的數據可以是存放在內存裏面的,也可以是存放在硬盤上的。其核心是CacheManager,一切Ehcache的應用都是從CacheManager開始的。它是用來管理Cache(緩存)的,一個應用可以有多個CacheManager,而一個CacheManager下又可以有多個Cache。Cache內部保存的是一個個的Element,而一個Element中保存的是一個key和value的配對,相當於Map裏面的一個Entry。

Ehcache緩存過期策略

當緩存需要被清理時(比如空間佔用已經接近臨界值了),需要使用某種淘汰算法來決定清理掉哪些數據。常用的淘汰算法有下面幾種:

FIFO:First In First Out,先進先出。判斷被存儲的時間,離目前最遠的數據優先被淘汰。

LRU:Least Recently Used,最近最少使用。判斷最近被使用的時間,目前最遠的數據優先被淘汰。

LFU:Least Frequently Used,最不經常使用。在一段時間內,數據被使用次數最少的,優先被淘汰。

Ehcache的使用場景

使用純java的ehcache作爲本地緩存

Reids 作爲遠程分佈式緩存

解決redis緩存壓力過大,提高緩存速度,以及緩存性能。

Redis和Ehcache緩存的區別

如果是單個應用或者對緩存訪問要求很高的應用,用ehcache。
如果是大型系統,存在緩存共享、分佈式部署、緩存內容很大的,建議用redis。

實際工作中使用Ehcache

我們在項目中使用集中式緩存(Redis或者式Memcached等),通常都是檢查緩存中是否存在

期望值的數據,如果存在直接返回,如果不存在就查詢數據庫讓後在將數據庫緩存,

這個時候如果緩存系統因爲某寫原因宕機,造成服務無法訪問,那麼大的量請求直接穿透到數據庫,最數據庫壓力非常大。

這時候我們讓ehcache作爲二級緩存,當redis服務器宕機後,可以查詢ehcache緩存。

這樣能夠有效的扛住服務器請求壓力。

Ehcache集羣模式

由於 EhCache 是進程中的緩存系統,一旦將應用部署在集羣環境中,每一個節點維護各自的緩存數據,當某個節點對緩存數據進行更新,這些更新的數據無法在其它節點中共享,這不僅會降低節點運行的效率,而且會導致數據不同步的情況發生。例如某個網站採用 A、B 兩個節點作爲集羣部署,當 A 節點的緩存更新後,而 B 節點緩存尚未更新就可能出現用戶在瀏覽頁面的時候,一會是更新後的數據,一會是尚未更新的數據,儘管我們也可以通過 Session Sticky 技術來將用戶鎖定在某個節點上,但對於一些交互性比較強或者是非 Web 方式的系統來說,Session Sticky 顯然不太適合。

常用集羣模式

EhCache從1.7版本開始,支持五種集羣方案,分別是:

Terracotta、RMI、JMS、JGroups、EhCache Server

RMi集羣模式

你如何知道集羣環境中的其他緩存?

• 分佈式傳送的消息是什麼形式?

• 什麼情況需要進行復制?增加(Puts),更新(Updates)或是失效(Expiries)?

• 採用什麼方式進行復制?同步還是異步方式?

1、正確的元素類型:只有可序列化的元素可以進行復制。一些操作,比如移除,只需要元素的鍵值而不用整個元素;在這樣的操作中即使元素不是可序列化的但鍵值是可序列化的也可以被複制。

2、成員發現(Peer Discovery):Ehcache進行集羣的時候有一個cache組的概念。每個cache都是其他cache的一個peer,沒有主cache的存在。成員發現(Peer Discovery)正是用來解決 “你如何知道集羣環境中的其他緩存?” 這個問題的。Ehcache提供了兩種機制用來進行成員發現,即:自動成員發現和手動成員發現。要使用一個內置的成員發現機制要在ehcache的配置文件中指定cacheManagerPeerProviderFactory元素的class屬性爲

net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章