您好,登錄后才能下訂單哦!
這篇文章主要介紹“NHibernate緩存管理機(jī)制怎么理解”,在日常操作中,相信很多人在NHibernate緩存管理機(jī)制怎么理解問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”NHibernate緩存管理機(jī)制怎么理解”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
緩存管理面臨的主要問題
緩存作為一個(gè)數(shù)據(jù)中心,具備添加、更新、刪除數(shù)據(jù)的操作,因此跟數(shù)據(jù)庫類似,會存在事務(wù)性、并發(fā)情況下數(shù)據(jù)一致性等問題需要解決
使用緩存比較典型的方式如下面代碼:
Database db = new Database(); Transaction tx = db.BeginTransaction(); try { //從緩存讀取 MyEntity1 entity1 = cache.Get("pk of entity1"); //緩存中沒有時(shí)從數(shù)據(jù)庫讀取 if (entity1 == null) entity1 = db.Get("pk of entity1"); //對entity1進(jìn)行處理 updated = db.Update(entity1); //entity1的更新保存到數(shù)據(jù)庫中 if (updated) cache.Put(entity1); //數(shù)據(jù)庫更新成功,則更新緩存 //事務(wù)中的其他處理 tx.Commit(); } catch { tx.Rollback(); throw; }
上面的示例代碼,是在一個(gè)事務(wù)性環(huán)境中使用緩存,存在更新操作(非只讀緩存),如果這是一個(gè)共享緩存,這樣的使用方式存在很多問題,比如說: 如果事務(wù)中的其他處理導(dǎo)致異常,數(shù)據(jù)庫中對entity1的更新可以被回滾掉,但是cache中的entity1已經(jīng)被更新了,如果不處理這樣的情況后續(xù)從cache中讀出的entity1就是一個(gè)不正確的數(shù)據(jù)
所以,要正確的使用緩存,必須有一個(gè)完善的方案,充分考慮事務(wù)、并發(fā)等狀況,確保數(shù)據(jù)的正確性、一致性
NHibernate 2個(gè)級別的緩存機(jī)制
相對于session來說,一級緩存是私有緩存,二級緩存是共享緩存
session加載實(shí)體的搜索順序?yàn)? 1. 從一級緩存中查找;2. 從二級緩存中查找;3. 從數(shù)據(jù)庫查找
一級緩存在事務(wù)之間擔(dān)當(dāng)了一個(gè)隔離區(qū)域的作用,事務(wù)內(nèi)對實(shí)體對象的所有新增、修改、刪除,在事務(wù)提交之前對其他session是不可見的,事務(wù)提交成功之后批量的將這些更新應(yīng)用到二級緩存中
這樣的2級緩存機(jī)制能夠在很大程度上確保數(shù)據(jù)的正確性(比如前面示例代碼中事務(wù)失敗的情況下,就不會將數(shù)據(jù)更新到二級緩存中,防止了二級緩存出現(xiàn)錯(cuò)誤的數(shù)據(jù)),以及防止ReadUncommited等其他一些事務(wù)一致性問題
內(nèi)部實(shí)現(xiàn)上,對一級緩存的管理很簡單,所有已加載的實(shí)體(以及已經(jīng)創(chuàng)建proxy但未加載的實(shí)體等)都被緩存在持久化上下文(NHibernate.Engine.StatefulPersistenceContext)中
待新增、更新、刪除的實(shí)體,使用3個(gè)列表緩存起來,事務(wù)提交的時(shí)候?qū)⑺麄儜?yīng)用到數(shù)據(jù)庫和二級緩存中(Flush調(diào)用或者因?yàn)椴樵兊葘?dǎo)致的 NHibernate自動(dòng)執(zhí)行的Flush操作也會將他們應(yīng)用到數(shù)據(jù)庫,但不會應(yīng)用到二級緩存中,二級緩存只在事務(wù)提交成功之后才更新)
NH1.2中這3個(gè)列表維護(hù)在SessionImpl中,NH2.0以后添加的新功能特性以及代碼本身的重構(gòu)動(dòng)作相當(dāng)多,這3個(gè)列表維護(hù)在NHibernate.Engine.ActionQueue中
二級緩存因?yàn)槭枪蚕砭彺?,存在并發(fā)更新沖突,但又必須保證二級緩存數(shù)據(jù)的正確性,因此處理機(jī)制就復(fù)雜得多。下面是詳細(xì)的二級緩存處理機(jī)制
二級緩存的主要結(jié)構(gòu)
主要接口:
接口職責(zé):
ICache: 統(tǒng)一的緩存存取訪問接口
ICacheProvider: 工廠類、初始化類,用于創(chuàng)建ICache對象,啟動(dòng)時(shí)對cache server或組件進(jìn)行初始化,退出時(shí)對cache server或組件進(jìn)行必要的退出處理等
處理過程:
1. 配置文件中指定ICacheProvider的實(shí)現(xiàn)類
2. SessionFactory啟動(dòng)時(shí)創(chuàng)建ICacheProvider對象,執(zhí)行ICacheProvider.Start()方法,并為每一個(gè)cache region創(chuàng)建一個(gè)ICache對象
3. 整個(gè)運(yùn)行過程中,NHibernate可以使用SessionFactory創(chuàng)建的ICache完成緩存的存取操作
4. SessionFactory關(guān)閉時(shí)調(diào)用ICacheProvider.Stop()方法
實(shí)體狀態(tài)的轉(zhuǎn)換:
以memcached為例,實(shí)體緩存時(shí)的狀態(tài)轉(zhuǎn)換如上圖
NHibernate2.1新特性之Tuplizers
淺析NHibernate一對一映射的延遲加載
LINQ to SQL與NHibernate橫向?qū)Ρ?/p>
講解Nhibernate與代碼生成
講解NHibernate Session
1. CacheEntry表示一個(gè)需要存儲到緩存中或者從緩存中返回的對象
CacheEntry中包含拆解后的實(shí)體屬性值(DisassembledState,object[]類型,數(shù)組中是每個(gè)屬性的值)、實(shí)體的版本(樂觀鎖時(shí)使用)、類型名稱。采用這樣的處理方式,我們定義的domain對象就不需要實(shí)現(xiàn)Serializable接口,也可以被序列化存儲到緩存中
對于primitive type的實(shí)體屬性,拆解和組裝過程沒有特殊的處理;對于composite component、one-to-one、one-to-many的collection等實(shí)體屬性,分解之后在DisassembledState中存放的是owner(即當(dāng)前被緩存的實(shí)體對象)的id值,組裝過程中根據(jù)這個(gè)id值去取相關(guān)的對象設(shè)置到這個(gè)屬性上(可能從一級緩存、二級緩存,或者數(shù)據(jù)庫加載,依賴于具體的設(shè)置和運(yùn)行時(shí)的狀態(tài))
2. CacheItem用于解決并發(fā)更新二級緩存時(shí)的數(shù)據(jù)一致性問題(不考慮這個(gè)問題的話,直接將CacheEntry存到緩存中就可以了),主要是對soft lock機(jī)制的處理,后面詳細(xì)介紹
3. 將CacheItem轉(zhuǎn)換成DictionaryEntry的處理,是由NHibernate.Caches.Memcache進(jìn)行的,完全是一個(gè)多余的處理
NHibernate使用規(guī)則 [完整的類名#id值] 生成cache key,NHibernate.Caches.Memcache會在NHibernate生成的key前面再添加上 [region名稱@](如果類的hbm文件中沒有設(shè)置region名稱,默認(rèn)region為完整的類名,這樣完整類名會在cache key中出現(xiàn)2次)
memcached的key最長只能是250個(gè)字符,NHibernate.Caches.Memcache在cache key超過250字符時(shí),取key的hash值作為新的memcached key值,因?yàn)檫@樣會存在hash沖突,所以NHibernate.Caches.Memcache構(gòu)造一個(gè)DictionaryEntry對象(原 key值的MD5作為DictionaryEntry的key值,被緩存的對象作為value),將 DictionaryEntry存到memcached中。從緩存get對象時(shí),NHibernate.Caches.Memcache對返回的 DictionaryEntry的key值再做一次比較,排除掉hash沖突的情況
這樣的方式使用memcached,效率上太浪費(fèi)了。一不留神,完整的類名就會在緩存數(shù)據(jù)中出現(xiàn)4次!
基于NHibernate的機(jī)制和memcached的特點(diǎn),可以考慮使用cache region來區(qū)分不同的memcached集群,比如說用A、B 2臺服務(wù)器作為只讀緩存,region取名為readonly_region;C、D、E 3臺服務(wù)器作為讀寫緩存,region取名為readwrite_region
4. 從DictionaryEntry到Memcached Server這段處理由Memcached.ClientLibrary完成,關(guān)于Memcached.ClientLibrary的分析,參考memcached client - memcacheddotnet (Memcached.ClientLibrary)
解決并發(fā)更新沖突
NHibernate定義了3中緩存策略: 只讀策略(useage="read-only")、非嚴(yán)格的讀寫策略(useage="nonstrict-read-write")和讀寫策略(useage="read-write")
處理并發(fā)更新的結(jié)構(gòu)
ICacheConcurrencyStrategy聚合了一個(gè)ICache對象,NHibernate操作緩存時(shí)不是直接使用ICache對象,而是通過ICacheConcurrencyStrategy 完成,這樣確保系統(tǒng)對二級緩存的操作,都是在特定的緩存策略下進(jìn)行的
ICacheConcurrencyStrategy和ICache接口的語義有差別,ICache純粹是緩存的操作接口,而ICacheConcurrencyStrategy則與實(shí)體的狀態(tài)變化相關(guān)
ICacheConcurrencyStrategy的語義
Evict: 讓緩存項(xiàng)失效
Get, Put, Remove, Clear: 與ICache的相關(guān)方法相同,純粹的緩存讀取、存儲等操作
Insert, AfterInsert: 新增實(shí)體時(shí)的方法,實(shí)體新增到數(shù)據(jù)庫之后會執(zhí)行Insert方法,事務(wù)提交后會執(zhí)行AfterInsert方法。這些方法中如何處理二級緩存,由具體的緩存策略確定
Update, AfterUpdate: 更新實(shí)體時(shí)的方法,實(shí)體修改update到數(shù)據(jù)庫之后會執(zhí)行Update方法,事務(wù)提交后會執(zhí)行AfterUpdate方法。這些方法中如何處理二級緩存,由具體的緩存策略確定
Lock, Release: 這2個(gè)方法分別對緩存項(xiàng)進(jìn)行加鎖、解鎖。語義上,事務(wù)中開始更新實(shí)體時(shí)對緩存項(xiàng)執(zhí)行Lock方法,事務(wù)提交后對緩存項(xiàng)執(zhí)行Release方法,在這些方法中如何處理二級緩存由具體的緩存策略確定
在前面實(shí)體狀態(tài)轉(zhuǎn)換的圖中,CacheEntry到CacheItem的轉(zhuǎn)換由ICacheConcurrencyStrategy接口完成,CacheItem只被ICacheConcurrencyStrategy使用,NHibernate內(nèi)部其他需要與緩存交互的地方均使用 CacheEntry和ICacheConcurrencyStrategy接口
ReadOnly策略
運(yùn)用場景為,數(shù)據(jù)不會被更新,NHibernate不更新二級緩存的數(shù)據(jù)。采用只讀策略的實(shí)體不能執(zhí)行update操作,否則會拋出異常,可以執(zhí)行新增、刪除操作。只讀策略只在實(shí)體從數(shù)據(jù)庫加載后寫到緩存中
UnstrictReadWrite策略
運(yùn)用場景為,數(shù)據(jù)會被更新,但頻率不高,并發(fā)存儲情況很少
采用該策略的實(shí)體,新增時(shí)不會操作二級緩存;更新時(shí)只是簡單的將二級緩存的數(shù)據(jù)刪除掉(Update, AfterUpdate方法中都會刪除二級緩存數(shù)據(jù)),這樣期間或者后續(xù)的請求將從數(shù)據(jù)庫加載數(shù)據(jù)并重新緩存
因?yàn)楦逻^程沒有對緩存數(shù)據(jù)使用lock,讀取時(shí)也不會進(jìn)行版本檢查,因此并發(fā)存取時(shí)無法保證數(shù)據(jù)的一致性,下面是一個(gè)這樣的示例場景:
1, 2: 請求1在事務(wù)中執(zhí)行更新,NH更新數(shù)據(jù)庫并從二級緩存刪除該數(shù)據(jù)
3: 某些操作(例如ISession.Evict)導(dǎo)致請求1的一級緩存中該數(shù)據(jù)失效
4, 5: 請求2從數(shù)據(jù)庫加載該數(shù)據(jù),并放入二級緩存。因?yàn)檎埱?在另外的事務(wù)上下文中,因此加載的數(shù)據(jù)不包含請求1的更新
6: 請求1需要重新加載該數(shù)據(jù),因?yàn)橐患壘彺嬷袥]有,因此從二級緩存讀取,結(jié)果讀到的將是一份錯(cuò)誤的數(shù)據(jù)
ReadWrite策略
運(yùn)用場景為,數(shù)據(jù)可能經(jīng)常并發(fā)更新,NHibernate確保ReadCommitted的事務(wù)隔離級別,如果數(shù)據(jù)庫的隔離級別為RepeatableRead,該策略也能基本保證二級緩存滿足RepeatableRead的隔離級別
NHibernate通過使用版本、timestamp檢查、soft lock等機(jī)制實(shí)現(xiàn)這一目標(biāo)
soft lock的原理比較簡單,假如事務(wù)中需要更新key為839的數(shù)據(jù),首先創(chuàng)建一個(gè)soft lock對象,用839這個(gè)key存到cache中(如果cache中原來已經(jīng)用839的key緩存了這個(gè)數(shù)據(jù),也直接用soft lock覆蓋他),然后更新數(shù)據(jù)庫,完成事務(wù)的其他處理,事務(wù)提交之后將id為839的實(shí)體對象再重新存入cache中。事務(wù)期間其他所有從二級緩存讀取 839的請求都將返回soft lock對象,表明二級緩存中這個(gè)數(shù)據(jù)已經(jīng)被加鎖了,因此轉(zhuǎn)向數(shù)據(jù)庫讀取
ReadWriteCache.ILockable為soft lock接口,CacheItem和CacheLock兩個(gè)類實(shí)現(xiàn)了這個(gè)接口
更新數(shù)據(jù)時(shí)的處理步驟
1: 更新操作前先鎖定二級緩存的數(shù)據(jù)
2,3: 從二級緩存取數(shù)據(jù),如果返回的是null或者CacheItem,則新建一個(gè)CacheLock并存入二級緩存;如果返回的是一個(gè)CacheLock,則表明有另外的事務(wù)已經(jīng)鎖定該值,將并發(fā)鎖定計(jì)數(shù)器增1并更新回二級緩存中
4: 返回lock對象給EntityAction
5, 6, 7: 更新數(shù)據(jù)庫,完成事務(wù)的其他處理,提交事務(wù)。ReadWriteCache的Update不做任何處理
8: 事務(wù)提交后執(zhí)行ReadWriteCache的AfterUpdate方法
先從二級緩存讀取CacheLock對象,如果返回null說明鎖已經(jīng)過期(事務(wù)時(shí)間太長造成)
如果鎖已經(jīng)過期,或者返回的CacheLock已經(jīng)不是加鎖時(shí)返回的那個(gè)(鎖過期后又被其他線程重新加鎖了),則新建一個(gè)CacheLock,設(shè)為 unlock狀態(tài)放回二級緩存,結(jié)束整個(gè)更新處理
如果CacheLock為并發(fā)鎖狀態(tài),則將CacheLock并發(fā)鎖計(jì)數(shù)器減一,更新回二級緩存,結(jié)束整個(gè)更新處理
如果不是上面這些情況,則說明期間沒有并發(fā)更新,將新的實(shí)體狀態(tài)更新到二級緩存(鎖自然被解除掉了)
一旦發(fā)生并發(fā)更新,并發(fā)的***一個(gè)事務(wù)提交之后,NHibernate也不會將實(shí)體重新存入二級緩存,此時(shí)在二級緩存中存儲的是一個(gè)unlock狀態(tài)的 CacheLock對象,在這個(gè)CacheLock過期以后,實(shí)體才可能被重新緩存到二級緩存中。采用這樣的處理方式,是因?yàn)椴l(fā)事務(wù)發(fā)生時(shí),NHibernate不知道數(shù)據(jù)庫中哪一個(gè)事務(wù)先執(zhí)行、哪一個(gè)后執(zhí)行,為了確保ReadWrite策略的語義,強(qiáng)制這段時(shí)間內(nèi)二級緩存失效
ReadWriteCache的Get方法,除了在二級緩存的數(shù)據(jù)被鎖定時(shí)將返回null之外,還會將緩存項(xiàng)的時(shí)間戳與請求線程的事務(wù)時(shí)間進(jìn)行比較,也可能返回null,使得請求轉(zhuǎn)向數(shù)據(jù)庫查詢,由數(shù)據(jù)庫保證事務(wù)隔離級別
而put方法還會比較實(shí)體的版本(使用樂觀鎖的情況)
看源代碼時(shí),Timestamper類是一個(gè)時(shí)間戳與計(jì)數(shù)器結(jié)合的產(chǎn)物,在時(shí)間上精確到毫秒,每毫秒內(nèi)采用1-4096的一個(gè)計(jì)數(shù)器,增量分配。NHibernate.Caches.MemCache將ReadWriteCache的二級緩存鎖超時(shí)時(shí)間設(shè)置為0xea60000,換算過來就是1分鐘
到此,關(guān)于“NHibernate緩存管理機(jī)制怎么理解”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。