基于事件驱动的自动化交易系统实践

前言

自己一直对自动化交易系统有着浓厚的兴趣，但由于平时较忙，属于纸上谈兵，直到去年年底开始有些业余时间开始实践。整个过程令人兴奋，从一开始有了个策略想法，然后着手写代码回测证明能够实现理论盈利。于是开始实现系统，上线，小额试水，逐渐调高本金，调优。最终，实现账面上的真实盈利。本文则是对该系统实现的一个阶段总结与分享。

目标

实现一套自动化交易系统（平台），能够回测/执行自定义的交易策略（交易对象为比特币）。该系统需要具备以下特性：

易于扩展：随着不断对自动化交易的理解，系统能够适应不断丰富的功能
易于回测：能够基于历史价格对策略进行回测，评估有效性，调优参数
易于调试：能够重现历史执行状态，重现系统问题
低延迟：能够支持中频交易（非高频），tick-to-trade在3秒以内

事件驱动
记录所有时间序列事件（报价，订单，账户等变化事件），通过对事件的回放从而可以重现任何时间点的历史状态。

架构 V1.0

特点： 单交易策略单执行流

ets_arch_v1.png

各种Feed将Exchange的不同变化按时间序列转换为事件放进Event Queue，后者会将事件持久化到Event Logs
Engine将产生的订单放入Order Queue，由Execution异步请求Exchange，并将执行结果送回Event Queue
订单是否被fill的结果由Order Feed捕捉相应Order变化事件

策略引擎组成

ets-engine.png

Event Handlers处理所有事件，更新当前系统状态
Validator可以按需定制，如检查Order是否fill，价格延迟是否较高，损失是否过大等
鉴于Deflection是耗时操作，因此放在Strategy之后执行（在下一次Strategy执行时产生效果），以避免增加R2D延迟
整个过程由单线程执行

回测支持

ets-regression.png

通过Event Logs读取持久化的历史价格事件（忽略其它事件）进行策略回测，参数调优
Fake Client不发送请求至Exchange，而是模拟fill order事件

调试支持

ets-replay.png

通过回放Event Logs里所有事件（包括错误等）以恢复任何历史时间点状态
Fake Execution可以只是简单的控制台输出
有多种方式可以选择设置Clock以回放出与历史相一致的时间（这里不多叙述）

架构 V2.0

特点： 单交易策略多执行流
多执行流提供了以下优势：

可以减少单执行流的Order Size，从而降低实际交易产生的摩擦
不同执行流锚定不同的价格梯度，从而提高策略深度和Scalability

ets-arch-v2.png

Dispatch Event Queue将事件发送到所有执行流各自的Event Queue上
执行流相互独立，各自运行于单独线程，无需线程同步（除了下面讲到的令牌场景作为例外）

架构 V3.0 (TBD)

特点： 多交易策略多执行流
通过多交易策略捕捉更多日内交易机会

一些问题的处理策略

延时衡量

目前系统所需衡量的延迟有：

tick-to-receive (T2R): 交易所报价到系统收到价格间的延迟（主要取决于网络延迟，交易所系统的成熟度/健康度）
receive-to-decision （R2D)：收到价格到订单决策间的延迟
decision-to-execution (D2E)：订单决策与订单执行间的延迟（应该很小）
execution-to-executed (E2E)：订单执行所需时间（主要取决于网络延迟，交易所系统的成熟度），目前不属于系统优化范畴
executed-to-filled (E2F)：订单被交易所满足所需时间，目前不属于系统优化范畴

所见非所得

由于订单决策价格（Decision Price）往往与实际执行价格不完全相等（目前都是采用Market Order下单），目前采取的策略有：

引入“摩擦力”，订单决策基于所看到的价格加上预设摩擦力
将订单执行后实际产生的摩擦力记入交易成本
减小每次交易的Order Size，从而降低市场价格影响

策略饥饿

当市场表现与策略所定参数长时间相悖，导致策略长时间不被执行（饥饿），错过交易机会。目前采取的策略有：

动态根据市场表现调整策略参数(Deflection)
采用多执行流，提高策略深度

极端场景

默认情况下策略会自动调整来适应当前市场变化，以此减少饥饿，但当市场进入极端场景时，可能会被套牢。目前采取的策略是：

限定策略参数动态调整的范围，允许在极端场景下的饥饿，这样可以避免因套牢产生的损失，并且一旦市场又回归常态，也避免因套牢而产生的进一步饥饿。

多执行流冲突

当运行多执行流，市场的快速波动可能同时触发多个执行流的策略下单。为了避免使情况复杂化，采用如下策略简化执行：

执行流共享同一令牌，当多个执行流下单条件被同时触发时（不常见），需要先请求令牌，只有获得令牌的执行流才能执行下单。