量化交易中对于系统效能的思考

在这里插入图片描述



前言

在量化交易系统开发过程中,系统本身的效能是一个十分重要的考量指标。如何高效的利用系统资源是长久以来一直都在讨论的话题。
从之前的多线程到多线程的优化方案,其实可以解决了大部分交易系统中存在的并发,多任务等相关为。剩下的就是为数不多的系统本身的资源消耗问题。
因为本身我们使用的语言就是Python,所以针对多核CPU的使用率一直以来都是诟病,很多人也给出了很多很好的解决方案,但是在我看来作为一个交易者来说,其实根本没必要纠结于如何让Python跑出比C++更快的速度,其实这个问题本身就是以为伪命题。没必要纠结。你需要考虑的是针对目前的交易系统来说如果做到最优解。轮速度你一个人永远比不了一些机构,他们不论是软件、硬件都是团队高投入的作战,你拿什么比?

一、交易系统中的效能主要指的是什么

在我看来在一套交易系统中效能主要指的就是一下几点:

  • 系统本身对CPU资源的消耗情况
  • 系统自身消耗情况

首先、系统本身对CPU的消耗。

先定几个基调:

  • 语言:Python3.7
  • 系统:Centos7.5
  • 实现:多进程分布式异步

通过定义了上面几个情况,我们讨论系统的资源消耗问题。
其实网上有很多关于Python的性能优化问题,我觉得集中针对在解析器、提供JIT、循环算法优化等。很多时候觉得没必要那么复杂。既然选择了这门语言就欣然接受他的高效性,而不是纠结于他的性能问题,因为你确实做的交易没那么快,可以说Python可以满足大多数人对速度的要求,少数人其实可以考虑有C/C++来玩。
但是对于一个刚入门的人来说,他用任何语言写出来的代码都不会比高手来的快,这是经验和编程习惯问题。
假设需求:在充分利用Python高效开发效率的情况下,尽可能的让交易系统在系统资源有限的情况下实现一套交易系统
6. 系统资源利用:多进程
7. 高效性:异步协程
以上两点是我目前能够想到的问题。
想要让Python充分的跑满CPU的唯一有效可行的方法就是多进程。给不同功能和不同模块的程序分配不同的进程,然后统一管理这多个进程,并让进程可以实现通讯交流。这个很多框架可以实现,不一一列举,后面找时间详细说。
想要让Python高效的运行现在最好的原生方案应该就是新特性的异步协程多任务模式。
在这里插入图片描述
以上是我的交易系统跑一个4核8G阿里云的情况,我使用的是多任务分布式的架构,底层SDK开发我使用的是Python,界面展示使用了NodeJs、Vue做的页面,Web端展示策略和账户的基本情况,目前托管了5个账户,加起来一共有大概30多个策略。每个策略和不同的任务之间都是一个独立的进程,进程中间使用的是异步协程,加了中间消息件做数据和消息的传输。
我之前测过如果想跑满我的CPU大概需要跑到700以上的策略才能达到CPU满负载运行的状态。

其次、系统自身消耗情况

系统自身的消耗,我称之为内消耗。
随着微服务的普及现在大多数交易系统都采取的是微服务结构。
这样做有一个好处,那就是在减少系统资源占有率的情况下可以充分实现模块之间的独立运行,不至于我一个模块出了问题我所有的功能都宕机了,这样我就可以在风控模块中做到对应接口和系统进程的检测,一旦某一个模块出了问题我就可以把控制权交给风控处理。
很久之前我也在速度上有着无线的追求,但是后来也就是放弃了,因为总有人会比你快,我作为个人投资者,不希望在这上面下太多的时间,因为我的经历可能更多的需要放在策略上,当然我单也没想象中那么快。正常的make,一般的低延迟是完全能够满足我的需求的。
内消耗在Python中是十分好控制的,减少对应的内消耗其实从另一个方面就是在加快系统本身的效率。
这也是我采用分布式的原因之一。
底层SDK的实现其目的是为了和交易所保持持久稳定的联系,为了让我随时想用一个接口的时候我随时都可以用得上,再加上对应的接口检测风控模块,我可以保证在交易时间段内给我的消息模块提供稳定持有的数据。SDK的启用本身就是一个持久模块,不需要很高的资源消耗,因为对于整个系统来说最消耗资源的应该是消息中间件。消息中间件的作用是起到消息和数据的传输,在交易过程中需要对Ticker、Trade、Asset、Position等信息做长久的监控和传输。还要针对我的订单请求和仓位请求等做对应的响应,频率没那么高,又是单机运行效率其实还可以,没有想象中那么慢。整体下来延迟可以做到10ms左右,这点我已经很满足了。
Web界面的NodeJs其实根本不需要考虑效率的问题,我只是用来检测账户、策略数据的一些基础情况,数据也都是从数据库直接拿,通过消息中间件来实现数据持久化。
大多数情况我是在检测我的微信和钉钉的报警提醒,这个也是独立出来的分支,独立的进程,有任何的一样的数据和接口问题都可以第一之间反馈到我的手机上,基本上可以做到24小时检测。
在这里插入图片描述
以上就是这个系统的分布情况。

二、再说分布式

分布式系统目前在我看来是最好的解决方案

作为交易系统而言,需要考虑的点主要有一下几点:

  1. 功能模块独立,互不干扰
  2. 资源占有率低,性能优越
  3. 交易、风控效率高

要解决以上的几个问题,我觉得最好的解决方案就是分布式了。
对于交易而言,我需要的是只解决交易相关的问题,没有太多复杂的功能区让真个系统过于臃肿。单纯的异步效益其实效率是很高的。
对于风控而言,我也是需要独立的管理,在出现问题的时候有绝对的控制权可以托管这个账户系统,让交易受限。
对于数据而言,我需要不断的存储很多我需要的数据,并且在不影响其他功能的情况下做这件事。
所以综合以上来说,想高效,想高性能就需要把每个功能都拆分开来,通过多进程来管理,分配独立的运行空间并且数据共享。

这里很多人会担心,拆分开来的系统响应效率问题,其实我觉得没必要过于担心。
考虑一下几点问题:
1、你的交易速度有多快?如果追求效率那么可能Python本身就不适合你。
2、你的策略是多策略还是单策略的运行,如果多策略,那么消息中心这种分布式接口很适合你,你可以跑上百上千个策略。
3、功能结构的管理是否对你来说需要分开?

总结

不论是系统消耗还是内消耗,都是交易系统研发过程中所需要解决的问题。
我从线性的交易模式发现了效率的低下后面采取了多线程、线程池的模式,在考虑对账户、数据、监控等多方面的思考我才去了分布式的接口,又回到效率问题,我研究异步协程。踩了无数的坑,通过无数的测试,目前来说这套系统我还是比较满意的。可能再过几个月,我依旧会发现新的为,或者是采用新的语言去重写这套东西。对于个人量化者来说,要走的路很多,都是不断一步一步积累来的。没有那种一蹴而就的事儿。就像打磨产品,需要时间和技术的积累。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值