XXXX項(xiàng)目是目前在實(shí)際工作中正在做的事情,該項(xiàng)目是一個(gè)大型系統(tǒng)的內(nèi)容管理內(nèi)核,負(fù)責(zé)最核心的meta data的集中管理,性能有較高的要求,設(shè)計(jì)初期就要求能夠支持cluster。項(xiàng)目使用Hibernate 3.2,針對(duì)開發(fā)過程中對(duì)于各種緩存的不同看法,撰寫了。重點(diǎn)在于澄清一些hibernate的緩存細(xì)節(jié),糾正一些錯(cuò)誤的緩存用法。
一、hibernate的二級(jí)緩存
如果開啟了二級(jí)緩存,hibernate在執(zhí)行任何一次查詢的之后,都會(huì)把得到的結(jié)果集放到緩存中,緩存結(jié)構(gòu)可以看作是一個(gè)hash table,key是數(shù)據(jù)庫記錄的id,value是id對(duì)應(yīng)的pojo對(duì)象。當(dāng)用戶根據(jù)id查詢對(duì)象的時(shí)候(load、iterator方法),會(huì)首先在緩存中查找,如果沒有找到再發(fā)起數(shù)據(jù)庫查詢。但是如果使用hql發(fā)起查詢(find, query方法)則不會(huì)利用二級(jí)緩存,而是直接從數(shù)據(jù)庫獲得數(shù)據(jù),但是它會(huì)把得到的數(shù)據(jù)放到二級(jí)緩存?zhèn)溆。也就是說,基于hql的查詢,對(duì)二級(jí)緩存是只寫不讀的。
針對(duì)二級(jí)緩存的工作原理,采用iterator取代list來提高二級(jí)緩存命中率的想法是不可行的。Iterator的工作方式是根據(jù)檢索條件從數(shù)據(jù)庫中選取所有目標(biāo)數(shù)據(jù)的id,然后用這些id一個(gè)一個(gè)的到二級(jí)緩存里面做檢索,如果找到就直接加載,找不到就向數(shù)據(jù)庫做查詢。因此假如iterator檢索100條數(shù)據(jù)的話,最好情況是100%全部命中,最壞情況是0%命中,執(zhí)行101條sql把所有數(shù)據(jù)選出來。而list雖然不利用緩存,但是它只會(huì)發(fā)起1條sql取得所有數(shù)據(jù)。在合理利用分頁查詢的情況下,list整體效率高于iterator。
二級(jí)緩存的失效機(jī)制由hibernate控制,當(dāng)某條數(shù)據(jù)被修改之后,hibernate會(huì)根據(jù)它的id去做緩存失效操作。基于此機(jī)制,如果數(shù)據(jù)表不是被hibernate獨(dú)占(比如同時(shí)使用JDBC或者ado等),那么二級(jí)緩存無法得到有效控制。
由于hibernate的緩存接口很靈活,cache provider可以方便的切換,因此支持cluster環(huán)境不是大問題,通過使用swarmcache、jboss cache等支持分布式的緩存方案,可以實(shí)現(xiàn)。但是問題在于: 分布式緩存本身成本偏高(比如使用同步復(fù)制模式的jboss cache)
2、 分布式環(huán)境通常對(duì)事務(wù)控制有較高要求,而目前的開源緩存方案對(duì)事務(wù)緩存(transaction cache)支持得不夠好。當(dāng)jta事務(wù)發(fā)生會(huì)滾,緩存的最后更新結(jié)果很難預(yù)料。這一點(diǎn)會(huì)帶來很大的部署成本,甚至得不償失。
結(jié)論:XXXX不應(yīng)把hibernate二級(jí)緩存作為優(yōu)化的主要手段,一般情況下建議不要使用。
原因 XXXX的DAO類大部分是從1.0升級(jí)過來,由于1.0采用的是hibernate 2.1,所以在批量刪除數(shù)據(jù)的時(shí)候采用了native sql的方式。雖然XXXX2.0已經(jīng)完全升級(jí)到hibernate 3.2,支持hibernate原生的批量刪改,但是由于hibernate批量操作的性能不如sql,而且為了兼容1.0的dao類,所以很多地方保留了sql操作。哪些數(shù)據(jù)表是單純被hibernate獨(dú)占無法統(tǒng)計(jì),而且隨著將來業(yè)務(wù)的發(fā)展可能會(huì)有很大變數(shù)。因此不宜采用二級(jí)緩存。
2、 針對(duì)系統(tǒng)業(yè)務(wù)來說,基于id檢索的二級(jí)緩存命中率極為有限,hql被大量采用,二級(jí)緩存對(duì)性能的提升很有限。
3、 hibernate 3.0在做批量修改、批量更新的時(shí)候,是不會(huì)同步更新二級(jí)緩存的,該問題在hibernate 3.2中是否仍然存在尚不確定。