第2章订单簿原理

订单簿原理：构建逻辑、价格优先与时间优先、增量更新机制

做高频交易这些年，我越来越觉得订单簿就是市场的「心跳」。你盯着它，能感受到买卖双方的呼吸节奏。今天咱们就聊聊订单簿的底层逻辑——这东西看着简单，但真要在纳秒级战场上用好它，里面的门道可不少。

说白了，订单簿就是一个「排队簿」。买方排一队，卖方排一队。每笔订单进来，系统就把它塞到对应的队伍里。

我习惯把订单簿想象成两个链表：买盘（Bid）和卖盘（Ask）。每个节点代表一个价格档位，节点里挂着这个价格上的所有订单。

核心数据结构：

举个例子，假设当前市场是这样的：

你看，买盘最高价是10.01，卖盘最低价是10.02。这中间的0.01差价，就是所谓的「价差」（Spread）。

我在搭建第一个订单簿引擎时犯过一个低级错误——用数组来存价格档位。结果每次插入新价格都要移动大量数据，延迟直接飙到微秒级。后来改用跳表（Skip List）才解决问题。嗯，这里要注意：订单簿的底层数据结构，直接决定了你的延迟天花板。

这两个原则，是订单簿的「宪法」。任何交易所都得遵守。

价格优先：买方出价高的优先成交，卖方要价低的优先成交。这很好理解——谁出的条件好，谁先成交。

时间优先：价格相同的情况下，先到先得。这就跟排队买奶茶一样，先来的先喝。

我曾经帮一家券商优化过撮合引擎。他们原来的代码里，时间优先是用一个全局时间戳来比较的。但问题是，在高并发场景下，两个订单可能落在同一个纳秒里。你想想看，这怎么比？

解决方案其实很简单：用序列号（Sequence Number）代替时间戳。每个订单进来时，原子递增一个全局计数器。这样既保证了唯一性，又避免了时钟同步的问题。

实战技巧：在实现时间优先时，别用系统时间。用单调递增的序列号，性能更好，也更可靠。

全量推送订单簿？那是新手才干的事。高频交易里，每一微秒都是钱。全量推送一次，可能几百KB的数据量，网络延迟直接爆炸。

所以，我们只推送增量更新。说白了，就是只告诉你「变了什么」，而不是「现在是什么样」。

增量更新的消息类型通常有这几种：

举个例子，假设卖盘10.02这个档位原来有500股。现在来了一个撤单，撤掉了200股。增量更新消息就是：

{
  "type": "Cancel",
  "price": 10.02,
  "side": "Ask",
  "size": 200,
  "order_id": "abc123"
}

客户端收到这个消息后，只需要把本地订单簿里10.02这个档位的数量减掉200就行。整个过程，可能只需要几十纳秒。

避坑指南：我曾经遇到过一个问题——增量更新消息丢失了。结果本地订单簿和交易所的订单簿对不上，导致策略做出了错误的交易决策。后来我加了一个序列号校验机制：每条增量消息都带一个递增的序列号，客户端发现序列号不连续时，立即请求全量快照进行同步。

增量更新的核心挑战在于：如何保证本地订单簿和交易所订单簿的最终一致性。我的做法是：

你想想看，如果没有这个机制，一旦出现数据不一致，你的策略就是在「盲打」。那后果...嗯，我不说你也懂。

说了这么多，咱们用一张图来总结订单簿的核心逻辑：

这张图展示了订单簿的核心结构。左边是买盘，右边是卖盘。每个价格档位都按时间顺序排列。中间的价差，就是市场流动性的「温度计」。

我个人习惯在监控面板上同时显示三个东西：订单簿快照、增量更新流、以及本地重建后的订单簿。一旦发现本地和交易所的不一致，立刻报警。这招帮我避免过好几次重大事故。

总结一下：

好了，订单簿的原理就聊到这儿。下一节咱们会深入盘口数据的实战解析——到时候我会拿真实的Level-2数据来演示，怎么从订单簿里嗅出主力的意图。