1. 高频交易概述：什么是高频交易、HFT的核心目标、系统架构概览
1.1 什么是高频交易？
高频交易，说白了就是「用极快的速度完成交易」。
有多快？我见过最极端的场景，从行情数据到达网卡，到交易指令发出，整个流程控制在几百纳秒。嗯，纳秒，十亿分之一秒。你眨一下眼睛的时间，够它跑几十万笔交易了。
高频交易不是一种策略，而是一种能力。它依赖的是硬件、软件、网络、数据中心的极致配合。我入行时带我的老工程师说过一句话，我一直记着：「高频交易的本质，是把时间压缩到物理极限。」
具体来说，HFT 有几个典型特征：
- 持仓时间极短——几秒到几分钟，甚至几毫秒
- 单笔利润极薄——可能只有零点几个 tick
- 交易频率极高——每天成千上万笔
- 对延迟极度敏感——慢一微秒可能就亏钱
你想想看，如果一笔交易赚 0.01 个 tick，一天做 10 万笔，那就是 1000 个 tick 的利润。但如果你比别人慢 1 微秒，这笔单子就被别人抢走了。这就是 HFT 的残酷现实。
1.2 HFT 的核心目标：低延迟与高吞吐
HFT 系统追求两个核心指标：低延迟和高吞吐。这两个词经常被混用，但在我眼里完全是两码事。
低延迟：快，才是王道
延迟，指的是从「事件发生」到「系统响应」之间的时间差。在 HFT 里，我们通常用纳秒（ns）来衡量。
举个例子：
- 行情数据从交易所到达你的网卡：假设 500 纳秒
- 网卡把数据传给 FPGA 处理：50 纳秒
- FPGA 解析行情并生成信号：100 纳秒
- 信号传给交易引擎：30 纳秒
- 交易引擎生成订单并发送：80 纳秒
加起来不到 1 微秒。这就是一个合格的 HFT 系统该有的水平。
关键点：延迟是端到端的。你不能只看 CPU 处理时间，网卡、交换机、光纤、甚至机柜内的线缆长度都会影响延迟。我曾经在项目中因为一根光纤长了 3 米，导致延迟多了 15 纳秒——别笑，15 纳秒在 HFT 里是巨大的差距。
高吞吐：处理海量数据的能力
吞吐量，指的是单位时间内系统能处理多少数据。HFT 系统每秒可能要处理几十万笔行情更新，同时还要管理数千个订单状态。
低延迟和高吞吐有时候是矛盾的。你想想看，为了降低延迟，你可能用 FPGA 做硬连线处理，但 FPGA 的灵活性差，吞吐量上不去。反过来，用 GPU 做并行计算，吞吐量很高，但延迟又下不来。
我个人的经验是：先保证低延迟，再优化吞吐量。因为 HFT 的核心竞争力就是「比别人快」，吞吐量只要够用就行。
| 指标 | 典型值 | 衡量方式 | 优化方向 |
|---|---|---|---|
| 端到端延迟 | < 1 微秒 | 行情到订单发出 | 硬件加速、减少拷贝 |
| 行情处理吞吐 | > 50 万笔/秒 | 每秒行情更新数 | 并行流水线、FPGA |
| 订单发送速率 | > 10 万笔/秒 | 每秒订单数 | 内核旁路、零拷贝 |
1.3 HFT 系统的整体架构概览
一个典型的 HFT 系统，从数据流入到订单发出，大致分为四个阶段。我画了一张图，你可以对照着看。
这张图展示的是最简化的数据流。实际项目中，每个阶段都有大量细节。
第一阶段：行情接收
行情数据从交易所通过光纤到达你的机房。网卡收到数据后，直接通过 DMA 写入内存，或者直接送到 FPGA 处理。这里的关键是减少拷贝次数。我见过很多团队用标准 Linux 协议栈，结果延迟直接飙到几十微秒——这在 HFT 里是不可接受的。
我的建议：行情接收一定要用内核旁路技术，比如 DPDK 或者直接上 FPGA。别想着用标准 socket，那玩意儿是为通用场景设计的，不是为 HFT 准备的。
第二阶段：信号生成
行情数据解析完成后，需要运行策略逻辑。这里有两种主流方案：
- FPGA 方案：延迟极低（几十纳秒），但开发周期长，改策略要重新烧录
- GPU 方案：吞吐量高，但延迟相对较高（微秒级）
我个人更倾向于 FPGA 做核心策略，GPU 做辅助计算。当然，这取决于你的策略类型。
第三阶段：订单管理
信号生成后，需要交给订单管理系统（OMS）。OMS 负责维护订单状态、做风控检查、管理资金。这个阶段最容易出问题。我曾经遇到过因为 OMS 状态机设计有 bug，导致重复下单——那一次亏了六位数。
注意：风控检查必须在订单发送之前完成，而且不能拖慢整体延迟。我见过有人把风控放在 FPGA 里做，延迟只增加了几十纳秒，这才是正确做法。
第四阶段：订单发送
最后一步，把订单编码成交易所协议格式，通过网卡发送出去。这里同样要用内核旁路技术，避免操作系统介入。
1.4 一个典型的延迟分布
为了让你有个直观感受，我列一个实际项目中的延迟分布数据：
| 阶段 | 延迟（纳秒） | 占比 |
|---|---|---|
| 网卡接收 + DMA | 200 | 20% |
| 行情解析（FPGA） | 150 | 15% |
| 策略计算（FPGA） | 300 | 30% |
| 风控检查 | 100 | 10% |
| 订单编码 + 发送 | 250 | 25% |
| 总计 | 1000 | 100% |
你看，整个流程刚好 1 微秒。每个环节都有优化空间，但策略计算占了 30%，往往是瓶颈所在。
1.5 我的一些经验总结
做了这么多年 HFT 系统，我总结了几条铁律：
- 硬件是基础，软件是灵魂——再好的 FPGA，代码写得烂也没用
- 延迟预算要精确到纳秒——每个环节都要量化，不能靠感觉
- 测试环境要和生产环境一致——我曾经在测试环境用普通交换机，结果上线后延迟翻倍
- 风控永远不能省——快是好事，但快出问题就是灾难
一句话总结：高频交易不是魔法，是工程。每一纳秒的优化，背后都是对硬件、软件、网络的深刻理解。别想着走捷径，老老实实把每个环节做到极致，你就能跑赢大多数人。
公众号:蓝海资料掘金营，微信deep3321