第2章事件驱动框架

事件驱动框架：让订单簿“活”起来

好，咱们接着聊。上一章我们搞清楚了订单簿的数据结构，说白了就是一堆挂单在那里排队。但问题来了——数据是死的，策略是活的。你怎么让这些数据“动”起来？

答案就是事件驱动。我个人习惯把事件驱动理解成“条件反射”。你想想看，狗看到肉会流口水，对吧？那我们的程序呢，看到订单簿有变化，就得立刻做出反应。这就是事件驱动的核心。

事件驱动编程模型

传统的编程模型，就像你写一个菜谱，从头到尾一步步执行。但事件驱动不一样，它更像一个服务员——站在那儿等着，客人一招手（事件发生），他就过去服务（执行回调）。

在量化交易里，这个模型特别适合。为什么？因为市场是不可预测的。你不知道下一秒是有人砸盘还是拉盘。你只能等事件发生，然后快速响应。

核心三要素：

事件源——谁产生事件？订单簿、成交记录、行情推送
事件循环——一直在那“监听”的循环体
事件处理器——真正干活的函数

我在项目中遇到过一种情况：有人把事件驱动和轮询搞混了。轮询是你每隔一秒去问“有变化吗？”，事件驱动是“有变化了通知你”。前者浪费CPU，后者高效得多。嗯，这里要注意，高频交易里差几微秒可能就是几百万的差距。

事件循环：程序的“心脏”

事件循环，说白了就是一个死循环。但它不是傻转，它是有节奏地转。

# 一个简化的事件循环
while True:
    event = get_next_event()  # 从队列里拿下一个事件
    if event is None:
        continue              # 没事件就歇着
    handle_event(event)       # 有事件就处理

你看，就这么几行。但实际生产环境里，这个循环要处理的事情多得多：

管理多个事件源（比如同时监听多个交易对）
控制处理优先级（大单事件优先处理）
超时处理（如果一个事件处理太久，得能打断）

我的经验：事件循环里千万别做耗时操作。我曾经犯过一个错，在事件处理器里写了个数据库写入操作，结果行情一快，事件队列直接爆了。后来改成异步写入，问题就解决了。

事件处理器：真正干活的

事件处理器就是回调函数。但回调函数这个名字，我觉得有点误导人。它不是什么“回头再调”，而是“来了就调”。

在订单簿策略里，事件处理器通常长这样：

def on_orderbook_update(event):
    """
    订单簿更新事件处理器
    event 包含：交易对、更新类型、价格、数量
    """
    symbol = event['symbol']
    update_type = event['type']  # 'add', 'remove', 'update'
    price = event['price']
    size = event['size']
    
    # 更新本地订单簿
    orderbook.update(symbol, update_type, price, size)
    
    # 检查是否有交易信号
    signal = check_signal(orderbook)
    if signal:
        execute_trade(signal)

这里有个关键点：事件处理器要尽量轻量。你想想看，如果每秒有几千次订单簿更新，你的处理器要是跑个几百毫秒，那后面的事件全得排队等着。市场早变样了。

避坑指南：我曾经在事件处理器里加了日志打印，结果生产环境日志量太大，直接把磁盘写满了。后来我改用采样日志——每100个事件才打一条。记住，事件处理器里不要做任何I/O操作，除非你确定它不会阻塞。

回调函数：事件驱动的“灵魂”

回调函数，说白了就是把一个函数当作参数传给另一个函数。在事件驱动里，你告诉事件循环：“嘿，如果订单簿变了，就调用我这个函数。”

Python里实现回调很简单：

class OrderBookEngine:
    def __init__(self):
        self.callbacks = []
    
    def register_callback(self, callback):
        """注册回调函数"""
        self.callbacks.append(callback)
    
    def on_data(self, data):
        """收到新数据时，调用所有回调"""
        for callback in self.callbacks:
            callback(data)

# 使用示例
engine = OrderBookEngine()
engine.register_callback(on_orderbook_update)
engine.register_callback(on_trade_log)  # 可以注册多个

为什么叫“回调”？其实是因为控制权反转。正常情况下，是你调用库函数。但在事件驱动里，是库函数反过来调用你的函数。嗯，刚开始接触这个概念的同事经常搞混，习惯了就好。

完整的事件驱动框架图

下面这张图，是我自己画的事件驱动框架。你看一眼就能明白整个流程：

实际项目中的事件驱动设计

说了这么多理论，咱们看看实际项目里怎么用。我一般会把事件驱动拆成三层：

层级	职责	示例
接入层	连接交易所，接收原始数据	WebSocket 连接、REST API 轮询
处理层	数据清洗、事件生成、队列管理	订单簿重建、事件分类、优先级排序
策略层	信号生成、风控、执行	价差检测、挂单策略、止损检查

这三层之间通过事件队列通信。接入层只管收数据，处理层只管清洗和生成事件，策略层只管做决策。各司其职，互不干扰。

我的建议：刚开始做事件驱动时，别想着一步到位。先写一个简单的事件循环，注册一两个回调，跑通了再慢慢加功能。我见过太多人一上来就想搞个分布式事件总线，结果连本地的事件都没处理好。

最后说一句，事件驱动框架看着简单，但真正用好它，需要你对业务有深刻理解。什么样的数据需要触发事件？事件的优先级怎么定？处理失败了怎么办？这些问题，咱们后面的章节会一个一个解决。

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

📚 课程目录

事件驱动框架：让订单簿“活”起来

事件驱动编程模型

事件循环：程序的“心脏”

事件处理器：真正干活的

回调函数：事件驱动的“灵魂”

完整的事件驱动框架图

实际项目中的事件驱动设计