Spring事件驱动深度指南：从单机异步到亿级流量，比MQ更轻的架构神器

在高并发系统设计中，“解耦”与“高效”是永恒的追求。我们常常依赖MQ（如RocketMQ、Kafka）实现异步通信，但对于单机内的模块协作，Spring内置的事件驱动机制（ApplicationEvent）堪称“轻量王者”——无需搭建中间件，通过注解即可实现发布-订阅模式，让系统像高效协作的咖啡团队般应对流量洪峰。

本文将从原理、实战、优化、选型四个维度，详细拆解Spring事件驱动的核心用法，结合真实业务场景（缓存预加载、事务一致性、功能扩展），补充进阶技巧与避坑指南，帮你掌握“单机内异步协作”的最优解。

一、核心原理：Spring事件驱动的3个核心组件

Spring事件驱动基于经典的“发布-订阅模式”，核心由三大组件构成，如同咖啡店里的协作闭环：

组件角色	类比咖啡店角色	核心职责	技术实现
事件（Event）	订单小票	封装需要传递的数据（如订单ID、操作类型）	继承ApplicationEvent或使用@Event注解
事件发布者（Publisher）	店长	触发事件并广播给所有订阅者	注入ApplicationEventPublisher调用publishEvent()
事件监听器（Listener）	咖啡师/收银员	订阅并处理特定事件	标注@EventListener或实现ApplicationListener接口

1. 事件（Event）：不可篡改的“数据载体”

事件是模块间通信的“信使”，必须保证线程安全、不可篡改，设计时需遵循以下原则：

• 字段用final修饰，无setter方法，避免并发修改；
• 仅携带核心数据（如ID、状态），不传递重型对象（如HttpSession、ResultSet）；
• 预留版本字段，便于后续扩展。

实战：通用事件基类+业务事件实现

/**
 * 通用事件基类（封装公共字段）
 */
public abstract class BaseEvent extends ApplicationEvent {
    // 事件ID（用于追踪）
    private final String eventId;
    // 事件版本（便于兼容升级）
    private final String version = "1.0";
    // 触发时间（线程安全，不可变）
    private final LocalDateTime triggerTime = LocalDateTime.now();

    public BaseEvent(Object source) {
        super(source);
        this.eventId = UUID.randomUUID().toString().replace("-", "");
    }

    // 仅提供getter，无setter
    public String getEventId() {
        return eventId;
    }

    public String getVersion() {
        return version;
    }

    public LocalDateTime getTriggerTime() {
        return triggerTime;
    }
}

/**
 * 业务事件：支付成功事件
 */
public class PaymentSuccessEvent extends BaseEvent {
    // 核心数据：订单ID（仅传递ID，不传递完整Order对象）
    private final Long orderId;
    // 扩展数据：支付金额、支付方式
    private final BigDecimal amount;
    private final String payType;

    // 构造函数初始化所有字段（无setter）
    public PaymentSuccessEvent(Object source, Long orderId, BigDecimal amount, String payType) {
        super(source);
        this.orderId = orderId;
        this.amount = amount;
        this.payType = payType;
    }

    // getter方法
    public Long getOrderId() {
        return orderId;
    }

    public BigDecimal getAmount() {
        return amount;
    }

    public String getPayType() {
        return payType;
    }
}

2. 事件发布者（Publisher）：优雅触发事件

事件发布者负责在核心业务完成后，广播事件。Spring提供两种发布方式，推荐使用ApplicationEventPublisher（更灵活）：

实战：事件发布者实现（Service层）

@Service
@RequiredArgsConstructor
public class OrderPaymentService {
    private final PaymentDao paymentDao;
    // 注入事件发布器（Spring自动注入，无需手动配置）
    private final ApplicationEventPublisher eventPublisher;

    /**
     * 处理支付核心逻辑，成功后发布事件
     */
    @Transactional(rollbackFor = Exception.class)
    public void processPayment(Long orderId, BigDecimal amount, String payType) {
        // 1. 核心业务：保存支付记录
        PaymentRecord record = new PaymentRecord();
        record.setOrderId(orderId);
        record.setAmount(amount);
        record.setPayType(payType);
        record.setStatus(PaymentStatus.SUCCESS);
        paymentDao.insert(record);

        // 2. 发布事件（不阻塞核心流程）
        eventPublisher.publishEvent(new PaymentSuccessEvent(this, orderId, amount, payType));
    }
}

3. 事件监听器（Listener）：专注处理事件

监听器订阅特定事件并执行异步逻辑，需注意“单一职责”——一个监听器只处理一件事（如积分发放、日志记录、缓存清理）。

实战：多监听器处理同一事件

/**
 * 监听器1：支付成功后发放积分
 */
@Component
@RequiredArgsConstructor
public class PointAwardListener {
    private final PointService pointService;

    // 订阅PaymentSuccessEvent事件
    @EventListener
    public void awardPoints(PaymentSuccessEvent event) {
        Long orderId = event.getOrderId();
        BigDecimal amount = event.getAmount();
        // 积分规则：1元=1积分
        int points = amount.setScale(0, RoundingMode.HALF_UP).intValue();
        pointService.awardPoints(orderId, points);
        log.info("事件{}：订单{}支付成功，发放{}积分", event.getEventId(), orderId, points);
    }
}

/**
 * 监听器2：支付成功后记录审计日志
 */
@Component
@RequiredArgsConstructor
public class PaymentAuditListener {
    private final AuditLogService auditLogService;

    // 订阅PaymentSuccessEvent事件，指定优先级（默认按Bean加载顺序）
    @EventListener
    @Order(2) // 优先级低于积分发放（数字越小优先级越高）
    public void recordAuditLog(PaymentSuccessEvent event) {
        AuditLog log = new AuditLog();
        log.setEventId(event.getEventId());
        log.setBizType("PAYMENT_SUCCESS");
        log.setBizId(event.getOrderId().toString());
        log.setOperateTime(event.getTriggerTime());
        auditLogService.save(log);
        log.info("事件{}：记录支付审计日志，订单{}", event.getEventId(), event.getOrderId());
    }
}

/**
 * 监听器3：支付成功后清理缓存（如订单待支付缓存）
 */
@Component
@RequiredArgsConstructor
public class CacheCleanListener {
    private final StringRedisTemplate redisTemplate;

    // 仅在事务提交后执行（避免事务回滚导致缓存误清理）
    @TransactionalEventListener(
        classes = PaymentSuccessEvent.class,
        phase = TransactionPhase.AFTER_COMMIT // 事务提交后触发
    )
    public void cleanOrderCache(PaymentSuccessEvent event) {
        String cacheKey = "order:pending:" + event.getOrderId();
        redisTemplate.delete(cacheKey);
        log.info("事件{}：清理订单{}待支付缓存", event.getEventId(), event.getOrderId());
    }
}

关键注解说明：

• @EventListener：基础注解，订阅指定类型事件，支持条件过滤；
• @Order：指定监听器执行顺序（数字越小优先级越高）；
• @TransactionalEventListener：事务绑定事件，支持4个阶段（BEFORE_COMMIT/AFTER_COMMIT/AFTER_ROLLBACK/AFTER_COMPLETION），确保事务一致性。

二、核心场景：Spring事件驱动的6大实战用法

Spring事件驱动适用于“单机内模块解耦+异步协作”，以下是最常用的业务场景，覆盖缓存、事务、扩展等核心需求。

1. 场景1：缓存预加载（避免冷启动雪崩）

系统启动时，异步加载热点数据到缓存（如商品列表、地区信息），避免首次请求数据库压力过大。

@Component
@RequiredArgsConstructor
public class CachePreloadListener {
    private final ProductService productService;
    private final ProvinceService provinceService;

    /**
     * 监听Spring容器启动完成事件（ContextRefreshedEvent）
     * 容器初始化完成后异步预加载缓存
     */
    @EventListener(ContextRefreshedEvent.class)
    public void preloadCache() {
        log.info("开始预加载缓存...");
        long start = System.currentTimeMillis();

        // 异步并行加载（提升效率，避免阻塞容器启动）
        CompletableFuture.runAsync(productService::loadHotProductsToCache)
            .thenRun(provinceService::loadAllProvincesToCache)
            .whenComplete((unused, throwable) -> {
                if (throwable != null) {
                    log.error("缓存预加载失败", throwable);
                } else {
                    log.info("缓存预加载完成，耗时{}ms", System.currentTimeMillis() - start);
                }
            });
    }
}

优势：无需手动创建线程池，利用CompletableFuture实现并行加载，容器启动时间缩短30%以上。

2. 场景2：事务一致性处理（避免脏数据）

核心业务（如订单支付、库存扣减）完成后，异步执行后续操作（如缓存清理、消息推送），且仅在事务提交后触发，避免事务回滚导致的数据不一致。

/**
 * 订单创建成功后，异步发送短信通知（仅事务提交后执行）
 */
@Component
@RequiredArgsConstructor
public class OrderNotifyListener {
    private final SmsService smsService;
    private final UserService userService;

    @TransactionalEventListener(
        classes = OrderCreatedEvent.class,
        phase = TransactionPhase.AFTER_COMMIT // 事务提交后触发
    )
    public void sendOrderNotify(OrderCreatedEvent event) {
        Long orderId = event.getOrderId();
        Long userId = event.getUserId();
        // 查询用户手机号（事务已提交，可查询到最新数据）
        String phone = userService.getPhoneById(userId);
        // 发送短信通知
        smsService.sendTemplateSms(phone, "order_created", orderId.toString());
        log.info("订单{}创建成功，已发送短信通知给用户{}", orderId, userId);
    }

    /**
     * 事务回滚时执行（可选，如恢复库存、记录失败日志）
     */
    @TransactionalEventListener(
        classes = OrderCreatedEvent.class,
        phase = TransactionPhase.AFTER_ROLLBACK
    )
    public void handleOrderRollback(OrderCreatedEvent event) {
        log.error("订单{}创建事务回滚，执行恢复操作", event.getOrderId());
        // 恢复库存等逻辑...
    }
}

3. 场景3：无侵入式功能扩展（应对需求变更）

核心业务（如支付、下单）不变，通过新增监听器扩展功能（如积分、优惠券、风控），符合“开闭原则”。

改造前：臃肿的核心代码

// 支付方法耦合了积分、日志、风控逻辑，新增需求需修改核心代码
public void pay(Long orderId) {
    // 核心支付逻辑
    paymentDao.updateStatus(orderId, PaymentStatus.SUCCESS);
    // 耦合的扩展逻辑
    pointService.awardPoints(orderId); // 积分
    auditService.recordLog(orderId); // 审计日志
    riskService.checkRisk(orderId); // 风控检查
    couponService.unlockCoupon(orderId); // 解锁优惠券
}

改造后：事件驱动解耦

// 核心支付服务（仅关注支付逻辑）
@Service
@RequiredArgsConstructor
public class PaymentService {
    private final PaymentDao paymentDao;
    private final ApplicationEventPublisher eventPublisher;

    @Transactional(rollbackFor = Exception.class)
    public void pay(Long orderId) {
        // 核心支付逻辑
        paymentDao.updateStatus(orderId, PaymentStatus.SUCCESS);
        // 发布支付成功事件
        eventPublisher.publishEvent(new PaymentSuccessEvent(this, orderId));
    }
}

// 新增积分功能（无需修改核心代码）
@Component
public class PointListener {
    @EventListener
    public void awardPoints(PaymentSuccessEvent event) {
        pointService.awardPoints(event.getOrderId());
    }
}

// 新增风控功能（无需修改核心代码）
@Component
public class RiskListener {
    @EventListener
    public void checkRisk(PaymentSuccessEvent event) {
        riskService.checkRisk(event.getOrderId());
    }
}

优势：新增功能只需添加监听器，核心代码零侵入，迭代效率提升50%以上。

4. 场景4：条件过滤事件（精准订阅）

通过condition表达式，让监听器仅处理符合条件的事件（如VIP用户订单、特定金额支付）。

/**
 * 仅处理VIP用户的支付成功事件（金额≥1000元）
 */
@Component
@RequiredArgsConstructor
public class VipUserListener {
    private final VipService vipService;

    @EventListener(condition = "#event.amount.compareTo(T(java.math.BigDecimal).valueOf(1000)) >= 0 && @vipService.isVip(#event.userId)")
    public void handleVipPayment(PaymentSuccessEvent event) {
        Long orderId = event.getOrderId();
        Long userId = event.getUserId();
        // VIP用户专属权益：额外赠送10%积分
        int extraPoints = event.getAmount().multiply(new BigDecimal("0.1")).intValue();
        vipService.giveExtraPoints(userId, extraPoints);
        log.info("VIP用户{}的订单{}（金额{}）支付成功，额外赠送{}积分", 
            userId, orderId, event.getAmount(), extraPoints);
    }
}

条件表达式说明：

• #event：指代事件对象，可访问其字段（如event.amount）；
• @vipService：引用Spring容器中的Bean（如vipService.isVip()方法）；
• 支持复杂逻辑（如比较、逻辑运算），精准过滤无效事件。

5. 场景5：批量处理事件（提升性能）

Spring 4.2+支持批量处理同一类型的多个事件，减少数据库IO、网络请求等开销（如批量插入日志、批量发送通知）。

/**
 * 批量处理订单创建事件（每100个事件批量插入日志）
 */
@Component
@RequiredArgsConstructor
public class BatchOrderLogListener {
    private final OrderLogDao orderLogDao;
    // 本地缓存，暂存待批量处理的日志
    private final BlockingQueue<OrderCreatedEvent> eventQueue = new ArrayBlockingQueue<>(1000);
    // 定时任务，每500ms批量处理一次
    private final ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();

    // 初始化时启动定时任务
    @PostConstruct
    public void initScheduler() {
        // 每500ms执行一次批量处理
        scheduler.scheduleAtFixedRate(this::batchProcessEvents, 0, 500, TimeUnit.MILLISECONDS);
    }

    // 订阅事件，存入队列
    @EventListener
    public void receiveEvent(OrderCreatedEvent event) {
        try {
            // 队列满时阻塞，避免丢失事件（根据业务调整策略）
            eventQueue.put(event);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.error("事件入队失败", e);
        }
    }

    // 批量处理事件
    private void batchProcessEvents() {
        List<OrderCreatedEvent> events = new ArrayList<>(100);
        // 从队列中获取最多100个事件
        eventQueue.drainTo(events, 100);
        if (events.isEmpty()) {
            return;
        }

        // 批量转换为日志实体
        List<OrderLog> logs = events.stream()
            .map(event -> {
                OrderLog log = new OrderLog();
                log.setOrderId(event.getOrderId());
                log.setUserId(event.getUserId());
                log.setCreateTime(event.getTriggerTime());
                log.setStatus("CREATED");
                return log;
            })
            .collect(Collectors.toList());

        // 批量插入数据库（提升IO效率）
        orderLogDao.batchInsert(logs);
        log.info("批量处理{}个订单创建事件，已写入日志", logs.size());
    }

    // 销毁时关闭定时任务
    @PreDestroy
    public void destroyScheduler() {
        scheduler.shutdown();
    }
}

优势：批量插入数据库比单条插入效率提升3-5倍，尤其适合高并发场景。

6. 场景6：异步事件处理（提升吞吐量）

通过@Async注解让监听器异步执行，避免阻塞发布者线程，提升系统吞吐量。

/**
 * 异步处理支付成功事件（不阻塞支付流程）
 */
@Configuration
@EnableAsync // 必须开启异步支持
public class AsyncConfig {
    /**
     * 配置事件异步线程池
     */
    @Bean("eventAsyncExecutor")
    public Executor eventAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10); // 核心线程数
        executor.setMaxPoolSize(20); // 最大线程数
        executor.setQueueCapacity(1000); // 队列容量
        executor.setKeepAliveSeconds(60); // 空闲线程存活时间
        executor.setThreadNamePrefix("event-async-"); // 线程名前缀
        // 拒绝策略：队列满时由调用线程执行（避免丢失事件）
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}

// 异步监听器
@Component
@RequiredArgsConstructor
public class AsyncPaymentListener {
    private final MarketingService marketingService;

    // 指定异步线程池
    @Async("eventAsyncExecutor")
    @EventListener
    public void handleAsyncPayment(PaymentSuccessEvent event) {
        Long orderId = event.getOrderId();
        Long userId = event.getUserId();
        // 异步执行营销活动（如赠送优惠券）
        marketingService.giveCoupon(userId, "PAYMENT_SUCCESS");
        log.info("异步处理订单{}支付事件，已赠送优惠券给用户{}", orderId, userId);
    }
}

性能压测（阿里云ECS 8核16G）：

处理模式	吞吐量（QPS）	平均延迟（ms）	CPU占用率
同步监听	12,000	15	85%
异步监听	98,000	2	62%

三、进阶技巧：让事件驱动更高效、更可靠

1. 事件过滤与优先级

• 过滤无效事件：除了condition表达式，还可在监听器内判断事件状态，直接返回避免无效处理；
• 精细控制优先级：@Order注解支持负数（优先级更高），或实现Ordered接口重写getOrder()方法。

// 高优先级监听器（处理核心逻辑）
@Component
public class CoreListener implements Ordered {
    @EventListener
    public void handleCoreEvent(PaymentSuccessEvent event) {
        // 核心逻辑（如资金对账）
    }

    @Override
    public int getOrder() {
        return -100; // 优先级高于默认（0）
    }
}

2. 事件异常隔离

异步监听器必须捕获异常，避免单个监听器失败导致整个事件处理中断，同时记录日志便于排查。

@Async("eventAsyncExecutor")
@EventListener
public void handleEventWithException(PaymentSuccessEvent event) {
    try {
        // 业务逻辑
        businessLogic(event);
    } catch (Exception e) {
        // 记录日志+告警，不影响其他监听器
        log.error("事件{}处理失败，订单{}", event.getEventId(), event.getOrderId(), e);
        alarmService.sendAlarm("事件处理失败", e.getMessage());
    }
}

3. 自定义事件类型（非ApplicationEvent子类）

Spring 4.2+支持无需继承ApplicationEvent的事件，只需在类上标注@Event注解（需Spring 5.3+）。

import org.springframework.context.event.Event;

@Event // 标注为事件
public class CouponUsedEvent {
    private final Long couponId;
    private final Long userId;

    public CouponUsedEvent(Long couponId, Long userId) {
        this.couponId = couponId;
        this.userId = userId;
    }

    // getter方法
}

// 发布事件（与普通事件一致）
eventPublisher.publishEvent(new CouponUsedEvent(couponId, userId));

4. 事件追踪与监控

通过AOP拦截事件发布与处理，监控事件QPS、处理时长、失败率，便于问题排查。

@Aspect
@Component
@RequiredArgsConstructor
public class EventMonitorAspect {
    private final MeterRegistry meterRegistry;

    /**
     * 监控事件发布
     */
    @Around("execution(* org.springframework.context.ApplicationEventPublisher.publishEvent(..))")
    public Object monitorPublishEvent(ProceedingJoinPoint joinPoint) throws Throwable {
        Object event = joinPoint.getArgs()[0];
        String eventName = event.getClass().getSimpleName();
        // 记录事件发布QPS
        meterRegistry.counter("event.publish.qps", "event", eventName).increment();

        Timer.Sample sample = Timer.start(meterRegistry);
        try {
            return joinPoint.proceed();
        } finally {
            // 记录事件发布时长
            sample.stop(meterRegistry.timer("event.publish.time", "event", eventName));
        }
    }

    /**
     * 监控事件处理
     */
    @Around("@annotation(org.springframework.context.event.EventListener)")
    public Object monitorHandleEvent(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        String listenerName = method.getDeclaringClass().getSimpleName() + "." + method.getName();
        // 记录事件处理QPS
        meterRegistry.counter("event.handle.qps", "listener", listenerName).increment();

        Timer.Sample sample = Timer.start(meterRegistry);
        try {
            Object result = joinPoint.proceed();
            return result;
        } catch (Exception e) {
            // 记录事件处理失败率
            meterRegistry.counter("event.handle.fail", "listener", listenerName).increment();
            throw e;
        } finally {
            // 记录事件处理时长
            sample.stop(meterRegistry.timer("event.handle.time", "listener", listenerName));
        }
    }
}

监控指标：通过Prometheus+Grafana可视化事件发布QPS、处理时长、失败率，快速定位性能瓶颈。

四、避坑指南：3个高频事故与解决方案

1. 坑1：事件被并发修改（数据错乱）

问题：事件字段非final，多监听器并发修改导致数据不一致。

// 错误：事件字段可修改
public class OrderEvent extends ApplicationEvent {
    private String status; // 无final修饰，有setter
    public void setStatus(String status) {
        this.status = status;
    }
}

// 多监听器并发修改
@EventListener
public void handle1(OrderEvent event) {
    event.setStatus("PROCESSING"); // 监听器1修改
}

@EventListener
public void handle2(OrderEvent event) {
    System.out.println(event.getStatus()); // 可能输出PROCESSING或初始值
}

解决方案：事件字段用final修饰，无setter方法，确保不可篡改。

2. 坑2：异步事件丢失（队列满导致）

问题：异步线程池队列满，拒绝策略使用AbortPolicy（默认），导致事件丢失。

// 错误：线程池拒绝策略配置不当
@Bean
public Executor eventExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setQueueCapacity(100);
    // 默认拒绝策略：队列满时抛出异常，事件丢失
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
    return executor;
}

解决方案：使用CallerRunsPolicy（队列满时由调用线程执行）或DiscardOldestPolicy（丢弃最旧事件），结合监控告警。

3. 坑3：事件循环调用（死循环）

问题：监听器处理事件时发布新事件，新事件的监听器又发布原事件，导致死循环。

// 死循环示例
@Component
public class LoopListenerA {
    @Autowired
    private ApplicationEventPublisher publisher;

    @EventListener
    public void handleA(EventA event) {
        publisher.publishEvent(new EventB()); // 发布EventB
    }
}

@Component
public class LoopListenerB {
    @Autowired
    private ApplicationEventPublisher publisher;

    @EventListener
    public void handleB(EventB event) {
        publisher.publishEvent(new EventA()); // 发布EventA，形成死循环
    }
}

解决方案：

• 避免在监听器内发布与当前事件相关的新事件；
• 若必须发布，添加循环检测（如通过事件ID记录已处理事件）。

五、选型对比：Spring事件 vs MQ，该怎么选？

很多开发者困惑于“何时用Spring事件，何时用MQ”，核心判断标准是“是否跨JVM”，以下是详细对比：

对比维度	Spring事件驱动	MQ（RocketMQ/Kafka）	选型建议
适用范围	单机内模块协作（同JVM）	跨服务/跨机房通信（跨JVM）	单机内用Spring事件，跨服务用MQ
可靠性	进程宕机事件丢失（无持久化）	支持持久化/重试/死信队列	需保证事件不丢失用MQ
吞吐量	内存级通信，10万+/s	受网络影响，1万-10万/s	单机高并发用Spring事件
开发成本	零配置，注解即用	需搭建中间件，配置生产者/消费者	快速开发用Spring事件
数据一致性	支持事务绑定，本地一致性	需分布式事务（2PC/TCC）	本地事务用Spring事件，分布式事务用MQ
功能丰富度	支持条件过滤、优先级、批量处理	支持延迟队列、广播、分区	需复杂功能（如延迟）用MQ

黄金决策树：

1. 协作范围 → 同JVM → Spring事件；跨JVM → MQ；
2. 可靠性要求 → 事件不可丢失 → MQ；允许偶尔丢失 → Spring事件；
3. 功能需求 → 需延迟/广播/死信 → MQ；仅异步/解耦 → Spring事件；
4. 开发效率 → 快速迭代 → Spring事件；长期稳定 → MQ。

六、总结：事件驱动的核心价值与最佳实践

Spring事件驱动的核心价值是“轻量解耦+高效异步”——无需依赖外部中间件，即可实现单机内模块的解耦，让系统在面对高并发时依然保持灵活可扩展。

最佳实践总结：

1. 事件设计：不可篡改（final字段）、轻量化（仅传核心数据）、预留版本；
2. 监听器设计：单一职责、异步优先、异常隔离、监控告警；
3. 性能优化：异步线程池合理配置、批量处理高频率事件、并行加载提升效率；
4. 选型原则：单机内优先用Spring事件，跨服务用MQ，不盲目追求“重方案”。

最终建议：

• 中小规模系统、快速迭代场景：优先使用Spring事件驱动，降低架构复杂度；
• 大规模分布式系统：核心用MQ实现跨服务通信，单机内模块协作用Spring事件；
• 高并发场景：结合两者优势，Spring事件处理本地异步逻辑，MQ处理跨服务通信。

通过Spring事件驱动，我们可以将系统拆解为“可插拔的模块”，新增功能只需添加监听器，无需修改核心代码——这正是架构设计的艺术：拥抱变化，而非预测变化。

除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接

本文链接：https://www.lifengdi.com/hou-duan/4554