XXXX项目hibernate与应用缓存方案总结

 XXXX项目缓存方案总结

    XXXX项目是目前在实际工作中正在做的事情，该项目是一个大型系统的内容管理内核，负责最核心的meta data的集中管理，性能有较高的要求，设计初期就要求能够支持cluster。项目使用Hibernate 3.2，针对开发过程中对于各种缓存的不同看法，撰写了。重点在于澄清一些hibernate的缓存细节，纠正一些错误的缓存用法。

一、hibernate的二级缓存 

    针对二级缓存的工作原理，采用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等支持分布式的缓存方案，可以实现。但是问题在于:  分布式缓存本身成本偏高（比如使用同步复制模式的jboss cache） 

结论：XXXX不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。

原因  XXXX的DAO类大部分是从1.0升级过来，由于1.0采用的是hibernate 2.1，所以在批量删除数据的时候采用了native sql的方式。虽然XXXX2.0已经完全升级到hibernate 3.2，支持hibernate原生的批量删改，但是由于hibernate批量操作的性能不如sql，而且为了兼容1.0的dao类，所以很多地方保留了sql操作。哪些数据表是单纯被hibernate独占无法统计，而且随着将来业务的发展可能会有很大变数。因此不宜采用二级缓存。 
3、 hibernate 3.0在做批量修改、批量更新的时候，是不会同步更新二级缓存的，该问题在hibernate 3.2中是否仍然存在尚不确定。