最大的延时来自账户席位和网络延时,一席的账户成交优先级高于二席,二席又高于散户。怎样做倒一席呢?只要账户上有足够多的钱就可以。网络延时是最大的,因此在物理位置上离交易所核心机房越近越好,能直接放进去当然最好,如果不能,也要放到ping交易前置机在1ms以内的地方。证券公司会有资源,这要求动用你的一切力量争取到最满意的位置。早年间,这是场内交易和场外交易的区别。接下来就是算法的效率了,这个可以抽象出来跟语言没关系,大多跟数学/统计模型有关系,然后是算法的实现,c/c++/fortran/汇编的效率确实很好,而且优化的空间很大,但是如果很复杂的算法matlab可能会优化得比自己写得好,那就用matlab实现。这还没完,操作系统也可以调优,交易接口也可以不用交易所或者证券公司给的,自己分析通信协议重新实现;如果模型很复杂,计算量超大,那么就用并行计算架构,MPI, CUDA什么的用上。如果还要求绝对的速度,就用硬件实现算法, 这时候就轮到DSP芯片, FPGA什么的上阵,最后做一个专用的黑盒子。总之呢,就是所有能提高效率的地方,都是可以想办法做的。但是,其实你要考虑的首先是,你的速度要求有多高,或者问你的交易策略是否真的需要那么高的速度吗?其次是投入产出比,你的算法是否真的能够挣足够的钱来支持你做各层面的优化。以上很多虽然只有一句话,但是做起来东西很多,好多我现在也只知道概念,还不会做,提供个思路供参考。
作者:Sean Go
来源:知乎作者: 龙听 时间: 2019-6-10 06:15
问题中限定语言是C++,可讨论的范围就比较精简了。现有的答案都在谈系统架构层次上的东西,略显跑题。我对C++了解不多,但我尝试以一名C++程序员的视角,从基本思路出发做一个分析,抛砖引玉。首先我们要明确系统的需求。所谓交易系统,从一个应用程序的角度来说,有以下几个特点:一定是一个网络相关的应用,假如机器没联网,肯定什么交易也干不了。所以系统需要通过TCP/IP连接来收发数据。数据要分两种,一种从交易所发过来的市场数据,流量很大,另一种是系统向交易所发出的交易指令,相比前者流量很小,这两种数据需要在不同的TCP/IP连接里传输。因为是自动化交易系统,人工干预的部分肯定比较小,所以图形界面不是重点。而为了性能考虑,图形界面需要和后台分开部署在不同的机器上,通过网络交互,以免任何图形界面上的问题导致后台系统故障或者被抢占资源。这样又要在后台增加新的TCP/IP连接。高频交易系统对延迟异常敏感,目前(2014)市面上的主流系统(可以直接买到的大众系统)延迟至少在100微秒级别,顶尖的系统(HFT专有)可以做到10微秒以下。其他答案里提到C++随便写写延迟做到几百微秒,是肯定不行的,这样的性能对于高频交易来说会是一场灾难。系统只需要专注于处理自己收到的数据,不需要和其他机器合作,不需要担心流量过载。有了以上几点基本的认识,我们可以看看用C++做为开发语言有哪些需要注意的。首先前两点需求就决定了,这种系统一定是一个多线程程序。虽然对于图形界面来说,后台系统相当于一个服务端,但这部分的性能不是重点,用常用的模式就能解决(也许这里你可以介绍一下常用的C++ Client/Server库,或者内嵌Web Server之类,相信应该有丰富的选择,这里不展开讨论)。而重要的面向交易所那端,系统其实是一个客户端程序,只需要维护好固定数量的连接就可以了。为延迟考虑,一定要选择异步I/O(阻塞的同步I/O会消耗时间在上下文切换),这里有两点需要注意:是否可以在单线程内完成所有处理?考虑市场数据的流量远远高于发出的交易指令,在单线程内处理显然是不行的,否则可能收了一大堆数据还没开始处理,错过了发指令的最佳时机。有答案提到要压低平时的资源使用率,这是完全错误的设计思路。问题同样出在上下文切换上,一旦系统进入IDLE状态,再重新切换回处理模式是要付出时间代价的。正确的做法是在线程同步代码中保持对共享变量/内存区的疯狂轮询,一旦有消息就立刻处理,之后继续轮询,这样是最快的处理方式。(顺带一提现在的CPU一般会带有环保功能,使用率低了会导致CPU进入低功耗模式,同样对性能有严重影响。真正的低延迟系统一定是永远发烫的!)现在我们知道核心的模块是一个多线程的,处理多个TCP/IP连接的模块,接下来就可以针对C++进行讨论。因为需要对接受到的每个TCP或UDP包进行处理,首先要考虑的是如何把包从接收线程传递给处理线程。我们知道C++是面向对象的语言,一般情况下最直观的思路是创建一个对象,然后发给处理线程,这样从逻辑上看是非常清晰的。但在追求低延迟的系统里不能这样做,因为对象是分配在堆上的,而堆的内存结构对我们来说是完全不透明的,没办法控制一个对象会具体分到内存的什么位置上,这直接导致的问题是本来连续收到的网络包,在内存里的分布是分散的,当处理线程需要读取数据时就会发生大量的cache miss,产生不可控的延迟。所以对C++开发者来说,第一条需要谨记的应该是,不要随便使用堆(用关键字new)。核心的数据要保证分配在连续内存里。另一个问题在于,市场数据和交易指令都是结构化的,包含了股票名称,价格,时间等一系列信息。如果使用C++ class来对数据进行建模和封装,同样会产生不可知的内存结构。为了严格控制内存结构,应该使用struct来封装。一方面在对接收到的数据解析时可以直接定义名称,一方面在分配新对象(比如交易指令)时可以保证所有数据都分配在连续的内存区域。以上两点是关于延迟方面最重要的注意事项(如果真正做好这两点,大概剩下的唯一问题是给系统取个好名字吧:TwoHardThings)。除此之外,需要考虑的是业务逻辑的编写。高频交易系统里注定了业务逻辑不会太复杂,但重要的是要保证正确性和避免指针错误。正确性应该可以借助于C++的特性比如强类型,模板等来加强验证,这方面我不熟悉就不多说了。高频系统往往运行时要处理大量订单,所以一定要保证系统运行时不能崩溃,一旦coredump后果很严重。这个问题也许可以多做编译期静态分析来加强,或者需要在系统外增加安全机制,这里不展开讨论了。以下是几点引申思考:如何存储系统日志?如何对系统进行实时监控?如果系统coredump,事后如何分析找出问题所在?如何设计保证系统可用性,使得出现coredump之类的情况时可以及时切换到备用系统?这些问题相信在C++框架内都有合适的解决方案,我对此了解不多,所以只列在这里供大家讨论。注:从开发语言角度上说,C++只是一种选择,并不是唯一的解决方案。简单的认为低延迟就等同于用C++开发,是不正确的。其他语言同样有可能做出高性能的设计,需要根据语言特性具体分析。关于整体的软硬件架构,可以看我的另一个回答:高频交易软硬件是怎么架构的?关于C++在性能方面的一些最新发展,包括内存结构的一些分析,可以参看:Modern C++: What You Need to Know作者: 龙听 时间: 2019-6-10 06:15
只搞过 sell side,没搞过 buy side,只能算“实时交易”,算不上“高频交易”。工作以来一直在跟延迟做斗争,勉强可以说上几句。要控制和降低延迟,首先要能准确测量延迟,因此需要比较准的钟,每个机房配几个带GPS和/或原子钟primary standard的NTP服务器是少不了的。而且就算用了NTP,同一机房两台机器的时间也会有毫秒级的差异,计算延迟的时候,两台机器的时间戳不能直接相减,因为不在同一时钟域。解决办法是设法补偿这个时差。另外,不仅要测量平均延迟,更重要的是要测量并控制长尾延迟,即99百分位数或99.9百分位数的延迟,就算是sell side,系统偶尔慢一下被speculator利用了也是要亏钱的。普通的C++服务程序,内部延迟(从进程收到消息到进程发出消息)做到几百微秒(即亚毫秒级)是不需要特殊的努力的。没什么忌讳,该怎么写就怎么写,不犯低级错误就行。我很纳闷国内流传的写 C++ 服务程序时的那些“讲究”是怎么来的(而且还不是 latency critical 的服务程序)。如果瓶颈在CPU,那么最有效的优化方式是“强度消减”,即不在于怎么做得快,而在于怎么做得少。哪些可以不用做,哪些可以不提前做,哪些做一次就可以缓存起来用一阵子,这些都是值得考虑的。网络延迟分传输延迟和惯性延迟,通常局域网内以后者为主,广域网以前者为主。前者是传送1字节消息的基本延迟,大致跟距离成正比,千兆局域网单程是近百微秒,伦敦到纽约是几十毫秒。这个延迟受物理定律限制,优化办法是买更好的网络设备和租更短的线路(或者想办法把光速调大,据说 Jeff Dean 干过)。惯性延迟跟消息大小成正比,跟网络带宽成反比,千兆网TCP有效带宽按115MB/s估算,那么发送1150字节的消息从第1个字节离开本机网卡到第1150个字节离开本机网卡至少需要 10us,这是无法降低的,因此必要的话可以减小消息长度。举例来说,要发10k的消息,先花20us CPU时间,压缩到3k,接收端再花10us解压缩,一共“60us+传输延迟”,这比直接发送10k消息花“100us+传输延迟”要快一点点。(广域网是否也适用这个办法取决于带宽和延迟的大小,不难估算的。)延迟和吞吐量是矛盾的,通常吞吐量上去了延迟也会跟着飚上去,因此控制负载是控制延迟的重要手段。延迟跟吞吐量的关系通常是个U型曲线,吞吐量接近0的时候延迟反而比较高,因为系统比较“冷”;吞吐量上去一些,平均延迟会降到正常水平,这时系统是“温”的;吞吐量再上去一些,延迟缓慢上升,系统是“热”的;吞吐量过了某个临界点,延迟开始飙升,系统是“烫”的,还可能“冒烟”。因此要做的是把吞吐量控制在“温”和“热”的范围,不要“烫”,也不要太冷。系统启动之后要“预热”。延迟和资源使用率是矛盾的,做高吞吐的服务程序,恨不得把CPU和IO都跑满,资源都用完。而低延迟的服务程序的资源占用率通常低得可怜,让人认为闲着没干什么事,可以再“加码”,要抵住这种压力。就算系统到了前面说的“发烫”的程度,其资源使用率也远没有到 100%。实际上平时资源使用率低是为了准备应付突发请求,请求或消息一来就可以立刻得到处理,尽量少排队,“排队”就意味着等待,等待就意味着长延迟。消除等待是最直接有效的降低延迟的办法,靠的就是富裕的容量。有时候队列的长度也可以作为系统的性能指标,而不仅仅是CPU使用率和网络带宽使用率。另外,队列也可能是隐式的,比如操作系统和网络设备的网络输入输出 buffer 也算是队列。延迟和可靠传输也是矛盾的,TCP做到可靠传输的办法是超时重传,一旦发生重传,几百毫秒的延迟就搭进去了,因此保持网络随时畅通,避免拥塞也是控制延迟的必要手段。要注意不要让batch job抢serving job的带宽,比方说把服务器上的日志文件拷到备份存储,这件事不要在繁忙交易时段做。QoS也是办法;或者布两套网,每台机器两个网口,两个IP。最后,设法保证关键服务进程的资源充裕,避免侵占(主要是CPU和网络带宽)。比如把服务器的日志文件拷到别的机器会占用网络带宽,一个办法是慢速拷贝,写个程序,故意降低拷贝速度,每50毫秒拷贝50kB,这样用时间换带宽。还可以先压缩再拷贝,比如gzip压缩100MB的服务器日志文件需要1秒,在生产服务器上会短期占满1个core的CPU资源,可能造成延迟波动。可以考虑写个慢速压缩的程序,每100毫秒压缩100kB,花一分半钟压缩完100MB数据,分散了CPU资源使用,减少对延迟的影响。千万不要为了加快压缩速度,采用多线程并发的办法,这就喧宾夺主了。
作者:陈硕