一、订单簿基础：定义、盘口、原则与位置

订单簿，说白了就是交易所用来记录所有买卖挂单的电子账本。我刚开始接触量化时，觉得这东西不就是个价格列表吗？后来才发现，订单簿是整个交易系统的「心脏」——所有撮合逻辑、行情推送、策略决策，都绕不开它。

1.1 订单簿的定义

订单簿（Order Book）是一个动态的数据结构。它维护着两个核心队列：

• 买单队列（Bid Queue）：按价格从高到低排列
• 卖单队列（Ask Queue）：按价格从低到高排列

每个队列里的订单，都包含价格、数量、时间戳、订单ID等信息。嗯，这里要注意：不同交易所对订单属性的定义略有差异，但核心字段基本一致。

1.2 买卖盘口

盘口（Order Book Depth）就是订单簿的「快照」。它展示了当前市场上所有挂单的分布情况。我个人习惯把盘口分为三层：

• 最优盘口：买一（最高买价）、卖一（最低卖价）
• 深度盘口：买二到买N、卖二到卖N
• 全量盘口：所有价位的挂单明细

我在项目中遇到过一个问题：某次回测时，策略只用了最优盘口数据，结果实盘时滑点巨大。为什么？因为最优盘口只有薄薄一层，真正的大单都在后面。你想想看，如果只看买一卖一，就像只看冰山一角——下面藏着多大的量，你根本不知道。

盘口层级	数据量	典型用途
最优盘口	2条记录	实时行情、快速判断
深度盘口	10-50条记录	流动性分析、订单簿重建
全量盘口	数百到数千条	回测、微观结构研究

1.3 价格优先、时间优先原则

这是撮合引擎的「宪法」。说白了就两句话：

1. 价格优先：买单出价高的先成交，卖单出价低的先成交
2. 时间优先：同价格下，先挂单的先成交

我曾经踩过一个坑：在实现撮合逻辑时，忘了处理「同价格不同时间」的情况。结果回测时一切正常，实盘时却出现了订单「插队」现象——后来排查发现，是时间戳精度不够，导致两个订单的时间戳相同。嗯，从那以后，我强制要求所有订单必须携带纳秒级时间戳。

1.4 订单簿在交易系统中的位置

订单簿不是孤立存在的。它处于交易系统的「中间层」：

• 上游：接收交易所的行情数据（增量更新或全量快照）
• 中游：维护订单簿状态，提供查询接口
• 下游：策略引擎、风控模块、监控系统

我习惯把订单簿比作「数据枢纽」——所有模块都依赖它，但谁都不能直接修改它。为什么？因为并发访问会搞乱状态。你想想看，如果策略引擎和风控模块同时修改订单簿，那数据就乱套了。

这张图展示了我常用的架构。订单簿引擎处于中心位置，上游只接收行情数据，下游只查询状态。这种「读写分离」的设计，能有效避免并发冲突。我在多个项目中验证过，这种架构在百万级订单/秒的压力下依然稳定。