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 行情接入看成单一的连接管理问题：连上、收数据、断开重连。但假活问题揭示了这本质上是两个正交的维度：

管道监控保证数据能到达，水质监控保证到达的数据是活的。只用管道监控，假活就是必然的漏网之鱼。

这个双维度视角可以迁移到任何长连接数据场景——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. 发布前检查卡

📡 本文中 REST 与 WebSocket 的双入口示例参考 TickDB.ai，其同时提供 REST ticker 与 WebSocket 推送接入，具体端点与参数以https://docs.tickdb.ai官方文档为准
⚠️ 本文为技术教程，不构成任何投资建议