第二章：硬件加速动机——为什么用FPGA做订单簿？

说实话，这个问题我经常被问到。

尤其是那些做软件交易系统的朋友，一听说我用FPGA做订单簿，第一反应就是：「有必要吗？CPU不够用？」

嗯，咱们今天就把这事掰扯清楚。

2.1 延迟：微秒级的生死线

先聊延迟。做交易的人都知道，延迟就是钱。

我有个客户，做高频做市。他们之前用C++写的软件订单簿，延迟大概在5-10微秒。听起来很快对吧？但他们的竞争对手，用FPGA方案，延迟压到了500纳秒以内。

你想想看，一个微秒的差距，在撮合高峰期可能就意味着几百笔订单的先后顺序。谁先成交，谁后成交，直接决定了你是赚钱还是亏钱。

为什么会差这么多？说白了，CPU是通用处理器，它要处理中断、缓存缺失、分支预测失败这些乱七八糟的事。而FPGA是定制化的数据流处理，数据进来，直接走硬件流水线，一步到位。

我记得有一次帮一个券商做延迟优化。他们的软件订单簿，在行情剧烈波动时，延迟能飙到50微秒以上。原因很简单——CPU被其他进程抢占了。这种问题在FPGA上根本不存在，因为逻辑资源是独占的。

2.2 吞吐量：每秒百万笔订单的处理能力

延迟讲完了，咱们说吞吐量。

你可能觉得，延迟低自然吞吐量就高。其实不完全对。

吞吐量考验的是并行处理能力。CPU再快，它也是串行的——一个时钟周期只能执行一条指令（超线程、多核能缓解，但本质还是串行思维）。

FPGA就不一样了。我可以在一个芯片里同时做：

• 行情解码
• 订单簿更新
• 价格计算
• 风控检查
• 日志记录

这些模块全部并行跑，互不干扰。你想想看，这吞吐量能差多少？

具体数字上，一个中等规模的FPGA（比如Xilinx KU060），可以轻松处理每秒500万笔以上的订单更新。而同样的软件方案，优化到极致也就100万笔左右。

2.3 确定性：最容易被忽视的杀手锏

嗯，这里我要重点讲一下。

很多人只盯着延迟和吞吐量，却忽略了确定性。什么叫确定性？就是每次处理的时间都一样，没有波动。

软件系统有个致命问题——抖动。GC暂停、系统调用、中断处理、上下文切换……这些都会导致处理时间忽长忽短。你可能99%的订单都在1微秒内处理完，但突然有一个订单花了100微秒。对于交易系统来说，这100微秒可能就是灾难。

FPGA为什么能做到确定性？因为它的逻辑是硬件实现的，没有操作系统，没有中断，没有缓存缺失。每个时钟周期做什么，都是固定的。

2.4 为什么不是ASIC？

你可能会问，既然FPGA这么好，为什么不直接做ASIC？

原因很简单：成本和灵活性。

ASIC流片一次，几百万美元起步，周期半年以上。而且一旦做出来，功能就固定了，想改？重新流片。

FPGA就灵活多了。今天支持这个交易所的协议，明天换个固件就能支持另一个。对于金融行业来说，业务变化太快，ASIC根本跟不上。

2.5 一张图看懂FPGA订单簿的优势

下面这张图，是我自己总结的FPGA订单簿核心优势框架：

2.6 总结一下

FPGA做订单簿，说白了就是三个字：快、稳、狠。

• 快：延迟从微秒级降到纳秒级
• 稳：确定性执行，没有抖动
• 狠：吞吐量碾压CPU方案

当然，FPGA也不是万能的。开发周期长、调试困难、成本高，这些都是现实问题。但如果你做的是高频交易，这些代价都是值得的。

嗯，这一章就到这里。下一章咱们开始动手，从最简单的订单簿数据结构讲起。