一、高频交易软硬件是怎么架构的
高频交易对计算机执行系统的要求非常苛刻，对执行速度、响应延迟的追求已经近似疯狂。那么这种极度精密的高性能系统一般是怎样架构设计的呢？在开始讲解之前，我们需要先澄清两个容易引起误解的概念：
第一，延迟和流量是不同的概念。低延迟不等于高数据量，事实上大部分时间交易数据流量并不大，一个 market 一天最多也就几个 GB。但 HFT 系统需要在流量高峰时也能快速响应，所以更看重延迟。这也是 HFT 系统和互联网系统最大的区别所在：HFT 系统的精髓在于把单机的软硬件系统的性能发挥到极致，而不是像互联网那样强调高负载和延展性，动辄用几千台机器搭集群的做法在这里是不适用的。用互联网系统的性能指标来认知 HFT 系统也是没有意义的，像淘宝这样的应用需要保证交易的正确和一致性，包括从终端用户的浏览器到淘宝后台，再到银行接口之间一系列复杂的事务性数据操作，这个场景和 HFT 直接对接交易所走高速线路收发交易指令有天壤之别，不能用同样的思维去理解。
第二，一个 HFT 业务包括从主机到交易所的整条通信线路，在这条线路上有很多段不同的延迟，是需要分开讨论的。如果是做跨交易所的交易，首先需要考虑的是两个交易所之间的网络延迟。当数据通过网络到达主机的时候，有一个最基本的 tick-to-trade 延迟，是指主机接收到数据到作出响应所需的时间。但这个东西的测量很需要技术含量，根据不同的测量方式，它可能包括或不包括网卡及网络栈的处理时间。所以拿到一个 HFT 系统的延迟数据时，首先要搞清楚它指的是什么，然后再来讨论。
有人提到从一个直连计算节点的 router 的角度来观测。这是一个理论上看起来可行但实际仍然很模糊的概念，因为一般 router 本身是不做存储和处理的。一个 router
会收发大量不同的数据，要理解一个接收到的包是对之前发出去的某个包的「回应」，是需要相当的处理逻辑的，一般很难这样测。比较合理的测试仍然是在主机端做记录，测试从收到市场数据（tick）的 TCP/UDP 包到发送交易指令（trade）包的时差。目前（2014 年）的情况是，这个延迟如果平均控制在个位数字微秒级就是顶级了。因为网络传输才是延迟的大头，如果网络上的平均延迟是 1 毫秒（1000 微秒）以上，你的单机延迟是 2 微秒还是 20 微秒其实是没有区别的。一般单机比网络低一个数量级就可以了，比如网络上需要 100 微秒（很现实的数字），单机控制在 10 微秒足以保证速度上没有劣势。至于公众报道，有时是为博人眼球，难免有夸大的成分，不必太当真。
接下来说说，身为一名高频交易工程师，我对高频交易系统架构各个层面的理解。
首先，网络架设上光纤肯定是最差的方案。国外几个主要的交易所（同一洲内）之间基本上都有微波（microwave/milliwave）线路，比光纤的延迟要低很多，延迟敏感的应用一定要选择这种线路。这个差距首先受制于光在光纤中的传播速度只有在空气中的 2/3 左右。另外，在大城市建筑密集地区（也正是一般交易所的所在地），光纤的复杂布线会进一步增大延迟，差距可能增至 2 到 3 倍。
但微波技术有两个主要的缺点：第一是微波在空气里传播受天气影响很大，刮风下雨都会导致通信受损，有时直接故障，所以需要备用的光纤线路，以及监控天气……
这方面进一步的发展可能是激光技术；第二是带宽太小，如果是跨交易所的业务，不可能通过微波来转移大流量的市场数据，只能用来收发下单指令，这方面有一些潜在发展空间，比如可以做一点有损压缩，传一个缩减版的市场数据，也能起到加快信息传递作用。这块网络服务本身就是一个独立的业务了，一般所说的 colocation 也是由服务商负责的，HFT 主要需要的是选择适合自己的服务商。
网络线路确定以后，数据就送到了 HFT 主机。这时候需要决定网卡的方案。专用的网卡除了自身硬件的设计外，一定需要的是切换掉系统自带的 kernel space TCP/IP stack，避免昂贵的 context switching。网络栈上的 I/O 延迟，收包、发包加起来做到 2～3 微秒是可以的。这个层面上 FPGA 是很有应用价值的，因为可以做一些额外的逻辑处理，进一步解放 CPU。
对于 FPGA，我的观点是，业务逻辑烧到硬件里的开发，调试成本和周期都是很难承受的，不看好作为长期发展的路线，这个东西其实和套利、数学模型一样，是吸引外行眼球的东西。但做专用的网络 I/O 设备却是比较有优势的。（这里可以另举一个例子以供思考 FPGA 的特点和适用性：目前很多主流交易所的技术架构上，为了适应高速交易的需要，市场数据是采取 UDP 双通道的方式发放的，即同一份数据发到两个 UDP broadcast channel 上，客户端需要自行收发排序。大家可以思考一下这种数据要如何编程才能高效稳定地处理，开发过程需要如何调试测试，如果数据协议发生变化要如何处理？FPGA 在这种场景中又该如何应用？这些当然是开放问题，但是应该有助于理解真实的需求。）
网络部分的问题解决以后，最后就是核心的业务逻辑的处理。这部分也许会用到一些数学建模，但是没有什么神话，并非什么菲尔兹奖得主才能搞的东西（那些人的用武之地更多是去投行那边做衍生品，那才是真正需要高等数学的东西）。很多时候核心的还是延迟，这个在计算机内部分两个部分：一是 Core 的使用率，比如 IRQ Balance，cpuisol，Affinity 等等，主要是要尽可能地独占 Core；另一个是 Cache Invalidation，从 L1/L2/L3 cache 到 TLB，Page Fault，Memory Locality 之类的，都要仔细考虑——这个更多考验的是对体系结构的理解和程序设计的功力，跟语言的关系不大。
具体选择哪种语言，首先是取决于公司的技术积累和市场上的技术人员供给。
使用 App 查看完整内容目前，该付费内容的完整版仅支持在 App 中查看
App 内查看 | 
转播
