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

緩存管理面臨的主要問題

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

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

Database db = new Database();  
Transaction tx = db.BeginTransaction();  
try 
{  
    //從緩存讀取  
    MyEntity1 entity1 = cache.Get("pk of entity1");   
    //緩存中沒有時從數(shù)據(jù)庫讀取  
    if (entity1 == null) entity1 = db.Get("pk of entity1");  
      
    //對entity1進行處理  
 
    updated = db.Update(entity1); //entity1的更新保存到數(shù)據(jù)庫中  
    if (updated) cache.Put(entity1); //數(shù)據(jù)庫更新成功，則更新緩存  
 
    //事務中的其他處理  
 
    tx.Commit();  
}  
catch 
{  
    tx.Rollback();  
    throw;  
} 

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

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

NHibernate 2個級別的緩存機制

   

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

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

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

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

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

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

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

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

二級緩存的主要結構

主要接口:

   

接口職責:

ICache: 統(tǒng)一的緩存存取訪問接口

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

處理過程:

1. 配置文件中指定ICacheProvider的實現(xiàn)類

2. SessionFactory啟動時創(chuàng)建ICacheProvider對象，執(zhí)行ICacheProvider.Start()方法，并為每一個cache region創(chuàng)建一個ICache對象

3. 整個運行過程中，NHibernate可以使用SessionFactory創(chuàng)建的ICache完成緩存的存取操作

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

實體狀態(tài)的轉換:

以memcached為例，實體緩存時的狀態(tài)轉換如上圖

#T#

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

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

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

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

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

NHibernate使用規(guī)則 [完整的類名#id值] 生成cache key，NHibernate.Caches.Memcache會在NHibernate生成的key前面再添加上 [region名稱@]（如果類的hbm文件中沒有設置region名稱，默認region為完整的類名，這樣完整類名會在cache key中出現(xiàn)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，效率上太浪費了。一不留神，完整的類名就會在緩存數(shù)據(jù)中出現(xiàn)4次！

基于NHibernate的機制和memcached的特點，可以考慮使用cache region來區(qū)分不同的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)

解決并發(fā)更新沖突

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

處理并發(fā)更新的結構

   

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

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

ICacheConcurrencyStrategy的語義

Evict: 讓緩存項失效

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

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

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

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

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

ReadOnly策略

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

UnstrictReadWrite策略

運用場景為，數(shù)據(jù)會被更新，但頻率不高，并發(fā)存儲情況很少

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

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

   

1, 2: 請求1在事務中執(zhí)行更新，NH更新數(shù)據(jù)庫并從二級緩存刪除該數(shù)據(jù)

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

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

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

ReadWrite策略

運用場景為，數(shù)據(jù)可能經(jīng)常并發(fā)更新，NHibernate確保ReadCommitted的事務隔離級別，如果數(shù)據(jù)庫的隔離級別為RepeatableRead，該策略也能基本保證二級緩存滿足RepeatableRead的隔離級別

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

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

   

ReadWriteCache.ILockable為soft lock接口，CacheItem和CacheLock兩個類實現(xiàn)了這個接口

更新數(shù)據(jù)時的處理步驟

   

1: 更新操作前先鎖定二級緩存的數(shù)據(jù)

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

4: 返回lock對象給EntityAction

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

8: 事務提交后執(zhí)行ReadWriteCache的AfterUpdate方法

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

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

如果CacheLock為并發(fā)鎖狀態(tài)，則將CacheLock并發(fā)鎖計數(shù)器減一，更新回二級緩存，結束整個更新處理

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

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

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

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

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

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

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