一、Spring 事件驅動完整流程總結

1. 定義事件：基類封裝 + 業(yè)務事件繼承

（1）事件基類：TestEvent（繼承 Spring 標準 ApplicationEvent）
作用：封裝通用事件數據，作為所有相關事件的父類，減少重復代碼。
核心：繼承 ApplicationEvent，通過構造器傳遞事件源（source） 和通用業(yè)務數據（cmd），并提供 getter 供子類 / 監(jiān)聽器獲取。

// 事件基類：封裝通用事件數據（可根據業(yè)務選擇是否需要通用事件封裝）
public class TestEvent extends ApplicationEvent {
    @Getter
    private CommonTestData cmd;
    // 構造器：必傳事件源 + 通用業(yè)務數據
    public TestEvent(Object source, CommonTestData  cmd) {
        super(source); // 調用父類ApplicationEvent構造器，綁定事件源
        this.cmd = cmd;
    }
}

（2）業(yè)務事件：RealTimeTestEvent（繼承 TestEvent）
作用：基于基類擴展，定義具體業(yè)務場景的事件，無需重復封裝通用數據。
核心：直接復用父類 TestEvent 的構造器，僅傳遞業(yè)務所需參數，簡化事件定義。

// 業(yè)務事件：繼承TestEvent，專注業(yè)務場景
public class RealTimeTestEvent extends TestEvent {
    // 直接復用父類構造器，傳遞事件源 + 業(yè)務數據cmd
    public RealTimeTestEvent(Object source, CommonTestData cmd) {
        super(source, cmd);
    }
}

2. 發(fā)布事件：業(yè)務方法中觸發(fā)

注入 Spring 內置 ApplicationEventPublisher，在核心業(yè)務邏輯完成后發(fā)布事件。
可通過開關（如 isTestEventTestEnable）控制是否發(fā)布，靈活適配業(yè)務需求。

@Autowired
private ApplicationEventPublisher eventPublisher;
// 業(yè)務方法中發(fā)布事件（核心邏輯執(zhí)行后）
if (isTestEventTestEnable) {
    // 構造業(yè)務事件，傳遞事件源(this) + 業(yè)務數據md
    eventPublisher.publishEvent(new RealTimeTestEvent(this, md));
}

3. 監(jiān)聽事件：異步監(jiān)聽 + 自定義線程池

監(jiān)聽器類加 @Service（或 @Component），被 Spring 容器管理。
用 @EventListener 綁定具體事件，@Async 指定自定義線程池，實現異步非阻塞處理。
從事件中通過 getCmd() 獲取通用業(yè)務數據，執(zhí)行附加邏輯。

@Slf4j
@Service
public class RealTimeTestEventListener {
    @SneakyThrows
    // 1. 指定自定義線程池，異步執(zhí)行（不阻塞主線程）
    @Async("RealTimeTestEventThreadPool")
    // 2. 監(jiān)聽RealTimeTestEvent事件（匹配事件類型）
    @EventListener(RealTimeTestEvent.class)
    public void handleEvent(RealTimeTestEvent event) {
        // 從事件基類TestEvent中獲取通用業(yè)務數據
        CommonTestData md = event.getCmd();
        // 執(zhí)行業(yè)務附加邏輯
        MktDataTestRealTimeListener.pushRealTimeTest(
            ...
        );
    }
}

4. 線程池配置：自定義隔離 + 動態(tài)參數

用 @Configuration 聲明配置類，@Bean 定義線程池，供 @Async 調用。
從配置文件讀取線程池參數（核心數、最大數、隊列容量），支持動態(tài)調整。
設置線程名前綴，方便日志排查；配置拒絕策略（如 CallerRunsPolicy）避免任務丟失。

@Configuration
public class TestEventThreadPool {
    @Autowired
    private ThreadPoolProperties threadPoolProperties;
    // 定義線程池Bean，指定名稱供@Async調用
    @Bean("realTimeTestEventThreadPool")
    public Executor realTimeTestEventThreadPool() {
        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
        // 動態(tài)讀取配置參數
        taskExecutor.setCorePoolSize(threadPoolProperties.getRealTimeTest().getCoreSize());
        taskExecutor.setMaxPoolSize(threadPoolProperties.getRealTimeTest().getMaxPoolSize());
        taskExecutor.setQueueCapacity(threadPoolProperties.getRealTimeTest().getQueueCapacity());
        // 通用配置：線程名前綴、拒絕策略等
        taskExecutor.setThreadNamePrefix("realTimeTestEventThreadPool--");
        taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        // 初始化線程池
        taskExecutor.initialize();
        return taskExecutor;
    }
}

二、@EventListener vs @TransactionalEventListener：核心區(qū)別與適用場景

1. 核心區(qū)別（一句話總結）

@EventListener：事件發(fā)布即執(zhí)行，不依賴事務狀態(tài)；
@TransactionalEventListener：綁定事務階段執(zhí)行（如事務提交后），專為事務場景設計。

2.關鍵事務階段（phase）

@TransactionalEventListener 支持 4 種事務階段，按需選擇：
TransactionPhase.BEFORE_COMMIT：事務提交前執(zhí)行（慎用，可能阻塞事務提交）；
TransactionPhase.AFTER_COMMIT：事務提交成功后執(zhí)行（最常用，保證數據一致性）；
TransactionPhase.AFTER_ROLLBACK：事務回滾后執(zhí)行（如回滾補償邏輯）；
TransactionPhase.AFTER_COMPLETION：事務完成后（無論提交 / 回滾）執(zhí)行。

3. 適用場景選型（結合你的業(yè)務）

（1）用 @EventListener 的場景
業(yè)務無數據庫事務，或事務與事件處理無數據依賴；不操作數據庫，無數據一致性風險，用 @EventListener 更簡潔高效。
事件處理是輕量操作（如推送消息、記錄日志、更新緩存），無需等待事務提交；
（2）用 @TransactionalEventListener 的場景
事件處理依賴主事務的數據庫數據（如主事務更新數據后，監(jiān)聽器需讀取最新數據）；
需避免 “事務未提交，監(jiān)聽器讀取臟數據” 的問題；

三、整體核心價值總結

代碼復用：通過 TestEvent 基類封裝通用事件數據，業(yè)務事件僅需繼承，減少重復代碼；
業(yè)務解耦：主業(yè)務只負責發(fā)布事件，監(jiān)聽器獨立處理附加邏輯，新增 / 刪除邏輯無需修改主業(yè)務；
性能優(yōu)化：@Async + 自定義線程池，讓附加邏輯異步執(zhí)行，不阻塞主線程，提升接口響應速度；
穩(wěn)定性保障：自定義線程池控制并發(fā)，避免默認線程池的 OOM 風險；@TransactionalEventListener 解決事務場景的數據一致性問題；
靈活擴展：支持多事件、多監(jiān)聽器、多線程池隔離，適配復雜業(yè)務場景。

四、快速選型口訣

非事務、輕量處理、無數據依賴 → 用 @EventListener；
事務場景、需讀最新事務數據、保證一致性 → 用 @TransactionalEventListener(phase = AFTER_COMMIT)。

五、Spring 事件驅動和消息中間件選型

（1）、Spring 事件驅動：僅適用于同一個服務（進程內） 本地解耦
Spring 事件驅動（ApplicationEvent/@EventListener/@TransactionalEventListener）的底層是基于 Spring 容器的內存事件廣播機制，事件的發(fā)布、監(jiān)聽全程都在同一個 JVM 進程內完成，無法跨服務、跨進程、跨服務器傳遞。
核心價值：解決單服務內部的業(yè)務解耦問題；
優(yōu)勢：輕量、無中間件依賴、執(zhí)行效率高、無需考慮網絡 / 序列化問題；
局限：僅單服務有效，服務集群部署時，事件僅在當前發(fā)布事件的服務實例中觸發(fā)，其他實例無法感知。
（2）、跨服務解耦：必須使用消息中間件（主流選型）
當需要跨服務、跨進程、跨服務器傳遞事件 / 消息時，Spring 事件驅動完全無法滿足，此時消息中間件（MQ） 是標準且唯一的解決方案，其核心作用是實現分布式系統中的異步通信與解耦。
主流消息中間件選型（按場景適配）：
RabbitMQ：基于 AMQP 協議，支持豐富的消息路由（直連、主題、扇出等）、消息確認、死信隊列，適配復雜的業(yè)務場景（如訂單支付后跨服務通知庫存、物流），企業(yè)級項目首選；
Kafka：基于發(fā)布 - 訂閱模式，高吞吐、低延遲、高可用，適合大數據量、高并發(fā)的日志收集、實時數據同步、流處理場景；
RocketMQ：阿里開源，兼顧 RabbitMQ 的功能豐富性和 Kafka 的高吞吐，支持分布式事務消息，適合電商、金融等核心業(yè)務場景；
ActiveMQ：老牌消息中間件，協議支持全面，但性能和高可用略遜于前三者，適合中小型項目或傳統項目。

到此這篇關于Spring 事件驅動用法完整流程的文章就介紹到這了,更多相關Spring 事件驅動用法內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論