第1章行情系统概述

一、行情系统概述

做量化系统这么多年，我始终觉得行情系统是整个交易链路里最容易被低估的一环。很多人一上来就盯着交易引擎、策略模型，结果行情数据还没到，策略就已经输了。说白了，行情系统就是交易系统的「眼睛」——眼睛不好使，再快的腿也没用。

低延迟行情系统，核心任务就一个：把交易所的行情数据，以尽可能快的速度、尽可能完整的形态，送到策略端。

我习惯把它拆成三个环节来看：

你想想看，一个高频交易策略，从行情到达、信号计算、到订单发出，整个链路可能也就几十微秒。行情系统如果慢了，后面的所有优化都是白搭。

核心定义：低延迟行情系统，是指在微秒甚至纳秒级别内完成行情数据的接收、处理与分发的系统。它不追求「大而全」，而是追求「快而稳」。

衡量一个行情系统好不好，我一般看三个指标：延迟、吞吐量、抖动。这三个指标缺一不可。

指标	定义	典型要求	我的经验
延迟	从交易所发出行情到策略收到数据的时间差	< 10 微秒（P50），< 50 微秒（P99）	我见过最夸张的项目，延迟要求是 5 微秒以内，连网卡中断合并都得关掉
吞吐量	单位时间内能处理的行情消息数量	百万级消息/秒	国内期货市场，单品种一天能产生几百万笔逐笔成交，吞吐量不够直接丢数据
抖动	延迟的波动程度，通常用 P99 - P50 来衡量	< 20 微秒	抖动比延迟更可怕。延迟高可以预测，抖动大策略根本没法做风控

避坑指南：我曾经在一个项目里只盯着 P50 延迟，结果 P99 抖动达到 200 微秒。策略在大部分时间跑得挺好，但每隔几秒就卡一下，直接导致做市商策略频繁撤单。后来我才意识到，对于高频交易来说，P99 比 P50 重要得多。

低延迟行情系统不是万能的，但在下面几个场景里，它是刚需。

高频交易的核心就是「快」。谁先拿到行情，谁就能先下单。我见过一个做期货跨期套利的团队，他们的行情系统延迟比对手慢了 3 微秒，结果一年下来少赚了上千万。嗯，3 微秒，就是一根光纤从上海到杭州的时间。

做市商需要同时维护买卖双边报价，行情抖动直接导致报价失效。我记得有个做市商朋友跟我说过：「行情系统抖一下，我的报价单就全废了。」做市商对行情系统的要求，不仅仅是快，还要稳——延迟可以稍微高一点，但绝对不能抖。

这个场景很多人会忽略。回测时如果行情数据不完整、时间戳不精确，策略在实盘里就会「水土不服」。我习惯把行情存储系统也纳入低延迟体系里——存得快，才能回测得准。

下面这张图是我自己画的一个行情系统整体架构。它不算复杂，但每个模块都有讲究。

这个架构图里，我刻意把「行情存储」和「行情分发」放在同一层。为什么？因为在实际项目中，存储和分发往往是同一个模块的两个功能——数据既要实时推给策略，也要落盘留作回测。我习惯用共享内存做分发，用异步IO做存储，两者互不干扰。

注意：很多初学者会把行情存储做成「先存后发」，也就是等数据写进磁盘再推给策略。这个做法在低延迟场景下是致命的——磁盘IO的延迟是微秒级的，而行情分发要求纳秒级。正确的做法是先发后存，或者并发处理。

好了，这一章我们先把行情系统的「骨架」搭起来。后面的章节，我会带着你一步步把每个模块的细节抠清楚——从网卡配置到内存管理，从协议解码到文件格式设计，咱们一个一个来。