事件驱动架构概述：事件驱动 vs 轮询、事件循环与回调、发布-订阅模式、消息队列基础
好，咱们直接进入正题。这一章聊的是事件驱动架构的核心概念。说实话，我见过太多做量化交易的朋友，一上来就写轮询代码，结果系统一跑起来，CPU 飙到 100%，订单却还卡在路上。嗯，这其实是个很典型的坑。
事件驱动 vs 轮询：两种思维模式
先说说轮询。轮询就像你每隔 5 分钟去问前台「有我的快递吗？」。如果快递没到，你就白跑一趟。如果快递到了，你可能已经晚了 4 分 59 秒。在交易系统里，这种延迟是致命的。
事件驱动则完全不同。它就像前台收到快递后直接打电话通知你：「嘿，你的货到了，快来拿！」。你不需要主动去问，系统会在数据到达的那一刻主动通知你。
我个人习惯把这两种模式画个对比表，方便团队新人理解：
| 特性 | 轮询 | 事件驱动 |
|---|---|---|
| CPU 利用率 | 高（空转浪费） | 低（有事件才干活） |
| 响应延迟 | 取决于轮询间隔 | 接近实时 |
| 代码复杂度 | 简单但低效 | 稍复杂但高效 |
| 扩展性 | 差（线性增长） | 好（异步非阻塞） |
我在项目中遇到过一位同事，坚持用轮询去拉取交易所的深度数据。结果呢？行情稍微一波动，CPU 直接拉满，订单簿重建延迟从 2 毫秒飙升到 200 毫秒。后来改成事件驱动，同样的硬件，延迟稳定在 1 毫秒以内。说白了，选对架构比堆硬件更重要。
事件循环与回调：核心机制
事件驱动架构的心脏，就是事件循环。你想想看，一个系统怎么知道「有事件来了」？答案就是事件循环——一个永不停歇的「监听-分发」循环。
伪代码大概长这样：
while (true) {
event = getNextEvent(); // 从事件队列取一个事件
if (event) {
dispatch(event); // 分发给对应的回调函数
}
// 没事件？那就歇着，不占 CPU
}回调函数就是「当事件发生时，你要执行的代码」。比如订单簿更新事件来了，回调函数就去重建订单簿。我曾经犯过一个错误：在回调里做了大量计算，导致事件循环被阻塞。结果后面的订单事件排着队等，延迟直接爆炸。
为什么会这样？因为事件循环是单线程的。你想想看，如果回调里有个死循环，整个系统就卡死了。所以，保持回调轻量、快速，这是铁律。
发布-订阅模式：解耦的艺术
发布-订阅模式，说白了就是「我不直接找你，我喊一嗓子，谁感兴趣谁来」。在订单簿系统里，这个模式特别好用。
举个例子：行情网关收到一笔新的订单簿快照，它不需要知道谁需要这个数据。它只需要发布一个「OrderBookSnapshot」事件。订单簿重建模块订阅了这个事件，收到后就干活。风控模块也订阅了，收到后做校验。日志模块也订阅了，收到后记录。
你看，发布者和订阅者完全解耦。我习惯用这样的结构图来表示：
这个模式的好处很明显：新增一个模块，只需要订阅对应的事件，不需要改任何已有代码。我在重构一个老系统时，就是靠发布-订阅模式，把原本耦合在一起的代码拆成了 7 个独立模块，每个模块只关心自己订阅的事件。维护成本直线下降。
消息队列基础：事件的中转站
消息队列，说白了就是事件的「缓冲区」。为什么需要它？因为生产事件的速度和消费事件的速度往往不一致。比如行情爆发时，每秒可能产生几万笔订单事件，但订单簿重建模块每秒只能处理几千笔。如果没有队列，事件就会丢失。
消息队列的核心概念就三个：生产者、队列、消费者。生产者把事件扔进队列，消费者从队列里取事件处理。就这么简单。
我建议你在设计订单簿系统时，至少分两层队列：
- 一级队列（内存级）：处理毫秒级的高频事件，比如行情 tick、订单簿增量更新。延迟要控制在微秒级。
- 二级队列（持久化）：处理秒级的中低频事件，比如订单确认、成交回报。需要保证不丢数据。
我曾经在项目中只用了一个内存队列，结果系统重启后，队列里还没处理完的事件全丢了。后来加了持久化队列做备份，虽然多了一点延迟，但数据安全性大大提升。嗯，这里要注意：没有银弹，要根据场景选合适的队列。
好了，这一章的内容就这些。事件驱动架构的核心思想其实不复杂：别主动去问，等着被通知。轮询是「我去找你」，事件驱动是「你来找我」。发布-订阅让模块之间解耦，消息队列让事件有地方暂存。把这些基础打牢，后面讲订单簿重建的具体实现时，你会觉得顺理成章。