3、订单簿数据结构：价格-数量队列、Level 2/Level 3数据、增量更新机制

订单簿这东西，说白了就是交易所的「实时账本」。你每下一笔单，它都会记下来。我做了这么多年量化，见过不少人把订单簿当成简单的买卖列表，结果策略一上线就亏钱。嗯，今天咱们就把这个数据结构彻底讲透。

3.1 价格-数量队列：订单簿的原子单位

先看最基础的东西。订单簿里每一档价格，都对应一个队列。这个队列里存的是啥？就是在这个价格上，所有未成交的订单。

举个例子，比特币在 30000 这个价位上有 5 个买单，每个买 1 个 BTC。那这个价格队列的长度就是 5，总数量是 5。我个人习惯把这种结构叫做「价格-数量对」——价格是 key，数量是 value。

我在项目中遇到过一个问题：某个策略同时监控多个交易所，结果发现同一价格档位的队列深度差异巨大。后来排查发现，有的交易所把「冰山订单」也暴露在队列里，有的则隐藏了部分数量。这个坑，大家一定要注意。

3.2 Level 2 数据：市场深度的「快照」

Level 2 数据，也叫市场深度数据。它展示的是订单簿的「当前状态」——每个价格档位上有多少买单和卖单。

你想想看，如果你只看买卖一档，那信息量太少了。Level 2 通常给你看 10 档、20 档甚至 50 档。我建议至少看 10 档，这样才能判断出真正的支撑位和压力位。

上面这个表就是典型的 Level 2 数据。注意看，30000 这个整数关口，买单有 8.3 个，卖单为 0。这说明啥？说明买方在死守这个价位。我记得有一次做股指期货，就是靠这种整数关口的订单簿分析，提前预判了反弹。

3.3 Level 3 数据：每一笔订单的「身份证」

Level 3 数据比 Level 2 更细。它不光告诉你每个价格上有多少单，还告诉你每一笔订单的详细信息——订单 ID、下单时间、数量、买卖方向等等。

说白了，Level 3 是「全量订单簿」。你拿到这个数据，就能还原出交易所撮合引擎的完整状态。我个人觉得，做高频交易的人必须用 Level 3，否则你根本不知道对手盘在干嘛。

// 一个典型的 Level 3 订单结构
{
  "order_id": "abc123",
  "price": 30000,
  "quantity": 1.5,
  "side": "buy",
  "timestamp": 1696000000000,
  "type": "limit"
}

为什么说 Level 3 重要？因为它能让你看到「订单的寿命」。比如某个大单挂上去 5 秒就撤了，那很可能是试探性挂单。我曾经用这个特征识别出好几个做市商的机器人——它们总是在价格波动前几秒撤单。

3.4 增量更新机制：别每次都全量拉取

好，现在问题来了。订单簿每秒都在变，难道每次都要重新拉取整个 Level 2 或 Level 3 数据吗？

当然不是。交易所提供了「增量更新」机制——只告诉你「变了什么」，而不是「全部是什么」。

增量更新通常包含三种操作：

• 新增（Add）： 新挂了一笔订单
• 删除（Delete）： 一笔订单被撤销或成交
• 修改（Modify）： 订单数量变了（比如部分成交）

你本地维护一个订单簿副本，然后不断接收增量事件，实时更新这个副本。这样带宽和计算量都小得多。

3.5 知识体系总览

下面这张图，是我自己总结的订单簿数据结构全景。你看一眼就能明白各个概念之间的关系。

从这张图能看出来，价格-数量队列是地基，Level 2 和 Level 3 是两种不同粒度的上层建筑。而增量更新机制，则是让整个系统高效运转的「润滑剂」。

好了，这一章的内容就到这里。记住：订单簿不是静态的表格，它是一个动态的、不断变化的数据流。理解了这个本质，你才能用好它。