基本介紹
Halo 專案中，當用戶或博主執行某些操作時，服務器會發布相應的事件，例如博主登錄管理員后臺時發布 "日志記錄" 事件，用戶瀏覽文章時發布 "訪問文章" 事件，事件發布后，負責監聽的 Bean 會做出相應的處理，這種設計稱為事件監聽機制，其作用是可以實作業務邏輯之間的解耦，提高程式的擴展性和可維護性，
ApplicationEvent 和 Listener
Halo 使用 ApplicationEvent 和 Listener 來實作事件的發布與監聽，二者由 Spring 提供，其中 ApplicationEvent 是需要發布的事件，Listener 則是監聽器，用戶可在監聽器中自定義事件的處理邏輯，當事件發生時，只需要將事件發布，監聽器會根據用戶定義的邏輯自動處理該事件，
定義事件
事件需要繼承 ApplicationEvent 類，且需要多載構造方法，以 LogEvent 為例：
public class LogEvent extends ApplicationEvent {
private final LogParam logParam;
/**
* Create a new ApplicationEvent.
*
* @param source the object on which the event initially occurred (never {@code null})
* @param logParam login param
*/
public LogEvent(Object source, LogParam logParam) {
super(source);
// Validate the log param
ValidationUtils.validate(logParam);
// Set ip address
logParam.setIpAddress(ServletUtils.getRequestIp());
this.logParam = logParam;
}
public LogEvent(Object source, String logKey, LogType logType, String content) {
this(source, new LogParam(logKey, logType, content));
}
public LogParam getLogParam() {
return logParam;
}
}
構造方法中的 source 指的是觸發事件的 Bean，也稱為事件源，通常用 this 關鍵字代替，其它引數可由用戶任意指定，
發布事件
ApplicationContext 介面的 publishEvent 方法可用于發布事件，例如博客初始化完成后發布 LogEvent 事件（InstallConroller 中的 installBlog 方法）：
public BaseResponse<String> installBlog(@RequestBody InstallParam installParam) {
// 省略部分代碼
eventPublisher.publishEvent(
new LogEvent(this, user.getId().toString(), LogType.BLOG_INITIALIZED, "博客已成功初始化")
);
return BaseResponse.ok("安裝完成！");
}
監聽器
監聽器的創建方式有多種，例如實作 ApplicationListener 介面、SmartApplicationListener 介面，或者添加 @EventListener 注解，專案中使用注解來定義監聽器，如 LogEventListener：
@Component
public class LogEventListener {
private final LogService logService;
public LogEventListener(LogService logService) {
this.logService = logService;
}
@EventListener
@Async
public void onApplicationEvent(LogEvent event) {
// Convert to log
Log logToCreate = event.getLogParam().convertTo();
// Create log
logService.create(logToCreate);
}
}
用戶可在 @EventListener 注解修飾的方法中定義事件的處理邏輯，方法接收的引數為監聽的事件型別，@Async 注解的作用是實作異步監聽，以上文中的 installBlog 方法為例，如果不添加該注解，那么程式需要等待 onApplicationEvent 方法執行結束后才能回傳 "安裝完成！"，加上 @Async 注解后，onApplicationEvent 方法會在新的執行緒中執行，installBlog 方法可以立即回傳，若要使 @Async 注解生效，還需要在啟動類或配置類上添加 @EnableAsync 注解，
事件處理
接下來我們分析一下 Halo 專案中不同事件的處理程序：
日志記錄事件
日志記錄事件 LogEvent 由 LogEventListener 中的 onApplicationEvent 方法處理，該方法的處理邏輯非常簡單，就是在 logs 表中插入一條系統日志，插入的記錄用于在管理員界面展示：
需要注意的是，不同型別日志的 logKey、logType 以及 content 會有所區別，例如用戶登錄時，logKey 為用戶的 userName，logType 為 LogType.LOGGED_IN，content 為用戶的 nickName：
eventPublisher.publishEvent(
new LogEvent(this, user.getUsername(), LogType.LOGGED_IN, user.getNickname()));
發布文章時，logKey 為文章的 id，logType 為 LogType.POST_PUBLISHED，content 為文章的 title：
LogEvent logEvent = new LogEvent(this, createdPost.getId().toString(),
LogType.POST_PUBLISHED, createdPost.getTitle());
eventPublisher.publishEvent(logEvent);
文章訪問事件
文章訪問事件 PostVisitEvent 由 AbstractVisitEventListener 中的 handleVisitEvent 方法處理，該方法的處理的邏輯是將當前文章的訪問量加一：
protected void handleVisitEvent(@NonNull AbstractVisitEvent event) throws InterruptedException {
Assert.notNull(event, "Visit event must not be null");
// 獲取文章 id
// Get post id
Integer id = event.getId();
log.debug("Received a visit event, post id: [{}]", id);
// 如果當前 postId 具有對應的 BlockingQueue, 那么直接回傳該 BlockingQueue, 否則為當前 postId 創建一個新的 BlockingQueue
// Get post visit queue
BlockingQueue<Integer> postVisitQueue =
visitQueueMap.computeIfAbsent(id, this::createEmptyQueue);
// 如果當前 postId 具有對應的 PostVisitTask, 不做任何處理, 否則為當前 postId 創建一個新的 PostVisitTask 任務
visitTaskMap.computeIfAbsent(id, this::createPostVisitTask);
// 將當前 postId 存入到對應的 BlockingQueue
// Put a visit for the post
postVisitQueue.put(id);
}
上述方法首先獲取當前被訪問文章的 postId，然后查詢 visitQueueMap 中是否存在 postId 對應的阻塞佇列（實際型別為 LinkedBlockingQueue），如果存在那么直接回傳該佇列, 否則為當前 postId 創建一個新的阻塞佇列并存入到 visitQueueMap，接著查詢 visitTaskMap 中是否存在 postId 對應的 PostVisitTask 任務（任務的作用是將文章的訪問量加一），如果沒有，那么就為 postId 創建一個新的 PostVisitTask 任務，并將該任務交給執行緒池 ThreadPoolExecutor（Executors.newCachedThreadPool()）執行，之后將 postId 添加到對應的阻塞佇列，這一步的目的是管理 PostVisitTask 任務的執行次數，
visitQueueMap 和 visitTaskMap 都是 ConcurrentHashMap 型別的物件，使用 ConcurrentHashMap 是為了保證執行緒安全，因為監聽器的事件處理方法被 @Async 注解修飾，默認情況下，@Async 注解修飾的方法會由 Spring 創建的執行緒池 ThreadPoolTaskExecutor 中的執行緒執行，因此當某一篇文章被多個用戶同時瀏覽時，ThreadPoolTaskExecutor 中的多個執行緒可能會同時在 visitQueueMap 中創建阻塞佇列，或在 visitTaskMap 中創建 PostVisitTask 任務，
下面看一下 PostVisitTask 任務中 run 方法的處理邏輯：
public void run() {
while (!Thread.currentThread().isInterrupted()) {
try {
BlockingQueue<Integer> postVisitQueue = visitQueueMap.get(id);
Integer postId = postVisitQueue.take();
log.debug("Took a new visit for post id: [{}]", postId);
// Increase the visit
basePostService.increaseVisit(postId);
log.debug("Increased visits for post id: [{}]", postId);
} catch (InterruptedException e) {
log.debug(
"Post visit task: " + Thread.currentThread().getName() + " was interrupted",
e);
// Ignore this exception
}
}
log.debug("Thread: [{}] has been interrupted", Thread.currentThread().getName());
}
執行緒池 ThreadPoolExecutor 中的一個執行緒處理該任務：
-
從 visitQueueMap 獲取 postId 對應的阻塞佇列（這里的 id 其實就是 postId），并取出隊首元素，
-
將 postId 對應的文章的點贊量加一，
-
只要執行緒不被中斷，就一直重復步驟 1 和步驟 2，如果佇列為空，那么執行緒進入阻塞，
綜上，文章訪問事件的處理流程總結如下：
當 id 為 postId 的文章被訪問時，系統會為其創建一個 LinkedBlockingQueue 型別的阻塞佇列和一個負責將文章點贊量加一的 PostVisitTask 任務，然后 postId 入隊，執行緒池 ThreadPoolExecutor 分配一個執行緒執行 PostVisitTask 任務，阻塞佇列有多少個 postId 該任務就執行多少次，
結語
事件監聽機制是一個非常重要的知識點，實際開發中，如果某些業務處理起來比較耗時，且與主要業務的關聯性并不是很強，那么可以考慮做任務拆分，利用事件監聽機制將串行執行異步化，改為并行執行（當然也可以使用訊息佇列），Halo 中還有新增評論、主題更新等事件，這些事件的的處理思路與文章訪問事件相似，所以本文就不再過多陳述了 ( ⊙?⊙)，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/466937.html
標籤：Java