前言

自己一直對(duì)自動(dòng)化交易系統(tǒng)有著濃厚的興趣，但由于平時(shí)較忙，屬于紙上談兵，直到去年年底開始有些業(yè)余時(shí)間開始實(shí)踐。整個(gè)過程令人興奮，從一開始有了個(gè)策略想法，然后著手寫代碼回測(cè)證明能夠?qū)崿F(xiàn)理論盈利。于是開始實(shí)現(xiàn)系統(tǒng)，上線，小額試水，逐漸調(diào)高本金，調(diào)優(yōu)。最終，實(shí)現(xiàn)賬面上的真實(shí)盈利。本文則是對(duì)該系統(tǒng)實(shí)現(xiàn)的一個(gè)階段總結(jié)與分享。

目標(biāo)

實(shí)現(xiàn)一套自動(dòng)化交易系統(tǒng)（平臺(tái)），能夠回測(cè)/執(zhí)行自定義的交易策略（交易對(duì)象為比特幣）。該系統(tǒng)需要具備以下特性：

• 易于擴(kuò)展：隨著不斷對(duì)自動(dòng)化交易的理解，系統(tǒng)能夠適應(yīng)不斷豐富的功能
• 易于回測(cè)：能夠基于歷史價(jià)格對(duì)策略進(jìn)行回測(cè)，評(píng)估有效性，調(diào)優(yōu)參數(shù)
• 易于調(diào)試：能夠重現(xiàn)歷史執(zhí)行狀態(tài)，重現(xiàn)系統(tǒng)問題
• 低延遲：能夠支持中頻交易（非高頻），tick-to-trade在3秒以內(nèi)

事件驅(qū)動(dòng)
記錄所有時(shí)間序列事件（報(bào)價(jià)，訂單，賬戶等變化事件），通過對(duì)事件的回放從而可以重現(xiàn)任何時(shí)間點(diǎn)的歷史狀態(tài)。

架構(gòu) V1.0

特點(diǎn)： 單交易策略單執(zhí)行流

ets_arch_v1.png

• 各種Feed將Exchange的不同變化按時(shí)間序列轉(zhuǎn)換為事件放進(jìn)Event Queue，后者會(huì)將事件持久化到Event Logs
• Engine將產(chǎn)生的訂單放入Order Queue，由Execution異步請(qǐng)求Exchange，并將執(zhí)行結(jié)果送回Event Queue
• 訂單是否被fill的結(jié)果由Order Feed捕捉相應(yīng)Order變化事件

策略引擎組成

ets-engine.png

• Event Handlers處理所有事件，更新當(dāng)前系統(tǒng)狀態(tài)
• Validator可以按需定制，如檢查Order是否fill，價(jià)格延遲是否較高，損失是否過大等
• 鑒于Deflection是耗時(shí)操作，因此放在Strategy之后執(zhí)行（在下一次Strategy執(zhí)行時(shí)產(chǎn)生效果），以避免增加R2D延遲
• 整個(gè)過程由單線程執(zhí)行

回測(cè)支持

ets-regression.png

• 通過Event Logs讀取持久化的歷史價(jià)格事件（忽略其它事件）進(jìn)行策略回測(cè)，參數(shù)調(diào)優(yōu)
• Fake Client不發(fā)送請(qǐng)求至Exchange，而是模擬fill order事件

調(diào)試支持

ets-replay.png

• 通過回放Event Logs里所有事件（包括錯(cuò)誤等）以恢復(fù)任何歷史時(shí)間點(diǎn)狀態(tài)
• Fake Execution可以只是簡(jiǎn)單的控制臺(tái)輸出
• 有多種方式可以選擇設(shè)置Clock以回放出與歷史相一致的時(shí)間（這里不多敘述）

架構(gòu) V2.0

特點(diǎn)： 單交易策略多執(zhí)行流
多執(zhí)行流提供了以下優(yōu)勢(shì)：

• 可以減少單執(zhí)行流的Order Size，從而降低實(shí)際交易產(chǎn)生的摩擦
• 不同執(zhí)行流錨定不同的價(jià)格梯度，從而提高策略深度和Scalability

ets-arch-v2.png

• Dispatch Event Queue將事件發(fā)送到所有執(zhí)行流各自的Event Queue上
• 執(zhí)行流相互獨(dú)立，各自運(yùn)行于單獨(dú)線程，無需線程同步（除了下面講到的令牌場(chǎng)景作為例外）

架構(gòu) V3.0 (TBD)

特點(diǎn)： 多交易策略多執(zhí)行流
通過多交易策略捕捉更多日內(nèi)交易機(jī)會(huì)

一些問題的處理策略

延時(shí)衡量

目前系統(tǒng)所需衡量的延遲有：

• tick-to-receive (T2R): 交易所報(bào)價(jià)到系統(tǒng)收到價(jià)格間的延遲（主要取決于網(wǎng)絡(luò)延遲，交易所系統(tǒng)的成熟度/健康度）
• receive-to-decision （R2D)：收到價(jià)格到訂單決策間的延遲
• decision-to-execution (D2E)：訂單決策與訂單執(zhí)行間的延遲（應(yīng)該很?。?/li>
• execution-to-executed (E2E)：訂單執(zhí)行所需時(shí)間（主要取決于網(wǎng)絡(luò)延遲，交易所系統(tǒng)的成熟度），目前不屬于系統(tǒng)優(yōu)化范疇
• executed-to-filled (E2F)：訂單被交易所滿足所需時(shí)間，目前不屬于系統(tǒng)優(yōu)化范疇

所見非所得

由于訂單決策價(jià)格（Decision Price）往往與實(shí)際執(zhí)行價(jià)格不完全相等（目前都是采用Market Order下單），目前采取的策略有：

• 引入“摩擦力”，訂單決策基于所看到的價(jià)格加上預(yù)設(shè)摩擦力
• 將訂單執(zhí)行后實(shí)際產(chǎn)生的摩擦力記入交易成本
• 減小每次交易的Order Size，從而降低市場(chǎng)價(jià)格影響

策略饑餓

當(dāng)市場(chǎng)表現(xiàn)與策略所定參數(shù)長(zhǎng)時(shí)間相悖，導(dǎo)致策略長(zhǎng)時(shí)間不被執(zhí)行（饑餓），錯(cuò)過交易機(jī)會(huì)。目前采取的策略有：

• 動(dòng)態(tài)根據(jù)市場(chǎng)表現(xiàn)調(diào)整策略參數(shù)(Deflection)
• 采用多執(zhí)行流，提高策略深度

極端場(chǎng)景

默認(rèn)情況下策略會(huì)自動(dòng)調(diào)整來適應(yīng)當(dāng)前市場(chǎng)變化，以此減少饑餓，但當(dāng)市場(chǎng)進(jìn)入極端場(chǎng)景時(shí)，可能會(huì)被套牢。目前采取的策略是：

• 限定策略參數(shù)動(dòng)態(tài)調(diào)整的范圍，允許在極端場(chǎng)景下的饑餓，這樣可以避免因套牢產(chǎn)生的損失，并且一旦市場(chǎng)又回歸常態(tài)，也避免因套牢而產(chǎn)生的進(jìn)一步饑餓。

多執(zhí)行流沖突

當(dāng)運(yùn)行多執(zhí)行流，市場(chǎng)的快速波動(dòng)可能同時(shí)觸發(fā)多個(gè)執(zhí)行流的策略下單。為了避免使情況復(fù)雜化，采用如下策略簡(jiǎn)化執(zhí)行：

• 執(zhí)行流共享同一令牌，當(dāng)多個(gè)執(zhí)行流下單條件被同時(shí)觸發(fā)時(shí)（不常見），需要先請(qǐng)求令牌，只有獲得令牌的執(zhí)行流才能執(zhí)行下單。