业务缓存设计

缓存设计"/>

业务缓存设计

  对于优化网站速度，缓存有：CDN，js及静态资源文件缓存。数据库缓存，数据映射层缓存(mybatis)，以及业务层缓存。

  缓存能提高访问速度，但也会造成代码逻辑复杂度的增加。通常缓存对于非实时性的可以选择失效时间，对于实时性要求较高的则最好采用事件式更新。

  使用缓存时，一致性很重要，这样就涉及到不能用类似ehcache这种本地分布式缓存，例：商品服务有两台机子，对数据a都做了缓存，那么当数据a更新时，如何更新商品服务的两台机子中的缓存

 对于CDN的缓存，是让用户就近访问一个缓存cache服务器，通常是用于静态类资源，如图片，静态网页等。

 数据库缓存是数据库自身的缓存，如对于一些查询热点，数据库会将这些结果放入缓存中。

 数据映射层缓存mybatis，有一级缓存和二级缓存。

其中一级缓存是local本地缓存，在应用开启一个SqlSession时，对于重复的查询会缓存，但个人觉得大多业务不会在一个事务中重复查询某个数据。反而如果这个数据由另外一个事务修改并提交，这时当前事务还是看不到已提交的更新。建议关闭一级缓存

mybatis二级缓存是应用级别的，基本上是存储在应用服务器上。每次查询时会先查询二级缓存，没有再查一级缓存，还是没有最终查找数据库。从一级缓存或数据库查询到数据后会将结果集放入二级缓存。由于二级缓存mybaits默认实现是存储在相应服务机子上，会存在缓存不一致问题。

相对于mybatis缓存（一，二级缓存），个人更顷向于在业务层构建缓存，采用集中式缓存。

业务层构建缓存关键在于易用性，性能，一致性。

对于我们这边的业务，我们总结出服务提供方cache的规范，目标在于能够保证性能的情况下，一定程度保证一致性：

1.服务提供者cache约定


  分为：基础块，普通查询块及其它块
  
  基础块：
  根据Id查询的cache块
cache块名称：search+服务业务实体名称+ById，例对于商品PoProduct服务，则cache块名称为:searchPoProductById


  普通查询块:
普通查询块，根据查询so进行查找
cache块名称：search+服务业务实体名称+BySo，例对于商品PoProduct服务，则cache块名称为:searchPoProductBySo


  根据po进行查找的块(特例):
根据poId进行查找
cache块名称：search+服务业务实体名称+ByPoId，例对于商品PoProduct服务，则cache块名称为:searchPoProductByPoId


  其它块


  对于基础块需要做到事件式更新，在创建业务实体时加入缓存，更新业务实体时更新对应实体缓存，删除时删除对应缓存中业务实体。
  普通查询块及根据po进行查找的块，在它们下面的商品发生变动时（含添加，更新，删除）需要清除