- 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独立的接口是采用异步执行的方式，不会造成大量请求都处于同步处理中）
-
Spring Cache对缓存的生命周期进行管理，由于spring版本迭代较快，出于@Cacheable 注解的便利性，逻辑简单的模块，我们暂时使用的是4.2版本进行管理
Guava Cache VS Spring Cache Manager
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
推荐阅读更多精彩内容
- Spring cache是对缓存使用的抽象，通过它我们可以在不侵入业务代码的基础上让现有代码即刻支持缓存。但是使用...
