xywanz / ft Goto Github PK

紧急！！！

在ctp附近加的log，和策略ontick加的log比较。

2021-03-25 02:04:39.057.057464 [error][] : instrumentid=ag2106
2021-03-25 02:04:39.057.057794 [info][] : GridStrategy::on_tick ft::datetime::Datetime(2021, 3, 25, 2, 4, 38, 500000),id:au2106, last_price:367.36, grid:5239.00, long:0, short:0, trades:1

有什么办法能减少这个延迟么， 比如跳过redis直接先送到策略。

一是可以把oms和行情系统解耦开。

二是一个行情服务可以同时接入多个行情源，对多个来源的行情进行去重、融合、择优，最后分发给策略。

仓位、资金等信息都加载到共享内存，行情数据也考虑写入到共享内存。策略程序单独出来，通过共享内存获取仓位资金等信息，并通过共享内存队列进行下单，这样一来既可以解耦各个部分，又可以实现一个策略一个进程。

zmq连接建立需要时间，但是如果在连接还未建立的时候发送消息，会导致消息丢失。
目前的解决方式是连接建立后等待200ms，更好的解决方案应该是通过poll监听连接成功的事件，但是会让逻辑复杂

本人也正在酝酿中，下一步准备根据当前的轮子做一些扩展，如期货跨期套利、ETF套利的支持，完成之后会一次性地提交

@DuckDuckDuck0 您好，python的demo使用redis进行通信，添加zmq通信后，使用zmq发生tick和订单回报，python是否还能使用，是不是需要手动切换回redis通信？

都是travis相关的，希望在大家的机器上都能直接编译成功

TradingEngine现在是一个基于tick数据的交易框架，并未提供历史数据的采集、处理等操作，目前需要一套较为完整的历史数据解决方案供策略使用：

1. 加载历史数据，指定加载的数据，从数据库、文件或网站等
2. 对数据进行加工，生成指标等
3. 同时支持通过实时tick数据对指标进行更新
4. 数据采集、持久化等，供后续使用

请问目前这套系统支持单账户多策略吗？

是否有开发计划测算 tick to trade 的延迟？

比如使用chrono提供的 API std::chrono::steady_clock::now().time_since_epoch() 计算 real time latency；或者 tsc frequency 校准不同 CPU core 后计算 CPU time latency？

问题描述：
策略向ft_trader发消息是通过zmq pub/sub模式。
ft_trader为sub，策略为pub，所以同一时间无法有多个策略绑定到同一个ft_trader

解决方案(TODO)：
方案一：采用zmq xpub/xsub模式
方案二：使用redis来发送交易指令
方案三：使用共享内存队列发送交易指令

1. 策略引擎的重构。策略引擎（StrategyEngine）现在完全是单线程的，包括仓位、订单、成交回执、tick数据的处理、策略的执行都是在同一个线程里，这样可以避免锁，对于现在只加载单个合约、不使用复杂指标、只加载单个策略、策略不进行复杂计算的情况来说没什么性能问题。但是考虑到如果订阅的合约数量大了，以及合约和策略将来可能是多对多的关系，而且策略可能要进行一些比较复杂的计算（深度学习之类的），当前的架构就会存在性能瓶颈，严重则会导致tick数据被无限滞后。所以需要对策略引擎进行重新设计，使得策略引擎能应付n:m（n个策略对应m个合约）的策略。
   ---- 已完成
2. 开发行情系统。从行情系统应能高效地获取到历史行情数据以及当日行情数据。这里还需要对行情数据进行一些定义，到底需要用到哪些基本的行情数据（如tick，K线等）。
   ---- 目前完成行情转发，历史行情管理及指标将在其他模块提供
3. 指标模块。指标模块能根据历史数据预先计算历史的指标，还能根据当日的tick数据更新当日的指标，用户可自定义指标，同时交易系统也会提供常用的指标）。
4. TradingView对于订单的处理可能存在问题。
   ---- 已废弃
5. 开发回测系统，通过替换CTP的动态库（换成自己开发的）来实现回测。
   ---- 直接自己写个模拟的gateway而不用替换ctp的so
6. 要能处理断开连接等错误情况。
7. 每日收盘结算。
8. 能处理本地资金更新信息。
9. 能处理启动时就已经存在的挂单。
   ---- 启动时撤单，已完成

开发计划：
第一阶段：提供一个完整的策略交易平台，对于速度不做过多优化，能够保证易用性，目前处于该阶段
第二阶段：行情回报分发以及交易指令分发全部基于无锁共享内存队列实现。这个其实可以和第一阶段一起推进，但由于精力有限还未实施
第三阶段：优化数据结构、cache命中率以及整体架构

ctp的中文字符集是gb2312，ft会把其转换成utf8，如果本地没有安装gb2312的话，程序运行到需要转码的地方时会抛出错误，临时的解决办法就是修改gb2312_to_utf8这个函数，使其直接返回传入的字符串即可，但是这样会在运行时打印出乱码。