不要依賴hibernate的二級緩存

版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://eckelcn.blogbus.com/logs/8226879.html

一、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事務發生會滾，緩存的最後更新結果很難預料。這一點會帶來很大的部署成本，甚至得不償失。
結論：不應把hibernate二級緩存作爲優化的主要手段，一般情況下建議不要使用。
原因如下：
1、 由於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匹配，如果不，緩存會被失效。因此查詢緩存的失效控制是以數據表爲粒度的，只要數據表中任何一條記錄發生一點修改，整個表相關的所有查詢緩存就都無效了。因此查詢緩存的命中率可能會很低。
結論：不應把hibernate二級緩存作爲優化的主要手段，一般情況下建議不要使用。
原因如下：
1、 項目上層業務中檢索條件都比較複雜，尤其是涉及多表操作的地方。很少出現重複執行一個排序、分頁、參數一致的查詢，因此命中率很難提高。
2、 查詢緩存必須配合二級緩存一起使用，否則極易出現1+N的情況，否則性能不升反降
3、 使用查詢緩存必須在執行查詢之前顯示調用Query.setCacheable(true)才能激活緩存，這勢必會對已有的hibernate封裝類帶來問題。
總結
詳細分析hibernate的二級緩存和查詢緩存之後，在底層使用通用緩存方案的想法基本上是不可取的。比較好的做法是在高層次中（業務邏輯層面），針對具體的業務邏輯狀況手動使用數據緩存，不僅可以完全控制緩存的生命週期，還可以針對業務具體調整緩存方案提交命中率。Cluster中的緩存同步可以完全交給緩存本身的同步機制來完成。比如開源緩存swarmcache採用invalidate的機制，可以根據用戶指定的策略，在需要的時候向網絡中的其他swarmcache節點發送失效消息，建議採用。