原帖地址:https://www.fmz.com/bbs-topic/1184
在商品期貨高頻交易策略中, Tick行情的接收速度對策略的盈利結果有着決定性的影響,
但市面上大多數交易框架,都是采用回調模式的機制, onBar/onTick, Tick不漏掉就不錯了, 為什么呢
因為onBar/onTick函數里面,你要處理一整遍代碼邏輯,很浪費時間, 不管你願不願意,你的策略邏輯必須被打斷,必須采用狀態機的模式,比如:
1 var state = STATE_IDLE; 2 function onTick() { 3 if (state == STATE_IDLE) { 4 // do something... 5 } else if (state == ....) { 6 // do something 7 } 8 }
FMZ沒有采用這種落后的回調機制, 而是采用了不打斷策略邏輯的main函數入口機制, 讓用戶可以更自然的控制策略流程,
用C++與Golang做為穩定的策略底層,策略上層用Javascript/Python處理邏輯問題, 不要說腳本語言速度慢,
除非你用它來做神經網絡訓練, 就算用神經網絡訓練, 加入Jit熱編譯后,他在任何場合都夠用的了, Chrome秒IE十條街就是例子.
結合事件觸發機制,同樣的也能使策略在第一時間最快的速度處理行情, 入門級的策略這里就不再寫了, 就以期貨高頻Tick的合成來說,
比如我們連接一個期貨公司, 只能收到這個期貨公司的行情, 我們接收行情的速度跟質量也跟自己的網絡有關系,
跟期貨公司前置機的負載也有關系,那么,怎么樣才能做到更快的獲取更准確的期貨Tick數據呢。
在FMZ的策略模型下,你很容易就能操作N家不同期貨公司的賬戶,並把他們的行情,融合處理,以最快的速度下單,
正常情況下,我們最多可以從期貨公司拿到兩個Tick每秒, 但通過融合行情的技術,以MA801為例,我們可以拿到最多一秒6次不重復的Tick。

廢話不多說,直接上代碼(此代碼只能實盤,不能回測, 如果您不用FMZ可以只參考原理):
實盤添加交易所時,可以添加N個期貨公司,進行行情的並發融合處理. 這里暫時添加兩個, 演示說明:
function main() { Log("准備連接交易所並訂閱行情") // Step 1: 全部期貨前置機都開始訂閱品種 _.each(exchanges, function(e) { // 等待連接上交易所, 是的, 策略是 365 天不間斷運行的, 休盤了也可以運行, 而且不是事件回調的邏輯 while (!e.IO("status")) Sleep(1000); // 利用_C重試函數排除網絡錯誤, 剛剛連上交易所就訂閱行情, 可能會出現CTP未准備好的錯誤 _C(e.SetContractType, "MA801") // 切換行情接收模式為立即返回模式而非事件觸發模式, 可參考API文檔 e.IO("mode", 0) }) Log("開始融合數據...") // Step 2: 重要的地方開始了 var preVolume = 0 while (true) { var ts = new Date().getTime() // 任何一個交易所有tick事件發生時就返回 var ret = exchange.IO("wait_any") // 合適的時間重置Volume if (ret.Nano/1000000 - ts > 60000) { preVolume = 0 } // 定位到發生事件的交易所 var e = exchanges[ret.Index] // 獲取行情, 之前切換過事件模式為立即返回, 所以這里返回的是剛更新的行情, 而且GetTicker不會失敗 // 只顯示成交量遞增的Tick, 實際過程,不用比較,只用處理就可以了. var ticker = e.GetTicker() if (ticker.Volume >= preVolume) { Log(ret, ticker.Last, ticker.Volume) preVolume = ticker.Volume } } }
效果如下:

可以看到21:24:44秒的時候第一個期貨公司的數據比第二個先到, 添加兩個期貨公司就看出來效果了,如果添加5個以上期貨公司一起融合
那么你基本上沒有漏Tick的可能, 如果用來開發高頻交易策略,你已經解決了很重要也是決定性的一步,Tick接收的速度以及穩定可靠性.
FMZ是專門為對策略的穩定性以及速度有挑剔級別的要求的開發者打造的一個平台. CTP低層協議技術自主研發, 可以在Linux/Windows/Mac/ARM單片機, 甚至手機下運行, 下單速度極快. 對行情反應速度快, 是做高頻策略的不二之選.
