第1章事件驱动入门

1. 事件驱动入门：什么是事件驱动架构

各位同学好，我是老张。在量化交易这行摸爬滚打了十来年，今天咱们聊聊事件驱动架构。说实话，这个概念刚出来那会儿，我也觉得挺玄乎的。但用久了你会发现，它其实就是一套「等通知、再干活」的思路。

你想想看，传统的程序是怎么跑的？一条指令接一条指令，顺序执行。就像你去食堂打饭，必须排队，前面的人没打完，你就得等着。但事件驱动不一样——它更像你手机上的消息推送。微信来了新消息，手机会「叮」一声提醒你，你再去查看。没人催你的时候，你该干嘛干嘛。

核心思想：事件驱动架构是一种基于「事件产生 → 事件分发 → 事件处理」的编程范式。系统不主动轮询状态，而是等待事件发生后再响应。

1.1 量化交易中的事件类型

我在实战中，把量化交易里的事件分成三大类。这三类事件，几乎覆盖了你日常交易中遇到的所有情况。

事件类型	触发条件	典型示例
市场事件	行情数据变化	Tick更新、K线收盘、订单簿变化
订单事件	订单状态变更	委托成交、撤单成功、拒单
账户事件	账户资产变动	资金划转、持仓更新、风控触发

市场事件是最常见的。比如你监控某只股票的Tick数据，每来一笔新的成交，系统就会抛出一个事件。我早期做高频策略时，就靠这个捕捉盘口异动。嗯，这里要注意——市场事件的频率可能非常高，处理不好容易把系统打崩。

订单事件呢，说白了就是你的交易指令在交易所那边的「人生轨迹」。你下了个买单，系统会依次收到「已提交」「部分成交」「全部成交」这些事件。我曾经踩过一个坑：以为订单提交了就万事大吉，结果没监听「拒单」事件，白白错过了行情。

账户事件相对低频，但极其重要。资金变动、持仓变化、甚至风控规则的触发，都属于这一类。我个人习惯把账户事件单独开一个线程处理，避免影响交易主流程。

1.2 事件驱动 vs 轮询模式

聊完事件类型，咱们来对比一下两种模式。我直接画个图，大家一看就明白。

轮询模式就像你每隔5分钟给女朋友发条微信：「在吗？」「在吗？」「在吗？」——不仅自己累，对方也烦。事件驱动则是她主动告诉你：「我到了，来接我。」

具体到量化交易，区别更明显：

轮询模式：程序每隔100ms去查一次行情接口，问「价格变了吗？」。没变就白查，变了才处理。我见过有人用轮询做高频，结果CPU占用率飙到90%，大部分都在做无用功。
事件驱动模式：行情推送来了，程序才被唤醒。平时处于休眠或低功耗状态。说白了，就是「没事别烦我，有事叫我」。

我的建议：如果你做的是T+0级别的短线交易，或者策略对延迟敏感，请务必使用事件驱动。如果是日频甚至周频的策略，轮询其实也能凑合——但既然学了这门课，咱们就一步到位。

1.3 一个简单的事件驱动示例

光说不练假把式。我写个最简单的Python示例，大家感受一下事件驱动的味道。

# 一个极简的事件驱动框架
class Event:
    def __init__(self, event_type, data):
        self.type = event_type    # 事件类型
        self.data = data          # 事件数据

class EventEngine:
    def __init__(self):
        self.handlers = {}        # 事件处理器注册表
    
    def register(self, event_type, handler):
        """注册事件处理器"""
        if event_type not in self.handlers:
            self.handlers[event_type] = []
        self.handlers[event_type].append(handler)
    
    def put(self, event):
        """触发事件"""
        if event.type in self.handlers:
            for handler in self.handlers[event.type]:
                handler(event)

# 使用示例
def on_tick(event):
    print(f"收到Tick: {event.data['symbol']} 价格={event.data['price']}")

def on_order(event):
    print(f"订单状态更新: {event.data['order_id']} -> {event.data['status']}")

engine = EventEngine()
engine.register('tick', on_tick)
engine.register('order', on_order)

# 模拟行情推送
engine.put(Event('tick', {'symbol': 'BTC/USDT', 'price': 50000}))
engine.put(Event('order', {'order_id': '12345', 'status': 'filled'}))

这段代码虽然简陋，但麻雀虽小五脏俱全。你看到了吗？EventEngine 就像一个消息中转站。不同的模块往里面扔事件，对应的处理器自动被调用。各模块之间完全解耦，互不干扰。

避坑指南：我曾经在事件处理函数里直接写了耗时操作（比如写数据库），结果导致后续事件排队，系统延迟从微秒级飙升到秒级。记住：事件处理器里不要做耗时操作，实在要做，请用异步或丢到消息队列里。

1.4 事件驱动架构的优势

总结一下，事件驱动架构在量化交易中有几个实打实的好处：

低延迟：事件一来就处理，不用等轮询周期。对于高频策略，这可能是盈利和亏损的分水岭。
资源高效：没有事件时CPU可以休息。我优化过一个策略，从轮询改成事件驱动后，CPU占用从85%降到了12%。
扩展性好：想加一个新策略？注册一个新的事件处理器就行。老代码不用动，新代码往里插。
逻辑清晰：每个事件对应一个处理函数，代码结构一目了然。你想想看，维护一个事件驱动的代码库，比维护一堆if-else嵌套的轮询代码舒服多了。

当然，事件驱动也不是银弹。它需要你改变编程思维，而且事件处理的顺序和并发问题需要额外注意。但这些咱们后面章节会一一攻克。

好了，第一章就到这里。记住今天这三个关键词：市场事件、订单事件、账户事件。下一章咱们开始动手搭建一个真正能跑的事件驱动引擎。

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

📚 课程目录

1. 事件驱动入门：什么是事件驱动架构

1.1 量化交易中的事件类型

1.2 事件驱动 vs 轮询模式

1.3 一个简单的事件驱动示例

1.4 事件驱动架构的优势