3. Tick数据与增量行情概述
在构建任何行情系统之前，必须先厘清一个基础问题：我们究竟在处理什么样的数据。Tick数据是市场最小粒度的行情记录，它描述的是“某一时刻发生了什么”，而不是“当前状态是什么”。理解Tick、快照、增量、逐笔委托、逐笔成交以及订单簿更新事件之间的关系，是后续订单簿重建实战的起点。
一、Tick的定义与本质
Tick通常指交易所行情网关推送的一条最小行情消息，它带有时间戳、证券代码、事件类型和具体字段。Tick不是“价格变动一次”这么简单，它可能是一次委托、一笔成交、一次撤单，也可能是一次状态变更。不同交易所对Tick的封装不同，但核心思想一致：Tick是事件流，而不是状态快照。
从工程视角看，Tick具备三个关键属性：
- 有序性：同一交易通道内，Tick按交易所生成的顺序到达，序号或时间戳可用于排序与去重。
- 增量性：多数Tick只描述变化部分，例如“新增一笔买单”或“成交了100股”，而不是完整订单簿。
- 可重放性：只要保存原始Tick序列，就能在本地重放并重建任意时刻的订单簿状态。
二、快照与增量的区别
快照（Snapshot）是某一时刻订单簿的完整切片，通常包含买卖各档价格与数量；增量（Incremental）则是相邻快照之间的变化量。两者在行情系统中承担不同角色：快照用于初始化与校验，增量用于实时更新。
| 对比维度 | 快照行情 | 增量行情 |
|---|---|---|
| 数据内容 | 完整订单簿切片，含多档买卖盘 | 仅包含变化事件，如新增、修改、删除 |
| 数据量 | 较大，随档位增加而增长 | 较小，通常单条仅几十字节 |
| 更新频率 | 低频，如每秒或每几百毫秒 | 高频，逐笔实时推送 |
| 主要用途 | 初始化本地订单簿、定时校准 | 实时维护订单簿、驱动策略信号 |
| 丢失影响 | 可重新获取，影响有限 | 导致状态不一致，必须重放或重新初始化 |
三、逐笔委托、逐笔成交与订单簿更新事件
增量行情内部又可细分为多种事件类型，其中最常见的是逐笔委托和逐笔成交。它们共同驱动订单簿更新。
- 逐笔委托：描述一笔新订单进入交易所订单簿，字段通常包括委托序号、方向、价格、数量、订单类型。它是订单簿“挂单”的来源。
- 逐笔成交：描述买卖双方撮合成交，字段包括成交价、成交量、买卖委托序号。它会导致订单簿中对应订单数量减少甚至删除。
- 订单簿更新事件：这是本地系统根据逐笔委托与逐笔成交推导出的抽象事件，例如“新增档位”“修改档位数量”“删除档位”。它直接作用于本地订单簿数据结构。
三者的关系可以概括为：逐笔委托和逐笔成交是交易所原始输入，订单簿更新事件是本地重建过程的中间产物。下面用一张SVG展示从原始Tick到订单簿状态的数据链路。
四、案例：一笔限价买单的完整生命周期
假设某股票当前卖一价为10.00元，数量500股。现在有一笔新限价买单进入：价格10.00元，数量300股。我们观察Tick层面的变化。
事件1：逐笔委托
{
"type": "ORDER",
"side": "BUY",
"price": 10.00,
"qty": 300,
"orderId": "B1001",
"timestamp": "09:30:01.123"
}
事件2：逐笔成交
{
"type": "TRADE",
"price": 10.00,
"qty": 300,
"buyOrderId": "B1001",
"sellOrderId": "S2001",
"timestamp": "09:30:01.124"
}
事件3：订单簿更新事件（本地推导）
- 卖一档 10.00 数量从 500 减少到 200
- 买单 B1001 完全成交，不进入订单簿
这个案例说明：逐笔委托不一定都会留在订单簿中，如果立即成交，它只会短暂存在；逐笔成交才是真正改变订单簿数量的驱动因素。本地系统必须同时消费这两类事件，才能正确维护状态。
五、方法流程与复盘要点
从工程实现角度，处理Tick与增量行情的标准流程如下：
- 接入与解码：从行情网关接收二进制或JSON格式Tick，解析为内部结构体。
- 排序与去重：按交易所序号或时间戳排序，丢弃重复包。
- 事件分类：区分逐笔委托、逐笔成交、快照、状态变更等类型。
- 订单簿更新：根据事件类型调用新增、修改、删除档位逻辑。
- 一致性校验：定期与快照比对，发现偏差触发重建。
复盘时重点检查三个问题：事件是否按序处理、订单簿更新是否幂等、快照与增量切换时是否有状态断层。这三个问题解决了，订单簿重建的稳定性就有基本保障。