成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

淺析NHibernate緩存管理機制和相關問題

開發 后端
本文將討論的是NHibernate緩存管理機制和相關問題,希望通過本文能對大家了解緩存機制有所幫助。

這里我們將討論的是NHibernate緩存管理機制和相關問題,通過講解數據庫類似的情況,來讓大家對NHibernate緩存有一個更深刻的理解。

緩存管理面臨的主要問題

緩存作為一個數據中心,具備添加、更新、刪除數據的操作,因此跟數據庫類似,會存在事務性、并發情況下數據一致性等問題需要解決

使用緩存比較典型的方式如下面代碼:

  1. Database db = new Database();  
  2. Transaction tx = db.BeginTransaction();  
  3. try 
  4. {  
  5.     //從緩存讀取  
  6.     MyEntity1 entity1 = cache.Get("pk of entity1");   
  7.     //緩存中沒有時從數據庫讀取  
  8.     if (entity1 == null) entity1 = db.Get("pk of entity1");  
  9.       
  10.     //對entity1進行處理  
  11.  
  12.     updated = db.Update(entity1); //entity1的更新保存到數據庫中  
  13.     if (updated) cache.Put(entity1); //數據庫更新成功,則更新緩存  
  14.  
  15.     //事務中的其他處理  
  16.  
  17.     tx.Commit();  
  18. }  
  19. catch 
  20. {  
  21.     tx.Rollback();  
  22.     throw;  

上面的示例代碼,是在一個事務性環境中使用緩存,存在更新操作(非只讀緩存),如果這是一個共享緩存,這樣的使用方式存在很多問題,比如說: 如果事務中的其他處理導致異常,數據庫中對entity1的更新可以被回滾掉,但是cache中的entity1已經被更新了,如果不處理這樣的情況后續從cache中讀出的entity1就是一個不正確的數據

所以,要正確的使用緩存,必須有一個完善的方案,充分考慮事務、并發等狀況,確保數據的正確性、一致性

NHibernate 2個級別的緩存機制

    緩存機制

相對于session來說,一級緩存是私有緩存,二級緩存是共享緩存

session加載實體的搜索順序為: 1. 從一級緩存中查找;2. 從二級緩存中查找;3. 從數據庫查找

一級緩存在事務之間擔當了一個隔離區域的作用,事務內對實體對象的所有新增、修改、刪除,在事務提交之前對其他session是不可見的,事務提交成功之后批量的將這些更新應用到二級緩存中

這樣的2級緩存機制能夠在很大程度上確保數據的正確性(比如前面示例代碼中事務失敗的情況下,就不會將數據更新到二級緩存中,防止了二級緩存出現錯誤的數據),以及防止ReadUncommited等其他一些事務一致性問題

內部實現上,對一級緩存的管理很簡單,所有已加載的實體(以及已經創建proxy但未加載的實體等)都被緩存在持久化上下文(NHibernate.Engine.StatefulPersistenceContext)中

待新增、更新、刪除的實體,使用3個列表緩存起來,事務提交的時候將他們應用到數據庫和二級緩存中(Flush調用或者因為查詢等導致的 NHibernate自動執行的Flush操作也會將他們應用到數據庫,但不會應用到二級緩存中,二級緩存只在事務提交成功之后才更新)

NH1.2中這3個列表維護在SessionImpl中,NH2.0以后添加的新功能特性以及代碼本身的重構動作相當多,這3個列表維護在NHibernate.Engine.ActionQueue中

二級緩存因為是共享緩存,存在并發更新沖突,但又必須保證二級緩存數據的正確性,因此處理機制就復雜得多。下面是詳細的二級緩存處理機制

二級緩存的主要結構

主要接口:

    主要接口

接口職責:

ICache: 統一的緩存存取訪問接口

ICacheProvider: 工廠類、初始化類,用于創建ICache對象,啟動時對cache server或組件進行初始化,退出時對cache server或組件進行必要的退出處理等

處理過程:

1. 配置文件中指定ICacheProvider的實現類

2. SessionFactory啟動時創建ICacheProvider對象,執行ICacheProvider.Start()方法,并為每一個cache region創建一個ICache對象

3. 整個運行過程中,NHibernate可以使用SessionFactory創建的ICache完成緩存的存取操作

4. SessionFactory關閉時調用ICacheProvider.Stop()方法

實體狀態的轉換:

狀態轉換

以memcached為例,實體緩存時的狀態轉換如上圖

#T#

1. CacheEntry表示一個需要存儲到緩存中或者從緩存中返回的對象

CacheEntry中包含拆解后的實體屬性值(DisassembledState,object[]類型,數組中是每個屬性的值)、實體的版本(樂觀鎖時使用)、類型名稱。采用這樣的處理方式,我們定義的domain對象就不需要實現Serializable接口,也可以被序列化存儲到緩存中

對于primitive type的實體屬性,拆解和組裝過程沒有特殊的處理;對于composite component、one-to-one、one-to-many的collection等實體屬性,分解之后在DisassembledState中存放的是owner(即當前被緩存的實體對象)的id值,組裝過程中根據這個id值去取相關的對象設置到這個屬性上(可能從一級緩存、二級緩存,或者數據庫加載,依賴于具體的設置和運行時的狀態)

2. CacheItem用于解決并發更新二級緩存時的數據一致性問題(不考慮這個問題的話,直接將CacheEntry存到緩存中就可以了),主要是對soft lock機制的處理,后面詳細介紹

3. 將CacheItem轉換成DictionaryEntry的處理,是由NHibernate.Caches.Memcache進行的,完全是一個多余的處理

NHibernate使用規則 [完整的類名#id值] 生成cache key,NHibernate.Caches.Memcache會在NHibernate生成的key前面再添加上 [region名稱@](如果類的hbm文件中沒有設置region名稱,默認region為完整的類名,這樣完整類名會在cache key中出現2次)

memcached的key最長只能是250個字符,NHibernate.Caches.Memcache在cache key超過250字符時,取key的hash值作為新的memcached key值,因為這樣會存在hash沖突,所以NHibernate.Caches.Memcache構造一個DictionaryEntry對象(原 key值的MD5作為DictionaryEntry的key值,被緩存的對象作為value),將 DictionaryEntry存到memcached中。從緩存get對象時,NHibernate.Caches.Memcache對返回的 DictionaryEntry的key值再做一次比較,排除掉hash沖突的情況

這樣的方式使用memcached,效率上太浪費了。一不留神,完整的類名就會在緩存數據中出現4次!

基于NHibernate的機制和memcached的特點,可以考慮使用cache region來區分不同的memcached集群,比如說用A、B 2臺服務器作為只讀緩存,region取名為readonly_region;C、D、E 3臺服務器作為讀寫緩存,region取名為readwrite_region

4. 從DictionaryEntry到Memcached Server這段處理由Memcached.ClientLibrary完成,關于Memcached.ClientLibrary的分析,參考memcached client - memcacheddotnet (Memcached.ClientLibrary)

解決并發更新沖突

NHibernate定義了3中緩存策略: 只讀策略(useage="read-only")、非嚴格的讀寫策略(useage="nonstrict-read-write")和讀寫策略(useage="read-write")

處理并發更新的結構

    并發處理

ICacheConcurrencyStrategy聚合了一個ICache對象,NHibernate操作緩存時不是直接使用ICache對象,而是通過ICacheConcurrencyStrategy 完成,這樣確保系統對二級緩存的操作,都是在特定的緩存策略下進行的

ICacheConcurrencyStrategy和ICache接口的語義有差別,ICache純粹是緩存的操作接口,而ICacheConcurrencyStrategy則與實體的狀態變化相關

ICacheConcurrencyStrategy的語義

Evict: 讓緩存項失效

Get, Put, Remove, Clear: 與ICache的相關方法相同,純粹的緩存讀取、存儲等操作

Insert, AfterInsert: 新增實體時的方法,實體新增到數據庫之后會執行Insert方法,事務提交后會執行AfterInsert方法。這些方法中如何處理二級緩存,由具體的緩存策略確定

Update, AfterUpdate: 更新實體時的方法,實體修改update到數據庫之后會執行Update方法,事務提交后會執行AfterUpdate方法。這些方法中如何處理二級緩存,由具體的緩存策略確定

Lock, Release: 這2個方法分別對緩存項進行加鎖、解鎖。語義上,事務中開始更新實體時對緩存項執行Lock方法,事務提交后對緩存項執行Release方法,在這些方法中如何處理二級緩存由具體的緩存策略確定

在前面實體狀態轉換的圖中,CacheEntry到CacheItem的轉換由ICacheConcurrencyStrategy接口完成,CacheItem只被ICacheConcurrencyStrategy使用,NHibernate內部其他需要與緩存交互的地方均使用 CacheEntry和ICacheConcurrencyStrategy接口

ReadOnly策略

運用場景為,數據不會被更新,NHibernate不更新二級緩存的數據。采用只讀策略的實體不能執行update操作,否則會拋出異常,可以執行新增、刪除操作。只讀策略只在實體從數據庫加載后寫到緩存中

UnstrictReadWrite策略

運用場景為,數據會被更新,但頻率不高,并發存儲情況很少

采用該策略的實體,新增時不會操作二級緩存;更新時只是簡單的將二級緩存的數據刪除掉(Update, AfterUpdate方法中都會刪除二級緩存數據),這樣期間或者后續的請求將從數據庫加載數據并重新緩存

因為更新過程沒有對緩存數據使用lock,讀取時也不會進行版本檢查,因此并發存取時無法保證數據的一致性,下面是一個這樣的示例場景:

    示例場景

1, 2: 請求1在事務中執行更新,NH更新數據庫并從二級緩存刪除該數據

3: 某些操作(例如ISession.Evict)導致請求1的一級緩存中該數據失效

4, 5: 請求2從數據庫加載該數據,并放入二級緩存。因為請求2在另外的事務上下文中,因此加載的數據不包含請求1的更新

6: 請求1需要重新加載該數據,因為一級緩存中沒有,因此從二級緩存讀取,結果讀到的將是一份錯誤的數據

ReadWrite策略

運用場景為,數據可能經常并發更新,NHibernate確保ReadCommitted的事務隔離級別,如果數據庫的隔離級別為RepeatableRead,該策略也能基本保證二級緩存滿足RepeatableRead的隔離級別

NHibernate通過使用版本、timestamp檢查、soft lock等機制實現這一目標

soft lock的原理比較簡單,假如事務中需要更新key為839的數據,首先創建一個soft lock對象,用839這個key存到cache中(如果cache中原來已經用839的key緩存了這個數據,也直接用soft lock覆蓋他),然后更新數據庫,完成事務的其他處理,事務提交之后將id為839的實體對象再重新存入cache中。事務期間其他所有從二級緩存讀取 839的請求都將返回soft lock對象,表明二級緩存中這個數據已經被加鎖了,因此轉向數據庫讀取

    數據庫讀取

ReadWriteCache.ILockable為soft lock接口,CacheItem和CacheLock兩個類實現了這個接口

更新數據時的處理步驟

    更新數據

1: 更新操作前先鎖定二級緩存的數據

2,3: 從二級緩存取數據,如果返回的是null或者CacheItem,則新建一個CacheLock并存入二級緩存;如果返回的是一個CacheLock,則表明有另外的事務已經鎖定該值,將并發鎖定計數器增1并更新回二級緩存中

4: 返回lock對象給EntityAction

5, 6, 7: 更新數據庫,完成事務的其他處理,提交事務。ReadWriteCache的Update不做任何處理

8: 事務提交后執行ReadWriteCache的AfterUpdate方法

先從二級緩存讀取CacheLock對象,如果返回null說明鎖已經過期(事務時間太長造成)

如果鎖已經過期,或者返回的CacheLock已經不是加鎖時返回的那個(鎖過期后又被其他線程重新加鎖了),則新建一個CacheLock,設為 unlock狀態放回二級緩存,結束整個更新處理

如果CacheLock為并發鎖狀態,則將CacheLock并發鎖計數器減一,更新回二級緩存,結束整個更新處理

如果不是上面這些情況,則說明期間沒有并發更新,將新的實體狀態更新到二級緩存(鎖自然被解除掉了)

一旦發生并發更新,并發的***一個事務提交之后,NHibernate也不會將實體重新存入二級緩存,此時在二級緩存中存儲的是一個unlock狀態的 CacheLock對象,在這個CacheLock過期以后,實體才可能被重新緩存到二級緩存中。采用這樣的處理方式,是因為并發事務發生時,NHibernate不知道數據庫中哪一個事務先執行、哪一個后執行,為了確保ReadWrite策略的語義,強制這段時間內二級緩存失效

ReadWriteCache的Get方法,除了在二級緩存的數據被鎖定時將返回null之外,還會將緩存項的時間戳與請求線程的事務時間進行比較,也可能返回null,使得請求轉向數據庫查詢,由數據庫保證事務隔離級別

而put方法還會比較實體的版本(使用樂觀鎖的情況)

看源代碼時,Timestamper類是一個時間戳與計數器結合的產物,在時間上精確到毫秒,每毫秒內采用1-4096的一個計數器,增量分配。NHibernate.Caches.MemCache將ReadWriteCache的二級緩存鎖超時時間設置為0xea60000,換算過來就是1分鐘

原文標題:NHibernate的緩存管理機制

鏈接:http://www.cnblogs.com/RicCC/archive/2009/12/28/nhibernate-cache-internals.html

責任編輯:彭凡 來源: 博客園
相關推薦

2022-06-01 16:01:58

MySQL內存管理系統

2010-01-06 10:23:47

.NET Framew

2020-08-18 19:15:44

Redis內存管理

2013-09-29 15:11:46

Linux運維內存管理

2009-07-08 15:10:00

Servlet會話管理

2010-07-23 09:34:48

Python

2010-09-26 13:23:13

JVM內存管理機制

2010-12-10 15:40:58

JVM內存管理

2011-06-29 17:20:20

Qt 內存 QOBJECT

2020-11-08 14:32:01

JavaScript變量內存管理

2016-09-06 22:05:41

HttpCookieWeb

2009-09-23 17:48:00

Hibernate事務

2022-02-28 10:25:17

Python參數傳遞拷貝

2016-10-09 14:41:40

Swift開發ARC

2009-08-03 18:35:51

ASP.NET數據緩存

2009-09-25 12:59:53

Hibernate事務

2021-12-15 06:58:27

Go多版本管理

2019-01-23 17:08:52

Python內存管理RealPython

2010-04-08 15:43:28

Oracle緩沖塊

2011-08-18 13:28:35

Objective-C內存
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 日韩三级电影在线看 | 亚洲一区二区三区在线 | 久久久久久综合 | 亚洲精品视频免费观看 | 欧美日韩国产在线观看 | 国产小网站 | 韩国精品在线观看 | www.色综合 | 一级a性色生活片久久毛片 一级特黄a大片 | 做a视频在线观看 | 亚洲女人天堂成人av在线 | 久久人| 亚洲精品日韩视频 | 亚洲日韩第一页 | 国产欧美日韩在线一区 | 亚洲欧美日韩成人在线 | 国产精品久久久久久久久久久久 | 亚洲精品一区二区三区在线 | 精品国产精品国产偷麻豆 | 成人妇女免费播放久久久 | 黄视频在线网站 | 一区二区高清 | 久久av一区二区 | 韩日一区二区 | 中国一级特黄真人毛片 | 九九综合| 一区二区三区欧美 | 伊人伊人| 日韩三级在线 | 欧美a级网站| 国产免费看 | 免费成人av | 蜜月aⅴ免费一区二区三区 99re在线视频 | 中文字幕 亚洲一区 | 日本在线播放一区二区 | 日韩视频精品 | 亚洲精品视频播放 | 国产一区影院 | 中文字幕一区在线观看视频 | 国产欧美一区二区三区另类精品 | 免费观看av|