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