应用层缓存 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。想要透明化,需要有一定的代码工作量,不容易达到ORM缓存最强大的那种透明化和灵活可配置,你可以使用Ehcache, 也可以选Jboss,有钱的话,可以用Tangosol。
3。如果不对第三方缓存包,进行一定的封装的话,会直接耦合于第三方的缓存包,不能像Hibernate那样,灵活选择和配置缓存工具。
4。对业务层代码有一定的侵入
目前的方案是采用应用层的现代化,同时使用如Proxy模式来提供透明化的设计,
IOrderService -》 OrderService -》 CacheableOrderService
通过Spring的Bean配置,一样可以实现透明化的操作。
结论:
1。缓存的清空与更新,要尽量精确的去操作受到更新影响的对象,而不是全部搞掉。
在Hibernate当中,也提供了sessionFactory.evict(class, id)这样细粒度的清空缓存对象的方法。
sessionFactory.evice(class)的操作,要看这样的操作是否频繁,如果频繁,对于缓存的作用就会大大的折扣。
2。如果缓存对象过多,对于失效的算法与处理,要与业务对象的特性紧密的联合起来,通过事件来驱动对象的失效。
3。对于商业对象的缓存,必须要深刻分析对象的生命周期,业务特性。
4。对于数据不一致的风险,要有足够的认识与预防手段。
5。合理的估计订单对象的大小,分配足够的内存
6。如果只使用中心缓存,只能减小数据库的压力,对于网络带宽的压力,还是有的,速度上也远远逊于本地缓存的效果,所以要结合本地缓存+中心缓存的策略方案,即提高速度,避免群集复制时的瓶颈。
上一篇: SOA穿着华丽外衣的苦力
下一篇: JSON字符串