3. 事件驱动机制：事件类型划分与实战避坑

事件驱动，说白了就是状态机里的“触发器”。状态不会自己变，得有人踹它一脚。这一脚就是事件。

我见过太多团队，状态图画得漂漂亮亮，一上线就崩。为什么？事件没管好。今天咱们就把事件这块掰开揉碎，看看里面到底有多少坑。

3.1 事件类型划分：内部事件 vs 外部事件

事件分两种：内部事件和外部事件。这个区分很重要，因为它直接决定了你的状态机该怎么响应。

维度	内部事件	外部事件
来源	状态机自身产生	外部系统或用户触发
示例	超时、重试次数耗尽、状态自检失败	用户点击、API调用、消息队列推送
可靠性要求	高（内部逻辑依赖）	中（可降级或重试）
处理优先级	通常较高	视业务而定
典型风险	死循环、资源泄漏	并发冲突、数据不一致

我个人习惯，在设计状态机时先把事件分类画出来。内部事件用虚线框，外部事件用实线框。这样一眼就能看出哪些事件是“自己人”，哪些是“外来客”。

为什么？内部事件是状态机自己产生的，如果它不幂等，一旦重试就可能重复触发。外部事件来自不可控的源头，你不校验，脏数据就进来了。

3.2 事件优先级：别让低优先级事件堵了高优先级的路

事件多了，就得排队。谁先谁后？这就是优先级的问题。

我在项目中遇到过这样一个场景：订单状态机同时收到“支付成功”和“取消订单”两个事件。按业务逻辑，支付成功应该优先处理。但代码里没做优先级控制，结果取消订单先执行了，订单被关掉，支付回调回来时状态已经不对了。

嗯，那次事故让我养成了一个习惯：所有事件必须带优先级标签。

// 事件优先级定义示例
public enum EventPriority {
    CRITICAL(0),   // 关键事件，立即处理
    HIGH(1),       // 高优先级
    NORMAL(2),     // 普通
    LOW(3);        // 低优先级，可延迟

    private final int level;
    EventPriority(int level) { this.level = level; }
    public int getLevel() { return level; }
}

// 事件队列实现
public class PriorityEventQueue {
    private final PriorityBlockingQueue<StateEvent> queue = 
        new PriorityBlockingQueue<>(11, 
            Comparator.comparingInt(e -> e.getPriority().getLevel()));
    
    public void enqueue(StateEvent event) {
        queue.offer(event);
    }
    
    public StateEvent dequeue() throws InterruptedException {
        return queue.take();
    }
}

3.3 事件丢失与重试：最容易被忽视的坑

事件丢失，说白了就是“踹了一脚，但没踹到”。状态机没反应，业务卡住了。

我曾经负责过一个支付系统，线上偶尔出现“支付成功但订单没更新”的问题。查了半天，发现是事件在传输过程中丢了。消息队列确认了发送，但状态机没收到。为什么？网络抖动，ACK丢了。

从那以后，我定了一条铁律：所有关键事件必须实现至少一次投递（at-least-once）。

但“至少一次”又带来了新问题：重复事件。所以还得配合幂等处理。

// 带指数退避的重试逻辑
public class EventRetryHandler {
    private static final int MAX_RETRIES = 5;
    private static final long BASE_DELAY_MS = 100;
    
    public boolean processWithRetry(StateEvent event) {
        for (int attempt = 0; attempt < MAX_RETRIES; attempt++) {
            try {
                return processEvent(event);
            } catch (Exception e) {
                long delay = BASE_DELAY_MS * (long) Math.pow(2, attempt);
                Thread.sleep(delay);
                // 记录重试日志
                log.warn("事件处理失败，第{}次重试，延迟{}ms", attempt + 1, delay);
            }
        }
        // 超过最大重试次数，进入死信队列
        sendToDeadLetterQueue(event);
        return false;
    }
}

3.4 事件风暴的应对：别让系统被冲垮

事件风暴，就是短时间内大量事件涌入。比如秒杀、大促、热点事件。这时候状态机如果处理不过来，就会雪崩。

你想想看，一个订单状态机平时每秒处理100个事件，突然来了10000个。队列满了，内存爆了，CPU打满了。然后呢？整个系统挂了。

怎么应对？我总结了三个策略：

1. 限流：在入口处控制事件流入速率。超过阈值直接拒绝或降级。
2. 削峰：用消息队列做缓冲，让状态机按自己的节奏处理。
3. 隔离：不同业务的事件走不同的队列，避免互相影响。

下面这张图展示了事件驱动的整体架构和风暴应对策略：

3.5 实战总结：事件处理的黄金法则

说了这么多，最后总结几条我这些年摸爬滚打出来的经验：

• 事件分类：内部事件和外部事件分开管理，处理策略不同
• 优先级控制：所有事件带优先级标签，用优先级队列调度
• 至少一次投递：关键事件必须保证不丢，配合幂等处理
• 指数退避重试：重试要有退避策略，设置最大重试次数
• 风暴应对：限流+削峰+隔离，保核心弃边缘