在对接加密货币行情数据、搭建量化交易系统时，订单簿实时性是决定策略效果的关键指标。很多开发者初次接入交易所 API 都会疑惑：订单簿快照多久更新一次？所谓 “实时” 究竟能做到多快？本文从接口特性、数据机制、实践方案三方面，解析订单簿快照与增量更新的底层逻辑，为行情系统开发提供参考。
订单簿快照是什么
订单簿快照指某一时刻全量买卖挂单的状态镜像，包含各价格档位对应的挂单量。行业内主流实时 API 并非持续推送完整快照，而是采用快照 + 增量更新的组合模式：
- 快照：初始化订单簿的基准数据
- 增量（Diff） ：后续订单变动的增量事件
简单类比：快照如同某一刻的完整状态截图，增量则是不断新增的动态变更，二者结合即可低成本维持订单簿的最新状态。
接口类型决定更新频率
交易所对外提供两类主流接口，订单簿更新性能差异显著：
REST 接口
- 更新频率：数秒至数十秒
- 适用场景：历史数据拉取、批量统计、低频查询
- 特点：延迟高、非实时，不适合高频交易与实时监控
WebSocket 接口
- 更新频率：毫秒级至数百毫秒
- 适用场景：实时行情订阅、策略回测、自动交易
- 特点：低延迟、事件驱动，是实时行情的首选方案
实际开发中，REST 接口仅适合低频场景；高频策略与实时监控必须依赖 WebSocket 接口。
为什么快照更新间隔不固定
API 文档标注的 “实时” 并非严格等间隔更新，核心原因有三点：
- 币种活跃度差异：热门币种订单簿变动剧烈，交易所会动态限制推送频次以降低带宽压力；冷门币种成交稀疏，更新间隔自然更长。
- 带宽与负载优化：全量快照数据量大，高频推送会造成服务器与网络资源浪费，行业普遍采用快照 + 增量的轻量化方案。
- 动态流量调度：交易所会根据服务器负载、网络拥堵情况，动态调整数据推送策略。
因此，订单簿更新间隔会随行情热度动态波动，不存在绝对固定的更新周期。
最佳实践：快照初始化 + 增量实时更新
稳定获取实时订单簿的标准方案：
- 通过 REST 接口拉取一次全量快照，初始化本地内存订单簿。
- 建立 WebSocket 长连接，持续订阅增量更新事件。
- 用增量数据实时修正本地订单簿，维持毫秒级同步。
该方案兼顾数据完整性与实时性，是行业通用的高性能实践。以下为基于 AllTick API 的 Python 示例代码：
import websocket
import json
def on_message(ws, message):
data = json.loads(message)
# 根据增量数据更新本地订单簿
process_orderbook_update(data)
ws = websocket.WebSocketApp("wss://apis.alltick.co/ws/stock", on_message=on_message)
ws.run_forever()
开发核心要点
- 增量数据是实时核心：仅依赖快照会严重滞后，增量事件才是行情同步的关键。
- 网络延迟不可忽视：跨国服务器、公网波动会额外引入数十毫秒延迟，需预留容错空间。
- 拒绝纯 REST 依赖：高频场景下，纯 REST 轮询会导致行情滞后、错过关键交易节点。
总结
加密货币实时 API 的订单簿快照更新频率，由接口类型、币种活跃度、服务器负载共同决定，不存在固定标准。REST 接口适合低频查询，WebSocket 接口结合快照初始化 + 增量更新，才能满足实时行情与量化交易的需求。开发者需聚焦增量数据处理与本地数据结构优化，而非单纯追求快照更新频率，才能构建稳定高效的行情系统。
参考文档：https://apis.alltick.co/
GitHub：https://github.com/alltick/alltick-realtime-forex-crypto-stock-tick-finance-websocket-api