简介这是一份面向期货程序化交易开发者的上期CTP API C源代码工程在原有可实盘版本基础上升级支持多合约订阅与多策略并发。填入经纪公司代码、实盘账号及密码即可接入行情与交易接口实现TICK行情接收、指标策略计算、实盘连续开平仓。工程包含行情与交易双线程架构MD线程负责最多20个合约的TICK缓存及1分钟K线生成TRADE线程负责下单与响应并附有独立策略计算及下单控制示例代码。内置行情/交易配置读写、断线重登后自动获取上一笔交易数据以及基于TXT Tick文件的批量仿真测试功能可生成Simulation报告。压缩包共89个文件包含C头文件、实现文件、动态库、可执行程序、配置文件及文档整体12.52MB目录划分清晰。已有950人学习下载适合具备C基础并希望直接参考或二次改造CTP交易系统的开发者。1. 上期CTP_API_C可实盘多合约多策略版本源代码为什么必须自己搭框架做期货程序化交易的人早晚会撞上一个坎账号里同时挂着十来个合约每个合约背后的策略逻辑还不一样把官方Demo改来改去最后下单线程、行情回调、撤单重试全搅在一起一个合约的异常能把整个进程拖死。这套上期CTP_API_C可实盘多合约多策略版本源代码核心就是解决这件事——它不是单个策略的示例而是一个把行情接入、交易通道、策略调度、订单管理彻底拆开的C框架。适合手里已经有稳定单策略、想从脚本升级成多合约实盘系统的开发者也适合正在评估C方案能不能扛住自己策略组的人。下面按我在实际项目里搭这套框架的路径把架构拆分、最小可实盘代码、关键参数和踩过的坑一次讲透。2. 框架怎么拆交易通道、行情通道与策略引擎的分工2.1 为什么选C延迟、稳定性与原生接口的契合CTP对外开放的标准接口就是C接口Python封装、Java封装都是在外面再包一层不管你用得多熟回调里拿到的数据总是要经过一次类型转换和数据拷贝。多合约多策略意味着一个进程里每秒要处理成百上千次行情回调C可以直接在回调函数里拿到结构体指针一次拷贝进自己管理的缓存整个处理过程可以控制在微秒级。我最早用Python封装跑单策略没有问题加了第二个合约以后行情回调线程和GIL打架行情延迟从几毫秒涨到几十毫秒都不止这就是必须换C的直接原因。另一个原因是CTP的API本身就是为C设计的线程模型。它内部维护了独立的网络线程和回调线程你只需要保证自己的业务逻辑线程安全。这套模型在C下用得最多社区里踩坑案例也最少网上能查到的都是经过长时间验证的用法。做实盘稳定比什么都重要选C不是追求极致的性能是求一条官方长期测试过、经验足够多的稳妥路径。有人会问不用C行不行我的回答是行但你要自己想清楚承担的成本。社区封装的非官方语言版本在API更新时你得跟着封装作者一起升级一旦没人维护就很被动。C虽然写起来繁琐但代码没有任何隐藏层出问题可以直接看CTP头文件、查错误码、翻协议日志。程序化交易这个方向关键时刻能少一层依赖就少一层依赖。2.2 行情端与交易端一对必须分开管的会话CTP接口从形态上分成两个完全独立的对象CThostFtdcMdApi负责订阅行情CThostFtdcTraderApi负责登录、报单、撤单、查询。很多人第一次做这个把两者搞混以为注册一次就能又收行情又下单。实际上两者要分别连接前置机、分别登录各自的会话状态互不相通。行情端登录返回的是一个交易日标识交易端登录返回的是FrontID和SessionID后者是后续撤单定位的关键参数。行情端的会话很轻登录成功、订阅合约、然后就是纯接收。交易端的会话重得多有完整的登录、确认结算单、查询持仓、报单、撤单、回报状态机。在框架里这两个API各自独立持有各自维护自己的回调实例绝不能在一个类里同时实现两套Spi然后混用回调。我见过有人把两个Spi写在同一个类里结果行情回调线程调用了交易逻辑导致行情延迟忽高忽低这个错误非常隐蔽排查难度也大。行情端和交易端的日志文件也要分开。创建API实例时的第一个参数是流文件路径前缀两者用同一个前缀会互相覆盖特别是断线重连后过滤条件恢复会出问题。我一般用md_flow和td_flow两个前缀各自独立目录存放排查问题的时候也方便对照。这个看起来不起眼的细节实盘跑到一半遇到重连时就知道值钱了。2.3 多合约多策略的调度模型事件驱动回调与策略实例隔离我用的模型不复杂一个全局事件分发器行情回调只负责把快照推给匹配的策略实例每个策略实例有独立的上下文不共享可变状态风控模块独立挂在交易通道上不依赖任何一个策略。任何一个策略出问题只会影响它自己的挂单其他策略照常跑。这个策略故障隔离的机制是多合约框架最重要的设计目标。策略实例隔离看起来简单但做多策略框架时最容易翻车的地方就在这。如果两个策略共享一个全局订单容器A策略撤单时通过OrderRef去查很可能查到B策略的订单一撤就把别人的仓给动了。每个策略持有自己的OrderRouter路由器内部自己维护订单表这是多策略框架的基本底线不要破。调度模型还有一层选择事件驱动还是定时轮询。我选事件驱动行情来了才触发策略计算没有行情时策略什么都不做。轮询模型的好处是能保证固定节奏但期货行情本身是事件流轮询取旧数据来做决策本质是浪费。事件驱动下每个策略实例在自己的上下文里计算计算结果通过共享指针推给OrderRouter同一个合约上多个策略可以同时持有多空方向由风控模块统一判断净持仓是否符合上限。行情快照的共享要特别注意线程可见性。CTP回调线程把最新价写进缓存策略线程读取如果中间没有同步机制策略线程可能读到旧值。我一般用atomic变量存最新价和最新时间戳或者用无锁队列保证读到的一定是某个时刻的完整快照。这个细节不处理好策略会出现一瞬间的价格抖动导致误触发在多策略并发时尤其明显。3. 最小可实盘代码从初始化到第一笔订单怎么写3.1 接入前置机MdApi和TraderApi的初始化序列初始化序列是所有实盘流程的起点顺序错了后面全是白搭。我一般把行情和交易两个前置地址放到配置文件里启动时先分别创建、注册回调、注册前置然后Init。Init之后不能立刻发任何请求必须等OnFrontConnected回调确认连接建立。// 初始化行情接口 CThostFtdcMdApi* md_api CThostFtdcMdApi::CreateFtdcMdApi( md_flow, true); // 第二个参数true用文件记录过滤条件 MdSpi* md_spi new MdSpi(md_api); md_api-RegisterSpi(md_spi); md_api-RegisterFront(tcp://127.0.0.1:41213); // 行情前置机地址 md_api-Init(); // 初始化交易接口 CThostFtdcTraderApi* trader_api CThostFtdcTraderApi::CreateFtdcTraderApi( td_flow, true); TraderSpi* trader_spi new TraderSpi(trader_api); trader_api-RegisterSpi(trader_spi); trader_api-SubscribePublicTopic(THOST_TERT_RESUME); // 重连后补回报 trader_api-RegisterFront(tcp://127.0.0.1:41205); // 交易前置机地址 trader_api-Init();CreateFtdcMdApi的第二个参数实盘必须用true。它会让API把订阅过的合约和过滤条件持久化到本地文件断线重连后不用重新订阅也能恢复行情。SubscribePublicTopic用THOST_TERT_RESUME意思是交易端重连后把断线期间的报单回报、成交回报重新推送一遍这是实盘不丢单的关键。注意这两个API都要调用Join或者在自己的线程里跑不要让主线程直接退出。连接建立后下一步是各自登录。最容易犯的错是连接一建立就发登录请求正确的做法是等OnFrontConnected里再ReqUserLogin。void MdSpi::OnFrontConnected() { CThostFtdcReqUserLoginField req{}; strncpy(req.BrokerID, broker_id_.c_str(), sizeof(req.BrokerID) - 1); strncpy(req.UserID, user_id_.c_str(), sizeof(req.UserID) - 1); strncpy(req.Password, password_.c_str(), sizeof(req.Password) - 1); md_api_-ReqUserLogin(req, next_request_id_); }登录成功后行情的OnRspUserLogin里会返回一个交易日字段拿到它以后再去订阅合约。交易端的登录回调里还要多做两步确认结算单、查询持仓和可用资金。这两个动作做完才算真正具备下单条件。我之前见过有人在登录回调里直接下单结果资金还没查询到位下进去就是废单这个问题在模拟环境不容易暴露实盘必现。3.2 订阅多合约行情回调里别做重活登录行情端之后直接批量订阅合约列表。CTP支持一次传入多个合约代码订阅比循环单个订阅效率高。void MdSpi::OnRspUserLogin(CThostFtdcRspUserLoginField* rsp, CThostFtdcRspInfoField* rsp_info, int req_id, bool is_last) { if (rsp_info rsp_info-ErrorID ! 0) { // 登录失败记录错误码等几秒再重试 return; } std::vectorstd::string symbols {rb2410, cu2409, m2409}; std::vectorchar* ptrs; for (auto s : symbols) ptrs.push_back(s[0]); md_api_-SubscribeMarketData(ptrs.data(), (int)ptrs.size()); }订阅以后所有合约的行情都进同一个OnRtnDepthMarketData回调。框架里这个回调只做两件事按InstrumentID找到对应的合约缓存把最新价、买卖价、时间戳拷进去然后触发事件分发器通知订阅了这个合约的策略实例。绝对不要在回调里写日志文件、做网络请求、或者直接跑策略逻辑这些活全放到业务线程里做。行情回调是CTP网络线程直接调用的阻塞太久会拖垮整个行情链路。行情缓存的结构我一般用一个固定大小的数组或哈希表每个合约一条记录字段包括最新价、买一价、卖一价、买一量、卖一量、快照时间戳。多策略读这份缓存时用原子变量保证“要么读到旧的一整份要么读到新的一整份”不要让策略在中间状态上计算。3.3 策略基类与多策略注册共享行情、独立逻辑多合约框架里策略要抽象成统一的接口。我定义一个策略基类所有策略都继承它实现行情回调、订单回调、成交回调三个方法。策略引擎负责把CTP的回调分发到对应的策略实例或者反过来策略注册自己的回调到引擎里。class StrategyBase { public: explicit StrategyBase(std::string instrument) : instrument_(std::move(instrument)) {} virtual ~StrategyBase() default; virtual void OnTick(const CThostFtdcDepthMarketDataField* tick) 0; virtual void OnOrder(const CThostFtdcOrderField* order) 0; virtual void OnTrade(const CThostFtdcTradeField* trade) 0; void set_router(std::shared_ptrOrderRouter router) { router_ std::move(router); } protected: std::string instrument_; std::shared_ptrOrderRouter router_; }; class StrategyEngine { public: void AddStrategy(std::shared_ptrStrategyBase strategy) { strategies_.push_back(strategy); } void DispatchTick(const CThostFtdcDepthMarketDataField* tick) { for (auto s : strategies_) { if (s-instrument() tick-InstrumentID) { s-OnTick(tick); } } } private: std::vectorstd::shared_ptrStrategyBase strategies_; };分发逻辑就是简单的合约匹配策略少的时候这种线性扫描完全够用。多个策略可以订阅同一个合约比如一个做趋势一个做套利各自持有自己的OrderRouter产生的订单互不干扰。注意每个策略实例化后必须单独set_router千万不要让两个策略共享一个OrderRouter否则订单表一混撤单就会撤到别人的单子上。策略引擎本身不需要线程安全它只在行情回调线程里被调用。真正要保证线程安全的是OrderRouter因为它会被策略线程调用同时又被交易回报回调线程更新订单状态。我一般给OrderRouter加一把独立的锁锁粒度控制在“单笔订单的插入和状态更新”级别不要在整个容器上长时间加锁。3.4 下单与撤单的封装订单状态机是核心下单封装的核心不是ReqOrderInsert本身而是订单状态机。CTP的报单回报会经历已报、部分成交、全部成交、已撤、废单等状态框架必须正确维护每个订单的状态才能决定什么时候能撤、什么时候不能再动。struct OrderRecord { std::string order_ref; std::string instrument; double price 0.0; int volume 0; int traded 0; int status 0; // 0:已报 1:部分成交 2:全部成交 3:已撤 4:废单 }; class OrderRouter { public: std::string SendOrder(const std::string instr, double price, int vol, bool is_buy, bool is_open) { CThostFtdcInputOrderField req{}; strncpy(req.InstrumentID, instr.c_str(), sizeof(req.InstrumentID) - 1); req.LimitPrice price; req.VolumeTotalOriginal vol; req.Direction is_buy ? THOST_FTDC_D_Buy : THOST_FTDC_D_Sell; req.CombOffsetFlag[0] is_open ? THOST_FTDC_OF_Open : THOST_FTDC_OF_CloseToday; req.CombHedgeFlag[0] THOST_FTDC_HF_Speculation; req.TimeCondition THOST_FTDC_TC_GFD; req.VolumeCondition THOST_FTDC_VC_AV; req.ContingentCondition THOST_FTDC_CC_Immediately; req.MinVolume 1; req.ForceCloseReason THOST_FTDC_FCC_NotForceClose; req.IsAutoSuspend 0; std::string ref std::to_string(next_ref_); strncpy(req.OrderRef, ref.c_str(), sizeof(req.OrderRef) - 1); OrderRecord rec; rec.order_ref ref; rec.instrument instr; rec.volume vol; { std::lock_guardstd::mutex lock(mutex_); orders_[ref] rec; } int rt trader_api_-ReqOrderInsert(req, next_req_id_); if (rt ! 0) { std::lock_guardstd::mutex lock(mutex_); orders_[ref].status 4; // 报单被流控拒绝标记废单 } return ref; } private: std::mutex mutex_; std::unordered_mapstd::string, OrderRecord orders_; int next_ref_ 1; int next_req_id_ 1; CThostFtdcTraderApi* trader_api_ nullptr; };这里的坑是OrderRef是char数组CTP接收的是字符串不能用局部临时变量直接丢进去。先把它转成std::string存到map里再把内容拷到请求结构体。撤单时不能拿本地的OrderRef去撤必须要等报单回报里返回OrderSysID、FrontID、SessionID之后用这三个字段定位订单。撤单的代码里还要对订单状态做检查只在已报或部分成交状态下才能撤否则会收到“订单状态不正确”的拒单错误。4. 多合约多策略的关键参数从行情快照到风控阈值4.1 配置文件怎么组织合约、策略、资金三层分离框架跑起来之后参数管理决定你改策略要不要重新编译。我一般用JSON配置文件分成broker连接信息、合约列表、策略列表、风控参数四块。合约列表和策略列表分开启动时先订阅合约再注册策略两者通过合约代码关联。{ broker: { id: 0000, user: 000001, password: your_password, md_front: tcp://127.0.0.1:41213, td_front: tcp://127.0.0.1:41205 }, contracts: [rb2410, cu2409, m2409], strategies: [ { name: ma_cross, instrument: rb2410, params: {fast: 5, slow: 20, volume: 2} }, { name: arb, instrument: cu2409, params: {spread_limit: 30, volume: 1} } ], risk: { max_order_per_second: 5, max_position_per_instrument: 30, max_daily_loss: 5000, order_timeout_ms: 8000 } }策略参数放在各自节点的params里这样同一个策略类可以通过不同参数实例化成多个策略实例分别挂在不同合约上。风控参数是全局的独立于任何策略这个设计是为了让风控模块能够在策略失控时以独立身份拦截所有下单。密码字段建议用环境变量或单独加密文件注入不要直接写在配置文件里提交到代码仓库。4.2 必须调对的几个参数流控、超时与重连间隔实盘能不能稳定跑很大程度上取决于这几个参数。我列出自己常用的基准值具体还要结合柜台配置微调参数推荐基准值说明单笔报单最小间隔100ms规避柜台流控过快会被拒绝流控失败重试等待1s流控拒单后立即重发大概率继续被拒订单超时未成交8s超过后主动撤单防止僵尸挂单占用资金断线重连间隔2s起步指数退避到10s前置机恢复需要时间不能死循环猛连行情时间戳容忍差500ms快照时间与本地时间差过大按过期数据处理订单超时这个参数在实盘里非常重要。一次报价没成交如果挂在那里不管资金占用不说策略后续的信号可能会在错误仓位基础上继续叠加。我一般会在策略里设一个比全局更短的超时比如全局8秒、趋势策略5秒让策略自己决策是撤还是追。重连间隔用指数退避第一次2秒第二次4秒最多10秒封顶。CTP前置机在业务时段很少掉线一旦掉线往往是网络抖动或者前置切换如果毫秒级就重连会把前置机打挂。这个参数是框架里改动最频繁的每次版本更新都要重新审视一遍当前网络的稳定性。4.3 多策略并发下单的哪些参数决定会不会出事多个策略同时触发信号是框架里最容易出问题的地方。我要求每个OrderRouter内部有一个信号量控制单位时间内的下单次数同时全局风控模块兜底检查所有策略的单笔报单方向、数量、当前持仓上限。全局风控的几个阈值我按三个维度设单合约持仓上限、全局单日亏损上限、每秒报单总量。持仓上限防止策略在趋势行情里不断加仓单日亏损上限是硬止损到了直接关闭所有策略的开仓权限并撤掉所有挂单每秒报单总量是配合柜台流控的最后一层拦截。这三个阈值不是随便拍的要根据账户资金量和策略历史回撤来定。比如账户权益五十万单合约持仓上限设为三十手按保证金比例算大约是四成仓位这个量级能把单策略翻车的损失限制在可控范围内。这种硬性约束决定了框架的下限关键时候能兜住命。风控模块挂在交易通道的回调前面而不是策略里。任何策略发单时先过风控再进OrderRouter。这样即便某个策略因为bug在一个信号周期里发了十次单风控也能拦下其中的超额部分。这个顺序不能反一旦策略直接跑到OrderRouter风控就形同虚设。5. CTP实盘避坑记录流控、重连与订单状态不一致的六个典型问题5.1 登录成功却收不到行情现象交易端登录正常持仓和资金都能查到行情端也显示“已连接”但行情回调一次都没触发。这个状态特别坑因为程序不报错一切看起来正常就是没有数据进来。原因行情端虽然TCP连接建立了但它是一个独立会话必须走一次独立的登录流程。很多人只调了SubscribeMarketData没调登录或者登录用的账户信息与交易端不一致导致订阅被交易所静默拒绝。解决在行情端的OnFrontConnected回调里先登录登录成功回调返回后再调SubscribeMarketData。我把这个时序写死在框架初始化流程里登录不成功不允许进入订阅步骤从根上杜绝这个坑。5.2 撤单失败订单还没回报就把撤单请求发出去了现象策略判断挂单超过超时时间调用撤单接口结果回报返回“撤单失败订单状态不正确”或者“订单已处理”。原因CTP的撤单请求里需要填OrderSysID而OrderSysID是在报单回报里才返回的字段。如果本地订单表里没有保存这个字段或者保存滞后撤单请求就找不到对应的系统订单。解决OrderRouter在成交回报回调里先把OrderSysID、FrontID、SessionID存进OrderRecord然后只有在该订单状态为“已报”或“部分成交”时才允许发起撤单。客户端做一次状态检查比盲目发撤单再等错误回执要稳得多。5.3 行情延迟突升回调里干了不该干的活现象框架刚跑起来时延迟一毫秒跑了一天后涨到几十毫秒下单时感觉行情明显比盘面慢半拍。原因行情回调里加了日志、统计、或者把行情数据通过网络转发到另一个进程。这些操作会阻塞CTP的回调线程而CTP行情回调是串行的一笔阻塞会导致后续所有行情排队。解决回调里只做“拷贝数据 触发事件”两件事。日志、统计、跨进程转发全部放到业务线程用无锁队列把行情对象传出去。我给队列设置了容量上限满了直接丢最老的数据保证行情永远是新的优先绝不能让指标统计拖累交易链路。5.4 多策略并发触发流控报单被柜台拦下现象两个策略在同秒内发单第二个单子的回报是“CTP:流控”订单直接废掉策略的仓位和目标不一致。原因CTP前置机对单用户有报单频率限制通常是每秒一笔。多策略并行时两个策略各自的下单器互不知道对方节奏合起来就超了。解决全局加一个令牌桶每秒放行一定数量的订单所有OrderRouter发单前先申请令牌。同时把流控失败后的重试加上一秒退避不要立刻重发。这个令牌桶要放在风控模块里和单合约持仓上限放一起保证是全框架唯一的不能被绕过。5.5 第二天连接失败结算单没确认现象每天开盘前启动程序交易端登录报错错误码对应“结算结果未确认”。原因期货账户每个交易日结束后会生成结算单当天第一次登录必须确认结算结果后才能进行交易。如果框架里没有做结算单确认这一步第二天登录就会被拒绝。解决交易端登录成功后的下一个动作就是调结算单确认接口只确认当前交易日的结算单。注意要等这个确认的回报返回成功之后再往下走不要登录完就立刻开始下单操作否则可能被判定为未完成初始化。5.6 重启后订单状态未知本地订单表和交易所不一致现象进程崩溃重启重新连接后本地订单表是空的之前挂的单还在交易所里挂着后续策略可能重复下单。原因订单状态只在本地内存里维护一重启就丢了。如果不知道哪些单子还活着策略继续按新逻辑发单会在已有仓位上叠加产生超量持仓。解决交易端登录并确认结算单之后主动调用订单查询和成交查询接口把当天所有报单和成交拉回来再用OrderRef和OrderSysID重建本地订单表。重建完成前风控模块拒绝所有新单。这套恢复流程我做成独立函数每次启动必须执行完才放开交易权限相当于给自己的后悔药。6. 把框架能力再往上提一档前置验证、状态校准与多进程改造6.1 先接模拟前置把链路完整跑一遍实盘切换前把行情前置和交易前置地址指到模拟环境跑整个框架走一遍初始化、订阅、下单、撤单、重启恢复全流程。我每次改完框架都会先在模拟环境跑满一个交易日的全部时段重点关注重连、流控、超时撤单三个分支三处都通过才考虑切实盘。这个习惯救过我很多次曾经一次改动把重连后的结算单确认顺序调错了模拟环境第一天就暴露切实盘前及时发现没有造成实际损失。6.2 用查询接口做状态校准脚本盘中每隔一段时间或者每次异常恢复后主动发起订单查询、成交查询和持仓查询把本地订单表、持仓表与柜台全量对一遍。对不上的地方以柜台为准本地表做增量修正。这个校准脚本就是你的后悔药别等到收盘后才发现持仓不对。收盘后也要跑一次确认所有订单都闭环没成交的全部撤掉资金还原。6.3 多进程改造把行情、策略、交易彻底拆分最后再提一个进阶方向。当策略数量进一步增大单进程内回调分发开始吃紧时我会把框架拆成三个进程行情进程负责订阅与分发策略进程负责计算信号交易进程负责下单与风控。进程之间用共享内存传行情快照用带确认的消息队列传订单指令。这样某个策略进程崩溃交易进程不会跟着死重启策略进程后还能继续跑。C做这个改造的边际成本不高但稳定性能上一个台阶是这套框架跑一两年后最值得做的升级。我自己的教训是框架里最容易出事的永远是“状态不一致”行情慢一点可以接受订单状态搞错就是要亏钱的。所以我把上面的状态校准、初始化恢复、风控前置这三件事当作底线功能任何版本迭代都不允许破坏它们。希望这套思路对你搭自己的多合约多策略框架有帮助动手前先把这些兜底设计想清楚实盘会稳得多。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 2:16:30 · 阅读 1.2k CTP API C++多合约多策略框架设计与实盘避坑指南
简介这是一份面向期货程序化交易开发者的上期CTP API C源代码工程在原有可实盘版本基础上升级支持多合约订阅与多策略并发。填入经纪公司代码、实盘账号及密码即可接入行情与交易接口实现TICK行情接收、指标策略计算、实盘连续开平仓。工程包含行情与交易双线程架构MD线程负责最多20个合约的TICK缓存及1分钟K线生成TRADE线程负责下单与响应并附有独立策略计算及下单控制示例代码。内置行情/交易配置读写、断线重登后自动获取上一笔交易数据以及基于TXT Tick文件的批量仿真测试功能可生成Simulation报告。压缩包共89个文件包含C头文件、实现文件、动态库、可执行程序、配置文件及文档整体12.52MB目录划分清晰。已有950人学习下载适合具备C基础并希望直接参考或二次改造CTP交易系统的开发者。1. 上期CTP_API_C可实盘多合约多策略版本源代码为什么必须自己搭框架做期货程序化交易的人早晚会撞上一个坎账号里同时挂着十来个合约每个合约背后的策略逻辑还不一样把官方Demo改来改去最后下单线程、行情回调、撤单重试全搅在一起一个合约的异常能把整个进程拖死。这套上期CTP_API_C可实盘多合约多策略版本源代码核心就是解决这件事——它不是单个策略的示例而是一个把行情接入、交易通道、策略调度、订单管理彻底拆开的C框架。适合手里已经有稳定单策略、想从脚本升级成多合约实盘系统的开发者也适合正在评估C方案能不能扛住自己策略组的人。下面按我在实际项目里搭这套框架的路径把架构拆分、最小可实盘代码、关键参数和踩过的坑一次讲透。2. 框架怎么拆交易通道、行情通道与策略引擎的分工2.1 为什么选C延迟、稳定性与原生接口的契合CTP对外开放的标准接口就是C接口Python封装、Java封装都是在外面再包一层不管你用得多熟回调里拿到的数据总是要经过一次类型转换和数据拷贝。多合约多策略意味着一个进程里每秒要处理成百上千次行情回调C可以直接在回调函数里拿到结构体指针一次拷贝进自己管理的缓存整个处理过程可以控制在微秒级。我最早用Python封装跑单策略没有问题加了第二个合约以后行情回调线程和GIL打架行情延迟从几毫秒涨到几十毫秒都不止这就是必须换C的直接原因。另一个原因是CTP的API本身就是为C设计的线程模型。它内部维护了独立的网络线程和回调线程你只需要保证自己的业务逻辑线程安全。这套模型在C下用得最多社区里踩坑案例也最少网上能查到的都是经过长时间验证的用法。做实盘稳定比什么都重要选C不是追求极致的性能是求一条官方长期测试过、经验足够多的稳妥路径。有人会问不用C行不行我的回答是行但你要自己想清楚承担的成本。社区封装的非官方语言版本在API更新时你得跟着封装作者一起升级一旦没人维护就很被动。C虽然写起来繁琐但代码没有任何隐藏层出问题可以直接看CTP头文件、查错误码、翻协议日志。程序化交易这个方向关键时刻能少一层依赖就少一层依赖。2.2 行情端与交易端一对必须分开管的会话CTP接口从形态上分成两个完全独立的对象CThostFtdcMdApi负责订阅行情CThostFtdcTraderApi负责登录、报单、撤单、查询。很多人第一次做这个把两者搞混以为注册一次就能又收行情又下单。实际上两者要分别连接前置机、分别登录各自的会话状态互不相通。行情端登录返回的是一个交易日标识交易端登录返回的是FrontID和SessionID后者是后续撤单定位的关键参数。行情端的会话很轻登录成功、订阅合约、然后就是纯接收。交易端的会话重得多有完整的登录、确认结算单、查询持仓、报单、撤单、回报状态机。在框架里这两个API各自独立持有各自维护自己的回调实例绝不能在一个类里同时实现两套Spi然后混用回调。我见过有人把两个Spi写在同一个类里结果行情回调线程调用了交易逻辑导致行情延迟忽高忽低这个错误非常隐蔽排查难度也大。行情端和交易端的日志文件也要分开。创建API实例时的第一个参数是流文件路径前缀两者用同一个前缀会互相覆盖特别是断线重连后过滤条件恢复会出问题。我一般用md_flow和td_flow两个前缀各自独立目录存放排查问题的时候也方便对照。这个看起来不起眼的细节实盘跑到一半遇到重连时就知道值钱了。2.3 多合约多策略的调度模型事件驱动回调与策略实例隔离我用的模型不复杂一个全局事件分发器行情回调只负责把快照推给匹配的策略实例每个策略实例有独立的上下文不共享可变状态风控模块独立挂在交易通道上不依赖任何一个策略。任何一个策略出问题只会影响它自己的挂单其他策略照常跑。这个策略故障隔离的机制是多合约框架最重要的设计目标。策略实例隔离看起来简单但做多策略框架时最容易翻车的地方就在这。如果两个策略共享一个全局订单容器A策略撤单时通过OrderRef去查很可能查到B策略的订单一撤就把别人的仓给动了。每个策略持有自己的OrderRouter路由器内部自己维护订单表这是多策略框架的基本底线不要破。调度模型还有一层选择事件驱动还是定时轮询。我选事件驱动行情来了才触发策略计算没有行情时策略什么都不做。轮询模型的好处是能保证固定节奏但期货行情本身是事件流轮询取旧数据来做决策本质是浪费。事件驱动下每个策略实例在自己的上下文里计算计算结果通过共享指针推给OrderRouter同一个合约上多个策略可以同时持有多空方向由风控模块统一判断净持仓是否符合上限。行情快照的共享要特别注意线程可见性。CTP回调线程把最新价写进缓存策略线程读取如果中间没有同步机制策略线程可能读到旧值。我一般用atomic变量存最新价和最新时间戳或者用无锁队列保证读到的一定是某个时刻的完整快照。这个细节不处理好策略会出现一瞬间的价格抖动导致误触发在多策略并发时尤其明显。3. 最小可实盘代码从初始化到第一笔订单怎么写3.1 接入前置机MdApi和TraderApi的初始化序列初始化序列是所有实盘流程的起点顺序错了后面全是白搭。我一般把行情和交易两个前置地址放到配置文件里启动时先分别创建、注册回调、注册前置然后Init。Init之后不能立刻发任何请求必须等OnFrontConnected回调确认连接建立。// 初始化行情接口 CThostFtdcMdApi* md_api CThostFtdcMdApi::CreateFtdcMdApi( md_flow, true); // 第二个参数true用文件记录过滤条件 MdSpi* md_spi new MdSpi(md_api); md_api-RegisterSpi(md_spi); md_api-RegisterFront(tcp://127.0.0.1:41213); // 行情前置机地址 md_api-Init(); // 初始化交易接口 CThostFtdcTraderApi* trader_api CThostFtdcTraderApi::CreateFtdcTraderApi( td_flow, true); TraderSpi* trader_spi new TraderSpi(trader_api); trader_api-RegisterSpi(trader_spi); trader_api-SubscribePublicTopic(THOST_TERT_RESUME); // 重连后补回报 trader_api-RegisterFront(tcp://127.0.0.1:41205); // 交易前置机地址 trader_api-Init();CreateFtdcMdApi的第二个参数实盘必须用true。它会让API把订阅过的合约和过滤条件持久化到本地文件断线重连后不用重新订阅也能恢复行情。SubscribePublicTopic用THOST_TERT_RESUME意思是交易端重连后把断线期间的报单回报、成交回报重新推送一遍这是实盘不丢单的关键。注意这两个API都要调用Join或者在自己的线程里跑不要让主线程直接退出。连接建立后下一步是各自登录。最容易犯的错是连接一建立就发登录请求正确的做法是等OnFrontConnected里再ReqUserLogin。void MdSpi::OnFrontConnected() { CThostFtdcReqUserLoginField req{}; strncpy(req.BrokerID, broker_id_.c_str(), sizeof(req.BrokerID) - 1); strncpy(req.UserID, user_id_.c_str(), sizeof(req.UserID) - 1); strncpy(req.Password, password_.c_str(), sizeof(req.Password) - 1); md_api_-ReqUserLogin(req, next_request_id_); }登录成功后行情的OnRspUserLogin里会返回一个交易日字段拿到它以后再去订阅合约。交易端的登录回调里还要多做两步确认结算单、查询持仓和可用资金。这两个动作做完才算真正具备下单条件。我之前见过有人在登录回调里直接下单结果资金还没查询到位下进去就是废单这个问题在模拟环境不容易暴露实盘必现。3.2 订阅多合约行情回调里别做重活登录行情端之后直接批量订阅合约列表。CTP支持一次传入多个合约代码订阅比循环单个订阅效率高。void MdSpi::OnRspUserLogin(CThostFtdcRspUserLoginField* rsp, CThostFtdcRspInfoField* rsp_info, int req_id, bool is_last) { if (rsp_info rsp_info-ErrorID ! 0) { // 登录失败记录错误码等几秒再重试 return; } std::vectorstd::string symbols {rb2410, cu2409, m2409}; std::vectorchar* ptrs; for (auto s : symbols) ptrs.push_back(s[0]); md_api_-SubscribeMarketData(ptrs.data(), (int)ptrs.size()); }订阅以后所有合约的行情都进同一个OnRtnDepthMarketData回调。框架里这个回调只做两件事按InstrumentID找到对应的合约缓存把最新价、买卖价、时间戳拷进去然后触发事件分发器通知订阅了这个合约的策略实例。绝对不要在回调里写日志文件、做网络请求、或者直接跑策略逻辑这些活全放到业务线程里做。行情回调是CTP网络线程直接调用的阻塞太久会拖垮整个行情链路。行情缓存的结构我一般用一个固定大小的数组或哈希表每个合约一条记录字段包括最新价、买一价、卖一价、买一量、卖一量、快照时间戳。多策略读这份缓存时用原子变量保证“要么读到旧的一整份要么读到新的一整份”不要让策略在中间状态上计算。3.3 策略基类与多策略注册共享行情、独立逻辑多合约框架里策略要抽象成统一的接口。我定义一个策略基类所有策略都继承它实现行情回调、订单回调、成交回调三个方法。策略引擎负责把CTP的回调分发到对应的策略实例或者反过来策略注册自己的回调到引擎里。class StrategyBase { public: explicit StrategyBase(std::string instrument) : instrument_(std::move(instrument)) {} virtual ~StrategyBase() default; virtual void OnTick(const CThostFtdcDepthMarketDataField* tick) 0; virtual void OnOrder(const CThostFtdcOrderField* order) 0; virtual void OnTrade(const CThostFtdcTradeField* trade) 0; void set_router(std::shared_ptrOrderRouter router) { router_ std::move(router); } protected: std::string instrument_; std::shared_ptrOrderRouter router_; }; class StrategyEngine { public: void AddStrategy(std::shared_ptrStrategyBase strategy) { strategies_.push_back(strategy); } void DispatchTick(const CThostFtdcDepthMarketDataField* tick) { for (auto s : strategies_) { if (s-instrument() tick-InstrumentID) { s-OnTick(tick); } } } private: std::vectorstd::shared_ptrStrategyBase strategies_; };分发逻辑就是简单的合约匹配策略少的时候这种线性扫描完全够用。多个策略可以订阅同一个合约比如一个做趋势一个做套利各自持有自己的OrderRouter产生的订单互不干扰。注意每个策略实例化后必须单独set_router千万不要让两个策略共享一个OrderRouter否则订单表一混撤单就会撤到别人的单子上。策略引擎本身不需要线程安全它只在行情回调线程里被调用。真正要保证线程安全的是OrderRouter因为它会被策略线程调用同时又被交易回报回调线程更新订单状态。我一般给OrderRouter加一把独立的锁锁粒度控制在“单笔订单的插入和状态更新”级别不要在整个容器上长时间加锁。3.4 下单与撤单的封装订单状态机是核心下单封装的核心不是ReqOrderInsert本身而是订单状态机。CTP的报单回报会经历已报、部分成交、全部成交、已撤、废单等状态框架必须正确维护每个订单的状态才能决定什么时候能撤、什么时候不能再动。struct OrderRecord { std::string order_ref; std::string instrument; double price 0.0; int volume 0; int traded 0; int status 0; // 0:已报 1:部分成交 2:全部成交 3:已撤 4:废单 }; class OrderRouter { public: std::string SendOrder(const std::string instr, double price, int vol, bool is_buy, bool is_open) { CThostFtdcInputOrderField req{}; strncpy(req.InstrumentID, instr.c_str(), sizeof(req.InstrumentID) - 1); req.LimitPrice price; req.VolumeTotalOriginal vol; req.Direction is_buy ? THOST_FTDC_D_Buy : THOST_FTDC_D_Sell; req.CombOffsetFlag[0] is_open ? THOST_FTDC_OF_Open : THOST_FTDC_OF_CloseToday; req.CombHedgeFlag[0] THOST_FTDC_HF_Speculation; req.TimeCondition THOST_FTDC_TC_GFD; req.VolumeCondition THOST_FTDC_VC_AV; req.ContingentCondition THOST_FTDC_CC_Immediately; req.MinVolume 1; req.ForceCloseReason THOST_FTDC_FCC_NotForceClose; req.IsAutoSuspend 0; std::string ref std::to_string(next_ref_); strncpy(req.OrderRef, ref.c_str(), sizeof(req.OrderRef) - 1); OrderRecord rec; rec.order_ref ref; rec.instrument instr; rec.volume vol; { std::lock_guardstd::mutex lock(mutex_); orders_[ref] rec; } int rt trader_api_-ReqOrderInsert(req, next_req_id_); if (rt ! 0) { std::lock_guardstd::mutex lock(mutex_); orders_[ref].status 4; // 报单被流控拒绝标记废单 } return ref; } private: std::mutex mutex_; std::unordered_mapstd::string, OrderRecord orders_; int next_ref_ 1; int next_req_id_ 1; CThostFtdcTraderApi* trader_api_ nullptr; };这里的坑是OrderRef是char数组CTP接收的是字符串不能用局部临时变量直接丢进去。先把它转成std::string存到map里再把内容拷到请求结构体。撤单时不能拿本地的OrderRef去撤必须要等报单回报里返回OrderSysID、FrontID、SessionID之后用这三个字段定位订单。撤单的代码里还要对订单状态做检查只在已报或部分成交状态下才能撤否则会收到“订单状态不正确”的拒单错误。4. 多合约多策略的关键参数从行情快照到风控阈值4.1 配置文件怎么组织合约、策略、资金三层分离框架跑起来之后参数管理决定你改策略要不要重新编译。我一般用JSON配置文件分成broker连接信息、合约列表、策略列表、风控参数四块。合约列表和策略列表分开启动时先订阅合约再注册策略两者通过合约代码关联。{ broker: { id: 0000, user: 000001, password: your_password, md_front: tcp://127.0.0.1:41213, td_front: tcp://127.0.0.1:41205 }, contracts: [rb2410, cu2409, m2409], strategies: [ { name: ma_cross, instrument: rb2410, params: {fast: 5, slow: 20, volume: 2} }, { name: arb, instrument: cu2409, params: {spread_limit: 30, volume: 1} } ], risk: { max_order_per_second: 5, max_position_per_instrument: 30, max_daily_loss: 5000, order_timeout_ms: 8000 } }策略参数放在各自节点的params里这样同一个策略类可以通过不同参数实例化成多个策略实例分别挂在不同合约上。风控参数是全局的独立于任何策略这个设计是为了让风控模块能够在策略失控时以独立身份拦截所有下单。密码字段建议用环境变量或单独加密文件注入不要直接写在配置文件里提交到代码仓库。4.2 必须调对的几个参数流控、超时与重连间隔实盘能不能稳定跑很大程度上取决于这几个参数。我列出自己常用的基准值具体还要结合柜台配置微调参数推荐基准值说明单笔报单最小间隔100ms规避柜台流控过快会被拒绝流控失败重试等待1s流控拒单后立即重发大概率继续被拒订单超时未成交8s超过后主动撤单防止僵尸挂单占用资金断线重连间隔2s起步指数退避到10s前置机恢复需要时间不能死循环猛连行情时间戳容忍差500ms快照时间与本地时间差过大按过期数据处理订单超时这个参数在实盘里非常重要。一次报价没成交如果挂在那里不管资金占用不说策略后续的信号可能会在错误仓位基础上继续叠加。我一般会在策略里设一个比全局更短的超时比如全局8秒、趋势策略5秒让策略自己决策是撤还是追。重连间隔用指数退避第一次2秒第二次4秒最多10秒封顶。CTP前置机在业务时段很少掉线一旦掉线往往是网络抖动或者前置切换如果毫秒级就重连会把前置机打挂。这个参数是框架里改动最频繁的每次版本更新都要重新审视一遍当前网络的稳定性。4.3 多策略并发下单的哪些参数决定会不会出事多个策略同时触发信号是框架里最容易出问题的地方。我要求每个OrderRouter内部有一个信号量控制单位时间内的下单次数同时全局风控模块兜底检查所有策略的单笔报单方向、数量、当前持仓上限。全局风控的几个阈值我按三个维度设单合约持仓上限、全局单日亏损上限、每秒报单总量。持仓上限防止策略在趋势行情里不断加仓单日亏损上限是硬止损到了直接关闭所有策略的开仓权限并撤掉所有挂单每秒报单总量是配合柜台流控的最后一层拦截。这三个阈值不是随便拍的要根据账户资金量和策略历史回撤来定。比如账户权益五十万单合约持仓上限设为三十手按保证金比例算大约是四成仓位这个量级能把单策略翻车的损失限制在可控范围内。这种硬性约束决定了框架的下限关键时候能兜住命。风控模块挂在交易通道的回调前面而不是策略里。任何策略发单时先过风控再进OrderRouter。这样即便某个策略因为bug在一个信号周期里发了十次单风控也能拦下其中的超额部分。这个顺序不能反一旦策略直接跑到OrderRouter风控就形同虚设。5. CTP实盘避坑记录流控、重连与订单状态不一致的六个典型问题5.1 登录成功却收不到行情现象交易端登录正常持仓和资金都能查到行情端也显示“已连接”但行情回调一次都没触发。这个状态特别坑因为程序不报错一切看起来正常就是没有数据进来。原因行情端虽然TCP连接建立了但它是一个独立会话必须走一次独立的登录流程。很多人只调了SubscribeMarketData没调登录或者登录用的账户信息与交易端不一致导致订阅被交易所静默拒绝。解决在行情端的OnFrontConnected回调里先登录登录成功回调返回后再调SubscribeMarketData。我把这个时序写死在框架初始化流程里登录不成功不允许进入订阅步骤从根上杜绝这个坑。5.2 撤单失败订单还没回报就把撤单请求发出去了现象策略判断挂单超过超时时间调用撤单接口结果回报返回“撤单失败订单状态不正确”或者“订单已处理”。原因CTP的撤单请求里需要填OrderSysID而OrderSysID是在报单回报里才返回的字段。如果本地订单表里没有保存这个字段或者保存滞后撤单请求就找不到对应的系统订单。解决OrderRouter在成交回报回调里先把OrderSysID、FrontID、SessionID存进OrderRecord然后只有在该订单状态为“已报”或“部分成交”时才允许发起撤单。客户端做一次状态检查比盲目发撤单再等错误回执要稳得多。5.3 行情延迟突升回调里干了不该干的活现象框架刚跑起来时延迟一毫秒跑了一天后涨到几十毫秒下单时感觉行情明显比盘面慢半拍。原因行情回调里加了日志、统计、或者把行情数据通过网络转发到另一个进程。这些操作会阻塞CTP的回调线程而CTP行情回调是串行的一笔阻塞会导致后续所有行情排队。解决回调里只做“拷贝数据 触发事件”两件事。日志、统计、跨进程转发全部放到业务线程用无锁队列把行情对象传出去。我给队列设置了容量上限满了直接丢最老的数据保证行情永远是新的优先绝不能让指标统计拖累交易链路。5.4 多策略并发触发流控报单被柜台拦下现象两个策略在同秒内发单第二个单子的回报是“CTP:流控”订单直接废掉策略的仓位和目标不一致。原因CTP前置机对单用户有报单频率限制通常是每秒一笔。多策略并行时两个策略各自的下单器互不知道对方节奏合起来就超了。解决全局加一个令牌桶每秒放行一定数量的订单所有OrderRouter发单前先申请令牌。同时把流控失败后的重试加上一秒退避不要立刻重发。这个令牌桶要放在风控模块里和单合约持仓上限放一起保证是全框架唯一的不能被绕过。5.5 第二天连接失败结算单没确认现象每天开盘前启动程序交易端登录报错错误码对应“结算结果未确认”。原因期货账户每个交易日结束后会生成结算单当天第一次登录必须确认结算结果后才能进行交易。如果框架里没有做结算单确认这一步第二天登录就会被拒绝。解决交易端登录成功后的下一个动作就是调结算单确认接口只确认当前交易日的结算单。注意要等这个确认的回报返回成功之后再往下走不要登录完就立刻开始下单操作否则可能被判定为未完成初始化。5.6 重启后订单状态未知本地订单表和交易所不一致现象进程崩溃重启重新连接后本地订单表是空的之前挂的单还在交易所里挂着后续策略可能重复下单。原因订单状态只在本地内存里维护一重启就丢了。如果不知道哪些单子还活着策略继续按新逻辑发单会在已有仓位上叠加产生超量持仓。解决交易端登录并确认结算单之后主动调用订单查询和成交查询接口把当天所有报单和成交拉回来再用OrderRef和OrderSysID重建本地订单表。重建完成前风控模块拒绝所有新单。这套恢复流程我做成独立函数每次启动必须执行完才放开交易权限相当于给自己的后悔药。6. 把框架能力再往上提一档前置验证、状态校准与多进程改造6.1 先接模拟前置把链路完整跑一遍实盘切换前把行情前置和交易前置地址指到模拟环境跑整个框架走一遍初始化、订阅、下单、撤单、重启恢复全流程。我每次改完框架都会先在模拟环境跑满一个交易日的全部时段重点关注重连、流控、超时撤单三个分支三处都通过才考虑切实盘。这个习惯救过我很多次曾经一次改动把重连后的结算单确认顺序调错了模拟环境第一天就暴露切实盘前及时发现没有造成实际损失。6.2 用查询接口做状态校准脚本盘中每隔一段时间或者每次异常恢复后主动发起订单查询、成交查询和持仓查询把本地订单表、持仓表与柜台全量对一遍。对不上的地方以柜台为准本地表做增量修正。这个校准脚本就是你的后悔药别等到收盘后才发现持仓不对。收盘后也要跑一次确认所有订单都闭环没成交的全部撤掉资金还原。6.3 多进程改造把行情、策略、交易彻底拆分最后再提一个进阶方向。当策略数量进一步增大单进程内回调分发开始吃紧时我会把框架拆成三个进程行情进程负责订阅与分发策略进程负责计算信号交易进程负责下单与风控。进程之间用共享内存传行情快照用带确认的消息队列传订单指令。这样某个策略进程崩溃交易进程不会跟着死重启策略进程后还能继续跑。C做这个改造的边际成本不高但稳定性能上一个台阶是这套框架跑一两年后最值得做的升级。我自己的教训是框架里最容易出事的永远是“状态不一致”行情慢一点可以接受订单状态搞错就是要亏钱的。所以我把上面的状态校准、初始化恢复、风控前置这三件事当作底线功能任何版本迭代都不允许破坏它们。希望这套思路对你搭自己的多合约多策略框架有帮助动手前先把这些兜底设计想清楚实盘会稳得多。本文还有配套的精品资源点击获取