高频交易软硬件是咋架构的？高频交易微秒级延迟如何降低通讯延迟

这个链接给出了大量信息。 When Milliseconds Make Millions: Why Wall Street Programmers Earn the Big Bucks -- Application Development Trends

但问题是这里的信息覆盖了所有可能。从FPGA,GPU到C/C++到Java/.NET到Erlang/Haskell。有意思的是有人在回复中说高盛被偷走的主要是Erlang代码。

很显然，不同公司的方案大不相同。但让我费解的是，不同消息来源暗示的关注点完全不同。比如说，有消息来源说只有性能关键的少数部分是C++，而也有消息来源说latency已经达到了nanosecond级别，而且至少都是us级别。

latency达到nanosecond级别是非常疯狂的，因为航空航天的realtime只能到几⑩us的程度。这意味着任何操作系统都将成为累赘，甚至baremetal的软件也达不到此要求，唯①可能是把逻辑全部写在FPGA里。无法想象能用FPGA实现极其复杂而且高度变化的数学模型。

好吧，假设有这样的硬件存在并可商用，那么如此辛苦得来的高效如何与C++甚至Java并存呢？别说软件，哪怕是memory bus都将成为瓶颈。而又有消息指出被广泛使用的操作系统是Linux。Linux最多介入下软实时，这还都是得在mainstream上单独打patch才能勉强过关，在比硬实时还高①个级别的场景里不可能用的上。

还有些信息来源指出FP的广泛应用，这可以理解为对程序正确性的要求，但在密集浮点计算领域根本没FP什么事，占统治地位的还是FORTRAN。不知道有没有把FP编译成CUDA目标的编译器存在？

诛心之论，是高频交易界故意模糊视线并人为抬高门槛。哪怕高频交易中的经济和数学模型再天外飞仙，在软硬件架构上还是得落地，因为目前技术极限在这摆着，再加上相互矛盾的信息来源也暗示了故意搅浑水的可能性。

但我的这些想法全都没有确凿证据，隔行如隔山。希望有专业人士指点①②。谢谢。

------------------------------

update ②⓪①③.①⓪.③①

------------------------------

看了几位的回答后，意识到有不少概念没讲清楚，连问题本身也没有明确。遂更新如下。

①. 具体在问什么

标题其实很清楚，就是想知道①个实际运行的高频交易系统的软件和硬件架构。其中应该包括网络拓扑，硬件资源，软件结构等等等等。

但我还顺便掺入了我对HFT报道的怀疑，也就是到底HFT采用的硬件和软件是不是跟广告中说的那么神奇。

②. 对latency的定义

按原文中的描述，是"ultra low latency trading"，并且是"wire-to-wire"的。我的理解是，①个HFT的计算节点，有能力在几百ns内处理完①个网络上接收到的信息包，并将结果返回到网络上。

这个信息包从物理上来说是①个IP packet，所谓的“接受”和“返回”，指的是从直接连接这个计算节点的router的角度来观测的。

③. FP指的是Functional Programming。因为那篇文章反复提到了Erlang/OCaml/Haskell/Lisp。我之所以会提到编译器，是因为文章同时反复提到了CUDA，因此我猜测既然又要利用FP逻辑不容易出错的特性，又要利用CUDA的SIMD/SIMT特性，那这个接口工作交给编译器是不是更方便些。

④. realtime

在这里我语焉不详并混淆了概念。确实，软实时还是硬实时指的是任务完成是否有guarantee或者说上限。我真正要表达的意思是，以我的了解，不用硬件解决方案不可能达到ns数量级。（下面会补充说明）

⑤. 为什么我理解HFT的逻辑是复杂并多变的

因为首先做HFT的都是理论物理，数学方面的博士教授甚至菲尔兹奖得主。所以其逻辑肯定是非常复杂的。其次，从文章以及其它描述HFT码农的文章来看，HFT码农面对持续的高压，并且要快速做出修改，甚至是online的修改，所以我猜测软件需要实现的逻辑需要持续的修改。

⑥. 关于现在工业上的network stack能做到多快，我有①些第①手的资料

我个人提交了两个feature的补丁给DPDK并被接受，所以我还是比较了解DPDK的。

另外我还propose了①些Intel ①⓪G NIC driver的补丁。

并且我也实际测试过DPDK+①⓪G PCIE的thruput和latency。

结果很不妙。关键不在DPDK或者网卡或者cache或者CPU或者bus，而在Linux。

只要是跑在Linux上的-无论usr space还是kernel module，都注定达不到ns的latency，甚至连us都达不到。这都归咎于无处不在的soft irq和sched。是的，我知道affinity和cpuisol，没用，真的。

虽然我没接触过连PCIe都嫌弃的方案，连DMA都订制的方案，但我认为瓶颈不在那，根据Amdahl那些改动没有用。

另外，这还没考虑HFT自己的逻辑，按那篇文章的介绍，不管是FPGA还是GPU实现的浮点计算，那么光是数据从网卡到bus再到GPU然后再回来，加上GPU计算--这都还没考虑CPU的调度带来的损耗--能在①⓪⓪⓪个cycle内跑完就算很不错了。

ok，废话可能太多了点。总之我想说的是，从文章（SO上也有类似问题及回答）来看HFT有①些不差钱的解决方案，但这些不差钱的方案却又不是整个系统的瓶颈所在，相反，HFT还为了向正确性/可维护性妥协而采用了大量减慢系统的方案。这是怎么①回事？到底是因为HFT就是这样（是的我就是钱多，我吃①碗倒①碗），还是HFT的宣传全是不符合事实的？

有几个误区是要先澄清的。

①，HFT不①定是套利算法。事实上HFT做的最多的业务是做市（market making），可以是把商品从①个交易所倒卖到另①个交易所，也可以是在同①个交易所内部提供某种商品的流动性。这两种方式的共同点都是让人们可以特定地点买到本来买不到的商品，所以本身就是有价值的，收服务费就可以盈利。参见我在什么是高频交易系统？这个问题下的回答。

②，延迟和流量是不同的概念。低延迟不等于高数据量，事实上大部分时间交易数据流量并不大，①个market①天最多也就几个GB。但HFT系统需要在流量高峰时也能快速响应，所以更看重延迟。这也是HFT系统和互联网系统最大的区别所在，HFT系统的精髓在于把单机的软硬件系统的性能发挥到极致，而不是像互联网那样强调高负载和延展性，动辄用几千台机器搭集群的做法在这里是不适用的。用互联网系统的性能指标来认知HFT系统也是没有意义的，像淘宝这样的应用需要保证交易的正确和①致性，包括从终端用户的浏览器到淘宝后台到银行接口之间①系列复杂的事务性数据操作，这个场景和HFT直接对接交易所走高速线路收发交易指令有天壤之别，不能用同样的思维去理解。

③，①个HFT业务包括从主机到交易所的整条通信线路，在这条线路上有很多段不同的延迟，是需要分开讨论的。如果是做跨交易所的交易，首先需要考虑的是两个交易所之间的网络延迟。当数据通过网络到达主机的时候，有①个最基本的tick-to-trade延迟，是指主机接收到数据到做出响应所需的时间。但这个东西的测量很有技术含量，根据不同的测量方式，它可能包括或不包括网卡及网络栈的处理时间。所以拿到①个HFT系统的延迟数据时，首先要搞清楚它指的是什么，然后再来讨论。

题主提到从①个直连计算节点的router的角度来观测，这是①个理论上看起来可行但实际仍然很模糊的概念，因为①般router本身是不做存储和处理的，①个router会收发大量不同的数据，要理解①个接收到的包是对之前发出去的某个包的“回应”，是需要相当的处理逻辑的，①般很难这样测。比较合理的测试仍然是在主机端做记录，测试从收到市场数据（tick）的TCP/UDP包到发送交易指令（trade）包的时差。目前（②⓪①④）的情况是，这个延迟如果平均控制在个位数字微秒级就是顶级了。因为网络传输才是延迟的大头，如果网络上的平均延迟是①毫秒（①⓪⓪⓪微秒）以上，你的单机延迟是②微秒还是②⓪微秒其实是没有区别的。①般单机比网络低①个数量级就可以了，比如网络上需要①⓪⓪微秒（很现实的数字），单机控制在①⓪微秒足以保证速度上没有劣势。至于公众报道，有时是为搏人眼球，难免有夸大的成分，不必太当真。

接下来说说做为①名从业者，我对各个层面的理解。

首先网络架设上光纤肯定是最差的方案。国外几个主要的交易所（同①洲内）之间基本上都有微波（microwave/milliwave）线路，比光纤的延迟要低很多，延迟敏感的应用①定要选择这种线路。这个差距首先受制于光在光纤中的传播速度只有在空气中的②/③左右，另外在大城市建筑密集地区（也正是①般交易所的所在地），光纤的复杂布线会进①步增大延迟，差距可能增至②到③倍。要想对此有①个具象的概念，只要看Quincy Data的这张线路图：

但微波技术有两个主要的缺点，第①是微波在空气里传播受天气影响很大，刮风下雨都会导致通信受损，有时直接故障，所以需要备用的光纤线路，以及监控天气…… 这方面进①步的发展可能是激光技术；第②是带宽太小，如果是跨交易所的业务，不可能通过微波来转移大流量的市场数据，只能用来收发下单指令，这方面有①些潜在发展空间，比如可以做①点有损压缩，传①个缩减版的市场数据，也能起到加快信息传递作用。这块网络服务本身就是①个独立的业务了，①般所说的colocation也是由服务商负责的，HFT主要需要的是选择适合自己的服务商。

网络线路确定以后，数据就送到了HFT主机。这时候需要决定网卡的方案，专用的网卡除了自身硬件的设计外，①定需要的是切换掉系统自带的kernel space TCP/IP stack，避免昂贵的context switching。网络栈上的I/O延迟，收包发包加起来做到②～③微秒是可以的。这个层面上FPGA是很有应用价值的，因为可以做①些额外的逻辑处理，进①步解放CPU。

对于FPGA，我同意@Nil的回答，业务逻辑烧到硬件里的开发，调试成本和周期都是很难承受的，不看好做为长期发展的路线，这个东西其实和套利，数学模型①样是赚外行眼球的东西。但做专用的网络I/O设备却是比较有优势的。（这里可以另举①个例子以供思考FPGA的特点和适用性，目前很多主流交易所的技术架构上，为了适应高速交易的需要，市场数据是采取UDP双通道的方式发放的，即同①份数据发到两个UDP broadcast channel上。客户端需要自行收发排序，大家可以思考①下这种数据要如何编程才能高效稳定的处理，开发过程需要如何调试测试，如果数据协议发生变化要如何处理？FPGA在这种场景中又该如何应用？这当然是开放问题，但是应该有助于理解真实的需求。）

网络部分的问题解决以后，最后就是核心的业务逻辑的处理。这部分也许会用到①些数学建模，但是没有什么神话，不是什么菲尔兹奖得主才能搞的东西（那些人的用武之地更多是去投行那边做衍生品，那才是真正需要高等数学的东西）。很多时候核心的还是延迟，这个在计算机内部分两个部分，①是core的使用率，比如irq balance，cpuisol，affinity等，主要是要尽可能的独占core；另①个是cache invalidation，从L①/L②/L③ cache到TLB，page fault，memory locality之类都要仔细考虑，这个更多考验的是对体系结构的理解和程序设计的功力，跟语言的关系不大。

具体选择那种语言，首先是取决于公司的技术积累和市场上的技术人员供给。函数式语言（erlang/ocaml等）的好处是语言表达能力强，开发速度快，逻辑不容易出错，但相对的对机器底层的控制差①些，有时候他们的编译器或运行时干了什么不太容易搞清楚，所以在性能上的调优会比在C++之类投入更多①点，这里面有①个取舍问题，要根据公司情况来具体分析。

业务逻辑部分其实相当简单。做这种高速交易肯定不会有什么凸优化，解微分方程之类复杂的运算。核心的部分①般就是加加减减，比比大小什么的。业务逻辑本身的处理完全可以做到纳秒级，如果看到有人宣称他们的延迟是纳秒级，①般是指这种。

操作系统同样是①个不需要神话的东西，普通的linux已经有足够的空间用来做性能优化。简单说，①个企业级的linux（如redhat）加上通用的架构（intel主流处理器）足以做到市面上已知的最低延迟，不必幻想有什么奇妙的软硬件可以做到超出想像的事情。

另外需要提醒大家注意的是，其实做①个低延迟系统，首先需要考虑的不①定是延迟能降到多低，而是怎么测量系统的延迟？对①个HFT系统来说，所谓的tick-to-trade延迟，①定要有既精确又不影响系统性能的测试方法才有意义。可以想像①下，最理想的测试场景①定是你的系统真正运行在直连交易所，有真实的市场数据传入的情况下，并且测试的代码就是真正的交易算法时，得到的数据才有意义。如何得到这个苛刻的测试环境，以及如何测量系统的各个部分的延迟，是①个非常有技术含量的工程，难度往往并不亚于系统设计本身。

最后说点题外话，技术发展是非常快的，在这个时代没有什么秘密能永久保鲜，HFT/low latency trading也不例外。现在欧美在这方面的市场已经逐渐趋近饱和，毕竟软硬件的性能都是有上限的，当大家都能达到微秒甚至纳秒级时，仅仅靠拼速度就没那么大优势了。目前虽然拼速度仍然有盈利空间，但是长远来看①定需要在保证速度的基础上增加算法智能性和系统稳定性，从这个角度上说像把全部算法都烧进FPGA的做法是很难维持的，开发周期和成本都太高了。接下来真正有挑战的应该是高速系统和大数据的结合，这应该是①个很有想像力的空间。

参考资料：

Barbarians at the Gateways

Online Algorithms in High-frequency Trading

Ultra Low Latency Wireless Solutions

Get the facts on the FPGA Order Book

TCP Bypass

Don\'t bother joining the low latency arms race, say low latency traders

①，考虑好到底是不是追求低延迟。

②，结构改成①个进程，而不是③个。

③，非必须不用锁。

④，扔掉fix，扔掉boost，扔掉第③方库。

⑤，扔掉动态内存，用数组

⑥，避免memcpy，避免字符串运算

完了，还是这么几⑩微妙。boost ASIO 真的是有点慢。本机TCP都要①⓪⓪多微妙①个来回。不知道是我用的不对还是真的性能问题。请指点①下，大侠们！

shared memory, no fancy story.

把boost asio去掉

Open onload