SpringBoot 缓存
SpringBoot 缓存
不使用框架工具
Map#computeIfAbsent
方法的逻辑是,key 不存在 value 就执行计算方法,存在则不执行,非常适合做缓存。
Spring Cache
项目采用的方案一般都是以 Spring Cache 为壳子接入多种缓存实现,比如 redis、caffeine,然后统一使用 Spring Cache 的 API,但是,这个 Spring Cache 为了兼容大部分的缓存框架,只提供了非常简单的功能。所以如果你想要更细致的缓存功能,比如到期自动失效,那就得选用别的缓存框架,即在通用性和功能性上做选择。
Spring缓存注解@Cacheable、@CacheEvict、@CachePut使用 - fashflying - 博客园
自动配置类 CacheAutoConfiguration
,只有在不存在 CacheManager
类型的 bean 的时候才生效,所以只要我们注册 CacheManager
类型的 bean,这个自动配置类就不会生效了
redis 有专门的 RedisCacheManager
,caffeine 有 CaffeineCacheManager
@Cacheable
spring cache 学习 —— @Cacheable 使用详解 - 水煮鱼它不香吗 - 博客园
@Cacheable
可以标记在一个方法上,也可以标记在一个类上。当标记在一个方法上时表示该方法是支持缓存的,当标记在一个类上时则表示该类所有的方法都是支持缓存的。对于一个支持缓存的方法,Spring 会在其被调用后将其返回值缓存起来,以保证下次利用同样的参数来执行该方法时可以直接从缓存中获取结果,而不需要再次执行该方法。Spring 在缓存方法的返回值时是以键值对进行缓存的,值就是方法的返回结果,至于键的话,Spring 又支持两种策略,默认策略和自定义策略,这个稍后会进行说明。需要注意的是当一个支持缓存的方法在对象内部被调用时是不会触发缓存功能的。@Cacheable
可以指定三个属性,value、key 和 condition。
@CachePut
在支持 Spring Cache 的环境下,对于使用 @Cacheable
标注的方法,Spring 在每次执行前都会检查 Cache 中是否存在相同 key 的缓存元素,如果存在就不再执行该方法,而是直接从缓存中获取结果进行返回,否则才会执行并将返回结果存入指定的缓存中。@CachePut
也可以声明一个方法支持缓存功能。与 @Cacheable
不同的是使用 @CachePut
标注的方法在执行前不会去检查缓存中是否存在之前执行过的结果,而是每次都会执行该方法,并将执行结果以键值对的形式存入指定的缓存中。
@CachePut
也可以标注在类上和方法上。使用 @CachePut
时我们可以指定的属性跟 @Cacheable
是一样的。
@CacheEvict
@CacheEvict
是用来标注在需要清除缓存元素的方法或类上的。当标记在一个类上时表示其中所有的方法的执行都会触发缓存的清除操作。@CacheEvict
可以指定的属性有 value、key、condition、allEntries 和 beforeInvocation。其中 value、key 和 condition 的语义与@Cacheable 对应的属性类似。即 value 表示清除操作是发生在哪些 Cache 上的(对应 Cache 的名称);key 表示需要清除的是哪个 key,如未指定则会使用默认策略生成的 key;condition 表示清除操作发生的条件。
缓存淘汰算法
真正的缓存之王,Google Guava 只是弟弟 介绍了为什么 Caffeine 的算法比 Guava Cache 要好
常见的缓存淘汰算法有 FIFO,LFU,LRU:
-
FIFO:先进先出,在这种淘汰算法中,先进入缓存的会先被淘汰,会导致命中率很低。
-
LRU:最近最少使用算法,每次访问数据都会将其放在我们的队尾,如果需要淘汰数据,就只需要淘汰队首即可。仍然有个问题,如果有个数据在 1 分钟访问了 1000 次,再后 1 分钟没有访问这个数据,但是有其他的数据访问,就导致了我们这个热点数据被淘汰。
-
LFU:最近最少频率使用,利用额外的空间记录每个数据的使用频率,然后选出频率最低进行淘汰。这样就避免了 LRU 不能处理时间段的问题。
上面三种策略各有利弊,实现的成本也是一个比一个高,同时命中率也是一个比一个好。
缺点:
-
LFU 的局限性 :在 LFU 中只要数据访问模式的概率分布随时间保持不变时,其命中率就能变得非常高(你可以把数据访问模式理解为被访问的数据的分布情况)。比如有部新剧出来了,我们使用 LFU 给他缓存下来,这部新剧在这几天大概访问了几亿次,这个访问频率也在我们的 LFU 中记录了几亿次。但是新剧总会过气的,比如一个月之后这个新剧的前几集其实已经过气了,但是他的访问量的确是太高了,其他的电视剧根本无法淘汰这个新剧,所以在这种模式下是有局限性。
-
LRU 的优点和局限性 :LRU 可以很好的应对突发流量的情况,因为他不需要累计数据频率。但 LRU 通过历史数据来预测未来是局限的,它会认为最后到来的数据是最可能被再次访问的,从而给与它最高的优先级。
Guava Cache 虽然有这么多的功能,但是本质上还是对 LRU 的封装,
W-TinyLFU:一种现代的缓存 。Caffine Cache 就是基于此算法而研发。Caffeine 因使用 Window TinyLfu 回收策略,提供了一个近乎最佳的命中率 。
当数据的访问模式不随时间变化的时候,LFU 的策略能够带来最佳的缓存命中率。然而 LFU 有两个缺点:
-
首先,它需要给每个记录项维护频率信息,每次访问都需要更新,这是个巨大的开销;
-
其次,如果数据访问模式随时间有变,LFU 的频率信息无法随之变化,因此早先频繁访问的记录可能会占据缓存,而后期访问较多的记录则无法被命中。
因此,大多数的缓存设计都是基于 LRU 或者其变种来进行的。相比之下,LRU 并不需要维护昂贵的缓存记录元信息,同时也能够反应随时间变化的数据访问模式。然而,在许多负载之下,LRU 依然需要更多的空间才能做到跟 LFU 一致的缓存命中率。因此,一个“现代”的缓存,应当能够综合两者的长处。
TinyLFU 维护了近期访问记录的频率信息,作为一个过滤器,当新记录来时,只有满足 TinyLFU 要求的记录才可以被插入缓存。如前所述,作为现代的缓存,它需要解决两个挑战:
-
一个是如何避免维护频率信息的高开销;
-
另一个是如何反应随时间变化的访问模式。
首先来看前者,TinyLFU 借助了数据流 Sketching 技术,Count-Min Sketch 显然是解决这个问题的有效手段,它可以用小得多的空间存放频率信息,而保证很低的 False Positive Rate。但考虑到第二个问题,就要复杂许多了,因为我们知道,任何 Sketching 数据结构如果要反应时间变化都是一件困难的事情,在 Bloom Filter 方面,我们可以有 Timing Bloom Filter,但对于 CMSketch 来说,如何做到 Timing CMSketch 就不那么容易了。
TinyLFU 采用了一种基于滑动窗口的时间衰减设计机制,借助于一种简易的 reset 操作:每次添加一条记录到 Sketch 的时候,都会给一个计数器上加 1,当计数器达到一个尺寸 W 的时候,把所有记录的 Sketch 数值都除以 2,该 reset 操作可以起到衰减的作用 。
W-TinyLFU 主要用来解决一些稀疏的突发访问元素。在一些数目很少但突发访问量很大的场景下,TinyLFU 将无法保存这类元素,因为它们无法在给定时间内积累到足够高的频率。因此 W-TinyLFU 就是结合 LFU 和 LRU,前者用来应对大多数场景,而 LRU 用来处理突发流量。
在处理频率记录的方案中,你可能会想到用 hashMap 去存储,每一个 key 对应一个频率值。那如果数据量特别大的时候,是不是这个 hashMap 也会特别大呢。由此可以联想到 Bloom Filter,对于每个 key,用 n 个 byte 每个存储一个标志用来判断 key 是否在集合中。原理就是使用 k 个 hash 函数来将 key 散列成一个整数。
在 W-TinyLFU 中使用 Count-Min Sketch 记录我们的访问频率,而这个也是布隆过滤器的一种变种。如下图所示:

如果需要记录一个值,那我们需要通过多种 Hash 算法对其进行处理 hash,然后在对应的 hash 算法的记录中 +1,为什么需要多种 hash 算法呢?由于这是一个压缩算法必定会出现冲突,比如我们建立一个 byte 的数组,通过计算出每个数据的 hash 的位置。比如张三和李四,他们两有可能 hash 值都是相同,比如都是 1 那 byte[1]
这个位置就会增加相应的频率,张三访问 1 万次,李四访问 1 次那 byte[1] 这个位置就是 1 万零 1,如果取李四的访问评率的时候就会取出是 1 万零 1,但是李四命名只访问了 1 次啊,为了解决这个问题,所以用了多个 hash 算法可以理解为 long[][]
二维数组的一个概念,比如在第一个算法张三和李四冲突了,但是在第二个,第三个中很大的概率不冲突,比如一个算法大概有 1%
的概率冲突,那四个算法一起冲突的概率是 1%
的四次方。通过这个模式我们取李四的访问率的时候取所有算法中,李四访问最低频率的次数。所以他的名字叫 Count-Min Sketch。
常见的缓存框架
Guava Cache
Caffeine
真正的缓存之王,Google Guava 只是弟弟 介绍了为什么 Caffeine 的算法比 Guava Cache 要好
Caffeine 提供基于对象引用的过期方式
Java 中四种引用类型,详情请看《Java 中的四种引用类型》
引用类型 | 被垃圾回收时间 | 用途 | 生存时间 |
---|---|---|---|
强引用 Strong Reference | 从来不会 | 对象的一般状态 | JVM 停止运行时终止 |
软引用 Soft Reference | 在内存不足时 | 对象缓存 | 内存不足时终止 |
弱引用 Weak Reference | 在垃圾回收时 | 对象缓存 | gc 运行后终止 |
虚引用 Phantom Reference | 从来不会 | 可以用虚引用来跟踪对象被垃圾回收器回收的活动,当一个虚引用关联的对象被垃圾收集器回收之前会收到一条系统通知 | JVM 停止运行时终止 |
相当于,Caffeine 将一部分缓存过期的操作交给了 JVM。让 JVM 在垃圾回收的时候,使一部分缓存过期。缓存中保存的对象被回收之后都为 null 了,可不就是缓存失效了。
(十七)、 SpringBoot 集成 Caffeine 实现本地缓存 - 邓维-java - 博客园
Redis
源码分析
https://juejin.cn/post/7066990990715781151
如果被缓存方法的返回值返回的是枚举类型,可能会出现缓存对象无法转换的问题
缓存的 key 一般就是我们的方法参数,我们可以有很多方式来自定义这个 key,比如自定义 @Cacheable
的 key 或者 keyGenerator 属性,
默认情况下,方法的返回值,也就是缓存的目标,变成二进制存储,但是这样不合适,一般情况下,我们会将其格式化为 json 字符串,以方便在多个缓存框架的存放,比如 caffeine 或者 redis
redis 中的写法:Spring Boot Cache配置 序列化成JSON字符串 - 废物大师兄 - 博客园
caffeine:懒得找了,dms 使用 caffeine 将缓存目标字符串化的方式是,自定义一个 CacheWrapper 对象,继承 Cache
,然后使用这个缓存对象,然后 put 方法里,将值 json 串化,在 get 方法里,将其还原为具体的对象。很有意思。
public CacheManager caffeineCacheManager() {
Map<String, Object> cacheConf = (Map)BootProperties.getAllProps().get("cache");
Map<String, Object> caches = (Map)cacheConf.get("names");
final Integer defTtl = (Integer)cacheConf.getOrDefault("ttl", 600);
final Integer defSize = (Integer)cacheConf.getOrDefault("size", 10000);
List<Cache> cacheList = new ArrayList();
if (caches != null) {
Iterator var6 = caches.keySet().iterator();
while(var6.hasNext()) {
String name = (String)var6.next();
Map<String, Object> cacheProp = (Map)caches.get(name);
if (cacheProp != null) {
String javaType = (String)cacheProp.get("javaType");
Integer ttl = (Integer)cacheProp.getOrDefault("ttl", defTtl);
Integer size = (Integer)cacheProp.getOrDefault("size", defSize);
if (javaType == null) {
cacheList.add(new CacheWrapper(this.buildCache(name, size, ttl), (Class)null));
} else {
try {
Class<?> clazz = Class.forName(javaType);
JsonDeserialize jsonDeserialize = (JsonDeserialize)clazz.getAnnotation(JsonDeserialize.class);
if (jsonDeserialize != null && jsonDeserialize.as() != null) {
clazz = jsonDeserialize.as();
}
cacheList.add(new CacheWrapper(this.buildCache(name, size, ttl), clazz));
} catch (ClassNotFoundException var14) {
throw new SystemException("缓存对象类型[" + javaType + "]不存在");
}
}
} else {
cacheList.add(new CacheWrapper(this.buildCache(name, defSize, defTtl), (Class)null));
}
}
}
SimpleCacheManager cacheManager = new SimpleCacheManager() {
protected Cache getMissingCache(String name) {
int size = defSize;
int ttl = defTtl;
if (name.trim().startsWith("{")) {
CacheProps cacheProps = (CacheProps)JsonUtils.fromJson(name, CacheProps.class);
ttl = TypeUtils.castToInt(cacheProps.getTtl(), defTtl);
size = TypeUtils.castToInt(cacheProps.getSize(), defSize);
CacheConfig.log.info(String.format("创建动态缓存[name:%s ,size:%d ,ttl: %d]", name, size, ttl));
Cache cache = CacheConfig.this.new CacheWrapper(CacheConfig.this.buildCache(name, size, ttl), (Class)null);
CacheConfig.this.dynamicCaches.put(name, cache);
return cache;
} else {
CacheConfig.log.info(String.format("自动创建缓存[name:%s ,size:%d, ttl: %d]", name, size, ttl));
return CacheConfig.this.new CacheWrapper(CacheConfig.this.buildCache(name, size, ttl), (Class)null);
}
}
};
cacheManager.setCaches(cacheList);
return cacheManager;
}
private CaffeineCache buildCache(String name, int size, int ttl) {
Caffeine<Object, Object> caffeineBuilder = Caffeine.newBuilder().maximumSize((long)size);
if (ttl > -1) {
caffeineBuilder = caffeineBuilder.expireAfterWrite((long)ttl, TimeUnit.SECONDS);
}
return new CaffeineCache(name, caffeineBuilder.build(), false);
}
private class CacheWrapper implements Cache {
private Cache cache;
private Class javaType;
public CacheWrapper(Cache cache, Class javaType) {
this.cache = cache;
this.javaType = javaType;
}
public String getName() {
return this.cache.getName();
}
public Object getNativeCache() {
return this.cache.getNativeCache();
}
public Cache.ValueWrapper get(Object key) {
Cache.ValueWrapper vw = this.cache.get(key);
if (vw == null) {
return vw;
} else {
Object value = vw.get();
return (Cache.ValueWrapper)(value != null && value instanceof String ? new SimpleValueWrapper(this.toObject((String)value)) : vw);
}
}
public <T> T get(Object key, Class<T> type) {
T value = this.cache.get(key, type);
if (value != null && value instanceof String) {
String json = (String)value;
return this.toObject(json);
} else {
return value;
}
}
public <T> T get(Object key, Callable<T> valueLoader) {
T value = this.cache.get(key, valueLoader);
if (value == null) {
return value;
} else {
String json = (String)value;
return this.toObject(json);
}
}
public void put(Object key, Object value) {
if (value == null) {
this.cache.put(key, value);
} else if (this.javaType == null) {
this.cache.put(key, JSON.toJSONString(value, new SerializerFeature[]{SerializerFeature.WriteClassName, SerializerFeature.IgnoreNonFieldGetter, SerializerFeature.WriteMapNullValue}));
} else {
this.cache.put(key, JSON.toJSONString(value, new SerializerFeature[]{SerializerFeature.IgnoreNonFieldGetter, SerializerFeature.WriteMapNullValue}));
}
}
public void evict(Object key) {
this.cache.evict(key);
}
public void clear() {
this.cache.clear();
}
private Object toObject(String json) {
return this.javaType == null ? JSON.parse(json, new Feature[]{Feature.SupportNonPublicField, Feature.SupportAutoType}) : JSON.parseObject(json, this.javaType, new Feature[]{Feature.SupportNonPublicField});
}
}
实践
手写 LRU 算法:Java 实现 LRU 算法 - 掘金:哈希表 + 双向链表