帮助IT团队快速构建符合jt808协议部标的基于java技术的GPS和视频平台(2379423771@qq.com)

应用层缓存 VS ORM缓存

  最近做一个比较大的电子商务项目,预计每天订单量将在5万多单,客服人员需要频繁的下单、查询订单、操作订单,客人预订完订单后,会立即进入处理流程,为了提高服务质量,要求流水化作业,平均要在40分钟-80分钟内处理完订单。所以订单在创建后,会在短时间内,被频繁的修改和查看。
  由于在项目中ORM层主要是基于Hibernate框架,所以在调优时,很自然的就想到打开Hibernate的二级缓存,以次来减小由于Load 订单大对象时N+1次查询给数据造成的压力,自己做的测试效果也非常好,也顺利通过压力测试。
  但在上线时,性能却并不佳,经过分析业务的操作特点,查找原因有以下几占:,

    1.但由于中台每天在工作当中,频繁的批量分配工单,
   
    因为要批量将订单分配给某一个工作人员处理,在代码当中执行了一个bulkUpdate的操作:
  template.bulkUpdate("update order set owner = ? where id in (?, ?,?)");
   
    这时Hibernate会直接将Order对象的二级缓存清楚掉。
    由于二级缓存,总是被刷掉,再查询时,需要重新从数据库Load,所以二级缓存变相直接起的作用很少。

    2.由于工作人员在处理订单时,每一次查看之后,都有更新操作,在更新之后,订单被清除缓存,下一组人在处理订单时,又得重新LOAD,所以效果并不好。
    3.无论是白盒测试,还是压力测试时,所基于的案例太过于简单,没有更深入的模仿业务操作,对于压力测试的脚本,也很难精确的模拟出真实的流程化的业务操作过程。


    开始想到,直接获得Session,直接使用JDBC来编写更新代码,并在更新后,使用sessionFactory.evict(Order.class, id);来有目标的逐个清除特定的对象,以避免全部清楚缓存。
    但样做,会对DAO层,修改过大。

    由于整个模块最核心的商业对象就是订单,最后决定在Service层对订单开小灶,对订单缓存的单独的定制处理。

    我觉得应用缓存存在以下优点:
      1。速度要快于ORM缓存,
      2。对于缓存的控制权更大,可以直接控制缓存工具的API进行操作,可以避免一些盲目清除的操作。
      3。更灵活的控制缓存中对象的失效,如根据事件来清除缓存,如订单的处理流程结束时,将该订单从缓存中清除掉,
      4。在更新数据库时,不是直接清除缓存,而是更新缓存(尽管这有风险),当业务层抛出异常时,才去清空缓存,避免由于频繁更新,而清空缓存。

    缺点:
     1。订单的更新操作,必须是单点的,只能通过IOrderService提供的接口,进行更新操作,否则数据不一致的风险较大。
     2。有一定的代码工作量
     3。如果不对第三方缓存包,进行一定的封装的话,会直接耦合于第三方的缓存包,不能像Hibernate那样,灵活选择和配置缓存工具。不容易达到ORM缓存最强大的那种透明化和灵活可配置,你可以使用Ehcache, 也可以选Jboss,有钱的话,可以用Tangosol。
     4。对业务层代码有一定的侵入

   

    目前的方案是采用应用层的现代化,同时使用如Proxy模式来提供透明化的设计,

      IOrderService -》  OrderService -》 CacheableOrderService

    通过Spring的Bean配置,一样可以实现透明化的操作。


    结论:
    1。缓存的清空与更新,要尽量精确的去操作受到更新影响的对象,而不是全部搞掉。
      在Hibernate当中,也提供了sessionFactory.evict(class, id)这样细粒度的清空缓存对象的方法。
          sessionFactory.evice(class)的操作,要看这样的操作是否频繁,如果频繁,对于缓存的作用就会大大的折扣。
   2。如果缓存对象过多,对于失效的算法与处理,要与业务对象的特性紧密的联合起来,通过事件来驱动对象的失效。
   3。对于商业对象的缓存,必须要深刻分析对象的生命周期,业务特性。
   4。对于数据不一致的风险,要有足够的认识与预防手段。
   5。合理的估计订单对象的大小,分配足够的内存
   6。如果只使用中心缓存,只能减小数据库的压力,对于网络带宽的压力,还是有的,速度上也远远逊于本地缓存的效果,所以要结合本地缓存+中心缓存的策略方案,即提高速度,避免群集复制时的瓶颈。

posted on 2007-06-02 19:39 Speed 阅读(2747) 评论(4)  编辑  收藏 所属分类: 框架设计J2EE

评论

# re: 应用层缓存 VS ORM缓存 2007-06-02 20:52 CowNew开源团队

我对hibernate不太熟悉,不过我的想法是Hibernate这种“一厢情愿”的进行缓存的方式很不好,不知道Hibernate有没有关闭所有缓存功能的选项。在关键性业务系统中还是由系统本身来进行缓存控制比较好。Hibernate应该只做单纯的ORM的工作,“缓存”不是应该它多管闲事的地方。  回复  更多评论   

# re: 应用层缓存 VS ORM缓存 2007-06-02 21:04 OneEyeWolf

@CowNew开源团队
那你就应当多了解Hibernate一下,再评论,也不迟。

hibernate 当然会提供关闭所有缓存的功能,

hibernate 做的是ORM的功能,CacheProvider是它非常棒的设计思想的一种体现,通过这个接口,可以交由其它的专业Cache来做。

在配置文件当中,也可以灵活配置。

ORM缓存最强大的是它的透明化和灵活可配置,你可以使用Ehcache, 也可以选Jboss,有钱的话,可以用Tangosol。  回复  更多评论   

# re: 应用层缓存 VS ORM缓存 2007-06-02 22:18 CowNew开源团队

我从不怀疑Hibernate有这些强大的功能,但是既然他是一个ORM工具,就应该只做好ORM的分内的工作,不要掺杂太多不属于它职权范围之外的东西。  回复  更多评论   

# re: 应用层缓存 VS ORM缓存 2007-06-04 10:32 yefeng

我一般是用,IBATIS来做DAO的,这样对象的可控型更强一点
对取出来的对象,再做缓存,这样可以分离DAO和CACHE,这样我觉得更加清楚,和更加可控  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

留言簿(15)

随笔分类

值得一看的博客

积分与排名

最新评论

阅读排行榜