加密貨幣即時 API 訂單簿深度：該如何穩定儲存與持續更新？

前言

過去一段時間開發加密貨幣盤口相關工具時，我花最多心力並非價格趨勢演算，而是訂單簿每一檔流動性的狀態維護。多數開發者直觀認為訂單簿只是即時刷新的表格，但若僅以靜態表格的思維處理即時串流，等到回測階段才會發現大量底層缺陷，無論後續如何調校策略參數，實盤與回測的走勢永遠無法對齊。

訂單簿本質並非靜態數據表，而是一條持續變動的狀態鏈，加密貨幣即時 API 的傳輸邏輯分為「初始完整快照」與「後續增量 diff 更新」兩個部分。快照僅作為基準起點，真實市場變化全部依附增量封包傳送；diff 不會重傳完整盤口，只標註單一價位的數量變動或刪除指令。若忽略這一特性直接覆蓋本地數據，長時間執行後本地盤口會與真實市場產生累積性偏差，且這類偏移屬於緩慢累積，短期運行難以察覺。

為什麼不建議使用陣列儲存訂單簿深度

剛入門的開發大多會選用陣列存放買賣掛單，寫作直觀、入門門檻低，但進入高頻 Tick 環境後會暴露出嚴重效能與一致性問題：陣列增刪、重新排序的運算成本極高，持續高負載下程式延遲明顯；同時陣列難以精準對應單一價位，長期執行容易出現狀態不同步。

更穩妥的分層設計思路是分離「底層狀態儲存」與「前端輸出展示」：以字典建立價格對掛單量的映射，分開維持買盤 bids、賣盤 asks 兩組獨立結構，排序動作延遲至策略讀取數據時才執行。更新階段只修改底層字典狀態，不碰展示層邏輯，大幅降低高頻場景的運算負荷。

簡單來說，所有盤口更新只改變原始狀態，排序、輸出等視覺動作延後處理，兩套流程完全解耦。

訂單更新的核心規律與常見踩坑點

加密貨幣即時 API 的 diff 更新規則十分簡單，僅分兩種狀態：

1. size > 0：新增該價位，或是覆蓋更新現有掛單數量

2. size = 0：直接移除這個無流動性的價位

規則看似淺顯，但工程實作中大量問題來自細節處理失當。最普遍的錯誤是將 diff 當作「增量累加」而非「最終狀態覆寫」，重複接收同價位封包時持續疊加數值，長期下盤口檔位徹底失真，畫面上卻看不出明顯異常。

穩健的處理邏輯是：每一筆 diff 都視為該價位當下的真實最終狀態，直接覆蓋或刪除，不做數值累加，除錯與狀態還原都更清晰簡單。

序列 seq 才是維持盤口一致的關鍵

相較價格、數量等流動性資訊，封包內的 seq（序列編號）才是防止盤口漂移的核心。幾乎所有加密貨幣即時行情串流都會攜帶遞增序列號，用來標註封包傳輸順序，處理邏輯必須遵守三個原則：

1. 正常穩定串流中，每筆新封包 seq 必須等於上一筆 seq + 1；

2. 若 seq 跳號、斷層，代表中間遺失數據，此時直接清空本地全部盤口，等待重新拉取完整快照對齊狀態，不可繼續用殘存數據演算；

3. 若接收到重複 seq 封包，直接丟棄不處理，避免重複覆寫造成數值錯亂。

這套順序校驗邏輯看似基礎，卻是長時間 7×24 執行時，杜絕隱性盤口偏移唯一手段；一旦序列順序混亂，後續所有因子、策略運算都會持續累積誤差。

基於 AllTick WebSocket 的完整維護範例

以 AllTick 加密貨幣即時 API 串流為範例，以下是精簡、可直接上線的本地盤口維護程式，核心重點不在複雜演算法，而是狀態與序列的嚴格管控：

import websocket
import json

# 全域盤口狀態，分離買賣盤與最新序列
order_book = {
    "bids": {},
    "asks": {},
    "last_seq": 0
}

def apply_update(side_map, price, size):
    """執行單一價位更新/刪除"""
    if size == 0:
        side_map.pop(price, None)
    else:
        side_map[price] = size

def on_message(ws, message):
    global order_book
    data = json.loads(message)
    seq = data["seq"]
    side = data["side"]
    price = float(data["price"])
    size = float(data["size"])

    # 序列斷層，清空盤重取快照
    if order_book["last_seq"] != 0 and seq != order_book["last_seq"]:
        order_book["bids"].clear()
        order_book["asks"].clear()
        order_book["last_seq"] = 0
        return

    target = order_book["bids"] if side == "bid" else order_book["asks"]
    apply_update(target, price, size)
    order_book["last_seq"] = seq

# 建立串流連線
ws = websocket.WebSocketApp(
    "wss://stream.alltick.co",
    on_message=on_message
)
ws.run_forever()

整套程式背後的核心思路：中間變化過程可捨棄，但盤口狀態與封包順序絕對不能混亂，狀態錯亂時寧可重置重來，也不要帶有偏差持續演算。

工程實務容易忽略的隱藏細節

實際長期運行後會發現，盤口失真不只有 seq 與更新邏輯兩大源頭，還有許多容易被忽視的細節問題：

1. 頻繁排序會拉高 CPU 負荷：每一次 diff 都執行買賣盤排序，高頻 Tick 下策略延遲明顯，排序必須延遲至讀取時執行；

2. 浮點精度錯位：價格、掛單量浮點儲存格式不統一，長期累積出現微小檔位錯位；

3. 快照只拉一次的誤區：無論串流多穩定，每半小時必須定期拉取完整快照校正，抵消長時間微小累積偏差；

4. 計算與更新未解耦：更新、因子運算同步執行，大量封包湧入時整個程式卡頓停滯。

加密貨幣即時 API 僅是數據入口，訂單簿的真實難點，是把一條無限延續的狀態鏈，在本地長期維持連續、無偏差的完整結構。當底層儲存與更新架構穩定運行後，無論市場劇烈波動，本地盤口永遠可追溯、可還原，這是量化回測與實盤統一最重要的基礎保障。