SpringBoot&Caffeine 灵活支持多个缓存配置策略

前言

缓存是几乎所有应用程序性能的关键。很多时候需要分布式缓存（比如常用的 Redis、Codis），但在许多情况下，本地缓存也可以很好地工作，并且不需要分布式缓存的开销和复杂性。

对于 DotNet 开发来说，本地 cache 很方便使用（比如 RuntimeCache 等）；对于 Java 说，也有很多优秀的本地 cache 库（比如 Ehcache、GuavaCache 等），而 Java 这个帝国中，spring 是一个伟大且垄断的存在。针对不同的缓存技术，Spring 定义了如下的 cacheManger 实现。

CacheManger	描述
`SimpleCacheManager`	使用简单的 Collection 来存储缓存，主要用于测试
`ConcurrentMapCacheManager`	使用 ConcurrentMap 作为缓存技术（默认），需要显式的删除缓存，无过期机制
`NoOpCacheManager`	仅测试用途，不会实际存储缓存
`EhCacheCacheManager`	使用 EhCache 作为缓存技术，以前在 hibernate 的时候经常用
`GuavaCacheManager`	使用 google guava 的 GuavaCache 作为缓存技术(1.5 版本已不建议使用）
`CaffeineCacheManager`	是使用 Java8 对 Guava 缓存的重写，spring5（springboot2）开始用 Caffeine 取代 guava
`HazelcastCacheManager`	使用 Hazelcast 作为缓存技术
`JCacheCacheManager`	使用 JCache 标准的实现作为缓存技术，如 Apache Commons JCS
`RedisCacheManager`	使用 Redis 作为缓存技术

因此，在许多应用程序中（包括普通的 Spring 和 Spring Boot），你都可以引入相应的依赖包后，简单的把 @Cacheable 打在任何方法上使用它，以使其结果被缓存，以便下次调用该方法时，将返回缓存的结果。

Tips：spring cache 使用基于动态生成子类的代理机制来对方法的调用进行切面，如果缓存的方法是内部调用而不是外部引用，会导致代理失败，切面失效。

虽然 Spring 有一些默认的缓存管理器实现，有时候，一些外部库总是比简单的实现更好、更灵活。例如，其中一个高性能的 Java 缓存库 Caffeine 。

今天，我们主要目标就是：认识 Caffeine 以及如何实现多缓存灵活配置。

那么，简单认识一下 Caffeine

Caffeine 是使用 Java8 对 Guava 缓存的重写版本，缓存类似于 ConcurrentMap，但并不完全相同，可提供接近最佳的命中率。它基于 LRU 算法实现，支持多种缓存过期策略。在 Spring Boot 2.0 中将取代 GuavaCache。特性如下：

自动将实体加载到缓存中，可以选择异步加载；
基于频率和新近度超过最大值时基于大小的淘汰；
自上次访问或上次写入以来的基于时间的过期；
基于第一个请求旧数据时的异步刷新（只放行一个请求去刷新数据）；
其他

Caffeine 的一些参数，我们后续也会用到

参数	描述
`initialCapacity=[integer]`	初始的缓存空间大小（比较常用）
`maximumSize=[long]`	缓存的最大条数（比较常用）
`maximumWeight=[long]`	缓存的最大权重
`expireAfterAccess=[duration]`	最后一次写入或访问后经过固定时间过期（比较常用）
`expireAfterWrite=[duration]`	最后一次写入后经过固定时间过期（比较常用）
`refreshAfterWrite=[duration]`	创建缓存或者最近一次更新缓存后经过固定的时间间隔，刷新缓存 refreshAfterWrite requires a LoadingCache
`weakKeys`	打开 key 的弱引用
`weakValues`	打开 value 的弱引用
`softValues`	打开 value 的软引用
`recordStats`	开发统计功能

注意：

refreshAfterWrite 必须实现 LoadingCache，跟 expire 的区别是，指定时间过后 expire 是 remove 该 key，下次访问是同步去获取返回新值，而 refresh 则是指定时间后，不会 remove 该 key，下次访问会触发刷新，新值没有回来时返回旧值。
expireAfterWrite 和 expireAfterAccess 同时存在时，以 expireAfterWrite 为准。
maximumSize 和 maximumWeight 不可以同时使用。
weakValues 和 softValues 不可以同时使用。

简单了解了 caffeine 是什么，有哪些属性可用，那么我们回过头来，你会发现，其实 SpringBoot 内部已经提供了一个默认实现 CaffeineCacheManager（具体可以参见源码 org.springframework.cache.caffeine.CaffeineCacheManager ）。这里不再过多的展开，可以自行阅读一下源码了解下~

因此，理想情况下，这就是你所需要的一切了：只需简单的创建一个 CacheManager 的 bean，就可以为带 @Cacheable 注释的方法进行缓存。

到此，我们大概了解了 caffeine 是个什么，以及应该如何用，那么接下来，我们就用示例说话。看不到代码瞎 BB 也是很让人讨厌的，不是么。

实战

阶段一目标：定义两个 manager，实现不同的缓存配置。

举例如下：

@Configuration
public class CaffeineConfig extends CachingConfigurerSupport {

    @Override
    @Bean(name = "cacheManager")
    public CacheManager cacheManager() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();

        // 方案一(常用)：定制化缓存Cache
        cacheManager.setCaffeine(Caffeine.newBuilder()
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .initialCapacity(100)
                .maximumSize(10_000));

        return cacheManager;
    }

    /**
     * 在@cacheable使用时，指定cacheManager=specCacheManager
     *
     * @return CacheManager
     */
    @Bean(name = "specCacheManager")
    public CacheManager cacheManagerWithSpec() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        // 不允许空值
        cacheManager.setAllowNullValues(false);
        // 传入一个CaffeineSpec定制缓存，它的好处是可以把配置方便写在配置文件里
        cacheManager.setCaffeineSpec(CaffeineSpec.parse("initialCapacity=20,maximumSize=100,expireAfterWrite=10m"));

        // 指定使用该策略的CacheNames
        cacheManager.setCacheNames(new ArrayList<String>(Arrays.asList("fetchById", "fetchByName")));

        return cacheManager;
    }
}

使用起来也很简单，毕竟 springBoot 这么牛 x 的框架提供了很好的集成和灵活性。

@Slf4j
@Service
public class UserServiceImpl implements UserService {

    @Override
    @Cacheable(cacheNames = "userSelectOrDefault", cacheManager = "cacheManager", key = "#userId")
    public MyUser selectOrDefault(Integer userId) {

        System.out.println("我要执行【selectOrDefault】方法的查询逻辑啦~ userId=" + userId);
        System.out.println("当前时间：" + LocalDateTime.now().toString());

        return new MyUser()
                .setUserId(userId)
                .setGender(userId % 2)
                .setUserName("userName_" + userId);
    }

    @Override
    @Cacheable(cacheNames = "fetchByName", cacheManager = "specCacheManager", key = "#userName")
    public MyUser fetchByName(String userName) {
        System.out.println("我要执行【fetchByName】方法的查询逻辑啦~userName=" + userName);
        System.out.println("当前时间：" + LocalDateTime.now().toString());

        int hashCode = userName.hashCode();

        return new MyUser()
                .setUserId(hashCode)
                .setGender(hashCode % 2)
                .setUserName(userName);
    }
}

通过指定 @Cacheable 的 cacheNames、 cacheManager 就可以“灵活”的使用不同的缓存策略了。可能你觉得已经有点小满足了，毕竟能灵活配置了嘛~~

然鹅~~

冷静下，真的“灵活”么？

假如一个项目中有很多要缓存（而且也肯定很常见），并且缓存的策略规则也不尽相同时（比如重要的到期时间、初始容量、最大大小等），你是不是就觉得写很多类似的 cacheManger 有点不爽？

笔者也翻阅了网上一些文章，但大多是告诉你如何使用自定义规范定义自定义缓存。但是，没有一个实现了我希望的理想状态。

我期望的是：既可以使用默认的一些策略规范自动创建缓存，又可以灵活的自定义设置你想要的缓存策略。

是不是听起来有点贪心？其实，我个人觉得这是追求完美的人很正常的一个想法。

毕竟方法总比困那多~

那么，接下来，我们就要把这个想法落地。

阶段二：目标：实现一个既可以手动配置，又可以默认的 `CacheManger`

更多实现细节，请通过移步公众号~