行情 API 这个话题我最近被问到的频率实在太高了。很多做量化交易的朋友尤其是从“研究”往“实盘”过渡的那批人最容易卡在一个环节实时行情 API 总算连上了价格也能在终端上跳动了心里就踏实了觉得“这不就有实时数据了吗”。可一到模拟盘或者小资金实盘就开始暴露出各种莫名其妙的问题。今天这篇文章我就把自己这些年踩过的坑、验证过的方法论以及真正决定一个实时行情 API 能否用于量化实盘的关键维度一次性说清楚。文章适合两类人一是准备自建量化交易系统的个人开发者二是已经在接 API 但总觉得“数据不对劲”的交易者。后面会涉及不少实操细节和具体的验证思路争取让刚入门的朋友也能照着检查一遍。1. 选实时行情 API 之前先把这三件事想明白很多人上来就问我“哪个行情源延迟最低”“哪家 WebSocket 稳定”这其实是把顺序搞反了。选型最重要的第一步不是比较供应商而是拿自己的策略去反推需求。你的交易频率、持仓周期、标的品种和运行时段直接决定了你需要什么级别的实时数据。1.1 你的策略到底需要多“实时”这是整个选型里最核心的问题。按策略频率可以粗略分成三档第一档分钟级甚至小时级策略。比如基于日线、小时线做趋势跟踪或者每天只调仓几次的网格。这种策略对行情的实时性要求并不极端用 REST 轮询每 1 到 3 秒拉一次最新价格和 K 线基本就能满足。没必要为了“实时”花大价钱上专用的极速行情。很多人在这档里就开始焦虑延迟其实是想多了。第二档秒级策略。比如高频套利里的差价监控、快速止盈止损或者一些中低频做市逻辑。这时候 REST 轮询就有点吃力了一方面是每秒钟请求次数会被限流另一方面是轮询周期本身就引入了不可控的延迟。这个档位基本需要 WebSocket 实时推送收到一笔成交就立刻处理一笔而不是定时去问“你变了没有”。第三档tick 级或者盘口级策略。比如抢开盘、做市、追逐盘口价差的策略数据颗粒度要到逐笔成交和买卖盘口的前几档甚至全档。这时候你需要的不仅是 WebSocket还要确保数据源能稳定推送完整的事件序列并且自身系统的接收、解析、计算链路不能成为瓶颈。判断自己属于哪一档有个很简单的标准假设行情推送比你现在的方案慢 500 毫秒你的策略收益会不会发生明显变化如果会你才需要在延迟上较劲如果不会那就把重点放在稳定性和成本上。1.2 标的市场不同接口规范和协议差距很大同一个“实时行情 API”在不同市场里的含义完全不同。如果是加密货币多数交易所都提供公开的 WebSocket 行情接口免费、文档相对完善、接入门槛低这也是为什么很多量化新手都喜欢从币圈开始。如果是股票、期货这类传统市场情况复杂得多有些市场需要通过券商或数据商才能拿到 Level 2 行情有些市场对行情分发有严格的订阅限制有些市场的实时行情要单独购买授权。这一块容易被忽略但直接影响后面所有技术选型。别等到代码写完了才发现自己用的免费接口在盘中会截断盘口深度或者有些数据字段要单独付费。所以确定标的市场后第一件事是把接口文档从第一页到最后一页完整读一遍尤其是“数据范围”“更新频率”“限流说明”“免责条款”这几节。1.3 接交易所直连还是走数据商中转实时行情数据的获取方式一般两条路直连交易所或者接入第三方数据商。直连的优点是源端唯一、延迟理论上最短而且省了一笔数据订阅费缺点是你要自己去处理不同交易所之间完全不同的接口协议、字段命名、错误码和限流规则。如果同时跑多个市场这个维护成本会直线上升。第三方数据商的好处是把多市场、多协议统一成一套接口还能附带一些处理干净的历史数据、自动重连和数据修复能力。代价是增加了一层网络转发延迟会略高一点并且每个月要付订阅费用。怎么选没有标准答案我见过小团队直连两个交易所跑得很好也见过个人开发者用数据商反而省了很多心力。关键是把成本和复杂度放在一起算别只看单价。2. 有实时数据不等于有能实盘的数据四个核心差距接下来是这篇文章最想讲清楚的部分。为什么说“有实时数据”离“能实盘”还差得很远因为你在回测和模拟阶段看到的“历史行情”和真正实盘时流进来的“实时行情”根本不是同一种东西。2.1 回测数据是做过清洗的实盘数据是原始现场回测用的历史数据通常都经过了严格的清洗异常 tick 被剔除断点被补齐时间戳经过校准复权因子被处理过。换句话说你看到的是“修剪整齐的花园”。但实盘是一条源源不断的原始事件流里面混着网络抖动、偶发断流、重复消息、乱序消息、交易所撮合引擎短暂的延迟甚至偶尔出现的脏数据。它不会等你清洗完再进来。同一根 K 线在历史数据里收盘价对应的是一个板上钉钉的确定值在实时场景里却可能因为最后一笔成交的回调而上下跳动。如果你把回测的假设原封不动搬到实盘策略行为失真几乎是必然的。2.2 “实时”不一定是“完整”行情是分层的很多接口都自称提供“实时行情”但你得看清它实时推送的到底是哪一层。最常见的分层包括最优买卖盘Top of Book只推买一卖一价和数量。盘口深度快照Depth Snapshot定期推整档盘口可能是每 100ms 一张快照。逐笔成交Trade Tick每一笔真实成交的推送。全量订单簿增量Order Book Delta记录订单簿每次变化的明细需要本地维护才能还原完整盘口。如果你是用盘口价差逻辑做策略却只接了 Trade Tick 或者买一卖一档那你在实盘里看到的“实时数据”只是冰山一角很多信号根本计算不出来。选型时一定要确认自己的策略依赖哪些字段接口是否完整提供别只看“延迟低”三个字。2.3 时间戳偏差和事件顺序比想象中更容易出事实时数据的准确性不仅仅是“价格对不对”还包括事件的时间顺序。不同的数据源时间戳定义可能完全不一样有的是撮合事件发生时间有的是服务端生成时间有的是网关收到消息的时间。如果不搞清楚你在本地做的事件排序就可能是错的。更棘手的是本机时间同步问题。很多人测延迟时拿“本地接收时间”减去“事件时间戳”但本机时钟本身可能就比交易所服务器快了几百毫秒。这个误差有时候比真实延迟还大测试出来的数据完全不能反映链路质量。正确做法是先通过 NTP 把本机时间校准到与交易所服务器接近的参考时间再做相对比较同时重点关注“同一事件在不同通道中的到达顺序”而不只是绝对时间。2.4 数据缺口往往出现在最不该出现的时刻接口平时怎么测都稳定一到开盘瞬间、重大新闻发布或者行情剧烈波动时就来问题这是实时行情最经典的“薛定谔式故障”。原因也不复杂极端行情下交易所本身的消息量会暴增网关和客户端负载同步升高不少 API 的限流策略也会在高负载时主动掉线。而掉线重连后很多接口只恢复增量或者快照不帮你补齐缺口。这意味着你的策略可能在最需要数据的时刻恰恰拿到的是断断续续的数据。这个问题很难在平静时段测出来必须在验证阶段就专门去制造压力或者直接把“断线后如何处理”“重连后如何补数据”设计成系统的一部分而不是指望数据源永远可靠。3. 实盘选型要盯住的六个关键指标理解了上面的差距你会意识到选型不能只看“他宣称延迟多少毫秒”而要从系统工程的视角去看。下面六个维度是我在评估一个实时行情 API 是否值得接入实盘时必须逐项过一遍的清单。3.1 延迟别只看平均值重点看尾部和测量口径延迟指标需要拆开看。很多人一上来就问“平均延迟多少”但真正影响交易的是 95 分位、99 分位和最大延迟。均值再漂亮如果某一次推送卡了 3 秒而恰好在这 3 秒里行情剧烈反转策略就可能吃到一根很高的滑点。测量口径也一样重要。是从数据商服务器到客户端的时间是从交易所撮合引擎到客户端的时间还是从客户端发出订阅请求到收到第一条推送的时间不同口径的数字可以差出十倍。我的习惯是只认“事件时间戳到本地接收时间”这一段并且用多条通道交叉验证而不是信文档里给的宣传值。3.2 可用性和自动重连99.9% 和 99.99% 的差别在盘中放大行情服务的年度可用性 99.9% 听起来已经很可靠了换算一下一年大约有 8.76 小时的不可用时间。如果是夜里低波动时段挂机这 8 小时可能无伤大雅但如果都落在开盘关键时段后果不堪设想。实盘更看重的是“故障后的恢复行为”。连接断开后能否自动重连重连后能否快速补齐断点有没有心跳机制和主动断开通知这些细节往往比可用性数字本身更能决定一个 API 是否可信任。我做选型时会专门做一次断网/重启压测观察系统会在多久内恢复恢复后数据是否连续这比看任何宣传指标都有用。3.3 限流规则免费额度往往在开盘瞬间耗尽限流是实时行情 API 最容易埋雷的地方尤其是免费档位。很多免费实时行情接口会给一个“每分钟多少次请求”或者“每小时多少次连接”的限制。平时用没问题但开盘瞬间大量策略同时启动、大量订阅同时发起很容易踩到限流轻则请求返回错误重则直接封 IP 一段时间。实盘前必须做压力测试模拟极端情况下的连接和订阅行为。同时要仔细算一笔账如果免费档位的限流不允许你按照需要的频率拉取数据为这套系统额外付出的时间成本是不是已经超过了直接买个付费档位的价格3.4 成本账订阅费、数据授权和隐藏的按量计费实时数据的成本账单往往比预想复杂。有些接口是按月度固定收费有些是按调用量计费有些则分为基础数据、深度数据、历史数据分别收费。更麻烦的是部分市场的数据授权是“地址级”或者“终端级”的同一家数据商的产品在不同市场或不同协议下收费方式完全不一样。我的建议是在选型前就拉一个全成本表把月费、超量费用、额外数据授权费全部列出来并且按未来一年数据量递增的趋势估算。先花钱买稳定和可靠通常比后期因为限流或数据缺失重写系统要便宜得多。3.5 历史数据与回放能力没有历史数据实盘策略就很难迭代很多实时 API 和高级历史数据是两套产品。实时数据再稳如果没有配套的 tick 级历史数据或者回放机制策略迭代和回测验证就很痛苦。你没法用同一套真实的行情序列去验证代码改完后的表现也没法做“假实盘”测试——也就是用历史数据流实时回放观察代码在模拟真实压力下的反应。所以选实时行情 API 的时候顺手考察它是否能方便地拉取满足精度要求的历史数据是否提供本地回放工具。这块能力往往比实时延迟更能决定一个团队半年后的研发效率。3.6 行情与下单两者越统一故障点越少从架构上看实时行情和交易下单如果来自同一家、使用同一套协议和鉴权体系会省掉很多麻烦比如连接生命周期统一、鉴权冲突减少、错误码体系一致、故障排查路径更短。行情和下单分开接的团队常见的问题是两边的时间基准不一致或者一方限流把另一方拖下水。当然很多成熟交易者会选择“行情用数据商、下单用券商或交易所直连”的混合架构这样可以各取所长。但即便如此你也要提前设计好两者之间的状态同步机制例如在行情断开时禁止下单在账户平仓后清空本地行情状态尽可能降低两个系统间的沟通成本。4. 三小时快速验证用 Python 把实时行情 API“遛一遛”说了这么多理论如果只记住一件事那就是任何实时行情 API 在进入实盘前必须做一整套自己的验证而不是轻信文档和别人的测评。下面这套验证流程是我个人实践过、能在半天内完成的方案你可以直接照抄。4.1 测试一用 WebSocket 量测真实消息延迟这个测试的目标是拿到“从一个事件被交易所产生到你的程序真正收到”之间的真实延迟。一般的做法是订阅行情推送比较消息里自带的事件时间戳和本机接收时间。注意这要求本机时间尽量准确否则结果会被系统时钟偏差污染。import asyncio import json import time import websockets async def measure_delay(ws_url, subscribe_msg, times50): async with websockets.connect(ws_url, ping_interval20, ping_timeout20) as ws: await ws.send(subscribe_msg) delays [] for _ in range(times): raw await ws.recv() data json.loads(raw) # 很多交易所在推送里会带事件时间戳字段名可能是 ts/time/trade_time event_ts data.get(ts) or data.get(time) or data.get(trade_time) if not event_ts: continue if event_ts 1e12: # 毫秒时间戳转成秒 event_ts / 1000 local_ts time.time() delay_ms (local_ts - event_ts) * 1000 delays.append(delay_ms) return delays url wss://your-stream-data-source/ws # 替换成你要测的地址 msg json.dumps({op: subscribe, args: [trade.BTCUSDT]}) delays asyncio.run(measure_delay(url, msg, 50)) print(平均延迟 ms:, sum(delays) / len(delays)) print(最大延迟 ms:, max(delays))跑完这段脚本我会额外输出一份延迟分布而不是只看平均值。如果最大延迟是平均值的五倍以上说明这条链路在部分时段存在明显抖动实盘要做延迟突变保护。注意用这个方案测延迟前提是本机时钟不能和设备端时钟偏差太大。至少先做一次系统时间 NTP 同步再跑测试另外某些 API 会把所有消息都统一标记为“发送时间”而不是“撮合时间”这样测出来的值会偏低要对照文档确认字段含义。4.2 测试二断网重连和数据连续性延迟测完接着测稳定性。方法是按实际策略的订阅方式启动连接然后在运行过程中主动断开网络 30 秒再恢复网络观察客户端的自动重连行为和重连后的数据是否连续。重点看三个指标重连耗时、重连后是否自动补齐断点、以及是否会出现重复消息。有些接口重连后只推送新数据把断点直接跳过这会导致你的本地 K 线、指标计算出现缺口。一个简单的验证方式是在断开前记录本地最后收到的事件时间戳重连后检查下一个事件的时间戳如果两者之间的时间间隔超过断网时长说明过程中数据确实丢了。4.3 测试三满负荷订阅和多路压力测试很多实时接口在少量订阅时表现很好一旦同时订阅几十个交易对或者上百个标的消息处理就跟不上。我的经验是直接按照实盘需要的最大订阅数量配置同时叠加本机高 CPU 负载观察是否有消息堆积、延迟突增或者连接被服务端主动断开。这一步非常有必要。因为实盘时你的策略计算、日志写入、数据存储本身就会占用 CPU 和内存行情接口需要在“被其他任务拖后腿”的情况下仍然稳定工作。不要在一个清爽的空项目里测试而是要模拟最接近实盘的运行环境。4.4 测试四用历史行情回放做“履带式”验证如果数据源能提供 tick 级或秒级的历史数据强烈建议做一次回放验证。方式是把历史数据按真实时间间隔重新推送让本地程序像处理实时数据一样处理一遍最后对比本地重建的 K 线、指标和回测结果确认整个数据处理链路没有偏差。这个方案特别适合检查两个隐蔽问题一是本地代码在时间戳转换时是否存在精度丢失二是不同数据源之间的价格、成交时间字段是否对齐。很多人实盘出现“策略在回测里赚钱实盘却亏损”的怪异现象其实根子就在这个环节。5. 常见故障与排查技巧实录下面这些是从实际运行中总结出来的高频问题。我按“症状、原因、检查方式、处理建议”整理成了速查表方便你直接定位。症状常见原因检查方式处理建议盘中突然收不到推送超过限流阈值连接被服务端关闭查看连接日志与服务端报错码降低订阅频率升级付费档位增加退避重连重连后数据出现缺失接口在重连后只恢复增量不补齐断点对比断开前后事件时间戳自行实现“从 REST 接口补历史”的补偿机制延迟在某个时段暴涨开盘/整点瞬间消息洪峰导致链路拥塞统计不同时段的延迟分布在策略中加入延迟保护洪峰时段主动降频本地 K 线和历史数据对不上事件时间戳字段定义不同或时区没对齐抽样核对同一时间段的逐笔数据统一时间换算逻辑并做回放验证连接一直正常但策略状态奇怪接收到了重复消息或乱序消息打印原始消息事件 ID 并做去重在本地维护消息序列号做幂等处理同样的代码重启后结果不一样状态未持久化依赖内存中的累计数据重启前后对比内部状态快照定期落盘状态重启后先跑数据补偿再恢复策略还有一个很容易忽略的坑很多实时 API 的“测试环境”和“实盘环境”是两套完全不同的系统。测试环境里的行情表现、限流阈值和实盘环境往往差得非常多。必须在实盘环境的小权限账户上再跑一遍完整验证而不是在测试环境跑完就直接上实盘。排查实时行情问题最重要的是建立日志体系。每次收到推送都记录一条简短的日志包括时间戳、事件类型、价格、事件 ID。别怕日志量大出问题时这些记录就是唯一能还原现场的线索。我见过太多人等到出 bug 了才发现自己什么日志都没留只能干瞪眼。6. 我踩过这么多坑后留下的选型底线回到文章标题那句话“有实时数据”不等于量化实盘就够用了。这些年我最大的体会是实时行情 API 的选型不是一个“越快越好”的问题而是一个“是否匹配你的策略和运行环境”的问题。有些场景里1 秒延迟的 REST 轮询已经足够有些场景里即使你用上了最贵的深度行情如果系统在极端行情下掉了链子照样满盘皆输。所以如果你现在正准备接入某个实时行情 API我建议你把稳定性、数据完整性、限流规则、故障恢复和成本一起放进评估清单并且务必花半天时间把上面这套验证流程完整跑一遍。测试时多暴露问题总好过实盘时措手不及。最后再分享一个个人习惯我会在所有实时行情接入代码里专门留一个“行情健康检查”模块周期性地统计延迟、断线次数和数据缺口。不要小看这个小模块它后来帮我提前发现了不少数据源端的隐患。量化这条路很长先把数据的底座夯实后面的策略逻辑才有真正的立足点。