当前位置：首页 > article >正文

【工具】第九期：高频交易系统开发简介与使用-03

article 2024/10/24 0:09:02

CTP接口无疑是高频交易最早的试验田，在众多的交易接口中，无论是期货市场的CTP量化交易接口，还是现货和期权市场的类CTP系统，如华鑫的奇点API和中泰的XTP，都有一套非常类似的报单回调规则，相比于迅投QMT、恒生PTrade或掘金量化，由于包含了相当多的交易细节，要复杂很多，非常容易出错。而很多市面上的三方系统由于对CTP的内部细节进行了封装与预处理，所以在上层二次开发就会比使用CTP原生的接口进行高频交易开发容易的多。不过对CTP处理的细节和委托规则，交易所规则越熟悉，就越能在系统层面对高频系统有更加精细的订单控制。

OnRtnOrder（）

交易系统返回的报单状态，每次报单状态发生变化时被调用。一次报单过程中会被调用数次：交易系统将报单向交易所提交时，交易所撤销或接受该报单时，该报单成交时。
新增处理方式：报单在交易所端校验失败，被交易所拒绝后，CTP 系统同样通过此接口返回报错信息；其中的 OrderStatusMsg 字段包含报错信息。

OnRtnTrade（）

如果该报单由交易所进行了撮合成交，交易所再次返回该报单的状态（已成交）。并通过此函数返回该笔成交。
报单成交之后，一个报单回报（OnRtnOrder）和一个成交回报（OnRtnTrade）会被发送到客户端，报单回报中报单的状态为“已成交”。但是仍然建议客户端将成交回报作为报单成交的标志，因为 CTP 的交易核心在收到 OnRtnTrade 之后才会更新该报单的状态。如果客户端通过报单回报来判断报单成交与否并立即平仓，有极小的概率会出现在平仓指令到达 CTP 交易核心时该报单的状态仍未更新，就会导致无法平仓。

在此次的高频订单中，不仅委托的合约比较特殊，回报也相对特殊。

一，如果使用OnRtnOrder()能保证委托和成交有精细的控制，但是无法确定OnRtnTrade()提前返回，也就是说无法保证在OnRtnOrder成交状态更新时，无法保证有真实的成交订单，而此时去在对向委托平仓单，就会出现委托失败-平仓量超过开仓量，如果使用OnOrder()去控制订单行为，就必须在OnRtnTrade()更新完全局的订单列表状态之后再去处理。在这里，回报是在同一个线程里，但是如果是两个线程，就涉及到线程同步的机制，需要使用轮询，信号/量机制来同步多个线程之间的执行流程。

二，如果使用OnRtnTrade()来控制订单的委托。能保证所有订单的成交都是真实的成交状态，但是仍然存在一个问题，就是OnRtnOrder()的OnRtnTrade()的时序返回先后无法保证，而OnRtnTrade()在控制订单的过程中，由于使用了委托状态中的委托价格，所以就必须通过OrderID去匹配，这个时候也是必须强制等待OnRtnOrder()的匹配订单的OrderID的返回，再去进行委托单的控制。

无论是上述哪种情况，其实都会涉及到策略业务逻辑和真实技术业务逻辑场景的匹配问题，这个时候就需要详细验证真实业务逻辑的可能存在的场景，使用更加合理的方案来处理和匹配策略业务逻辑。

使用程序化交易时需要时刻关注报单状态，无论是期货还是股票、可转债，大量撤单会造成天价的期货信息费或股票流量费，期货在前几年的委托申报中还新增了关于委撤比的费用通告，对成交率有更加严格的限制和管控，这点在系统设计上要更加注意，避免超过频次的报撤而采用更加灵活的设计，比如采用补单而非撤单重挂机制。