java应用层缓存_应用层缓存 VS ORM缓存 - 基于java技术开发符合jt808标准的GPS部标平台（jt808协议、jt809协议、netty框架、springmvc框架) - BlogJa...

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

但样做，会对DAO层，修改过大。

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

我觉得应用缓存存在以下优点：

１。速度要快于ORM缓存，

２。对于缓存的控制权更大，可以直接控制缓存工具的API进行操作，可以避免一些盲目清除的操作。

３。更灵活的控制缓存中对象的失效，如根据事件来清除缓存，如订单的处理流程结束时，将该订单从缓存中清除掉，

４。在更新数据库时，不是直接清除缓存，而是更新缓存(尽管这有风险)，当业务层抛出异常时，才去清空缓存，避免由于频繁更新，而清空缓存。

缺点：

１。订单的更新操作，必须是单点的，只能通过IOrderService提供的接口，进行更新操作，否则数据不一致的风险较大。

２。有一定的代码工作量

３。如果不对第三方缓存包，进行一定的封装的话，会直接耦合于第三方的缓存包，不能像Hibernate那样，灵活选择和配置缓存工具。不容易达到ORM缓存最强大的那种透明化和灵活可配置，你可以使用Ehcache, 也可以选Jboss，有钱的话，可以用Tangosol。

４。对业务层代码有一定的侵入

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

IOrderService －》  OrderService －》 CacheableOrderService

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

结论：

１。缓存的清空与更新，要尽量精确的去操作受到更新影响的对象，而不是全部搞掉。

在Hibernate当中，也提供了sessionFactory.evict(class, id)这样细粒度的清空缓存对象的方法。

sessionFactory.evice(class)的操作，要看这样的操作是否频繁，如果频繁，对于缓存的作用就会大大的折扣。

２。如果缓存对象过多，对于失效的算法与处理，要与业务对象的特性紧密的联合起来，通过事件来驱动对象的失效。

３。对于商业对象的缓存，必须要深刻分析对象的生命周期，业务特性。

４。对于数据不一致的风险，要有足够的认识与预防手段。

５。合理的估计订单对象的大小，分配足够的内存

６。如果只使用中心缓存，只能减小数据库的压力，对于网络带宽的压力，还是有的，速度上也远远逊于本地缓存的效果，所以要结合本地缓存＋中心缓存的策略方案，即提高速度，避免群集复制时的瓶颈。