事件驱动架构：从传统轮询到事件驱动

大家好，我是你们的老朋友。今天咱们聊聊事件驱动架构——这个在流处理领域绕不开的话题。

说实话，我最早接触这个理念时，心里是有点抵触的。那时候我习惯写轮询代码，觉得“定时去查一下”多简单啊。直到有一次，我在一个物联网项目里被轮询坑惨了——几万个传感器，每秒轮询一次，数据库直接被打挂了。嗯，从那以后，我才真正开始认真研究事件驱动。

传统轮询：为什么我们不再用它？

先说说轮询。说白了，就是客户端主动去问服务端：“有数据了吗？”

伪代码大概是这样的：

while (true) {
    Thread.sleep(1000);  // 每秒查一次
    List<Event> events = queryDatabase("SELECT * FROM events WHERE processed = 0");
    for (Event event : events) {
        process(event);
    }
}

你想想看，这里有几个问题：

• 资源浪费：大部分查询都是空转，白白消耗CPU和IO
• 实时性差：事件发生后，最多要等一个轮询周期才能被处理
• 扩展性差：数据量一上来，轮询频率不敢调高，调高了数据库扛不住

我在项目中遇到过最夸张的情况——有个团队把轮询间隔设成了100毫秒，结果数据库连接池直接被打满，连正常的业务查询都受影响。这就是典型的“用战术上的勤奋掩盖战略上的懒惰”。

事件驱动架构：换个思路看问题

事件驱动的核心思想其实很简单：别主动去问，等着被通知。

就像你等外卖——你不会每隔一分钟就给商家打个电话问“做好了没”，而是等商家做好后主动通知你。这个“通知”就是事件。

事件驱动架构有三个核心组件，我一个个说：

事件生产者（Event Producer）

谁产生事件？就是生产者。它可能是：

• 用户点击按钮的前端页面
• 传感器上报数据的IoT设备
• 数据库变更的CDC（Change Data Capture）组件
• 另一个微服务发出的业务通知

生产者只管“发出事件”，它不需要知道谁会消费这个事件。这种解耦，是事件驱动最大的魅力。

事件通道（Event Channel）

事件从生产者到消费者，中间需要一个通道。这个通道可以是：

• 消息队列：Kafka、RabbitMQ、Pulsar
• 事件总线：比如Spring Cloud Bus
• 日志系统：比如Kafka本身就可以当日志用

通道的作用不仅仅是“传数据”，它还负责：

• 缓冲：生产者和消费者速度不一致时，通道能扛住压力
• 持久化：事件不会丢，消费者挂了还能重放
• 路由：一个事件可以发给多个消费者

我个人习惯用Kafka做事件通道。为什么？因为它能保证分区内的顺序，而且吞吐量极高。但要注意——Kafka不是银弹，如果你的场景不需要持久化，用Redis的Pub/Sub可能更轻量。

事件处理器（Event Processor）

处理器就是消费事件的组件。它从通道里拉取事件，然后做业务逻辑处理。

处理器的设计有几个要点：

• 幂等性：同一个事件处理两次，结果应该一样。我踩过这个坑——有一次事件重复投递，导致用户被扣了两次钱
• 无状态：处理器最好是无状态的，这样方便水平扩展
• 错误处理：处理失败的事件要能重试，或者进入死信队列

// 一个简单的事件处理器示例
public class OrderEventHandler {
    
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        try {
            // 处理订单创建逻辑
            inventoryService.deductStock(event.getProductId(), event.getQuantity());
            notificationService.sendEmail(event.getUserId(), "订单已创建");
        } catch (Exception e) {
            // 记录失败事件，后续重试
            deadLetterQueue.send(event, e);
            log.error("处理订单创建事件失败: {}", event.getOrderId(), e);
        }
    }
}

事件驱动架构的优势

说了这么多，事件驱动到底好在哪？我总结了几点：

优势	说明
解耦	生产者和消费者互不知道对方存在，各自独立演进
实时性	事件一发生就处理，没有轮询延迟
弹性	消费者可以独立扩缩容，高峰期通道能缓冲压力
可追溯	事件日志就是天然的审计记录，出了问题可以回放

我记得有个电商项目，原来用RPC调用做订单处理。每次大促，订单服务一挂，整个链路都瘫痪。后来改成事件驱动，订单服务挂了，事件还在Kafka里存着，等它恢复后继续消费——系统可用性从99.9%提升到了99.99%。

事件驱动架构的挑战

当然，没有银弹。事件驱动也有它的坑：

我曾经在一个金融项目里，因为没处理好事件乱序问题，导致账户余额计算错误。后来我们给每个用户的事件都路由到同一个Kafka分区，才彻底解决。

核心逻辑图：事件驱动架构全景

下面这张图，是我自己画的事件驱动架构核心流程。你可以看到事件从产生到消费的完整链路：

这张图把事件驱动的核心链路画得很清楚。你想想看，从生产者到通道再到处理器，每个环节各司其职，互不干扰。这就是事件驱动能支撑高并发、高可用的根本原因。

---

公众号:蓝海资料掘金营，微信deep3321