高频交易系统 E01

温故而知新。

本系列主要讲(用于衍生品交易的)高频交易系统相关的东西,预计包括架构以及一点点细节。需要说明的是,实现高频交易系统的肯定不止这一种。

目录

框架

上图是我眼中的最简交易系统,它分为几个部分:

网关(Gateway): 负责和交易所/经纪人(远端)打交道。一方面接收行情数据(报价更新,订单更新等),另一方面把交易指令传给远端.
定价引擎(Pricing Engine): 接入的行情数据需要转换成策略需要的报价。对于衍生品来说,它的输出应当至少包含衍生品的理论价格。定价引擎可能还有额外的输入,比如对于期权定价而言,,一般会使用类Black-Scholes模型定价,有了标的物(underlying)的市场数据之后,它还需要波动率(volatility)、利率等参数的输入以及一些合规、风控相关的参数。
策略(Strategy): 交易策略接收定价引擎的信息,同时他也接受策略目标instrument的实时行情。不同的策略给出不同的执行建议,然后把这些执行建议传给后续模块。
风控&执行复用(Compliance & Execution Mux): 一个交易系统(很)可能同时执行多个策略。不同策略发出的执行建议可能互相重合、冲突或者产生执行时的合规风险。这个模块负责处理所有的执行请求,把合格的请求发给Gateway执行。这边用Mux相对形象一些,暂时还没想到更好的词。

需要说明的是,上面这些仅仅是极其基础的组件。如果把交易系统作为一个模块看待,它其实会有许多附加组件,例如高频交易员往往会根据经验值调整一些参数,这些参数会反映在策略执行、风控、定价模块中,于此就会产生一些和人交互的UI组件。

优化: 软件、硬件、程序语言…

不同于一众互联网公司的系统,高频交易系统对于低延迟的渴求相当急切,对它来说高并发往往是可以忽略的。重要的是一个报价更新如何最快到达系统,一个订单(order)如何在最快的时间内到达交易所。目前能见到的国外交易公司,主要用C++编写交易系统,当然也有很厉害的公司用自己定制的JVM跑Java交易。对于延迟不是非常敏感的市场,也有使用Python作为开发语言的。当然这些仅限于软件层面,事实上很多交易公司已经用上了FPGA用来进一步加速执行速度,甚至使用FPGA来执行一些简单但是对延迟极其敏感的交易策略。
以C++为例,代码编写上将会大量使用模板(template)替代虚函数。一般应用场景上虚函数调用的开销可能是不值一提的,但是如果算到了纳秒(或CPU tick)级别,虚函数的开销也会令人头疼。也许有人会问,那接口继承怎么不用虚函数弄呢?有兴趣的可以去看一下CRTP设计模式。

先讲这些吧,这个系列的以后几篇可能都会像这个模式写。一部分是系统相关的,另一部分讲代码优化上的一些有趣事情。

发表评论

电子邮件地址不会被公开。 必填项已用*标注