基本介紹
我們知道，頻繁運算元據庫會降低伺服器的系統效能，因此通常需要將頻繁訪問、更新的資料存入到快取。Halo 專案也引入了快取機制，且設定了多種實現方式，如自定義快取、Redis、LevelDB 等，下面我們分析一下快取機制的實現過程。
自定義快取
1. 快取的配置
由於資料在快取中以鍵值對的形式存在，且不同型別的快取系統定義的儲存和讀取等操作都大同小異，所以本文僅介紹專案中預設的自定義快取。自定義快取指的是作者自己編寫的快取，以 ConcurrentHashMap 作為容器，資料儲存在伺服器的記憶體中。在介紹自定義快取之前，我們先看一下 Halo 快取的體系圖：
本人使用的 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<String, CacheWrapper<String>> 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 成員變數的含義如下：
- CACHE_CONTAINER 是 InMemoryCacheStore 的快取容器，型別為 ConcurrentHashMap。使用 ConcurrentHashMap 是為了保證執行緒安全，因為快取中會存放快取鎖相關的資料（下文中介紹），每當使用者訪問後臺的服務時，就會有新的資料進入快取，這些資料可能來自於不同的執行緒，因此 CACHE_CONTAINER 需要考慮多個執行緒同時操作的情況。
-
timer 負責執行週期任務，任務的執行頻率為 PERIOD，預設為一分鐘，週期任務的處理邏輯是清除快取中已經過期的 key。
-
lock 是 ReentrantLock 型別的排它鎖，與快取鎖有關。
2. 快取中的資料
快取中儲存的資料包括：
-
系統設定中的選項資訊，其實就是 options 表中儲存的資料。
-
已登入使用者（博主）的 token。
-
已獲得文章授權的客戶端的 sessionId。
-
快取鎖相關的資料。
在之前的文章中，我們介紹過 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<Object> getByKey(@NonNull String key) {
Assert.hasText(key, "Option key must not be blank");
// 如果 val = listOptions().get(key) 不為空, 返回 value 為 val 的 Optional 物件, 否則返回 value 為空的 Optional 物件
return Optional.ofNullable(listOptions().get(key));
}
可以看到，重點是這個 listOptions 方法，該方法在 OptionServiceImpl 類中定義：
public Map<String, Object> listOptions() {
// Get options from cache
// 從快取 CACHE_CONTAINER 中獲取 "options" 這個 key 對應的資料, 並將該資料轉化為 Map 物件
return cacheStore.getAny(OPTIONS_KEY, Map.class).orElseGet(() -> {
// 初次呼叫時需要從 options 表中獲取所有的 Option 物件
List<Option> options = listAll();
// 所有 Option 物件的 key 集合
Set<String> keys = ServiceUtils.fetchProperty(options, Option::getKey);
/*
* options 表中儲存的記錄其實就是使用者自定義的 Option 選項, 當使用者修改部落格設定時, 會自動更新 options 表,
* Halo 中對一些選項的 value 設定了確定的型別, 例如 EmailProperties 這個類中的 HOST 為 String 型別, 而
* SSL_PORT 則為 Integer 型別, 由於 Option 類中 value 一律為 String 型別, 因此需要將某些 value 轉化為指
* 定的型別
*/
Map<String, Object> userDefinedOptionMap =
ServiceUtils.convertToMap(options, Option::getKey, option -> {
String key = option.getKey();
PropertyEnum propertyEnum = propertyEnumMap.get(key);
if (propertyEnum == null) {
return option.getValue();
}
// 對 value 進行型別轉換
return PropertyEnum.convertTo(option.getValue(), propertyEnum);
});
Map<String, Object> result = new HashMap<>(userDefinedOptionMap);
// Add default property
/*
* 有些選項是 Halo 預設設定的, 例如 EmailProperties 中的 SSL_PORT, 使用者未設定時, 它也會被設定為預設的 465,
* 同樣, 也需要將預設的 "465" 轉化為 Integer 型別的 465
*/
propertyEnumMap.keySet()
.stream()
.filter(key -> !keys.contains(key))
.forEach(key -> {
PropertyEnum propertyEnum = propertyEnumMap.get(key);
if (StringUtils.isBlank(propertyEnum.defaultValue())) {
return;
}
// 對 value 進行型別轉換並存入 result
result.put(key,
PropertyEnum.convertTo(propertyEnum.defaultValue(), propertyEnum));
});
// Cache the result
// 將所有的選項加入快取
cacheStore.putAny(OPTIONS_KEY, result);
return result;
});
}
伺服器首先從 CACHE_CONTAINER 中獲取 "options" 這個 key 對應的資料，然後將該資料轉化為 Map 型別的物件。由於初次查詢時 CACHE_CONTAINER 中 並沒有 "options" 對應的 value，因此需要進行初始化：
-
首先從 options 表中獲取所有的 Option 物件，並將這些物件存入到 Map 中。其中 key 和 value 均為 Option 物件中的 key 和 value，但 value 還需要進行一個型別轉換，因為在 Option 類中 value 被定義為了 String 型別。例如，"is_installed" 對應的 value 為 "true"，為了能夠正常使用 value，需要將字串 "true" 轉化成 Boolean 型別的 true。結合上下文，我們發現程式是根據 PrimaryProperties 類（繼承 PropertyEnum 的列舉類）中定義的列舉物件
IS_INSTALLED("is_installed", Boolean.class, "false")來確認目標型別 Boolean 的。 -
options 表中的選項是使用者自定義的選項，除此之外，Halo 中還設定了一些預設的選項，這些選項均在 PropertyEnum 的子類中定義，例如 EmailProperties 類中的
SSL_PORT("email_ssl_port", Integer.class, "465")，其對應的 key 為 "email_ssl_port"，value 為 "465"。伺服器也會將這些 key - value 對存入到 Map，並對 value 進行型別轉換。
以上便是 listOptions 方法的處理邏輯，我們回到 getByKey 方法，當獲取到 listOptions 方法返回的 Map 物件後，伺服器可以根據指定的 key（如 "is_installed"）獲取到對應的屬性值（如 true）。當使用者在管理員後臺修改部落格的系統設定時，伺服器會根據使用者的配置更新 options 表，併發布 OptionUpdatedEvent 事件，之後負責處理事件的監聽器會將快取中的 "options" 刪除，下次查詢時再根據上述步驟執行初始化操作（詳見 FreemarkerConfigAwareListener 中的 onOptionUpdate 方法）。
3. 快取的過期處理
快取的過期處理是一個非常重要的知識點，資料過期後，通常需要將其從快取中刪除。從上文中的 cacheStore.putAny(OPTIONS_KEY, result) 方法中我們得知，伺服器將資料儲存到快取之前，會先將其封裝成 CacheWrapper 物件：
class CacheWrapper<V> implements Serializable {
/**
* Cache data
*/
private V data;
/**
* Expired time.
*/
private Date expireAt;
/**
* Create time.
*/
private Date createAt;
}
其中 data 是需要儲存的資料，createAt 和 expireAt 分別是資料的建立時間和過期時間。Halo 專案中，"options" 是沒有過期時間的，只有當資料更新時，監聽器才會將舊的資料刪除。需要注意的是，token 和 sessionId 均有過期時間，對於有過期時間的 key，專案中也有相應的處理辦法。以 token 為例，攔截器攔截到使用者的請求後會確認使用者的身份，也就是查詢快取中是否具有 token 對應的使用者 id，這個查詢操作的底層呼叫的是 get 方法（在 AbstractCacheStore 類中定義）：
public Optional<V> get(K key) {
Assert.notNull(key, "Cache key must not be blank");
return getInternal(key).map(cacheWrapper -> {
// Check expiration
// 過期
if (cacheWrapper.getExpireAt() != null
&& cacheWrapper.getExpireAt().before(run.halo.app.utils.DateUtils.now())) {
// Expired then delete it
log.warn("Cache key: [{}] has been expired", key);
// Delete the key
delete(key);
// Return null
return null;
}
// 未過期返回快取資料
return cacheWrapper.getData();
});
}
伺服器獲取到 key 對應的 CacheWrapper 物件後，會檢查其中的過期時間，如果資料已過期，那麼直接將其刪除並返回 null。另外，上文中提到，timer（InMemoryCacheStore 的成員變數）的週期任務也負責刪除過期的資料，下面是 timer 週期任務執行的方法：
private class CacheExpiryCleaner extends TimerTask {
@Override
public void run() {
CACHE_CONTAINER.keySet().forEach(key -> {
if (!InMemoryCacheStore.this.get(key).isPresent()) {
log.debug("Deleted the cache: [{}] for expiration", key);
}
});
}
}
可見，週期任務也是通過呼叫 get 方法來刪除過期資料的。
快取鎖
Halo 專案中的快取鎖也是一個比較有意思的模組，其作用是限制使用者對某個功能的呼叫頻率，可認為是對請求的方法進行加鎖。快取鎖主要利用自定義註解 @CacheLock 和 AOP 來實現，@CacheLock 註解的定義如下：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface CacheLock {
@AliasFor("value")
String prefix() default "";
@AliasFor("prefix")
String value() default "";
long expired() default 5;
TimeUnit timeUnit() default TimeUnit.SECONDS;
String delimiter() default ":";
boolean autoDelete() default true;
boolean traceRequest() default false;
}
各個成員變數的含義為：
-
prefix：用於構建 cacheLockKey（一個字串）的字首。
-
value：同 prefix。
-
expired：快取鎖的持續時間。
-
timeUnit：持續時間的單位。
-
delimiter：分隔符，構建 cacheLockKey 時使用。
-
autoDelete：是否自動刪除快取鎖。
-
traceRequest：是否追蹤請求的 IP，如果是，那麼構建 cacheLockKey 時會新增使用者的 IP。
快取鎖的使用方法是在需要加鎖的方法上新增 @CacheLock 註解，然後通過 Spring 的 AOP 在方法執行前對方法進行加鎖，方法執行結束後再將鎖取消。專案中的切面類為 CacheLockInterceptor，負責加/解鎖的邏輯如下：
Around("@annotation(run.halo.app.cache.lock.CacheLock)")
public Object interceptCacheLock(ProceedingJoinPoint joinPoint) throws Throwable {
// 獲取方法簽名
// Get method signature
MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
log.debug("Starting locking: [{}]", methodSignature.toString());
// 獲取方法上的 CacheLock 註解
// Get cache lock
CacheLock cacheLock = methodSignature.getMethod().getAnnotation(CacheLock.class);
// 構造快取鎖的 key
// Build cache lock key
String cacheLockKey = buildCacheLockKey(cacheLock, joinPoint);
System.out.println(cacheLockKey);
log.debug("Built lock key: [{}]", cacheLockKey);
try {
// Get from cache
Boolean cacheResult = cacheStore
.putIfAbsent(cacheLockKey, CACHE_LOCK_VALUE, cacheLock.expired(),
cacheLock.timeUnit());
if (cacheResult == null) {
throw new ServiceException("Unknown reason of cache " + cacheLockKey)
.setErrorData(cacheLockKey);
}
if (!cacheResult) {
throw new FrequentAccessException("訪問過於頻繁，請稍後再試！").setErrorData(cacheLockKey);
}
// 執行註解修飾的方法
// Proceed the method
return joinPoint.proceed();
} finally {
// 方法執行結束後, 是否自動刪除快取鎖
// Delete the cache
if (cacheLock.autoDelete()) {
cacheStore.delete(cacheLockKey);
log.debug("Deleted the cache lock: [{}]", cacheLock);
}
}
}
@Around("@annotation(run.halo.app.cache.lock.CacheLock)") 表示，如果請求的方法被 @CacheLock 註解修飾，那麼伺服器不會執行該方法，而是執行 interceptCacheLock 方法：
-
獲取方法上的 CacheLock 註解並構建 cacheLockKey。
-
檢視快取中是否存在 cacheLockKey，如果存在，那麼丟擲異常，提醒使用者訪問過於頻繁。如果不存在，那麼將 cacheLockKey 存入到快取（有效時間為 expired），並執行請求的方法。
-
如果 CacheLock 註解中的 autoDelete 為 true，那麼方法執行結束後立即刪除 cacheLockKey。
快取鎖的原理和 Redis 的 setnx + expire 相似，如果 key 已存在，就不能再次新增。下面是構建 cacheLockKey 的邏輯：
private String buildCacheLockKey(@NonNull CacheLock cacheLock,
@NonNull ProceedingJoinPoint joinPoint) {
Assert.notNull(cacheLock, "Cache lock must not be null");
Assert.notNull(joinPoint, "Proceeding join point must not be null");
// Get the method
MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
// key 的字首
// Build the cache lock key
StringBuilder cacheKeyBuilder = new StringBuilder(CACHE_LOCK_PREFIX);
// 分隔符
String delimiter = cacheLock.delimiter();
// 如果 CacheLock 中設定了字首, 那麼直接使用該字首, 否則使用方法名
if (StringUtils.isNotBlank(cacheLock.prefix())) {
cacheKeyBuilder.append(cacheLock.prefix());
} else {
cacheKeyBuilder.append(methodSignature.getMethod().toString());
}
// 提取被 CacheParam 註解修飾的變數的值
// Handle cache lock key building
Annotation[][] parameterAnnotations = methodSignature.getMethod().getParameterAnnotations();
for (int i = 0; i < parameterAnnotations.length; i++) {
log.debug("Parameter annotation[{}] = {}", i, parameterAnnotations[i]);
for (int j = 0; j < parameterAnnotations[i].length; j++) {
Annotation annotation = parameterAnnotations[i][j];
log.debug("Parameter annotation[{}][{}]: {}", i, j, annotation);
if (annotation instanceof CacheParam) {
// Get current argument
Object arg = joinPoint.getArgs()[i];
log.debug("Cache param args: [{}]", arg);
// Append to the cache key
cacheKeyBuilder.append(delimiter).append(arg.toString());
}
}
}
// 是否新增請求的 IP
if (cacheLock.traceRequest()) {
// Append http request info
cacheKeyBuilder.append(delimiter).append(ServletUtils.getRequestIp());
}
return cacheKeyBuilder.toString();
}
可以發現，cacheLockKey 的結構為 cache_lock_ + CacheLock 註解中設定的字首或方法簽名 + 分隔符 + CacheParam 註解修飾的引數的值 + 分隔符 + 請求的 IP，例如：
cache_lock_public void run.halo.app.controller.content.api.PostController.like(java.lang.Integer):1:127.0.0.1
CacheParam 同 CacheLock 一樣，都是為實現快取鎖而定義的註解。CacheParam 的作用是將鎖的粒度精確到具體的實體，如點贊請求：
@PostMapping("{postId:\\d+}/likes")
@ApiOperation("Likes a post")
@CacheLock(autoDelete = false, traceRequest = true)
public void like(@PathVariable("postId") @CacheParam Integer postId) {
postService.increaseLike(postId);
}
引數 postId 被 CacheParam 修飾，根據 buildCacheLockKey 方法的邏輯，postId 也將是 cacheLockKey 的一部分，這樣鎖定的就是 "為 id 等於 postId 的文章點贊" 這一方法，而非鎖定 "點贊" 方法。
此外，CacheLock 註解中的 traceRequest 引數也很重要，如果 traceRequest 為 true，那麼請求的 IP 會被新增到 cacheLockKey 中，此時快取鎖僅限制同一 IP 對某個方法的請求頻率，不同 IP 之間互不干擾。如果 traceRequest 為 false，那麼快取鎖就是一個分散式鎖，不同 IP 不能同時訪問同一個功能，例如當某個使用者為某篇文章點贊後，短時間內其它使用者不能為該文章點贊。
最後我們再分析一下 putIfAbsent 方法（在 interceptCacheLock 中被呼叫），其功能和 Redis 的 setnx 相似，該方法的具體處理邏輯可追蹤到 InMemoryCacheStore 類中的 putInternalIfAbsent 方法：
Boolean putInternalIfAbsent(@NonNull String key, @NonNull CacheWrapper<String> cacheWrapper) {
Assert.hasText(key, "Cache key must not be blank");
Assert.notNull(cacheWrapper, "Cache wrapper must not be null");
log.debug("Preparing to put key: [{}], value: [{}]", key, cacheWrapper);
// 加鎖
lock.lock();
try {
// 獲取 key 對應的 value
// Get the value before
Optional<String> valueOptional = get(key);
// value 不為空返回 false
if (valueOptional.isPresent()) {
log.warn("Failed to put the cache, because the key: [{}] has been present already",
key);
return false;
}
// 在快取中新增 value 並返回 true
// Put the cache wrapper
putInternal(key, cacheWrapper);
log.debug("Put successfully");
return true;
} finally {
// 解鎖
lock.unlock();
}
}
上節中我們提到，自定義快取 InMemoryCacheStore 中有一個 ReentrantLock 型別的成員變數 lock，lock 的作用就是保證 putInternalIfAbsent 方法的執行緒安全性，因為向快取容器中新增 cacheLockKey 是多個執行緒並行執行的。如果不新增 lock，那麼當多個執行緒同時操作同一個 cacheLockKey 時，不同執行緒可能都會檢測到快取中沒有 cacheLockKey，因此 putInternalIfAbsent 方法均返回 true，之後多個執行緒就可以同時執行某個方法，新增 lock 後就能夠避免這種情況。
結語
關於 Halo 專案快取機制就介紹到這裡了，如有理解錯誤，歡迎大家批評指正 ( ̳• ◡ • ̳)。