二级缓存最佳实践用法.md · 云上的开阔者/l2cache

# 最佳实践用法
## `refreshAfterWrite` 策略 和 `@Cacheable(sync=true)`同步
期望：
利用`refreshAfterWrite`的定时刷新特性让缓存项保持可用。但请注意：缓存项只有在被检索时才会真正刷新。
保证在高并发场景下的性能和避免出现缓存击穿的情况。
注：`refreshAfterWrite`要求`Cache`必须是`LoadingCache` ，也就是要自定义`CacheLoader`。
```java
public class CustomCacheLoader implements CacheLoader<Object, Object> {
    @Nullable
    @Override
    public Object load(@NonNull Object key) throws Exception {
        logger.info("[CustomCacheLoader] direct return, key={}, value=null", key);
        return null;
    }
}
```

问题：
原本是想着直接在Cache.get(key)中调用LoadingCache.get(key)来利用`refreshAfterWrite`的特性。
但是验证下来发现由于CustomCacheLoader.load()返回的是null，所以在缓存项过期的场景下获取数据时每次都会再次去执行具体的业务方法加载数据，并put到缓存中。

分析：
该问题的本质，在于CustomCacheLoader.load()直接返回了null，而没有返回具体的业务数据。
也就是只要CustomCacheLoader.load()返回了具体的业务数据就可以利用到`refreshAfterWrite`的特性。
所以可以基于这个点进行突破。（关键在于拿到具体的业务方法method）

方案：
经研究和分析，Cache.get(key, Callable)方法的Callable就是加载数据的业务方法。
所以重写方法 Cache.get(key, Callable)的逻辑，将Callable包装到CacheLoader中，来达到实现不同缓存调用不同的加载数据逻辑的目的。
但是此方案有一个不好的点，其破坏了spring cache `@Cacheable(sync=true)`同步的概念(只有一个线程加载数据，其他线程均阻塞)。
也就是说，原本Cache.get(key, Callable)方法的语义是：同步获取并加载数据。
现在多了一层语义：如果是`refreshAfterWrite` 和 自定义CacheLoader 不为空时，则优先走LoadingCache.get(key)，否则走原本默认的同步逻辑。

结论：
设置 `refreshAfterWrite` 策略 和 设置`@Cacheable`的`sync`同步属性为true，来达到最佳的性能。

1、设置 `refreshAfterWrite` 策略
> 目的：
> 保证高并发场景下的缓存访问性能。
>
> 分析：
> `refreshAfterWrite`策略在缓存过期后不会被回收，当再次访问时才会去刷新缓存，在新值没有加载完毕前，其他的线程访问始终返回旧值
> 
> 注：
> `Caffeine`默认使用异步机制加载缓存数据，可有效防止缓存击穿（防止同一个key或不同key被击穿的场景）。

```yaml
spring:
  application:
    name: study-spring-demo
l2cache:
  config:
    # 是否存储空值，默认true，防止缓存穿透
    allowNullValues: true
    # 缓存类型
    cacheType: composite
    # 组合缓存配置
    composite:
      # 一级缓存类型
      l1CacheType: caffeine
      # 二级缓存类型
      l2CacheType: redis
    # 一级缓存
    caffeine:
      # 是否构建异步Caffeine true 是 false 否
      asyncCache: false
      # 是否自动刷新过期缓存 true 是 false 否
      autoRefreshExpireCache: true
      # 缓存刷新调度线程池的大小
      refreshPoolSize: 1
      # 缓存刷新的频率(秒)
      refreshPeriod: 5
      # 高并发场景下建议使用refreshAfterWrite，在缓存过期后不会被回收，再次访问时会去刷新缓存，在新值没有加载完毕前，其他的线程访问始终返回旧值
      # Caffeine在缓存过期时默认只有一个线程去加载数据，配置了refreshAfterWrite后当大量请求过来时，可以确保其他用户快速获取响应。
      # 创建缓存的默认配置（完全与SpringCache中的Caffeine实现的配置一致）
      # 如果expireAfterWrite和expireAfterAccess同时存在，以expireAfterWrite为准。
      # 推荐用法：refreshAfterWrite 和 @Cacheable(sync=true)
      defaultSpec: initialCapacity=10,maximumSize=200,refreshAfterWrite=30s,recordStats
      # 设置指定缓存名的创建缓存配置(如：userCache为缓存名称)
      specs:
        userCache: initialCapacity=10,maximumSize=200,expireAfterWrite=30s
        userCacheSync: initialCapacity=10,maximumSize=200,refreshAfterWrite=30s,recordStats
    # 二级缓存
    redis:
      # 是否启用缓存Key prefix
      useKeyPrefix: true
      # 缓存Key prefix
      keyPrefix: ""
      # 缓存过期时间(ms)
      expireTime: 30000
      # 缓存最大空闲时间(ms)
      maxIdleTime: 30000
      # 最大缓存数
      maxSize: 200
      # Redisson 的yaml配置文件
      redissonYamlConfig: redisson.yaml
      # 缓存同步策略配置
    cacheSyncPolicy:
      # 策略类型
      type: redis
      # 缓存更新时通知其他节点的topic名称
      topic: l2cache
```

2、设置`@Cacheable`的`sync`同步属性为true
> 目的：
> 设置`sync=true`是为了利用`Caffeine`的异步加载数据特性。
>
> 分析：
> 实际是通过方法 `com.github.benmanes.caffeine.cache.Cache.get(key, Callable)` 在获取数据时指定加载数据的逻辑(具体的业务方法)。
> 
> `Caffeine` 加载数据的方式：
> 1、`Cache.get(key)` ：从缓存中获取数据
>
> 2、`Cache.get(key, Callable)` ：在获取数据时指定加载数据的逻辑，该方法更加灵活，其中`Spring Cache`就是通过设置`sync=true`来走该方法的调用，
> 具体可见方法 `org.springframework.cache.interceptor.CacheAspectSupport.execute()`。不管有没有自动加载功能，都支持get(K, Callable<V>)方法。
> 
> 3、`CacheLoader.load(key)` ：指定加载数据的方式，在调用`get(key)`获取数据时，若数据不存在或已过期则执行`load()`方法加载新值。
>
>

```java
@Service
public class CaffeineCacheService {
    @Cacheable(value = "userCacheSync", key = "#userId", sync = true)
    public User queryUserSync(String userId) {
        return new User(userId, "addr");
    }
}
```

云上的开阔者/l2cache

简介

发行版

贡献者

近期动态

云上的开阔者/l2cache .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

云上的开阔者/l2cache