3. 订单簿动态：订单簿的更新机制、撮合引擎原理

订单簿这东西，说白了就是交易所的「记账本」。

每一笔挂单、撤单、成交，都会实时更新这个账本。我个人习惯把订单簿想象成一个动态的排队系统——有人插队，有人离开，有人被叫号成交。嗯，今天我们就来拆解这个系统的内部运作。

3.1 订单簿的底层数据结构

先看数据结构。交易所不会用普通的列表来存订单，那太慢了。我见过最主流的实现是「价格-订单链表」的映射结构。

# 简化版订单簿结构
class OrderBook:
    def __init__(self):
        self.bids = {}  # 买盘：价格 -> 订单链表
        self.asks = {}  # 卖盘：价格 -> 订单链表
        self.best_bid = None  # 最高买价
        self.best_ask = None  # 最低卖价

为什么用链表？因为订单的插入和删除非常频繁。数组的中间插入是 O(n)，链表是 O(1)。你想想看，每秒几千笔订单进来，用数组早就卡死了。

3.2 订单的生命周期

一笔订单从进入系统到最终消失，会经历几个阶段。我把它画成了一张流程图，方便你理解。

这张图我画得比较简洁。实际项目中，每个节点背后还有大量细节。比如「价格检查」这一步，交易所会校验你的价格精度、最小变动单位等。我曾经遇到过一个坑：某个币种的最小价格变动是 0.01，但有人挂了 0.001 的订单，系统直接 reject 了。

3.3 撮合引擎的核心逻辑

撮合引擎，就是那个「谁跟谁成交」的裁判。它的核心逻辑其实很简单：价格优先、时间优先。

• 价格优先：买单出价高的排前面，卖单出价低的排前面。
• 时间优先：同价格下，先挂单的先成交。

但实际实现时，有个细节很多人会忽略——市价单的处理。市价单没有价格，它直接吃对手盘的最优价格。我见过一些新手写的撮合引擎，市价单进来后直接循环遍历对手盘，结果性能惨不忍睹。

3.4 撮合流程的伪代码

下面是一个简化版的撮合流程。注意，这只是教学用途，真实交易所的代码要复杂得多。

def match_order(order):
    if order.side == 'buy':
        # 买单：找卖盘
        while order.quantity > 0 and order.price >= best_ask:
            # 取最优卖单
            sell_order = asks[best_ask].head
            trade_qty = min(order.quantity, sell_order.quantity)
            # 执行成交
            execute_trade(order, sell_order, trade_qty)
            # 更新数量
            order.quantity -= trade_qty
            sell_order.quantity -= trade_qty
            if sell_order.quantity == 0:
                # 移除已成交的订单
                asks[best_ask].remove(sell_order)
                if asks[best_ask].is_empty():
                    del asks[best_ask]
                    update_best_ask()
    else:
        # 卖单逻辑类似，略
        pass

这段代码里有个关键点：update_best_ask()。每次最优价格被吃光后，必须立即更新 best_ask。否则下一笔订单会继续用旧的最优价格，导致成交价错误。

3.5 订单簿的增量更新

真实交易中，订单簿不是每次都全量推送的。那样带宽扛不住。交易所通常采用增量快照机制：

消息类型	说明	示例
snapshot	全量快照，每隔一段时间推送一次	{"type":"snapshot","bids":[[100,10],[99,5]],"asks":[[101,8]]}
update	增量更新，只推送变化的部分	{"type":"update","bids":[[100,0]],"asks":[[102,3]]}

注意看 update 里的 [100, 0]，这表示价格 100 的买单数量变为 0，也就是这个价格档位被删除了。我刚开始做量化时，没注意这个细节，以为数量为 0 的订单只是空了，结果本地订单簿和交易所的永远对不上。

3.6 撮合引擎的延迟优化

撮合引擎的延迟，直接决定了你的策略能不能抢到单。我总结几个常见的优化点：

• 锁粒度：尽量用读写锁，读操作不阻塞。我见过用全局锁的，那性能直接腰斩。
• 内存池：订单对象频繁创建销毁，用内存池复用对象，减少 GC 压力。
• 无锁队列：订单进入和撮合可以用无锁队列解耦，避免锁竞争。

3.7 订单簿的异常处理

最后聊一个容易被忽视的点：异常处理。订单簿更新过程中，可能出现各种意外：

• 网络延迟导致快照和增量顺序错乱
• 重复的订单 ID
• 价格精度溢出

我的做法是：每次收到增量更新时，先校验序列号。如果序列号不连续，就丢弃增量，重新请求全量快照。虽然会损失几毫秒，但能保证数据一致性。

好了，订单簿的更新机制和撮合原理就聊到这里。这些东西看起来基础，但每一个细节都可能成为你策略的胜负手。记住：理解订单簿，就是理解市场的脉搏。