跳至主要内容

全深度訂單簿

訂閱全深度訂單簿推送。僅推送增量（delta）數據，提供深度全量行情。

覆蓋範圍: 現貨 / USDT永續 / USDC永續 / 反向合約

信息
  • 零售價格優化（RPI）訂單不會包含在推送消息中。
  • 此頻道僅推送增量數據，不會推送初始全量快照。請先通過 REST 全深度訂單簿接口 初始化本地訂單簿，再應用增量更新。

上線時間表​

產品測試網主網
現貨2026年7月6日2026年7月16日
期貨（線性 & 反向）預計2026年7月13日未定

推送頻率​

USDT合約、反向合約 & 現貨:
全深度數據，推送頻率: 200ms

Topic:
orderbook.full.{symbol} 例如, orderbook.full.BTCUSDT

重置場景 (u=1)
場景WebSocket 推送REST 快照客戶端處理
服務重啟u=1u 也可能重置為 1以 REST 快照覆蓋本地訂單簿
合約下架u=1, b=[], a=[]返回空數據清空本地訂單簿，標記為不可用
盤前競價期間（無訂單簿）u=1，delta 為空可能返回空保持本地訂單簿為空，標記為 NO_BOOK
競價 → 連續競價u=1，delta 為空返回有效快照拉取 REST 快照後繼續應用增量
精度等配置變更u=1，delta 可為空就緒後返回快照清空並重新同步本地訂單簿

響應參數​

參數類型說明
topicstringTopic名
typestring數據類型. 固定為 delta
tsnumber行情服務生成數據的時間戳（毫秒）
dataobjectObject
> sstring合約名稱
> barrayBid 增量, 買方. 按照價格從大到小
>> b[0]string買方報價
>> b[1]string買方數量. 0 表示該價位應被刪除
> aarrayAsk 增量, 賣方. 按照價格從小到大
>> a[0]string賣方報價
>> a[1]string賣方數量. 0 表示該價位應被刪除
> uinteger更新id
  • 在同一會話內始終遞增
  • 當 u=1 時，為重置信號——請立即拉取 REST 快照 並覆蓋本地訂單簿
> seqinteger撮合版本號. 可用於關聯不同檔位的 orderbook，值越小說明數據生成越早
ctsnumber產生此訂單簿數據時來自撮合引擎的時間戳. 可用於與平台成交頻道中的T進行關聯

訂閱示例​


響應示例​


全深度訂單簿同步流程​

提供了 REST 請求查詢 Order Book（OB）快照，並透過 WebSocket 訂閱 Order Book 增量資料，以維護完整的 Order Book。於 OB 快照與 OB 增量資料中，均提供 seq 與 u 兩個欄位，用於資料匹配與定位。

  • seq：撮合版本號，具備單調遞增特性，但不保證連續性。也就是說，同一交易對的相鄰增量資料包，其 seq 值可能不連續。
  • u：更新 ID，具備連續性，相鄰增量資料包的 u 值會依序遞增（u+1）。但當系統重啟或調整 Tick Size 時，u 會重置為 1，並重新對增量資料進行編號。
  1. 開啟行情 WebSocket 連接並訂閱全深度訂單簿頻道。
  2. 緩存從串流中接收到的所有增量，記錄第一個增量的 seq 与 u 值。
  • 若偵測到 u 不連續，清空緩存區並重新開始緩存。
  • 若偵測到 seq 变小，丢弃该增量包。
  1. 從Rest接口獲取全深度訂單簿快照
  2. 將快照的 seq，u 與緩存增量進行比對：
  • 若快照的 seq 嚴格小於第一個緩存增量的 seq，重複步驟 3，直到獲得足夠新的快照。
  • 在緩存增量中，丟棄所有 seq 小於快照 seq 的增量。
  • 若快照的seq与增量的seq相等，但u不相等，重複步驟 3，直到獲得足夠新的快照。
  1. 直到获取快照的seq，u与增量的seq，u都相同时，使用快照初始化本地訂單簿，本地訂單簿版本應設定為快照的u值。
  2. 按照以下的說明將所有剩餘的緩存增量應用至本地訂單簿，然後繼續處理後續到來的即時增量。

訂單簿更新流程​

針對每個收到的增量（delta）事件：

  1. 驗證增量連續性
  • 若增量的 u 小於本地訂單簿的 u，忽略該增量。
  • 若增量的 u 大於本地訂單簿的 u + 1，表示遺漏了一個或多個增量，此時：
    • 丟棄本地訂單簿。
    • 從頭重新啟動同步流程。
  • 正常情況下，下一個增量的 u 應等於上一個增量的 u + 1。
  • 若增量的 u 變成1，則重新啟動同步流程。
  1. 應用價位更新

對買方（b）和賣方（a）中的每個價位：

  • 若該價位不存在於本地訂單簿中，以指定數量插入該價位。
  • 若數量為零，從本地訂單簿中移除該價位。
  • 否則，更新現有價位的數量。
信息

REST 快照接口每側最多返回 10,000 個價位。因此，超出初始快照範圍的價位在增量更新中出現之前，其狀態是未知的。

這意味著超出快照深度的價位數量，可能無法完整反映訂單簿的實際狀態。不過，對於大多數交易和市場分析場景而言，可用深度（每側通常超過 10,000 個價位）已足以提供準確的市場流動性與交易狀況視圖。