应用层缓存 VS ORM缓存

 　　最近做一个比较大的电子商务项目，预计每天订单量将在５万多单，客服人员需要频繁的下单、查询订单、操作订单，客人预订完订单后，会立即进入处理流程，为了提高服务质量，要求流水化作业，平均要在４０分钟－８０分钟内处理完订单，对于疑难订单要到第二天，才能处理完。所以订单在创建后，会在短时间内，被频繁的修改和查看。
　　由于在项目中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层对订单开小灶，对订单缓存的单独的定制处理。

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

   　缺点：
   　　１。订单的更新操作，必须是单点的，只能通过IOrderService提供的接口，进行更新操作，否则数据不一致的风险较大。
   　　２。想要透明化，需要有一定的代码工作量,不容易达到ORM缓存最强大的那种透明化和灵活可配置，你可以使用Ehcache, 也可以选Jboss，有钱的话，可以用Tangosol。

   　　３。如果不对第三方缓存包，进行一定的封装的话，会直接耦合于第三方的缓存包，不能像Hibernate那样，灵活选择和配置缓存工具。
   　　４。对业务层代码有一定的侵入

   

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

    　　IOrderService －》  OrderService －》 CacheableOrderService

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

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