WebSocket 行情脚本最怕的不是断线，是“看起来还在跑”

摘要你的 WebSocket 行情脚本连接状态正常心跳日志在滚动价格却已经很久没变过——脚本活着数据早就死了。这就是行情连接的“假活”通道仍在信息已停。本文给出一套双层健康检查框架——连接级心跳证明通道可交互数据级新鲜度水位证明行情仍在更新——两者缺一不可。同时拆解重连风暴、订阅漂移、把 MCP 当 WebSocket、把重连后第一条数据当连续流四个常见坑以及为什么重连后应该先用 REST 快照校准再恢复流式处理。1. 什么叫行情连接的“假活”以下两种场景做行情监控的开发者多半不陌生WebSocket 连接未断开心跳正常收发但某个品种的last_price已经很久没有更新——程序没报任何错因为连接状态一切正常。网络闪断后自动重连成功订阅也重新发送了但回调函数收到的第一条数据与断开前的最后一条之间存在一段静默——中间有没有数据、缺了多少程序不知道。这两种情况的共同点是连接级指标全部正常数据级指标已经失效。这就是行情连接的“假活”状态。打个比方你打电话给一个人电话通了你每隔几秒问一句“还在吗”对方也回答“在”——这是心跳。但如果你问的是“外面现在什么价格”对方沉默了。电话没断信息断了。关键前提假活能否被及时发现除了客户端监控设计也取决于数据源是否提供明确的持续行情入口和当前状态查询入口——两者分工才能让客户端在恢复时有据可依。2. 五步递进从假活到恢复的完整链路以下五步覆盖从问题识别到恢复的全流程每一步都建立在“连接存活 ≠ 数据存活”这一核心前提之上。第一步识别假活监控脚本不能只看连接状态和心跳日志还要监控每个订阅品种最近一次收到数据的时间。当某个品种超过阈值未更新触发“数据失活”告警——连接还在但该品种的数据流可能已中断。第二步区分失活范围收到失活告警后先判断范围是单个品种失活还是全部品种失活。单个品种失活可能是上游数据源对该品种停止推送全部品种失活则可能是 WebSocket 服务端数据链路中断。两者的恢复策略不同前者重订阅该品种即可尝试恢复后者需要触发重连。第三步连接级心跳这是大多数脚本已有的部分——按服务端要求定期发送心跳超时未收到响应触发重连。心跳证明的是传输通道可交互不能证明行情数据仍在更新。它是必要但不充分的健康信号。第四步数据级新鲜度水位这是防止假活的关键补充。为每个订阅品种维护一个last_update_time设定失活阈值。阈值的设定取决于品种的交易时段和更新频率——盘中活跃品种推送间隔短阈值可以相对紧凑非交易时段推送稀疏用同一阈值会频繁误报。第五步失活后的恢复动作不立即断开 WebSocket——先对失活品种发起一次 REST 快照查询比对时间戳确认是否确实无新数据。如果所有品种都失活且超过更长时间阈值才判定连接级异常并触发重连。重连成功后不立即恢复流式处理而是先用 REST 快照校准当前状态、确认恢复锚点并记录断线空窗如果需要补查缺口应按业务场景另查具备历史或最近成交能力的 REST 接口但不能承诺完整补齐断线期间所有推送数据。数据源选型提示一个适合这类恢复流程的数据源至少应让持续行情接收与当前状态查询分开避免拿同一个协议硬扛所有任务。以 TickDB 为例WebSocket 用于持续接收行情更新REST ticker 用于恢复阶段的当前状态参照。两个入口各有分工而非互相替代。3. 认知升维WebSocket 行情是“管道水质”的双监控系统大多数开发者把 WebSocket 行情接入看成单一的连接管理问题连上、收数据、断开重连。但假活问题揭示了这本质上是两个正交的维度维度监控对象健康信号失效表现管道连接级TCP/WebSocket 通道心跳正常、无断开连接断开、超时水质数据级行情数据流时间戳持续更新数据停止更新但连接正常管道监控保证数据能到达水质监控保证到达的数据是活的。只用管道监控假活就是必然的漏网之鱼。这个双维度视角可以迁移到任何长连接数据场景——IoT 传感器流、日志推送、订单状态更新。任何“长连接 持续数据推送”的系统都需要同时监控管道和水质否则就会出现“设备在线但数据离线”的盲区。4. 四个常见的坑坑一重连风暴WebSocket 断开后客户端立即重连。连上后几秒又断又重连。短时间内大量重连触发服务端的连接频率限制。原因重连逻辑没有退避策略。改法指数退避重连——等待时间逐次翻倍增长设最大等待时间上限。超过最大重试次数后停止重连并告警。具体退避参数初始等待、倍增因子、上限应由应用根据业务容忍度自行配置各数据源可能有不同的建议值。坑二订阅漂移重连成功后客户端重新发送订阅但服务端返回的确认列表和断开前不一致。客户端没做校验继续按旧逻辑处理。原因重连时只检查订阅是否发送成功没有比对确认列表与原订阅。改法重连后接收服务端的订阅确认将确认列表与原订阅列表逐一比对。不匹配的品种记录日志并告警。坑三把 MCP 当 WebSocket先记结论MCP 是按需查询的工具调用入口不是行情持续推送通道。TickDB 托管 MCP 端点是 HTTPS 工具调用入口MCP 是 AI Agent 的工具调用协议适合按需查询不能替代 WebSocket 的流式推送。不要因为在 MCP 中能拿到一次行情数据就认为它能替代 WebSocket 做持续行情监控。什么时候不需要这套设计如果只是偶尔查询当前价格MCP 或 REST 单次查询就够不需要构建整套双层 watchdog。持续行情监控才需要本文这套设计。坑四把重连后的第一条数据当连续流重连后第一条数据只代表恢复后收到的第一条推送不能默认视为断线前序列的连续下一条其 timestamp 含义和单位需按具体频道、接口和资产类别确认。直接拼到断开前的序列里中间缺失时段的数据就消失了。正确做法重连后不立即恢复流式处理。先向数据源的 REST 接口发一次快照查询用快照校准当前状态、确认恢复锚点并记录断线空窗。REST 快照的作用是提供当前时刻的确定状态锚点不等于补齐断线期间全部推送数据。如需补查缺口应按业务场景另查具备历史或最近成交能力的接口。5. 恢复流程以下流程整合了前文的双层检查和坑点处理此为恢复流程示意非生产级完整代码WebSocket 断开 ↓ 指数退避重连等待时间逐次增长设上限 ↓ 重连成功 → 重新发送订阅 → 接收订阅确认 ↓ 校验订阅确认是否与原订阅一致 → 不一致则告警并记录差异 ↓ 不立即恢复流式处理先调用 REST 快照查询 ↓ 用 REST 快照校准当前状态、确认恢复锚点记录断线空窗 如需补查缺口另查具备历史或最近成交能力的 REST 接口 但不能承诺完整补齐断线期间所有推送数据 ↓ 恢复 WebSocket 推送处理 → 重新启动数据级新鲜度监控这个流程的关键在于重连后第一步是校准而非直接恢复。WebSocket 推送的是实时流断线期间的数据不会在重连后回溯。REST 快照让你在恢复流式处理之前有一个确定的状态锚点。为什么 TickDB 适合验证这套设计TickDB 同时提供 REST ticker 和 WebSocket 推送两种接入方式——在同一个数据源内完成当前状态参照与持续行情恢复可减少 symbol、时间口径和数据源差异造成的额外对齐工作。入口用途在恢复流程中的角色REST ticker单次查询当前快照重连后的状态校准锚点WebSocket持续接收行情更新正常运行时的主要数据通道具体端点、心跳格式和推送结构以 TickDB 官方文档或发布前实测为准。文档见https://docs.tickdb.ai。三个边界提醒REST 与 WebSocket 中 timestamp 的含义和单位需按具体接口、频道和资产类别分别确认不要跨方式假设天然统一。重连成功代表连接恢复、可以接收新的推送数据不代表数据连续。REST 快照用于校准当前状态不能承诺补齐断线期间全部推送数据。6. 发布前检查卡序号检查项通过标准1连接级心跳按服务端规范发送心跳超时触发重连2数据级新鲜度监控每个品种有last_update_time超过水位触发告警3失活范围判断区分单品种失活与全品种失活触发不同恢复策略4重连退避 订阅校验指数退避重连重连后比对订阅确认与原订阅5重连后校准重连后先调 REST 快照校准当前状态、确认恢复锚点记录空窗不把重连后第一条当连续流6协议边界清晰MCP 用于按需查询不用于持续行情监控持续监控用 WebSocketREST 快照不承诺补齐全部断线数据 本文中 REST 与 WebSocket 的双入口示例参考 TickDB.ai其同时提供 REST ticker 与 WebSocket 推送接入具体端点与参数以https://docs.tickdb.ai官方文档为准⚠️ 本文为技术教程不构成任何投资建议