1. HFT系统架构全景：从行情接入到订单执行的全链路拆解
做高频交易这些年，我见过不少团队把架构图画得跟蜘蛛网似的。其实说白了，HFT系统的核心链路就那么几条——行情怎么进来，策略怎么决策，订单怎么出去。今天咱们就把这条链路从头到尾捋一遍。
1.1 全链路总览：数据流与资金流
先看一张我手绘的架构图。这张图我改过至少五版，现在这个版本是我在实盘环境中验证过的。
这张图里，行情从左边进来，经过策略引擎加工，再通过订单管理系统发出去。风控模块像个“交警”，在关键路口做检查。我当年第一次搭这个架构时，犯了个低级错误——把风控放在了订单管理系统后面。结果有一次策略出bug，订单都发出去了风控才报警，那叫一个尴尬。
1.2 行情网关：系统的“眼睛”
行情网关是HFT系统的第一道关卡。它的任务很简单：从交易所接收行情数据，解码后送给策略引擎。但简单不代表容易。
行情网关的核心功能包括：
- 数据接收：通常通过UDP组播接收交易所的原始行情。我建议用双网卡绑定，避免单点故障。
- 协议解码：不同交易所的协议千奇百怪。上期所的STEP、中金所的FAST、国外的ITCH——每个都得单独写解码器。
- 数据分发：解码后的行情要广播给所有策略实例。这里要注意，分发延迟必须稳定，不能有抖动。
嗯，这里要注意一个坑。行情网关最容易出问题的地方是“数据粘包”。我曾经在生产环境遇到过，交易所突然加大数据量，UDP缓冲区溢出，导致行情断层。后来我加了个环形缓冲区，才彻底解决这个问题。
1.3 策略引擎：系统的“大脑”
策略引擎是整个系统最核心的部分。它接收行情，运行交易策略，输出买卖指令。说白了，这就是个“信号发生器”。
策略引擎的典型工作流程：
- 行情订阅：策略告诉引擎“我要看哪些品种的行情”。
- 信号计算：运行各种指标——价差、动量、订单簿不平衡度等等。
- 决策生成：根据信号和参数，决定是否下单、下什么单。
- 指令输出：把订单指令发给订单管理系统。
你想想看，为什么很多HFT团队用FPGA做策略引擎？因为CPU的指令流水线有不确定性——缓存未命中、分支预测失败，都会导致延迟抖动。FPGA是硬件逻辑，延迟是确定的。我见过一个团队，用CPU做策略引擎，延迟均值是8微秒，但P99能飙到50微秒。换成FPGA后，延迟稳定在3微秒，P99不超过5微秒。
1.4 订单管理系统：系统的“手”
订单管理系统（OMS）负责把策略生成的指令变成真正的订单，发到交易所。它要处理的事情比想象中多得多。
| 功能模块 | 职责 | 我踩过的坑 |
|---|---|---|
| 订单路由 | 选择最优的交易所或做市商 | 有一次路由算法没考虑交易所维护时间，订单全被拒了 |
| 订单状态机 | 跟踪每个订单的生命周期 | 状态机少了个“已撤销”状态，导致订单卡死 |
| 订单簿管理 | 维护本地订单簿，用于决策 | 本地订单簿和交易所不一致，导致重复下单 |
| 重连机制 | 断线后自动重连并恢复状态 | 重连时没清空旧订单，造成大量废单 |
OMS的延迟要求比策略引擎宽松一些，但也不能超过50微秒。我建议用无锁队列做模块间通信，避免锁竞争带来的延迟。
1.5 风控模块：系统的“刹车”
风控模块是HFT系统里最容易被忽视、但最重要的部分。没有风控，一次策略bug就能让你亏掉一年的利润。
风控通常分三层：
- 事前风控：订单发出前检查。比如单笔金额上限、日内累计交易量、自成交检查。我习惯在策略引擎和OMS之间加一道事前风控，这样即使策略发疯，订单也出不去。
- 事中风控：订单在途时监控。比如检查订单是否超时未成交、是否被交易所拒绝。我曾经遇到交易所网关超时，事中风控自动撤单，避免了资金占用。
- 事后风控：交易结束后分析。比如检查是否有异常交易、是否触及风控阈值。这部分可以离线做，不要求低延迟。
1.6 组件间的交互逻辑
这四个组件不是孤立的，它们之间的交互决定了系统的整体性能。我总结了一个“三原则”：
- 数据流单向：行情从网关到策略，指令从策略到OMS，成交回报从OMS回策略。不要搞成网状结构，否则调试起来想死。
- 控制流双向：风控和策略之间要有双向通信。策略可以查询风控状态，风控也可以强制停止策略。
- 心跳保活：每个组件之间都要有心跳检测。我习惯用共享内存做心跳，延迟最低。
举个例子，有一次策略引擎的行情订阅突然断了，但OMS还在正常发单。因为没有行情更新，策略用的全是旧数据，结果连续下了几十笔错误订单。后来我加了个“行情健康检查”——如果行情超过100毫秒没更新，策略自动进入“冻结模式”，不再产生新指令。
好了，这一章的内容就到这里。HFT系统的架构其实不复杂，难的是把每个组件的延迟压到极致，同时保证系统的稳定性。下一章我们会深入行情网关，聊聊如何用FPGA实现微秒级的行情解码。
公众号:蓝海资料掘金营，微信deep3321