注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

无线时代辐射无穷

抓紧生宝宝,小心辐射

 
 
 

日志

 
 

Hibernate缓存讨论与研究  

2009-11-10 14:41:01|  分类: cache |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
摘要:很长时间以来,笔者就想写写关于Hibernate缓存的一些文字,今天有这个不可多得的机会让我谈谈对它的一些想法。Hibernate缓存机制对Hibernate的性能发挥一直处于一个极其重要的作用,它是持久层性能提升的关键。对很多学习或使用Hibernate的朋友一来,还不一定真正的了解或使用她。现在大家就随我一起看看揭开她神秘面纱那张未知的“脸”。

个人备注:二级缓存与查询缓存---二级缓存-查询关联的多个对象中,只要有对象被缓存性能就会提高,而查询缓存只有关联的对象都被缓存性能才能提高,不然则和没有使用查询缓存一样的,甚至有可能降低性能。

1:Hibernate缓存概述

    首先在介绍Hibernate缓存之前,笔者在这里做一个小小的比喻,让大家先知道利用缓存的好处。

    这个比喻设计的事物有四个,一个是消费者,一个是该消费者附近的电脑城,一个是联想笔记本,一个是联想公司。笔记本是现在普及的商品,消费者想要去买一台联想笔记本,大家想想看,是去附近的电脑城买得快?还是去联想公司买得快?..当然是在电脑城买得快咯,总不能跑到联想公司去买吧?在这里消费者被比做应用程序,电脑城被比做缓存,联想笔记本被比做数据,联想公司被比做数据库。正像我们比喻的那样,应用程序查找我们需要的数据是从缓存中找得快,还是去数据库找得快?答案应该就不用我讲了吧!

    缓存是介于物理数据源与应用程序之间,是数据库数据在内存中的存放临时copy的容器,是其作用是为了减少应用程序对物理数据源访问的次数,从而提高了应用的运行性能。

    Hibernate在进行读取数据的时候,根据缓存机制在相应的缓存中查询,如果在缓存中找到了需要的数据(我们把这称做“缓存命中”),则就直接把命中的数据作为结果加以利用,避免的了建立数据库查询的性能损耗。说白话点就是,数据放在缓存中,当应用程序还需要他们的时候,就不必再去查数据库了,根据缓存策略从内存中查找速度就会快很多了。

2:Hibernate缓存分类

    Hibernate缓存我们通常分两类,一类称为一级缓存也叫内部缓存,另一类称为二级缓存。Hibernate的这两级缓存都位于持久化层,存放的都是数据库数据的拷贝,那么它们之间的区别是什么呢?为了理解二者的区别,需要深入理解持久化层的缓存的一个特性:缓存的范围。

    缓存的范围决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。

    (1) 事务范围:缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期,当事务结束时,缓存也就结束生命周期。在此范围下,缓存的介质是内存。事务可以是数据库事务或者应用事务,每个事务都有独自的缓存,缓存内的数据通常采用相互关联的的对象形式, 一级缓存就属于事务范围。

    (2) 应用范围:缓存被应用范围内的所有事务共享。这些事务有可能是并发访问缓存,因此必须对缓存采取必要的事务隔离机制。缓存的生命周期依赖于应用的生命周期,应用结束时,缓存也就结束了生命周期,二级缓存存在于应用范围。

    (3) 集群范围:在集群环境中,缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点,进程间通过远程通信来保证缓存中的数据的一致性,缓存中的数据通常采用对象的松散数据形式,二级缓存也存在与应用范围。

    注意:对大多数应用来说,应该慎重地考虑是否需要使用集群范围的缓存,因为访问它的速度不一定会比直接访问数据库数据的速度快多少,再加上集群范围还有数据同步的问题,所以应当慎用。

    持久化层可以提供多种范围的缓存。如果在事务范围的缓存中没有查到相应的数据,还可以到应用范围或集群范围的缓存内查询,如果还是没有查到,那么只有到数据库中查询了。

3:Hibernate缓存运用与管理

    本小节,我们来看看Hibernate的缓存管理,除了我们通常分的两类缓存外,笔者再介绍“查询缓存”,它依赖于二级缓存。
内部缓存:前面我们提到内部缓存是属于事物级缓存,在正常的情况下是由Hibernate自动维护的。当然在特殊的情况下需要我们进行手动维护,Hibernate就提供了以下几种方法供开发者选择:

    (1)Session.evict(XXX)
    将某个特定的对象从内部缓存中清除,上述的XXX 为对象的实例名。使用此方法有两种适用情形,一是在特定的操作(如批量处理),需要及时释放对象占用的内存维持系统的稳定性,笔者的关于批处理的文章中就运用了此方法,有兴趣的朋友可关注IT168“国庆加油站”技术栏目。二是不希望当前Session继续运用此对象的状态变化来同步更新数据库。 (2)Session.clear()
清除缓存中的所有持久化对象。
    二级缓存:在第2节的论述中我们知道,二级缓存涵盖了应用范围与集群范围。这里问题就来了,我们什么情况下要使用二级缓存?如果满足以下条件,则可以将其纳入二级缓存:(1)数据不会被第三放修改

    (2)同一数据系统经常引用
    (3)数据大小在可接受范围之内
    (4)非关键数据,或不会被并发的数据

    Hibernate本身并不提供二级缓存的产品化实现,而是为众多支持Hibernate的第三方缓存组件提供整和接口。笔者这里仅仅介绍现在主流的EHCache,它更具备良好的调度性能。
首先,Hibernate启用二级缓存,需要的在主配置文件hibernate.cfg.xml中配置以下参数(以EHCache为例子,使用Hibernate3

<hibernate-configuration>
<session-factory>
…………
<property name=”hibernate.cache.provider_class”>
org.ehcache.hibernate.Provider
</property>
…………
</session-factory>
</hibernate-configuration>

另外还需要对ehcache.xml进行配置,这是一个单独的xml文件,示例如下:
    ehcache.xml
<defaultCache
maxElementsInMemory="10000"
//缓存中最大允许创建的对象数
eternal="false"
//缓存中对象是否为永久的,如果是,超时设置将被忽略,对象从不过期
timeToIdleSeconds="120"
//缓存数据钝化时间(设置对象在它过期之前的空闲时间)
timeToLiveSeconds="120"
//缓存数据的生存时间(设置对象在它过期之前的生存时间)
overflowToDisk="true"
//内存不足时,是否启用磁盘缓存
/>

然后呢,我们还需要在映射文件中指定的映射实体的缓存同步策略(以下只列出核心配置,以供大家参考):
…………
<class name=”com.tenly.bean.Student”>
<cache usage=”read-write”>
…………
<set name=”classroom”……>
<cache usage=”read-only”>
…………
</set>
</class>
…………

    上面提到read-write、read-only是什么?这就是缓存的同步策略,下面我们来仔细的看看Hibernate提供的几钟缓存策略:

    (1) read-only
    只读。对于不会发生改变的数据,可使用只读型缓存。

    (2)nonstrict-read-write
    不严格可读写缓存。如果应用程序对并发访问下的数据同步要求不是很严格的话,而且数据更新操作频率较低。采用本项,可获得良好的性能。

    (3) read-write
    对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读这类的并发问题.

    (4)transactional(事物型)
    在Hibernate中,事务型缓存必须运行在JTA事务环境中。

查询缓存:我们前面提到查询缓存(Query Cache)依赖二级缓存,这到底是怎么回事呢?我看看二级缓存策略的一般过程:
    (1) Hibernate进行条件查询的时候,总是发出一条select * from XXX where …(XXX为 表名,类似的语句下文统称Select SQL)这样的SQL语句查询数据库,一次获得所有的符合条件的数据对象。

    (2) 把获得的所有数据对象根据ID放入到第二级缓存中。

    (3) 当Hibernate根据ID访问数据对象的时候,首先从内部缓存中查找,如果在内部缓存中查不到就配置二级缓存,从二级缓存中查;如果还查不到,再查询数据库,把结果按照ID放入到缓存。

    (4)添加数据、删除、更新操作时,同时更新二级缓存。这就是Hibernate做批处理的时候效率不高的原因,原来是要维护二级缓存消耗大量时间的缘故。

    我们看到这个过程后,可以明显的发现什么?那就是Hibernate的二级缓存策略是针对ID查询的策略,和对象ID密切相关,那么对于条件查询就怎么适用了。对于这种情况的存在,Hibernate引入了“查询缓存”在一定程度上缓解这个问题。

    那么我们先来看看我们为什么使用查询缓存?首先我们来思考一个问题,假如我们对数据表Student进行查询操作,查找age>20的所有学生信息,然后纳入二级缓存;第二次我们的查询条件变了,查找age>15的所有学生信息,显然第一次查询的结果完全满足第二次查询的条件,但并不是满足条件的全部数据。这样的话,我们就要再做一次查询得到全部数据才行。再想想,如果我们执行的是相同的条件语句,那么是不是可以利用之前的结果集呢?

    Hibernate就是为了解决这个问题的而引入Query Cache的。
    查询缓存策略的一般过程如下:
    (1)Query Cache保存了之前查询的执行过的Select SQL,以及结果集等信息,组成一个Query Key。(2)当再次遇到查询请求的时候,就会根据Query Key 从Query Cache找,找到就返回。但 是两次查询之间,数据表发生数据变动的话,Hibernate就会自动清除Query Cache中对应的Query Key。

    我们从查询缓存的策略中可以看出,Query Cache只是在特定的条件下才会发挥作用,而且要求相当严格:
   (1)完全相同的Select SQL重复执行。
   (2)重复执行期间,Query Key对应的数据表不能有数据变动(比如添、删、改操作)
    为了启用Query Cache,我们需要在hibernate.cfg.xml中进行配置,参考配置如下(只列出核心配置项):
<hibernate-configuration>
<session-factory>
…………
<property name=”hibernate.cache.user_query_cache”>true</property>
…………
</session-factory>
</hibernate-configuration>
应用程序中必须在查询执行之前,将Query.Cacheable设置为true,而且每次都应该这样。比如:
………
Query query=session.createQuery(hql).setInteger(0.15);
query.setCacheable(true);
………

    4:编后语
    关于Hibernate缓存的讨论就告一段落了,在实际开发中,运用好缓存可以让你的系统性能得到良好的提升。可缓存也有它的局限性,什么情况用什么情况不用,都要结合实际情况来考量。如果违背了相关的缓存机制,可能会得到负面效果,所以充分考虑实际情况来灵活运用缓存并发挥它的优势,这是我们需要做得更多的。
  评论这张
 
阅读(379)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017