Halo 开源项目学习（七）：缓存机制

基本介绍

我们知道，频繁操作数据库会降低服务器的系统性能，因此通常需要将频繁访问、更新的数据存入到缓存。Halo 项目也引入了缓存机制，且设置了多种实现方式，如自定义缓存、Redis、LevelDB 等，下面我们分析一下缓存机制的实现过程。

自定义缓存

由于数据在缓存中以键值对的形式存在，且不同类型的缓存系统定义的存储和读取等操作都大同小异，所以本文仅介绍项目中默认的自定义缓存。自定义缓存指的是作者自己编写的缓存，以 ConcurrentHashMap 作为容器，数据存储在服务器的内存中。在介绍自定义缓存之前，我们先看一下 Halo 缓存的体系图：

" src="http://img.e-com-net.com/image/info9/62d0251797a5436984c5f75df5d32ece.jpg" width="650" height="342" style="border:1px solid black;">

本人使用的 Halo 1.4.13 版本中并未设置 Redis 缓存，上图来自 1.5.2 版本。

可以看到，作者的设计思路是在上层的抽象类和接口中定义通用的操作方法，而具体的缓存容器、数据的存储以及读取方法则是在各个实现类中定义。如果希望修改缓存的类型，只需要在配置类 HaloProperties 中修改 cache 字段的值：

@Bean
@ConditionalOnMissingBean
AbstractStringCacheStore stringCacheStore() {
    AbstractStringCacheStore stringCacheStore;
    // 根据 cache 字段的值选择具体的缓存类型
    switch (haloProperties.getCache()) {
        case "level":
            stringCacheStore = new LevelCacheStore(this.haloProperties);
            break;
        case "redis":
            stringCacheStore = new RedisCacheStore(stringRedisTemplate);
            break;
        case "memory":
        default:
            stringCacheStore = new InMemoryCacheStore();
            break;
    }
    log.info("Halo cache store load impl : [{}]", stringCacheStore.getClass());
    return stringCacheStore;
}

上述代码来自 1.5.2 版本。

cache 字段的默认值为 "memory"，因此缓存的实现类为 InMemoryCacheStore（自定义缓存）：

public class InMemoryCacheStore extends AbstractStringCacheStore {

    /**
     * Cleaner schedule period. (ms)
     */
    private static final long PERIOD = 60 * 1000;

    /**
     * Cache container.
     */
    public static final ConcurrentHashMap> CACHE_CONTAINER =
        new ConcurrentHashMap<>();

    private final Timer timer;

    /**
     * Lock.
     */
    private final Lock lock = new ReentrantLock();

    public InMemoryCacheStore() {
        // Run a cache store cleaner
        timer = new Timer();
        // 每 60s 清除一次过期的 key
        timer.scheduleAtFixedRate(new CacheExpiryCleaner(), 0, PERIOD);
    }
    // 省略部分代码
}

InMemoryCacheStore 成员变量的含义如下：

1. CACHE_CONTAINER 是 InMemoryCacheStore 的缓存容器，类型为 ConcurrentHashMap。使用 ConcurrentHashMap 是为了保证线程安全，因为缓存中会存放缓存锁相关的数据（下文中介绍），每当用户访问后台的服务时，就会有新的数据进入缓存，这些数据可能来自于不同的线程，因此 CACHE_CONTAINER 需要考虑多个线程同时操作的情况。
   
2. timer 负责执行周期任务，任务的执行频率为 PERIOD，默认为一分钟，周期任务的处理逻辑是清除缓存中已经过期的 key。
3. lock 是 ReentrantLock 类型的排它锁，与缓存锁有关。

缓存中的数据

缓存中存储的数据包括：

1. 系统设置中的选项信息，其实就是 options 表中存储的数据。
2. 已登录用户（博主）的 token。
3. 已获得文章授权的客户端的 sessionId。
4. 缓存锁相关的数据。

在之前的文章中，我们介绍过 token 和 sessionId 的存储和获取，因此本文就不再赘述这一部分内容了，详见 Halo 开源项目学习（三）：注册与登录 和 Halo 开源项目学习（四）：发布文章与页面。缓存锁我们在下一节再介绍，本节中我们先看看 Halo 如何保存 options 信息。

首先需要了解一下 options 信息是什么时候存入到缓存中的，实际上，程序在启动后会发布 ApplicationStartedEvent 事件，项目中定义了负责监听 ApplicationStartedEvent 事件的监听器 StartedListener（listener 包下），该监听器在事件发布后会执行 initThemes 方法，下面是 initThemes 方法中的部分代码片段：

private void initThemes() {
    // Whether the blog has initialized
    Boolean isInstalled = optionService
        .getByPropertyOrDefault(PrimaryProperties.IS_INSTALLED, Boolean.class, false);
    // 省略部分代码
} 

该方法会调用 getByPropertyOrDefault 方法从缓存中查询博客的安装状态，我们从 getByPropertyOrDefault 方法开始，沿着调用链向下搜索，可以追踪到 OptionProvideService 接口中的 getByKey 方法：

default Optional