如何基于polygon.io实时报价数据流构建订单簿

先明确当前数据源的能力边界 #

你接入的是美股NBBO（全国最佳买卖报价）逐笔推送通道，先把你结构里没标注清楚的字段说清楚：

• bx/ax：分别是当前最优买价、最优卖价对应的来源交易所ID，本地维护一份Polygon官方给出的ID-交易所映射表即可识别
• q：Polygon内部的报价全局自增序列号，生产环境用来做乱序消息过滤，是非常有用的非公开字段
• z：市场分类标识，值为3时代表纳斯达克上市证券

可行性结论 #

该数据源仅可用于构建Level 1级别（仅最优买卖一档）的订单簿，完全无法支撑多档位Level 2及以上深度订单簿的构建

• 适用场景：如果你的业务只需要实时买卖一价量、点差计算、简单价格触发类逻辑，这个路径完全可行，接入成本低、延迟表现稳定
• 不适用场景：如果你需要多档位盘口深度、订单流不平衡计算、高频交易策略支撑，这个数据源从根源上不满足要求，不要在这上面浪费时间做无用功

踩坑提醒：不要尝试把历史推送的bp/ap攒起来拼接多档盘口。这个通道只会推送当前全市场最优一档的价量，次优档位在没有成为新的最优价之前，不会有任何推送，你攒的所有历史价格都是过期的最优价，和当前盘口的非最优挂单没有任何关系，拼出来的“深度盘口”没有任何参考价值。

Level1订单簿具体实现逻辑 #

实现非常简单，核心是做好乱序消息过滤，不要用过期消息污染盘口：

1. 本地维护内存状态表：以股票代码sym作为唯一key，每个key对应存储该股票的最新盘口状态，参考结构如下：

{
  "AAPL": {
    "bid_price": 0.0,
    "bid_size": 0,
    "bid_exchange_id": 0,
    "ask_price": 0.0,
    "ask_size": 0,
    "ask_exchange_id": 0,
    "latest_timestamp": 0,
    "latest_sequence": 0
  }
}

2. 消息预处理逻辑：
   • 首先过滤ev字段不为Q的非报价类消息
   • 序列号校验：如果当前消息的q值小于本地存储的该股票latest_sequence，直接丢弃——这是网络传输导致的乱序过期消息，更新后会导致盘口状态回退
   • 可选时间戳校验：如果消息的t（毫秒级时间戳）比本地存储的latest_timestamp滞后超过500ms，也直接丢弃，避免陈旧数据干扰
3. 盘口更新：校验通过后，直接用消息里的bp/bs/bx覆盖本地买盘字段，ap/as/ax覆盖本地卖盘字段，同时更新t和q到对应时间戳、序列号字段即可
4. 过期兜底：设置定时巡检任务，如果某只股票超过30秒没有收到新的有效报价，标记该股票盘口为过期状态，不要推送给下游业务使用。

需要多档位订单簿的可落地方案 #

如果你的业务需要Level2及以上深度盘口，直接更换适配的数据源即可，几个生产环境常用的选项：

• 同平台升级Polygon Level2深度流：和你当前接入的WebSocket逻辑完全一致，不用更换供应商，上手成本最低，数据源会推送各交易所各档位的挂单变化，你可以本地按价格聚合排序生成多档盘口，缺点是资费比Level1通道高不少
• 接入预聚合的SIP全市场Level2数据流：供应商已经提前完成了多交易所挂单的去重、排序、档位合并工作，你拿到的消息直接就是按价格排序好的多档位盘口数据，不用自己处理复杂的逐笔委托合并逻辑，适合研发资源有限的团队，延迟比自行聚合原始数据高3-5毫秒，绝大多数非超高频场景完全够用
• 交易所原始深度流本地聚合：通过专线直接接入各大美股交易所的原始挂单数据流，本地部署服务器自行聚合盘口，延迟最低，但成本极高，需要自行处理交易所协议适配、跨时钟同步、乱序消息处理、盘口重建等复杂逻辑，仅适合有超高频业务需求的团队，普通团队不用考虑。

内容的提问来源于stack exchange，提问作者Vasya Petrov