簡介基于上期技術(shù)綜合交易平臺CTP2011.4.19版本二次封裝的C#類庫專為期貨量化開發(fā)與交易系統(tǒng)集成場景設(shè)計(jì)解決C#環(huán)境直接對接原生CTP接口繁瑣、多賬戶同時(shí)登錄管理不便等實(shí)際問題。整套資料共65個(gè)文件、約452KB主體包含.h/.cpp原生接口聲明與實(shí)現(xiàn)、.cs托管封裝代碼配合.sln/.vcproj/.vcxproj工程文件、.xml/.con/.dtd配置定義以及DLL和LIB庫覆蓋交易與行情雙通道按文檔與代碼結(jié)合的方式呈現(xiàn)便于快速理解交易Api與行情Api的調(diào)用層級。已有391人學(xué)習(xí)下載。包內(nèi)將TradeApi、MdApi分開封裝交易和行情職責(zé)清晰提供自動(dòng)生成C#接口腳本、Struct結(jié)構(gòu)定義以及多賬戶登錄相關(guān)處理邏輯從接口聲明到托管包裝的完整鏈路均清晰可查可直接參考其命名與組織方式適合具備C#基礎(chǔ)并希望掌握CTP接口封裝的開發(fā)者研讀。1. 上期技術(shù)綜合交易平臺(C#封裝)量化團(tuán)隊(duì)繞不開的那個(gè)“黑匣子”接期貨量化系統(tǒng)時(shí)團(tuán)隊(duì)清一色C#柜臺側(cè)的上期技術(shù)綜合交易平臺CTP卻只給C接口指針、回調(diào)、結(jié)構(gòu)體文檔厚得能墊顯示器。第一次聯(lián)調(diào)就差點(diǎn)翻車不是連不上是不知道從哪下手包這一層。后來把CTP的行情通道和交易通道用C#重新封裝事情才順起來。這篇文章講這條封裝的落地路徑接口怎么拆、最小代碼怎么寫、參數(shù)怎么設(shè)、哪些地方特別容易踩坑。適合期貨量化開發(fā)、交易系統(tǒng)集成工程師以及想用C#重構(gòu)交易終端的團(tuán)隊(duì)。2. CTP接口組成與C#封裝三條路線先選型再動(dòng)手2.1 一個(gè)C核心、兩套獨(dú)立通道行情前置與交易前置CTP對外只提供C動(dòng)態(tài)庫開發(fā)者以加載動(dòng)態(tài)庫的方式獲得API能力。典型結(jié)構(gòu)是兩套通道行情通道負(fù)責(zé)連接行情前置、訂閱合約、接收快照和深度行情交易通道負(fù)責(zé)登錄、認(rèn)證、查詢賬戶、報(bào)單、撤單以及接收成交回報(bào)和資金變動(dòng)。兩套通道的連接地址、會話狀態(tài)、重連機(jī)制彼此獨(dú)立封裝的代碼也建議按這個(gè)邊界拆成兩個(gè)模塊不要合并成一個(gè)什么都干的類。為什么分成兩路行情推送頻率高、要求低延遲一個(gè)合約一秒可能推幾十筆交易指令頻率低但絕對要求可靠。如果共用一條TCP連接行情高峰會把交易指令擠到隊(duì)列后面撤單晚一刻可能就是要命。CTP把兩條通道物理隔開本身就是為生產(chǎn)環(huán)境設(shè)計(jì)的。封裝時(shí)必須保留這種分離否則等于把柜臺的優(yōu)化破壞掉。C側(cè)的交互模型是API與SPI分離應(yīng)用繼承回調(diào)類重寫OnRtnXXX方法CTP把數(shù)據(jù)通過回調(diào)指針交給應(yīng)用。對應(yīng)到C#世界就是C回調(diào)橋接層加C#事件委托。橋接層要處理的問題包括C線程進(jìn)入托管代碼、結(jié)構(gòu)體內(nèi)存拷貝、委托對象不能被垃圾回收。這些細(xì)節(jié)決定了封裝是三天寫完還是三周填坑。2.2 P/Invoke、C/CLI還是第三方庫三條路線的取舍第一條路線是P/Invoke直接用C#聲明入口函數(shù)用結(jié)構(gòu)體Layout映射C數(shù)據(jù)結(jié)構(gòu)。優(yōu)點(diǎn)是依賴最小、接口更新時(shí)可以自己跟進(jìn)缺點(diǎn)是結(jié)構(gòu)體對齊、回調(diào)委托生命周期要自己管理第一版工作量最大。第二條路線是C/CLI寫一個(gè)托管C包裝動(dòng)態(tài)庫內(nèi)部用原生C調(diào)CTP外部暴露純C#類。優(yōu)點(diǎn)是橋接代碼用C寫指針操作和回調(diào)翻譯都順手缺點(diǎn)是需要維護(hù)兩個(gè)工程編譯選項(xiàng)復(fù)雜團(tuán)隊(duì)里要有人真正懂C否則后期沒人敢動(dòng)。第三條路線是直接使用社區(qū)現(xiàn)成的C#封裝庫。優(yōu)點(diǎn)是上手最快API設(shè)計(jì)更接近C#風(fēng)格缺點(diǎn)是版本跟進(jìn)依賴社區(qū)期貨公司要求升級接口版本時(shí)容易被卡住有些封裝還會把底層錯(cuò)誤細(xì)節(jié)吞掉排查問題時(shí)像在猜謎。適合快速驗(yàn)證業(yè)務(wù)不適合長期跑真金白銀。路線學(xué)習(xí)成本版本跟進(jìn)回調(diào)控制力適合場景P/Invoke 手寫中自己跟進(jìn)強(qiáng)長期維護(hù)的生產(chǎn)系統(tǒng)C/CLI 橋接高自己跟進(jìn)很強(qiáng)團(tuán)隊(duì)本身會C第三方封裝庫低依賴社區(qū)弱原型驗(yàn)證、小規(guī)模工具我一般推薦P/Invoke或者C/CLI二選一。穩(wěn)定壓倒一切接口版本掌握在自己手里比什么都重要。選完技術(shù)路線還要決定封裝到哪一層。封裝不是把幾百個(gè)接口翻譯一遍而是做一個(gè)交易門面會話管理、模型轉(zhuǎn)換、請求與回報(bào)關(guān)聯(lián)、狀態(tài)緩存。只做翻譯不做事業(yè)務(wù)層還是寫不順手。2.3 封裝的最小模塊會話、事件、模型、狀態(tài)一個(gè)合格的C#封裝對外應(yīng)該是一套貼近業(yè)務(wù)的接口而不是一堆結(jié)構(gòu)體加回調(diào)。我會先把門面定出來public interface ITradeGateway { void Connect(string brokerId, string userId, string password); void Subscribe(string instrumentId); string PlaceOrder(OrderRequest order); void CancelOrder(string exchangeId, string orderSysId); event EventHandlerLoginInfoEventArgs LoggedIn; event EventHandlerOrderEventArgs OrderUpdated; event EventHandlerTickEventArgs TickReceived; }Connect對應(yīng)登錄過程PlaceOrder返回一個(gè)本地委托號業(yè)務(wù)層不感知CTP字段撤單也只需要知道交易所ID和柜臺報(bào)單號。這樣業(yè)務(wù)方只對接一個(gè)C#類將來換別的柜臺實(shí)現(xiàn)時(shí)替換內(nèi)部實(shí)現(xiàn)即可。內(nèi)部至少拆成五塊會話管理、事件分發(fā)、模型映射、請求序列器、狀態(tài)存儲。其中事件分發(fā)是核心CTP的回調(diào)線程既不是UI線程也不是業(yè)務(wù)線程網(wǎng)關(guān)內(nèi)部要維護(hù)一個(gè)并發(fā)隊(duì)列回調(diào)只投遞不處理工作線程出隊(duì)再觸發(fā)事件。這個(gè)決定直接影響后面所有性能問題的走向。3. 最小連接先跑通環(huán)境參數(shù)、C#登錄代碼與成功判定3.1 聯(lián)調(diào)前需要確認(rèn)的六類參數(shù)別把流文件目錄和AppID漏掉CTP接入最容易翻車的不是代碼是參數(shù)配對。聯(lián)調(diào)前先列一張參數(shù)確認(rèn)表每一項(xiàng)都找柜臺或運(yùn)維確認(rèn)而不是自己猜配置項(xiàng)示例說明行情前置地址tcp://x.x.x.x:41213行情通道連接地址由期貨公司分配交易前置地址tcp://x.x.x.x:41205交易通道連接地址BrokerID期貨公司統(tǒng)一編碼登錄必需UserID / Password資金賬號與密碼登錄憑證AppID / AuthCode認(rèn)證編號 / 認(rèn)證碼啟用認(rèn)證后必填缺失直接認(rèn)證失敗流文件目錄C:\ctp_flow保存會話與報(bào)單引用的本地目錄流文件目錄最容易被忽略。CTP會把登錄會話、報(bào)單序號等狀態(tài)寫進(jìn)這個(gè)目錄如果應(yīng)用沒有寫權(quán)限表現(xiàn)是連接能建立但運(yùn)行一段時(shí)間后被斷開重啟又能撐一會。另一個(gè)高頻踩坑是接口動(dòng)態(tài)庫版本與前置版本不一致不少團(tuán)隊(duì)在這里消耗一整天最后發(fā)現(xiàn)不是自己代碼問題。我一般會先做一個(gè)配置對象把所有參數(shù)收斂到一起啟動(dòng)時(shí)統(tǒng)一校驗(yàn)和存檔避免散落在各個(gè)模塊里public class CtpProfile { public string BrokerId { get; set; } public string UserId { get; set; } public string Password { get; set; } public string AppId { get; set; } public string AuthCode { get; set; } public string MdFrontAddress { get; set; } public string TraderFrontAddress { get; set; } public string FlowPath { get; set; } public void Validate() { if (!TraderFrontAddress.StartsWith(tcp://)) throw new ArgumentException(交易前置地址必須是以 tcp:// 開頭的完整地址); if (string.IsNullOrEmpty(BrokerId) || string.IsNullOrEmpty(UserId)) throw new ArgumentException(BrokerID 和 UserID 不能為空); } }配置對象的好處是啟動(dòng)時(shí)快速暴露問題而不是等登錄失敗后再從一堆控制臺輸出里翻原因。Address校驗(yàn)這種邏輯放在這里的成本幾乎為零卻能擋住最蠢的配置拼寫錯(cuò)誤。3.2 C#拉起交易通道的最小代碼初始化、登錄、等待回調(diào)以P/Invoke方案為例常見做法是先聲明加載交易通道動(dòng)態(tài)庫的入口然后創(chuàng)建API實(shí)例并注冊回調(diào)。核心代碼可以收斂成下面這樣[DllImport(thosttraderapi.dll, CallingConvention CallingConvention.Cdecl)] private static extern IntPtr CreateFtdcTraderApi(string pszFlowPath); public void Connect(CtpProfile profile) { _profile profile; Directory.CreateDirectory(profile.FlowPath); // 目錄必須提前存在且可寫 _api CreateFtdcTraderApi(profile.FlowPath); // 創(chuàng)建交易API實(shí)例 _callbackBridge new TraderCallbackBridge(this); _api.SetCallback(_callbackBridge); // 注冊回調(diào)橋接對象 _api.SubscribePrivateTopic(2); // 私有流斷線自動(dòng)補(bǔ)發(fā) _api.SubscribePublicTopic(2); // 公有流斷線自動(dòng)補(bǔ)發(fā) _api.RegisterFront(profile.TraderFrontAddress); _api.Init(); // 發(fā)起異步連接 }pszFlowPath必須是應(yīng)用有寫權(quán)限的獨(dú)立目錄。SubscribePrivateTopic和SubscribePublicTopic的參數(shù)2表示斷線重連后自動(dòng)補(bǔ)發(fā)數(shù)據(jù)這是生產(chǎn)環(huán)境的推薦值能減少回報(bào)丟失帶來的狀態(tài)不一致。Init之后連接是異步的真正連通要看OnFrontConnected回調(diào)而不是看Init返回值?；卣{(diào)橋接對象必須用字段持有不能用局部變量傳進(jìn)去。C側(cè)保存的是函數(shù)指針C#側(cè)如果委托被垃圾回收回調(diào)觸發(fā)時(shí)就是訪問已釋放內(nèi)存表現(xiàn)為隨機(jī)崩潰這類問題排查起來非常傷。連通之后發(fā)送登錄請求public void HandleFrontConnected() { var req new CThostFtdcReqUserLoginField { BrokerID _profile.BrokerId, UserID _profile.UserId, Password _profile.Password, AppID _profile.AppId, AuthCode _profile.AuthCode, ClientIPAddress LocalIPAddress() }; int ret _api.ReqUserLogin(req, _requestId); if (ret ! 0) { Log.Error(登錄請求發(fā)送失敗錯(cuò)誤碼: {0}, ret); } }ReqUserLogin返回0只表示請求已進(jìn)入發(fā)送隊(duì)列不表示登錄成功。登錄結(jié)果必須等回報(bào)回調(diào)來判斷。ClientIPAddress建議主動(dòng)填本機(jī)出口IP部分柜臺會做來源校驗(yàn)空著也可能被拒。3.3 登錄成功的三個(gè)關(guān)鍵值ErrorID、MaxOrderRef與會話持久化登錄響應(yīng)在OnRspUserLogin回調(diào)里返回判斷邏輯如下public void OnRspUserLogin( CThostFtdcRspUserLoginField rsp, CThostFtdcRspInfoField rspInfo, int requestId, bool isLast) { if (rspInfo ! null rspInfo.ErrorID ! 0) { Log.Error(登錄失敗: {0} - {1}, rspInfo.ErrorID, rspInfo.ErrorMsg); return; } _frontId rsp.FrontID; // 前置編號 _sessionId rsp.SessionID; // 會話編號 _currentOrderRef rsp.MaxOrderRef; // 本地報(bào)單序號基數(shù) Log.Info(登錄成功交易日: {0}, rsp.TradingDay); }這里保存三個(gè)關(guān)鍵值FrontID和SessionID唯一標(biāo)識當(dāng)前會話網(wǎng)絡(luò)斷開重連恢復(fù)時(shí)需要用到MaxOrderRef是本地報(bào)單引用的基數(shù)后續(xù)每發(fā)一單從它開始遞增。TradingDay決定當(dāng)前交易日像上期所平今倉判斷要用這個(gè)日期業(yè)務(wù)層也要記住。只判斷返回值和ErrorID還不夠要把這三個(gè)值保存下來。如果進(jìn)程重啟、網(wǎng)絡(luò)閃斷沒有會話信息就無法恢復(fù)后面行情正常但報(bào)單狀態(tài)錯(cuò)亂看起來就是玄學(xué)問題。4. 行情與交易落地訂閱推送、報(bào)單撤單與持倉核對4.1 訂閱行情從SubscribeMarketData到tick事件行情通道的登錄流程和交易通道類似登錄成功后才能訂閱合約。訂閱接口一次可以傳多個(gè)合約public void SubscribeMarketData(string[] instrumentIds) { var fields new CThostFtdcSubscribeMarketDataField[instrumentIds.Length]; for (int i 0; i instrumentIds.Length; i) { fields[i] new CThostFtdcSubscribeMarketDataField { InstrumentID instrumentIds[i] }; } int ret _mdApi.SubscribeMarketData(fields, fields.Length); if (ret ! 0) { Log.Error(訂閱行情失敗錯(cuò)誤碼: {0}, ret); } }訂閱是批量接口傳入結(jié)構(gòu)體數(shù)組和數(shù)量不要一個(gè)個(gè)循環(huán)調(diào)。每個(gè)合約的行情數(shù)據(jù)通過OnRtnDepthMarketData回調(diào)進(jìn)來核心字段包括LastPrice最新價(jià)、Volume成交量、AskPrice1和BidPrice1盤口價(jià)?；卣{(diào)里要做空值防護(hù)集合競價(jià)階段部分字段會是默認(rèn)值。行情回調(diào)里絕對不能做耗時(shí)操作。常見做法是回調(diào)里只把數(shù)據(jù)拷貝到一個(gè)線程安全的隊(duì)列由獨(dú)立行情線程消費(fèi)private readonly ChannelTickData _tickChannel Channel.CreateUnboundedTickData(); void OnRtnDepthMarketData(TickData tick) { _tickChannel.Writer.TryWrite(tick); // 只入隊(duì)不做業(yè)務(wù) } async Task TickLoopAsync() { while (await _tickChannel.Reader.WaitToReadAsync()) { var tick await _tickChannel.Reader.ReadAsync(); RaiseTick(tick); // 在業(yè)務(wù)線程觸發(fā)事件 } }這里用Channel而不是ConcurrentQueue是因?yàn)镃hannel支持異步讀取消費(fèi)者線程可以掛起等待而不是輪詢減少空轉(zhuǎn)CPU。行情高頻時(shí)這個(gè)設(shè)計(jì)能讓業(yè)務(wù)處理與網(wǎng)絡(luò)接收解耦行情再快也不阻塞CTP回調(diào)線程。4.2 下單與撤單報(bào)單字段、狀態(tài)機(jī)與OrderRef管理下單接口的入?yún)⒖雌饋碜侄味嗾嬲龢I(yè)務(wù)相關(guān)的就幾個(gè)。核心代碼如下public string PlaceOrder(OrderRequest order) { var req new CThostFtdcInputOrderField { BrokerID _profile.BrokerId, InvestorID _profile.UserId, InstrumentID order.InstrumentId, OrderRef GetNextOrderRef(), // 本地遞增報(bào)單號 Direction order.Direction, // 0買 / 1賣 CombOffsetFlag order.Offset, // 0開 / 1平 / 3平今 CombHedgeFlag 1, // 1投機(jī) LimitPrice order.Price, VolumeTotalOriginal order.Volume, TimeCondition 3, // 當(dāng)日有效 VolumeCondition 1, // 任何數(shù)量都接受 ContingentCondition 1, MinVolume 1 }; int ret _api.ReqOrderInsert(req, _requestId); if (ret ! 0) { Log.Error(下單請求發(fā)送失敗錯(cuò)誤碼: {0}, ret); return null; } return ${order.InstrumentId}_{req.OrderRef}; // 本地業(yè)務(wù)號 }OrderRef必須單調(diào)遞增不能隨機(jī)生成不能重啟后從1重新計(jì)數(shù)。它和柜臺返回的OrderSysID共同標(biāo)識一筆報(bào)單重復(fù)或回退都會導(dǎo)致撤單失敗。GetNextOrderRef的實(shí)現(xiàn)用Interlocked.Increment并在登錄時(shí)用MaxOrderRef初始化。CombOffsetFlag要注意上期所區(qū)分平今和平昨其他交易所不區(qū)分。封裝層最好統(tǒng)一暴露開倉、平倉、平今三個(gè)枚舉而不是讓業(yè)務(wù)直接填字符。報(bào)單提交后不是立即成功柜臺會通過OnRtnOrder連續(xù)推送多次狀態(tài)回報(bào)。常見順序是已提交、已報(bào)、部分成交、全部成交或已撤。封裝層的OrderUpdated事件要按狀態(tài)機(jī)處理不能用最后一個(gè)回報(bào)覆蓋全狀態(tài)。部分成交時(shí)成交數(shù)量字段在變剩余數(shù)量也在變業(yè)務(wù)層關(guān)聯(lián)合約后要自己維護(hù)這兩者的關(guān)系。撤單相對簡單但有個(gè)關(guān)鍵點(diǎn)撤單引用的是柜臺返回的OrderSysID不是本地OrderRef。public void CancelOrder(string exchangeId, string orderSysId) { var req new CThostFtdcInputOrderActionField { BrokerID _profile.BrokerId, InvestorID _profile.UserId, ExchangeID exchangeId, OrderSysID orderSysId, ActionFlag 0 // 0撤單 }; int ret _api.ReqOrderAction(req, _requestId); if (ret ! 0) { Log.Error(撤單請求發(fā)送失敗錯(cuò)誤碼: {0}, ret); } }ActionFlag還有修改報(bào)單的其他值但交易所實(shí)際支持有限不要依賴。撤單失敗的最常見原因是用了本地OrderRef而不是柜臺OrderSysID或者報(bào)單已經(jīng)全部成交再撤單。4.3 持倉與資金回報(bào)只做增量定時(shí)查詢做校準(zhǔn)訂單回報(bào)和成交回報(bào)只能告訴你發(fā)生了什么變化無法保證完整還原持倉。萬一中間丟一條回報(bào)或者程序在回報(bào)處理到一半時(shí)崩潰本地持倉就錯(cuò)位了而且很難被發(fā)現(xiàn)。真正可靠的方案是定時(shí)向柜臺主動(dòng)查詢持倉和資金用查詢結(jié)果校準(zhǔn)本地狀態(tài)。public void QueryPosition() { var req new CThostFtdcQryInvestorPositionField { BrokerID _profile.BrokerId, InvestorID _profile.UserId }; int ret _api.ReqQryInvestorPosition(req, _requestId); if (ret ! 0) { Log.Error(持倉查詢請求發(fā)送失敗錯(cuò)誤碼: {0}, ret); } }查詢結(jié)果通過OnRspQryInvestorPosition分批返回isLast標(biāo)志表示最后一條。在查詢結(jié)果返回期間本地緩存不要更新等全量結(jié)果回來再整體替換避免出現(xiàn)中間狀態(tài)的錯(cuò)誤持倉。查詢頻率要克制連續(xù)高頻查詢會被前置流控報(bào)“查詢太頻繁”反過來拖垮正常交易。資金查詢ReqQryTradingAccount也是同理。資金余額、可用資金、凍結(jié)保證金都要以查詢結(jié)果為準(zhǔn)成交回報(bào)只能用來更新“凍結(jié)合并”這類增量指標(biāo)。封裝層最好維護(hù)一個(gè)LastSyncTime字段每次查詢成功后記錄超過一定閾值自動(dòng)再查保證狀態(tài)不會長期偏離柜臺。5. C#封裝避坑清單5個(gè)真實(shí)翻車場景與排查方法5.1 現(xiàn)象登錄成功卻連不上行情日志報(bào)流文件相關(guān)錯(cuò)誤現(xiàn)象交易通道登錄成功行情通道也能連上但運(yùn)行一段時(shí)間后通道自動(dòng)斷開日志提示創(chuàng)建或?qū)懭胛募≈貑⒑笥只謴?fù)正常一段時(shí)間。原因行情API初始化時(shí)傳入的流文件目錄不可寫。應(yīng)用部署在系統(tǒng)目錄下或者以服務(wù)賬戶運(yùn)行時(shí)沒有寫權(quán)限。CTP要在流文件里保存行情訂閱狀態(tài)和會話信息寫不進(jìn)去就會在后續(xù)某個(gè)時(shí)間點(diǎn)斷開連接。這個(gè)問題在本地開發(fā)時(shí)不容易暴露因?yàn)楸镜毓芾韱T權(quán)限充足上線之后才出現(xiàn)。解決初始化API時(shí)主動(dòng)創(chuàng)建目錄并做寫權(quán)限探測不要只傳路徑。用前面提到的CtpProfile.Validate在啟動(dòng)階段先寫一個(gè)臨時(shí)文件再刪除確認(rèn)權(quán)限后才繼續(xù)初始化。給每個(gè)賬號分配獨(dú)立子目錄避免多實(shí)例共享流文件導(dǎo)致串號。string flowPath Path.Combine(baseDir, ctp_flow, ${brokerId}_{userId}); Directory.CreateDirectory(flowPath); string probeFile Path.Combine(flowPath, write_test.tmp); File.WriteAllText(probeFile, ok); File.Delete(probeFile);5.2 現(xiàn)象行情一多界面卡死撤單延遲到秒級現(xiàn)象訂閱幾十個(gè)合約后行情推送一多UI開始卡頓撤單請求發(fā)出后好幾秒才有回報(bào)嚴(yán)重時(shí)報(bào)單直接超時(shí)。原因在CTP回調(diào)線程里做了耗時(shí)操作。常見的錯(cuò)誤包括在OnRtnDepthMarketData里直接更新界面控件、寫數(shù)據(jù)庫、調(diào)用同步鎖。CTP回調(diào)線程是共享的任何一個(gè)事件處理器阻塞后面所有回報(bào)都排隊(duì)表現(xiàn)就是全線延遲。解決回調(diào)只做數(shù)據(jù)投遞業(yè)務(wù)邏輯移到獨(dú)立消費(fèi)線程。用Channel或BlockingCollection處理事件訂閱者也要注意自己的處理速度不要在事件處理器里啟動(dòng)同步IO。排查時(shí)先看回調(diào)線程的堆棧如果有數(shù)據(jù)庫訪問或UI調(diào)用基本就是它。5.3 現(xiàn)象撤單提示找不到原報(bào)單報(bào)單被秒撤現(xiàn)象高頻策略頻繁下單撤單時(shí)撤單回報(bào)返回“撤單未找到報(bào)單”或“報(bào)單已端到端處理”但本地明明還有未成交單。原因OrderRef沒有嚴(yán)格單調(diào)遞增。有些實(shí)現(xiàn)用DateTime.Now生成訂單號或者重啟進(jìn)程后從1重新計(jì)數(shù)導(dǎo)致新單和老單引用撞車。柜臺拿到的撤單指令對應(yīng)不到正確的報(bào)單自然撤不掉。解決OrderRef的唯一性由本地保證使用Interlocked.Increment并且在登錄成功后把MaxOrderRef作為起點(diǎn)。進(jìn)程重啟前把當(dāng)前OrderRef持久化重啟后接著用而不是回退到1。public int GetNextOrderRef() { return Interlocked.Increment(ref _currentOrderRef); } // 登錄回調(diào)里 _currentOrderRef rsp.MaxOrderRef;5.4 現(xiàn)象斷開重連后回報(bào)全部正常但持倉狀態(tài)不對現(xiàn)象網(wǎng)絡(luò)閃斷后程序自動(dòng)重連登錄成功行情也正常但部分報(bào)單的回報(bào)沒有補(bǔ)過來本地持倉與實(shí)際柜臺持倉對不上。原因重連時(shí)沒有恢復(fù)會話狀態(tài)。CTP私有流依賴FrontID、SessionID和OrderRef恢復(fù)上下文如果重連后這些值與之前不一致柜臺無法補(bǔ)發(fā)斷線期間的回報(bào)。很多實(shí)現(xiàn)只做了重連登錄沒做會話恢復(fù)。解決登錄成功時(shí)立刻把FrontID、SessionID、OrderRef持久化到本地。重連后調(diào)用會話恢復(fù)接口把保存的值重新設(shè)置回去。沒有收到補(bǔ)發(fā)回報(bào)之前不要接受新報(bào)單避免訂單狀態(tài)錯(cuò)上加錯(cuò)。5.5 現(xiàn)象一個(gè)賬號同時(shí)登錄多個(gè)實(shí)例互相被踢下線現(xiàn)象本地回測服務(wù)和一個(gè)交易終端同時(shí)使用同一個(gè)資金賬號其中一個(gè)登錄后另一個(gè)馬上斷開兩邊反復(fù)互踢。原因同一資金賬號的同時(shí)在線會話數(shù)有限。不同柜臺限制不同但超出后前置會主動(dòng)斷開舊連接或拒絕新連接。開發(fā)環(huán)境多人共用同一個(gè)測試賬號時(shí)特別常見。解決封裝層維護(hù)會話租約同一賬號只允許一個(gè)活躍網(wǎng)關(guān)實(shí)例其他實(shí)例排隊(duì)等待。開發(fā)、測試、生產(chǎn)環(huán)境必須用不同賬號不要把生產(chǎn)賬號拿去聯(lián)調(diào)。排查的時(shí)候先看是不是有多個(gè)進(jìn)程用同一套賬號參數(shù)。6. 進(jìn)階把封裝做成可運(yùn)維的交易門面自檢、會話恢復(fù)與行情監(jiān)控封裝走到能下單撤單只是第一步真正能上生產(chǎn)的版本還要把自檢和監(jiān)控做成網(wǎng)關(guān)內(nèi)置能力。我的習(xí)慣是登錄完成后立刻做一次開機(jī)自檢查一次資金、查一次持倉、訂閱一個(gè)活躍合約作為行情心跳。自檢不是登錄后跑一次就完而是把結(jié)果落到本地狀態(tài)文件啟動(dòng)時(shí)與上次記錄比對偏差直接告警。public async Task SelfCheckAsync() { Log.Info(開始開機(jī)自檢); QueryTradingAccount(); // 校驗(yàn)資金接口 QueryPosition(); // 校驗(yàn)持倉接口 SubscribeMarketData(new[] { _heartbeatInstrument }); await Task.Delay(TimeSpan.FromSeconds(10)); if (_lastTickTime DateTime.Now.AddSeconds(-10)) { Log.Error(行情心跳超時(shí)檢查行情通道狀態(tài)); } }重連策略也要固化第一次斷開等1秒第二次2秒指數(shù)退避到30秒封頂。每次重連成功后強(qiáng)制補(bǔ)一次資金和持倉查詢用柜臺數(shù)據(jù)覆蓋本地緩存而不是嘗試把斷線期間的回報(bào)拼回來。拼回報(bào)這條路看著像省事實(shí)際比全量查詢復(fù)雜得多而且容易漏。那次教訓(xùn)之后我把流文件目錄、會話持久化、開機(jī)自檢全部固化成網(wǎng)關(guān)的標(biāo)準(zhǔn)能力這幾年再沒遇到莫名其妙的斷線和持倉錯(cuò)位。希望這篇能幫到你。本文還有配套的精品資源點(diǎn)擊獲取