NHibernate的緩存管理機制

1. 首先舉一個比較經典的使用緩存的例子：
   

2. Database db = new Database();
   Transaction tx = db.BeginTransaction();
   try
   {
       //從緩存讀取數據
       MyEntity entity = cache.Get<MyEntity>(entityId); 
       
       //緩存中沒有時從數據庫讀取
       if (entity == null) entity = db.Get<MyEntity>(entityId);
       
       //對entity進行處理
   
       //entity的更新保存到數據庫中
       updated = db.Update(entity); 
       
       //數據庫更新成功，則更新緩存
       if (updated) cache.Put(entity); 
   
       //事務中的其餘處理
   
       
       tx.Commit();
   }
   catch
   {
       tx.Rollback();
       throw;
   }

         上面的示例代碼，是在一個事務性環境中使用緩存，存在更新操做（非只讀緩存），若是這是一個共享緩存，這樣的使用方式存在不少問題，好比說: 若是事務中的其餘處理致使異常，數據庫中對entity的更新能夠被回滾掉，可是cache中的entity已經被更新了，若是不處理這樣的狀況後續從cache中讀出的entity就是一個不正確的數據。因此，正確的使用緩存還須要考慮不少方面，確保數據的正確性、一致性。

3. nhibernate具備兩個級別的緩存機制，一級緩存和二級緩存：

   相對於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中。
   二級緩存由於是共享緩存，存在併發更新衝突，但又必須保證二級緩存數據的正確性，所以處理機制就複雜得多。

4. 二級緩存的主要結構：

   接口職責:
   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()方法

   實體轉換：

   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)

5. 解決併發更新衝突

   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方法還會比較實體的版本(使用樂觀鎖的狀況)