XXXX項目緩存方案總結
XXXX項目是目前在實(shí)際工作中正在做的事情，該項目是一個(gè)大型系統的內容管理內核，負責最核心的meta data的集中管理，性能有較高的要求，設計初期就要求能夠支持cluster。項目使用hibernate 3.2，針對開(kāi)發(fā)過(guò)程中對于各種緩存的不同看法，撰寫(xiě)了本文。重點(diǎn)在于澄清一些hibernate的緩存細節，糾正一些錯誤的緩存用法。
一、hibernate的二級緩存
如果開(kāi)啟了二級緩存，hibernate在執行任何一次查詢(xún)的之后，都會(huì )把得到的結果集放到緩存中，緩存結構可以看作是一個(gè)hash table，key是數據庫記錄的id，value是id對應的pojo對象。當用戶(hù)根據id查詢(xún)對象的時(shí)候（load、iterator方法），會(huì )首先在緩存中查找，如果沒(méi)有找到再發(fā)起數據庫查詢(xún)。但是如果使用hql發(fā)起查詢(xún)（find, query方法）則不會(huì )利用二級緩存，而是直接從數據庫獲得數據，但是它會(huì )把得到的數據放到二級緩存備用。也就是說(shuō)，基于hql的查詢(xún)，對二級緩存是只寫(xiě)不讀的。
針對二級緩存的工作原理，采用iterator取代list來(lái)提高二級緩存命中率的想法是不可行的。Iterator的工作方式是根據檢索條件從數據庫中選取所有目標數據的id，然后用這些id一個(gè)一個(gè)的到二級緩存里面做檢索，如果找到就直接加載，找不到就向數據庫做查詢(xún)。因此假如iterator檢索100條數據的話(huà)，最好情況是100%全部命中，最壞情況是0%命中，執行101條sql把所有數據選出來(lái)。而list雖然不利用緩存，但是它只會(huì )發(fā)起1條sql取得所有數據。在合理利用分頁(yè)查詢(xún)的情況下，list整體效率高于iterator。
二級緩存的失效機制由hibernate控制，當某條數據被修改之后，hibernate會(huì )根據它的id去做緩存失效操作?；诖藱C制，如果數據表不是被hibernate獨占（比如同時(shí)使用jdbc或者ado等），那么二級緩存無(wú)法得到有效控制。
由于hibernate的緩存接口很靈活，cache provider可以方便的切換，因此支持cluster環(huán)境不是大問(wèn)題，通過(guò)使用swarmcache、jboss cache等支持分布式的緩存方案，可以實(shí)現。但是問(wèn)題在于:
1、 分布式緩存本身成本偏高（比如使用同步復制模式的jboss cache）
2、 分布式環(huán)境通常對事務(wù)控制有較高要求，而目前的開(kāi)源緩存方案對事務(wù)緩存（transaction cache）支持得不夠好。當jta事務(wù)發(fā)生會(huì )滾，緩存的最后更新結果很難預料。這一點(diǎn)會(huì )帶來(lái)很大的部署成本，甚至得不償失。
結論：XXXX不應把hibernate二級緩存作為優(yōu)化的主要手段，一般情況下建議不要使用。
原因如下：
1、 XXXX的DAO類(lèi)大部分是從1.0升級過(guò)來(lái)，由于1.0采用的是hibernate 2.1，所以在批量刪除數據的時(shí)候采用了native sql的方式。雖然XXXX2.0已經(jīng)完全升級到hibernate 3.2，支持hibernate原生的批量刪改，但是由于hibernate批量操作的性能不如sql，而且為了兼容1.0的dao類(lèi)，所以很多地方保留了sql操作。哪些數據表是單純被hibernate獨占無(wú)法統計，而且隨著(zhù)將來(lái)業(yè)務(wù)的發(fā)展可能會(huì )有很大變數。因此不宜采用二級緩存。
2、 針對系統業(yè)務(wù)來(lái)說(shuō)，基于id檢索的二級緩存命中率極為有限，hql被大量采用，二級緩存對性能的提升很有限。
3、 hibernate 3.0在做批量修改、批量更新的時(shí)候，是不會(huì )同步更新二級緩存的，該問(wèn)題在hibernate 3.2中是否仍然存在尚不確定。
二、hibernate的查詢(xún)緩存
查詢(xún)緩存的實(shí)現機制與二級緩存基本一致，最大的差異在于放入緩存中的key是查詢(xún)的語(yǔ)句，value是查詢(xún)之后得到的結果集的id列表。表面看來(lái)這樣的方案似乎能解決hql利用緩存的問(wèn)題，但是需要注意的是，構成key的是：hql生成的sql、sql的參數、排序、分頁(yè)信息等。也就是說(shuō)如果你的hql有小小的差異，比如第一條hql取1-50條數據，第二條hql取20-60條數據，那么hibernate會(huì )認為這是兩個(gè)完全不同的key，無(wú)法重復利用緩存。因此利用率也不高。
另外一個(gè)需要注意的問(wèn)題是，查詢(xún)緩存和二級緩存是有關(guān)聯(lián)關(guān)系的，他們不是完全獨立的兩套東西。假如一個(gè)查詢(xún)條件hql_1，第一次被執行的時(shí)候，它會(huì )從數據庫取得數據，然后把查詢(xún)條件作為key，把返回數據的所有id列表作為value（請注意僅僅是id）放到查詢(xún)緩存中，同時(shí)整個(gè)結果集放到class緩存（也就是二級緩存），key是id，value是pojo對象。當你再次執行hql_1，它會(huì )從緩存中得到id列表，然后根據這些列表一個(gè)一個(gè)的到class緩存里面去找pojo對象，如果找不到就向數據庫發(fā)起查詢(xún)。也就是說(shuō)，如果二級緩存配置了超時(shí)時(shí)間（或者發(fā)呆時(shí)間），就有可能出現查詢(xún)緩存命中了，獲得了id列表，但是class里面相應的pojo已經(jīng)因為超時(shí)(或發(fā)呆)被失效，hibernate就會(huì )根據id清單，一個(gè)一個(gè)的去向數據庫查詢(xún)，有多少個(gè)id，就執行多少個(gè)sql。該情況將導致性能下降嚴重。
查詢(xún)緩存的失效機制也由hibernate控制，數據進(jìn)入緩存時(shí)會(huì )有一個(gè)timestamp，它和數據表的timestamp對應。當hibernate環(huán)境內發(fā)生save、update等操作時(shí)，會(huì )更新被操作數據表的timestamp。用戶(hù)在獲取緩存的時(shí)候，一旦命中就會(huì )檢查它的timestamp是否和數據表的timestamp匹配，如果不，緩存會(huì )被失效。因此查詢(xún)緩存的失效控制是以數據表為粒度的，只要數據表中任何一條記錄發(fā)生一點(diǎn)修改，整個(gè)表相關(guān)的所有查詢(xún)緩存就都無(wú)效了。因此查詢(xún)緩存的命中率可能會(huì )很低。
結論：XXXX不應把hibernate二級緩存作為優(yōu)化的主要手段，一般情況下建議不要使用。
原因如下：
1、 XXXX的上層業(yè)務(wù)中檢索條件都比較復雜，尤其是涉及多表操作的地方。很少出現重復執行一個(gè)排序、分頁(yè)、參數一致的查詢(xún)，因此命中率很難提高。
2、 查詢(xún)緩存必須配合二級緩存一起使用，否則極易出現1+N的情況，否則性能不升反降
3、 使用查詢(xún)緩存必須在執行查詢(xún)之前顯示調用Query.setCacheable(true)才能激活緩存，這勢必會(huì )對已有的hibernate封裝類(lèi)帶來(lái)問(wèn)題。
總結
詳細分析hibernate的二級緩存和查詢(xún)緩存之后，針對XXXX項目的具體情況做出結論，在底層使用通用緩存方案的想法基本上是不可取的。比較好的做法是在高層次中（業(yè)務(wù)邏輯層面），針對具體的業(yè)務(wù)邏輯狀況手動(dòng)使用數據緩存，不僅可以完全控制緩存的生命周期，還可以針對業(yè)務(wù)具體調整緩存方案提交命中率。Cluster中的緩存同步可以完全交給緩存本身的同步機制來(lái)完成。比如開(kāi)源緩存swarmcache采用invalidate的機制，可以根據用戶(hù)指定的策略，在需要的時(shí)候向網(wǎng)絡(luò )中的其他swarmcache節點(diǎn)發(fā)送失效消息，這一機制和XXXX1.0中已經(jīng)采用的MappingCache的同步方案基本一致。建議采用。
