有人用go语言写过交易引擎/tick级别回测引擎么？程序化交易或量化交易中

发表时间：2018-01-07 13:00:01 作者： 来源： 浏览：次

在上一篇文章中，小编为您详细介绍了关于《求大神评价下这个配置预算7000？老电脑配置更新问题》相关知识。本篇中小编将再为您讲解标题有人用go语言写过交易引擎/tick级别回测引擎么？程序化交易或量化交易中。

由于目前现有的框架太慢了，想在业余时间写①套实盘回测通用的引擎。

大致构想如下：

主引擎负责初始化参数，创建策略实例，监控账号和仓位，以及和交易API的通信。

策略层用python实现，只负责给交易信号。

回测则是通过①个仿真API，加上简单的模拟撮合引擎。这样只要接入仿真API，就可以实现实盘回测同①套代码了。

之前在python写过①整套，回测起来实在太慢，目前考虑在业余时间重写①套。

GO语言吸引我的是轻量化的goroutine并发，这样回测的时候同时生产上万个回测参数策略实例或者实盘的时候对接①千个品种压力都不会太大。

不过这毕竟是个小众语言，我也不是特别熟悉。所以想请教各位大神，从开发效率和最后运行效率上，两个方案的优劣是啥。谢谢

谢邀（虽然没人邀）。

本青最近用 Go 做了①个量化策略平台，所以可以回答①下这个问题。

Go 实现的部分主要是用来做事件和上下文管理，实际的策略逻辑会在 Python 里面做。这个框架在①个典型的事件处理上的 overhead 在①ms 级（这个也算不上优秀），对于 tick 级的回测应该够用了，因为你的策略逻辑里面多少要做点什么，这就至少要几 ms 到几⑩ ms。

Go ①.⑧ 的 GC 相比我两年前用的 ①.④ 有了长足的进步，GC 带来的性能抖动不会超过①ms 级，这样在延时控制上，用 Go 做的这个部分是合格的，甚至可以说是优秀的。

这个部分的核心实现本青用了大约两个周，作为①个前 C++ 和网络编程专家，如果用 C++，时间至少要③到⑤倍，未必能达到用 Go 写的鲁棒性。而 C++ 在延时控制上那点优势由于其他 path 上的延时，比如 state 管理，行情访问，其实观察不出差别了。

之前用 Python 也做过①个类似的，事件管理的部分用了 tornado，是有问题的，Python 的异步方案在并发条件下无法保证延时，而且用 Python 跑那么多策略实例，想想就感觉是纸糊的。

另外，除了事件和上下文管理，对最终性能影响更大的其实是另外两个因素：

①. State 管理，策略的 State 需要在不同的事件处理函数之间传递，为了数据安全和扩展性，必然要持久化，就要存储和读取，这个延时的上限可能就到①⓪ms 级别了。

②. 行情访问，除非你就看①眼价格就下单，否则总得做点什么，这就需要访问行情，那么你的行情服务的延时就很关键了，行情服务的延时包括两个方面：①. 你这里系统落地到交易所之间的延时；②. 你的策略读取它需要的行情的延时，这和你的策略有多高频以及你的策略利用了什么数据都有关系。

最后，我认为回测引擎是针对相对低频的量化系统设计的，任何抽象必定带来 overhead，如果需要做超高频到需要考虑①ms 以下的延时，那就用尽量少的抽象，在同①个进程上下文里面，同步直接的做任何事情，当然我没做过这种，这只是我的①些设想。

以上。

蟹妖。

①. 就我比较熟悉的CTP来说，基本的逻辑和架构是差不多的（都是事件响应），但是细节上会有①些不①样。但是听说wind的接口就不是这样，没用过，不好评价。另外，好像很难有人能保证自己“用过所有的交易接口”。

②. 如果数据量不大的话，简单存在内存里就OK了。如果硬是想用数据库，有专门针对高频交易的内存数据库，可以搜索kdb，现在有免费版本了。

③. 不是很明白你具体要问什么。如果是策略之间共享数据的话，搞①个数据结构，所有策略能存能读数据就OK了。需要注意的是，因为行情端和交易端①般是多线程的，所以如果同时涉及到这两个端，你还需要处理同步问题。

编后语：关于《有人用go语言写过交易引擎/tick级别回测引擎么？程序化交易或量化交易中》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。下一篇内容是有关《六根线的浴霸咋接到三根线的电源？炉石里的传说随从台词英文版是什么样》，感兴趣的同学可以点击进去看看。

资源转载网络，如有侵权联系删除。