Hibernate 二級緩衝 和 查詢快取

XXXX項目緩衝方案總結

　　XXXX項目是目前在實際工作中正在做的事情，該項目是一個大型系統的內容管理核心，負責最核心的meta data的集中管理，效能有較高的要求，設計初期就要求能夠支援cluster。項目使用Hibernate 3.2，針對開發過程中對於各種緩衝的不同看法，撰寫了本文。重點在于澄清一些hibernate的緩衝細節，糾正一些錯誤的緩衝用法。

　　一、hibernate的二級緩衝

　　如果開啟了二級緩衝，hibernate在執行任何一次查詢的之後，都會把得到的結果集放到緩衝中，緩衝結構可以看作是一個hash table，key是資料庫記錄的id，value是id對應的pojo對象。當使用者根據id查詢對象的時候（load、iterator方法），會首先在緩衝中尋找，如果沒有找到再發起資料庫查詢。但是如果使用hql發起查詢（find, query方法）則不會利用二級緩衝，而是直接從資料庫獲得資料，但是它會把得到的資料放到二級緩衝備用。也就是說，基於hql的查詢，對二級緩衝是唯寫不讀的。

　　針對二級緩衝的工作原理，採用iterator取代list來提高二級快取命中率的想法是不可行的。Iterator的工作方式是根據檢索條件從資料庫中選取所有目標資料的id，然後用這些id一個一個的到二級緩衝裡面做檢索，如果找到就直接載入，找不到就向資料庫做查詢。因此假如 iterator檢索100條資料的話，最好情況是100%全部命中，最壞情況是0%命中，執行101條sql把所有資料選出來。而list雖然不利用緩衝，但是它只會發起1條sql取得所有資料。在合理利用分頁查詢的情況下，list整體效率高於iterator。

　　二級緩衝的失效機制由hibernate控制，當某條資料被修改之後，hibernate會根據它的id去做緩衝失效操作。基於此機制，如果資料表不是被hibernate獨佔（比如同時使用JDBC或者ado等），那麼二級緩衝無法得到有效控制。

　　由於hibernate的緩衝介面很靈活，cache provider可以方便的切換，因此支援cluster環境不是大問題，通過使用swarmcache、jboss cache等支援分布式的緩衝方案，可以實現。但是問題在於:

　　1、 分布式緩衝本身成本偏高（比如使用同步複製模式的jboss cache）

　　2、 分布式環境通常對事務控制有較高要求，而目前的開源緩衝方案對事務緩衝（transaction cache）支援得不夠好。當jta事務發生會滾，緩衝的最後更新結果很難預料。這一點會帶來很大的部署成本，甚至得不償失。

　　結論：XXXX不應把hibernate二級緩衝作為最佳化的主要手段，一般情況下建議不要使用。

　　原因如下：

　　1、 XXXX的DAO類大部分是從1.0升級過來，由於1.0採用的是hibernate 2.1，所以在大量刪除資料的時候採用了native sql的方式。雖然XXXX2.0已經完全升級到hibernate 3.2，支援hibernate原生的批量刪改，但是由於hibernate大量操作的效能不如sql，而且為了相容1.0的dao類，所以很多地方保留了sql操作。哪些資料表是單純被hibernate獨佔無法統計，而且隨著將來業務的發展可能會有很大變數。因此不宜採用二級緩衝。

　　2、 針對系統業務來說，基於id檢索的二級快取命中率極為有限，hql被大量採用，二級緩衝對效能的提升很有限。

　　3、 hibernate 3.0在做批量修改、批次更新的時候，是不會同步更新二級緩衝的，該問題在hibernate 3.2中是否仍然存在尚不確定。

　　二、hibernate的查詢快取

　　查詢快取的實現機制與二級緩衝基本一致，最大的差異在於放入緩衝中的key是查詢的語句，value是查詢之後得到的結果集的id列表。表面看來這樣的方案似乎能解決hql利用緩衝的問題，但是需要注意的是，構成key的是：hql產生的sql、sql的參數、排序、分頁資訊等。也就是說如果你的hql有小小的差異，比如第一條hql取1-50條資料，第二條hql取20-60條資料，那麼hibernate會認為這是兩個完全不同的key，無法重複利用緩衝。因此利用率也不高。

　　另外一個需要注意的問題是，查詢快取和二級緩衝是有關聯關係的，他們不是完全獨立的兩套東西。假如一個查詢條件hql_1，第一次被執行的時候，它會從資料庫取得資料，然後把查詢條件作為key，把返回資料的所有id列表作為value（請注意僅僅是id）放到查詢快取中，同時整個結果集放到 class緩衝（也就是二級緩衝），key是id，value是pojo對象。當你再次執行hql_1，它會從緩衝中得到id列表，然後根據這些列表一個一個的到class緩衝裡面去找pojo對象，如果找不到就向資料庫發起查詢。也就是說，如果二級緩衝配置了逾時時間（或者發獃時間），就有可能出現查詢快取命中了，獲得了id列表，但是class裡面相應的pojo已經因為逾時(或發獃)被失效，hibernate就會根據id清單，一個一個的去向資料庫查詢，有多少個id，就執行多少個sql。該情況將導致效能下降嚴重。

　　查詢快取的失效機制也由hibernate控制，資料進入緩衝時會有一個timestamp，它和資料表的timestamp對應。當 hibernate環境內發生save、update等操作時，會更新被操作資料表的timestamp。使用者在擷取緩衝的時候，一旦命中就會檢查它的 timestamp是否和資料表的timestamp匹配，如果不，緩衝會被失效。因此查詢快取的失效控制是以資料表為粒度的，只要資料表中任何一條記錄發生一點修改，整個表相關的所有查詢快取就都無效了。因此查詢快取的命中率可能會很低。

　　結論：XXXX不應把hibernate二級緩衝作為最佳化的主要手段，一般情況下建議不要使用。

　　原因如下：

　　1、 XXXX的上層業務中檢索條件都比較複雜，尤其是涉及多表操作的地方。很少出現重複執行一個排序、分頁、參數一致的查詢，因此命中率很難提高。

　　2、 查詢快取必須配合二級緩衝一起使用，否則極易出現1+N的情況，否則效能不升反降

　　3、 使用查詢快取必須在執行查詢之前顯示調用Query.setCacheable(true)才能啟用緩衝，這勢必會對已有的hibernate封裝類帶來問題。

　　總結

　　詳細分析hibernate的二級緩衝和查詢快取之後，針對XXXX項目的具體情況做出結論，在底層使用通用緩衝方案的想法基本上是不可取的。比較好的做法是在高層次中（商務邏輯層面），針對具體的商務邏輯狀況手動使用資料緩衝，不僅可以完全控制緩衝的生命週期，還可以針對業務具體調整緩衝方案提交命中率。Cluster中的緩衝同步可以完全交給緩衝本身的同步機制來完成。比如開源緩衝swarmcache採用invalidate的機制，可以根據使用者指定的策略，在需要的時候向網路中的其他swarmcache節點發送失效訊息，這一機制和XXXX1.0中已經採用的MappingCache
的同步方案基本一致。建議採用。

原文連結地址：http://edu.21cn.com/ruankao/g_185_766953-1.htm