最近做一个比较大的电子商务项目，预计每天订单量将在５万多单，客服人员需要频繁的下单、查询订单、操作订单，客人预订完订单后，会立即进入处理流程，为了提高服务质量，要求流水化作业，平均要在４０分钟－８０分钟内处理完订单。所以订单在创建后，会在短时间内，被频繁的修改和查看。
由于在项目中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提供的接口，进行更新操作，否则数据不一致的风险较大。
２。有一定的代码工作量
３。如果不对第三方缓存包，进行一定的封装的话，会直接耦合于第三方的缓存包，不能像Hibernate那样，灵活选择和配置缓存工具。不容易达到ORM缓存最强大的那种透明化和灵活可配置，你可以使用Ehcache, 也可以选Jboss，有钱的话，可以用Tangosol。
４。对业务层代码有一定的侵入
目前的方案是采用应用层的现代化，同时使用如Proxy模式来提供透明化的设计，
IOrderService －》 OrderService －》 CacheableOrderService
通过Spring的Bean配置，一样可以实现透明化的操作。
结论：
１。缓存的清空与更新，要尽量精确的去操作受到更新影响的对象，而不是全部搞掉。
在Hibernate当中，也提供了sessionFactory.evict(class, id)这样细粒度的清空缓存对象的方法。
sessionFactory.evice(class)的操作，要看这样的操作是否频繁，如果频繁，对于缓存的作用就会大大的折扣。
２。如果缓存对象过多，对于失效的算法与处理，要与业务对象的特性紧密的联合起来，通过事件来驱动对象的失效。
３。对于商业对象的缓存，必须要深刻分析对象的生命周期，业务特性。
４。对于数据不一致的风险，要有足够的认识与预防手段。
５。合理的估计订单对象的大小，分配足够的内存
６。如果只使用中心缓存，只能减小数据库的压力，对于网络带宽的压力，还是有的，速度上也远远逊于本地缓存的效果，所以要结合本地缓存＋中心缓存的策略方案，即提高速度，避免群集复制时的瓶颈。