缓存使用纪要

一、本地缓存：Caffeine

1、简介

Caffeine是一种高性能、高命中率、内存占用低的本地缓存库，简单来说它是 Guava Cache 的优化加强版，是当下最流行、最佳（最优）缓存框架。

Spring5 即将放弃掉 Guava Cache 作为缓存机制，而改用 Caffeine 作为新的本地 Cache 的组件，这对于 Caffeine 来说是一个很大的肯定。为什么 Spring 会这样做呢？其实在 Caffeine 的Benchmarks[3]里给出了极具说服力的数据，对于读和写的场景，和其他几个缓存工具进行了比较，Caffeine 的性能都表现很突出。

https://zhuanlan.zhihu.com/p/610410926

从上图可以看出Caffine性能远超其他本地缓存框架，所以本地缓存用它准没错~~

Caffeine其性能突出表现得益于采用了W-TinyLFU（LUR和LFU的优点结合）开源的缓存技术，缓存性能接近理论最优，同时借鉴了 Guava Cache 大部分的概念（诸如核心概念Cache、LoadingCache、CacheLoader、CacheBuilder等等，几乎可以保证开发人员从Guava Cache 到Caffeine的无缝切换，Caffeine可谓是站在巨人肩膀上呱呱落地的，并且做到了精益求精。

2、用法

Caffeine借鉴了 Guava Cache 大部分的概念（诸如核心概念Cache、LoadingCache、CacheLoader、CacheBuilder）等等，所以数据加载方式都是一个套路

1）缓存类型

Caffeine提供了多种缓存类型：

从同步、异步的角度来说有

bash 复制代码

#	1、同步加载的缓存：Cache
Cache<Object, Object> cache = Caffeine.newBuilder()
                .maximumSize(10)
                .expireAfterWrite(1, TimeUnit.SECONDS)
                .build();

cache.put("1","张三");
System.out.println(cache.getIfPresent("1"));

#	2、异步加载的缓存：AsnyncCache
AsyncCache<String, User> asyncCache = Caffeine.newBuilder()
    .maximumSize(100)
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .buildAsync();

// 手动提交异步加载任务
CompletableFuture<User> future = asyncCache.get("user1", key -> userDao.getUserAsync(key));
future.thenAccept(user -> System.out.println("异步加载完成：" + user));

从手动加载、自动加载的角度来说有

bash 复制代码

#	1、手动加载的：Cache、AsnyncCache

#	2、自动加载的：LoadingCache、LoadingAsnyncCache
LoadingCache<String, String> dictionaryCache = Caffeine.newBuilder()
                .maximumSize(500)
                .expireAfterWrite(60 * 12, TimeUnit.MINUTES)
                .removalListener(new DictionaryRemovalListener())
                .recordStats()
                .build(new DictionaryLoader());
-- 或者 --
AsyncLoadingCache<String, String> asyncLoadingCache = Caffeine.newBuilder()
        .expireAfterWrite(1, TimeUnit.SECONDS)
        .maximumSize(10)
        .buildAsync(key -> {
            Thread.sleep(1000);
            return new Date().toString();
        });

//异步缓存返回的是CompletableFuture
CompletableFuture<String> future = asyncLoadingCache.get("1");
future.thenAccept(System.out::println);

2）常用的缓存属性

缓存初始容量

initialCapacity ：整数，表示能存储多少个缓存对象。

为什么要设置初始容量呢？

因为如果提前能预估缓存的使用大小，那么可以设置缓存的初始容量，以免缓存不断地进行扩容，致使效率不高。

最大容量

maximumSize ：最大容量，如果缓存中的数据量超过这个数值，Caffeine 会有一个异步线程来专门负责清除缓存，按照指定的清除策略来清除掉多余的缓存

注意，清除多余缓存不会立即执行，需要时间；比如最大容量为3，当添加第4个缓存后立即获取缓存数量可能发现是4，因为此时Caffeine的异步线程还没来得及根据策略清除多余的缓存，等待一段时间再查就变成3了。

最大权重（比较少用）

maximumWeight ：最大权重，可以为存入缓存的每个元素都设置一个权重值，当缓存中所有元素的权重值超过最大权重时，就会触发异步清除。

bash 复制代码

static class Student{
    Integer age;
    String name;
}

Caffeine<String, Student> caffeine = Caffeine.newBuilder()
                .maximumWeight(30)
                .weigher((String key, Student value)-> value.getAge())
                .build();
                
cache.put("one", new Student(12, "one"));
cache.put("two", new Student(18, "two"));
cache.put("three", new Student(1, "three"));
TimeUnit.SECONDS.sleep(10);
System.out.println(cache.estimatedSize());  // 2
System.out.println(cache.getIfPresent("two")); // null

#	如上示例，以缓存对象的age为权重值，并设置最大权重为30
#	当放入缓存对象的age之和超过30时，会执行异步清除(需要时间)
#	应该是依次清除占比最大的，直到低于最大权重值

过期策略

expireAfterAccess: 根据最后一次访问时间和当前时间间隔，超过指定值触发清除，注意：这里访问包括读取和写入

expireAfterWrite: 某个数据在多久没有被更新后，就过期。

refreshAfterWrite: 写操作完成后多久才将数据刷新进缓存中，即通过LoadingCache.refresh(K)进行异步刷新, 如果想覆盖默认的刷新行为, 可以实现CacheLoader.reload(K, V)方法

上面是基于时间实现过期清除的，Cadfeine也提供基于软/弱引用实现过期，但是比较复杂、我没搞懂

清除、更新监听

removalListener: 当缓存中的数据发送更新，或者被清除时，就会触发监听器:

removalListener 方法的参数是一个 RemovalListener 对象，但是可以函数式传参，当数据被更新或者清除时，会给监听器提供三个内容，（键，值，原因）分别对应代码中的三个参数，（键，值）都是更新前，清除前的旧值，这样可以了解到清除的详细了

清除的原因有 5 个，存储在枚举类 RemovalCause 中：
EXPLICIT ：表示显式地调用删除操作，直接将某个数据删除。
REPLACED ：表示某个数据被更新。
EXPIRED ：表示因为生命周期结束（过期时间到了），而被清除。
SIZE ：表示因为缓存空间大小受限，总权重受限，而被清除。
COLLECTED ：英文意思"冷静"，这个不明白。

bash 复制代码

public class CaffeineCacheRemovalListener implements RemovalListener<Object, Object> {
    @Override
    public void onRemoval(@Nullable Object k, @Nullable Object v, @NonNull RemovalCause cause) {
        log.info("[移除缓存] key:{} reason:{}", k, cause.name());
        // 超出最大缓存
        if (cause == RemovalCause.SIZE) {

        }
        // 超出过期时间
        if (cause == RemovalCause.EXPIRED) {
            // do something
        }
        // 显式移除
        if (cause == RemovalCause.EXPLICIT) {
            // do something
        }
        // 旧数据被更新
        if (cause == RemovalCause.REPLACED) {
            // do something
        }
    }
}

缓存状态与统计

默认情况下，缓存的状态会用一个 CacheStats 对象记录下来，通过访问 CacheStats 对象就可以知道当前缓存的各种状态指标，指标如下所示：
totalLoadTime ：总共加载时间。
loadFailureRate ：加载失败率，= 总共加载失败次数 / 总共加载次数
averageLoadPenalty ：平均加载时间，单位-纳秒
evictionCount ：被淘汰出缓存的数据总个数
evictionWeight ：被淘汰出缓存的那些数据的总权重
hitCount ：命中缓存的次数
hitRate ：命中缓存率
loadCount ：加载次数
loadFailureCount ：加载失败次数
loadSuccessCount ：加载成功次数
missCount ：未命中次数
missRate ：未命中率
requestCount ：用户请求查询总次数

3、实例

思路：

1）如果是mvc架构，就直接定义一个共用的util或者配置类加载缓存即可；

2）如果是ddd设计模式，建议直接在基础层新建一个配置类，配置类加载的时候初始化；

然后在repo调用这个缓存配置类对外暴露的查询方法获取缓存；

不同领域的app层的ervice调用repo获取缓存、使用。

bash 复制代码

@Component
@Slf4j
public class DictionaryCache {
	//	定义默认值，用于兜底
    private static final Map<String, String> defaultDictionaryMap = new HashMap<>(10);

    static {
        defaultDictionaryMap.put(CommonConstants.Dictionary.KEY_ELECTRICITY_ACTP, CommonConstants.Dictionary.VAL_ELECTRICITY_ACTP);
        defaultDictionaryMap.put(CommonConstants.Dictionary.KEY_NO_ACTP_MONIT_TIME, CommonConstants.Dictionary.VAL_NO_ACTP_MONIT_TIME);
    }

	//	定义缓存
    LoadingCache<String, String> dictionaryCache;

	//	注入查询实例，例如dao、delegate等
    @Resource
    private SystemDelegate systemDelegate;

	//	初始化
    @PostConstruct
    public void init() {
        dictionaryCache = Caffeine.newBuilder()
                .maximumSize(500)	//	容量
                .expireAfterWrite(12 * 60, TimeUnit.MINUTES)	//	过期时间
                .removalListener(new DictionaryRemovalListener())	//	清楚or更新监听
                .recordStats()	//	统计
                .build(new DictionaryLoader());
    }

	//	加载
    class DictionaryLoader implements CacheLoader<String, String> {
        @Override
        public String load(@NotNull String dicCode) {
            try {
                DictionaryQuery query = new DictionaryQuery();
                query.setDicParentCode("dic_type");
                List<SysDictionary> dictionaryList = systemDelegate.getDictionaryList(query);
                if(dictionaryList.isEmpty()) {
                    //  查询字典失败处理
                    log.error("dic list is empty, use default val");
                    return StringUtils.isBlank(defaultDictionaryMap.get(dicCode)) ? null : defaultDictionaryMap.get(dicCode);
                }
                List<SysDictionary> resultList = dictionaryList.stream().filter(obj -> dicCode.equals(obj.getDicCode())).collect(Collectors.toList());
                if(resultList.isEmpty()) {
                    //  字典不存在处理
                    log.error("dicCode does not match value, use default val");
                    return StringUtils.isBlank(defaultDictionaryMap.get(dicCode)) ? null : defaultDictionaryMap.get(dicCode);
                }
                return resultList.get(0).getDicExtValue1();
            } catch (Exception e) {
                log.error("load system dictionary from systemDelegate error, dicCode:{}, e:{}", dicCode, e.getMessage());
                return StringUtils.isBlank(defaultDictionaryMap.get(dicCode)) ? null : defaultDictionaryMap.get(dicCode);
            }
        }
    }

	//	清除or更新监听实现
    class DictionaryRemovalListener implements RemovalListener<Object, Object> {
        @Override
        public void onRemoval(@Nullable Object key, @Nullable Object val, @NonNull RemovalCause cause) {
        	//	可以打印要更新的缓存key，更新的原因
            log.info("DictionaryCache remove cache, key:{}, reason:{}", key, cause.name());
            //	可以顺带打印缓存的各种状态统计指标
            log.info("DictionaryCache hitCount:{}, hitRate:{}, missCount:{}, missRate:{}, loadCount:{}, loadSuccessCount:{}, totalLoadTime:{}",
                    dictionaryCache.stats().hitCount(),
                    dictionaryCache.stats().hitRate(),
                    dictionaryCache.stats().missCount(),
                    dictionaryCache.stats().missRate(),
                    dictionaryCache.stats().loadCount(),
                    dictionaryCache.stats().loadSuccessCount(),
                    dictionaryCache.stats().totalLoadTime()
            );
        }
    }

	//	对外暴露一个查询缓存的方法
    public String getDicValByDicCode(String dicCode) {
        return dictionaryCache.get(dicCode);
    }
}

4、补充：Caffeine高性能实现

判断一个缓存的好坏最核心的指标就是命中率，影响缓存命中率有很多因素，包括业务场景、淘汰策略、清理策略、缓存容量等等。如果作为本地缓存，它的性能的情况，资源的占用也都是一个很重要的指标。下面

我们来看看 Caffeine 在这几个方面是怎么着手的，如何做优化的。

W-TinyLFU 整体设计

上面说到淘汰策略是影响缓存命中率的因素之一，一般比较简单的缓存就会直接用到 LFU(Least Frequently Used，即最不经常使用) 或者LRU(Least Recently Used，即最近最少使用) ，而 Caffeine 就是使用了 W-TinyLFU 算法。

W-TinyLFU 看名字就能大概猜出来，它是 LFU 的变种，也是一种缓存淘汰算法。那为什么要使用 W-TinyLFU 呢？

LRU 和 LFU 的缺点

LRU 实现简单，在一般情况下能够表现出很好的命中率，是一个"性价比"很高的算法，平时也很常用。虽然 LRU 对突发性的稀疏流量（sparse bursts）表现很好，但同时也会产生缓存污染，举例来说，如果偶然性的要对全量数据进行遍历，那么"历史访问记录"就会被刷走，造成污染。

如果数据的分布在一段时间内是固定的话，那么 LFU 可以达到最高的命中率。但是 LFU 有两个缺点，第一，它需要给每个记录项维护频率信息，每次访问都需要更新，这是个巨大的开销；第二，对突发性的稀疏流量无力，因为前期经常访问的记录已经占用了缓存，偶然的流量不太可能会被保留下来，而且过去的一些大量被访问的记录在将来也不一定会使用上，这样就一直把"坑"占着了。

无论 LRU 还是 LFU 都有其各自的缺点，不过，现在已经有很多针对其缺点而改良、优化出来的变种算法。

TinyLFU

TinyLFU 就是其中一个优化算法，它是专门为了解决 LFU 上述提到的两个问题而被设计出来的。

解决第一个问题是采用了 Count--Min Sketch 算法。

解决第二个问题是让记录尽量保持相对的"新鲜"（Freshness Mechanism），并且当有新的记录插入时，可以让它跟老的记录进行"PK"，输者就会被淘汰，这样一些老的、不再需要的记录就会被剔除。

缓存使用纪要

一、本地缓存：Caffeine

1、简介

2、用法

1）缓存类型

2）常用的缓存属性

缓存初始容量

最大容量

最大权重（比较少用）

过期策略

清除、更新监听

缓存状态与统计

3、实例

4、补充：Caffeine高性能实现

二、本地缓存：Guava

1、简介

2、用法

3、实例

三、分布式缓存：Redis

1、简介

2、用法

3、实例