基本介紹
我們知道，頻繁操作資料庫會降低服務器的系統性能，因此通常需要將頻繁訪問、更新的資料存入到快取，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 專案快取機制就介紹到這里了，如有理解錯誤，歡迎大家批評指正 ( ?? ? ? ?)，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/467900.html
標籤：Java