一、本地缓存：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提供了多种缓存类型：
从同步、异步的角度来说有
# 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));
从手动加载、自动加载的角度来说有
# 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 ：最大权重，可以为存入缓存的每个元素都设置一个权重值，当缓存中所有元素的权重值超过最大权重时，就会触发异步清除。
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 ： 英文意思“冷静”，这个不明白。
public class CaffeineCacheRemovalListener implements RemovalListener<Object, Object> {@Overridepublic 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获取缓存、使用。
@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等@Resourceprivate SystemDelegate systemDelegate;// 初始化@PostConstructpublic 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> {@Overridepublic 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> {@Overridepublic 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”，输者就会被淘汰，这样一些老的、不再需要的记录就会被剔除。
