11月第三周完成了数据链的通信,原有的架构也在实际运行的过程中得到了修改,改动如下:
1.配置文件系统。
原先计划程序运行之前读取配置文件,盘后将数据写入到文件中。先后尝试了文本文件、sqlite3、Lua。但是这个过程非常的复杂,文本文件的问题是文本文件的换行符没法strip掉。sqlite3的问题是没法将读取的字符串类型数据保存到数组里。lua的问题是和sqlite3差不多。所以最后采用简化问题的思路:改为配置从命令行获取的方式,每日手工运行程序。因为我的交易系统还涉及到品种选择和资金管理,而这两部分是无法自动化的,所以干脆将复杂的配置文件处理工作简化成手工命令行参数的方式也是没有影响的。
2.灾备系统。
原设计是为了保证策略的安全性,程序在本地运行,在云端进行账户监控,防止断网断电发生时候的无人处理的现象。后来考虑到维护的便捷性,最后还是决定整体迁移到阿里云。为了保证策略的安全性,阿里云上的都是编译过的代码,这样省去了监控断网断电部分的程序开发。也省去了诸如防黑加固等工作。
3.系统架构。
最最初考虑的是多品种,每个品种运行一个线程的多线程架构,但是这里面存在一个问题,因为我的系统是以1分钟为交易周期的,因此每个品种线程会定时的60秒钟去读取一次行情这个定时就要用到localtime函数,而恰恰这个时间函数是多线程不安全的,localtime_r事实证明也不是线程安全的。后来考虑使用每个品种一个Bin程序,这样可以避免Localtiime的问题,但是后来发现,CTP仍然会把其它品种的成交回报发送到本品种里,这样事实上没有有效的隔离。考虑到我的交易系统不是高频交易,对时间延迟和点位的敏感度不是很高,因此决定采用最简单的架构:
A:主线程承担行情订阅和刷新任务,在CTP的回调函数里随着CTP发送的行情不断的把价格赋值给全局变量,对,为了避免使用互斥锁带来的死锁风险,由于主线程是500MS赋值一次全局变量,副线程是1min读取一次值,因此采用全局变量的通信方式是可以满足要求的。
B:副线程承担下单任务。副线程1min读取一次行情,因为我的交易系统每天交易的品种通常不多(3-5个),并且采用的是对手价成交的方式,做趋势跟踪的大波段,因此对延迟和滑点不是很敏感,因此这个线程里,是按照顺序依次判断每个品种是否满足开平仓条件然后执行操作，这样牺牲了多品种并行的性能,但是简化了控制逻辑。
