Guava Cache VS Spring Cache Manager

详细分析参考 本地缓存1
详细分析参考 本地缓存2

• Spring Cache Manager
  • 问题：同一个Class里面的多个Method使用@Cacheable进行注解，相互调用是无法触发缓存模块
  • 分析： AOP 对同一个@Component 里面的方法，进行调用的时候，直接使用 this 指向方法本身，而不会去解析 @Cacheable 的注解实现功能
  • 影响：使用注解方法没办法将依赖的缓存能力分离来独立使用
• Guava Cache
  • 解决的问题：解决了Spring Data Cache存在的问题
  • 问题：当缓存失效/初次缓存的时候，可能存在没有命中目标，调用原生接口也返回null的时候，会抛出 ExecutionException y异常
  • 解决方案：对返回的对象使用JAVA Optional封装一层保证绝对不会抛出异常/当然异常还是要捕捉一次
• 分析
  • Spring Cache对缓存的生命周期进行管理，由于spring版本迭代较快，出于@Cacheable 注解的便利性，逻辑简单的模块，我们暂时使用的是4.2版本进行管理
    • 4.2 版本的spring cache 存在缓存穿透的问题，此版本只能设置本地缓存expire时间，当失效时间内，有高并发请求访问，缓存无法命中，全部穿透本地缓存直达源数据，这时候如果是数据库作为主数据提供的情况下，恶劣的情况下会影响所有涉及业务
    • 我们解决的办法是使用 tair 做全局缓存，主数据由全局缓存来承载，当缓存穿透的时候轰击 tair 集群，短量的集中轰击 tair 集群，10w并发是可以承载的
    • 4.3+版本的spring cache 提供了 sync方式，当数据expire的时候，并不会马上失效，而是有一个独立的线程或者说是一个accessQueue，独立更新数据，在数据没有更新时，所有请求还是获取旧数据(类似guava的refreshAfterWriter)
  • Guava Cache 可以方便的实现统一缓存管理并且相互依赖，缓存相互依赖的不好之处是缓存有效性不可预计。我们并没有去重写同步为异步，额外管理一套 thread pool是我们不愿意接受的，存在不可预期的问题，并且业务也没有需要我们投入大量的人力成本去设计这块，收益太小。
    • expireAfterWriter -> 避免了缓存穿透的问题，保证了数据的实时性，牺牲的是性能，当数据expire的时候，大量请求过来的时候，只有一个请求会去更新数据，而没有更新完成之前，全部请求会被block（每个线程都要轮询的判断lock状态）
    • refreshAfterWriter -> 避免了block的问题，类似 spring cache 4.3提供的sync方式，问题是数据不能保证完全实时。机制是并非超时时间到就自动刷新，而是需要一次 get 的时候才去refresh，顺序是 get->loading，而get引起的loading是同步执行，如果有大量并发请求的时候，大量的get->loading同步执行，资源使用率和响应时长都会变长（官方建议自己实现定期刷新，这是由于refresh独立的接口是采用异步执行的方式，不会造成大量请求都处于同步处理中）