2. 行情数据基础
要做好行情数据新鲜度与延迟SLA监控，第一步不是写告警规则，而是把“被监控的对象”彻底看清楚。行情数据从交易所产生到进入策略或风控系统，中间要经过采集、归一化、分发、序列化、网络传输、反序列化等多个环节。每个环节的数据形态、协议和格式都不同，延迟的构成和可观测点也完全不同。本节先把行情数据的来源、类型、传输协议与常见格式梳理清楚，为后续的延迟度量与SLA设计打下基础。
一、行情数据的来源与链路位置
行情数据的源头是交易所或经监管许可的行情发布机构。按接入方式，常见来源可分为三类：
- 交易所直连行情：通过交易所提供的行情网关（如Binary/FAST/UDP组播、TCP恢复通道）直接获取，延迟最低，但接入成本高、协议各异。
- 行情供应商/经纪商转发：由券商、数据商对多交易所行情做汇聚、归一化后再分发，接入简单，但多了一层转发延迟。
- 聚合与衍生数据源：在原始行情基础上计算出的指标、指数、合成行情，属于二次加工数据，其“新鲜度”依赖上游原始行情。
监控时必须明确：我们监控的是哪一段链路的新鲜度。是交易所发出时间到本地接收时间，还是供应商发出时间到策略消费时间？不同起点的SLA口径完全不同，这也是后续章节设计时间戳体系的基础。
二、行情数据类型：Level-1、Level-2、逐笔与快照
行情数据类型决定了数据量、更新频率和延迟敏感度。理解它们的差异，才能为不同数据流设置合理的SLA阈值。
| 类型 | 典型内容 | 更新频率 | 延迟敏感度 | 常见用途 |
|---|---|---|---|---|
| Level-1 | 最优一档买卖价、成交量、最新价 | 毫秒~秒级 | 中 | 行情展示、简单策略 |
| Level-2 | 多档买卖盘、委托队列、逐笔成交 | 毫秒级或更高 | 高 | 盘口分析、高频策略 |
| 逐笔成交（Tick/Trade） | 每一笔成交的价格、数量、方向 | 事件驱动，频率高 | 极高 | 微观结构、T0策略 |
| 快照（Snapshot） | 某一时刻的盘口全量切片 | 固定周期（如3秒/500ms） | 中~高 | 状态重建、回放 |
逐笔数据是事件流，强调“每一笔都不能丢、不能乱序”；快照是状态切片，强调“周期稳定、时间戳准确”。监控逐笔时更关注序列号连续性和乱序率，监控快照时更关注周期抖动和快照间隔。两者不能用同一套SLA指标。
三、传输协议与常见格式
行情数据在网络上传输时，协议和格式共同决定了延迟特性与解析开销。常见组合如下：
- UDP组播：交易所行情分发的首选，延迟低、支持一对多，但不保证可靠，需要配合序列号检测丢包与乱序。
- TCP：用于恢复通道、快照请求或供应商转发，可靠但存在队头阻塞，延迟抖动更大。
- 专线/低延迟网络：配合内核旁路、网卡时间戳，进一步压缩传输延迟。
数据格式方面，常见的有：
- 二进制私有格式：如交易所自定义的定长/变长结构，解析快、体积小，但需按交易所文档实现。
- FAST/FAST-like：通过模板和增量编码压缩字段，广泛用于国际交易所行情。
- JSON/XML：可读性好，多用于供应商API或Web行情，但解析开销大、体积大，延迟较高。
- Protobuf/FlatBuffers：现代低延迟系统常用，序列化紧凑，部分支持零拷贝解析。
# 典型行情报文头（示意）
struct MarketHeader {
uint32_t seq_num; // 序列号，用于检测丢包/乱序
uint64_t exchange_ts; // 交易所发出时间（纳秒）
uint64_t recv_ts; // 本地接收时间（纳秒）
uint16_t msg_type; // 消息类型：快照/逐笔/心跳
uint16_t symbol_id; // 标的编号
};
监控系统通常需要在报文头中提取交易所时间戳和本地接收时间戳，两者之差即为链路延迟的核心度量。若格式中缺少交易所时间戳，则只能退化为“到达间隔”监控，SLA精度会明显下降。
四、案例：一条逐笔成交的完整旅程
以某交易所逐笔成交为例，数据从产生到被策略消费，大致经历：交易所撮合产生成交 → 行情网关编码 → UDP组播发送 → 本地网卡接收 → 内核协议栈 → 行情采集进程解析 → 归一化 → 内部消息队列 → 策略进程消费。每一跳都可能引入延迟，且不同跳的延迟特征不同。
假设监控发现策略端延迟突然升高，排查思路应是：先看采集进程的接收时间戳与交易所时间戳之差是否正常，若正常则问题在内部队列或策略消费；若异常，则问题在交易所到采集端之间，需检查网络、组播丢包或解析耗时。这个“分段定位”方法，正是建立在清楚数据来源、类型和协议的基础之上。
五、复盘：监控设计前的检查清单
- 数据来源是哪一类？直连、转发还是聚合？
- 数据类型是Level-1、Level-2、逐笔还是快照？更新频率如何？
- 传输协议是UDP组播还是TCP？是否有恢复通道？
- 数据格式是否包含交易所时间戳和序列号？
- 解析后的内部格式是否保留原始时间戳？
- 不同数据流是否分开监控，避免指标互相污染？
只有把上述问题回答清楚，后续的延迟度量、SLA阈值设定和告警策略才有可靠依据。行情数据基础不是背景知识，而是监控体系的地基。