美股 API WebSocket 斷線後訂閱復原：解決量化實盤行情採集的數據斷檔問題

9 月 1 日

在量化研究與實盤策略運作的場景中，即時Tick、K線數據的連續性，會直接影響回測可重現性、訊號生成以及策略執行的品質。不少行情採集腳本僅實作 WebSocket 斷線重連，卻忽略訂閱狀態還原，造成「連線顯示正常，但行情停止推送」的隱性故障。本文從實戰角度梳理問題成因、處理流程，提供可除錯的 Python 程式範例，同時說明長時間運行下的數據處理重點。

Matters｜技術筆記 · 研究分享

進行量化策略的實盤開發時，多數研究者會把心力投入因子建構、回測邏輯、交易訊號模型的調校。面對底層行情接入，很容易產生一種預設：只要 WebSocket 長連線建立完成，就能穩定持續取得美股即時行情。

但程式進入長時間不間斷運行之後，網路抖動、連線逾時、伺服器端連線限制等客觀因素，都可能造成 WebSocket 連線靜默斷開。這類故障不會直接讓程式崩潰，程序仍持續執行，僅僅是行情推送停止。

對於量化工作來說，這種靜默斷連所帶來的數據缺口具有不小的危害：Tick原始序列遺失，會導致實盤與回測樣本不一致；K線片段缺漏會干擾技術指標運算，進而造成策略訊號失真。僅僅把網路連線重新接通並不足以解決問題，重連之後還需要還原原本的訂閱任務，才能維持行情數據流的完整，這也是許多採集腳本常見的短板。

WebSocket斷線對量化工作帶來的影響

WebSocket 依靠長連線實現雙向數據流。連線建立後，伺服器持續推送標的行情，本機客戶端負責接收、解析，供後續模型與指標計算模組使用。

一旦連線關閉，會出現幾個現象：

應用程式不會報錯退出，外部難以直覺察覺故障；
行情數據流直接中斷，採集模組停止輸出資料；
若缺少連線狀態檢測邏輯，系統會持續產生殘缺數據集，不僅影響實盤訊號，也會造成未來實盤與歷史回測結果無法對齊。

實務上建議在採集程式內維護兩組狀態：WebSocket連線健康狀態、完整訂閱中繼資料（包含標的代碼、數據顆粒度等）。連線重建完成後，讀取已儲存的中繼資料重新發送訂閱請求，無須手動重啟程式，確保數據來源持續輸出，為策略模型提供完整的輸入資料。

核心觀念：重連不等於訂閱復原只完成網路重連，卻沒有重新下發訂閱指令，會出現連線狀態顯示正常，但伺服器不會繼續回傳目標標的行情，採集程式持續接收空的數據流。

完整的故障自愈流程分為四個步驟：

持續監控 WebSocket 連線的健康狀態；
偵測斷線異常，重建 WebSocket 通訊通道；
讀取預先儲存的訂閱參數，重新提交訂閱請求；
恢復行情封包接收，繼續對指標、策略模組輸出數據。

務必留存訂閱參數。如果同時訂閱多檔美股標的，需要保存完整的訂閱清單，否則故障復原後，只能取得部分標的的行情。

Python實戰範例：斷線自動重連與訂閱復原

以下為Tick逐筆行情採集的基礎實作範例。連線異常斷開後，程式自動重建WebSocket連線，並恢復標的訂閱，讓行情持續流入，適合做策略前置數據採集模組的原型驗證。

import websocket
import json
import time


def subscribe(ws):
    data = {
        "action": "subscribe",
        "symbol": "AAPL",
        "type": "tick",
        "source": "alltick"
    }
    ws.send(json.dumps(data))


def on_open(ws):
    print("連線成功")
    subscribe(ws)


def on_message(ws, message):
    data = json.loads(message)
    print(data)


def on_close(ws, code, msg):
    print("連線關閉")


while True:
    try:
        ws = websocket.WebSocketApp(
            "wss://api.alltick.co/ws",
            on_open=on_open,
            on_message=on_message,
            on_close=on_close
        )

        ws.run_forever()

    except Exception as e:
        print("異常:", e)

    time.sleep(5)

程式邏輯說明：連線終止之後，程式等待數秒重新建立 WebSocket 工作階段；新連線開啟觸發 on_open 回呼函數，再次執行訂閱，恢復行情推送。此版本適合原型驗證，不建議未經修改直接投入高強度的實盤環境。

量化實盤場景下的工程注意事項

上面的範例屬於基礎版本，當策略需要7×24小時運行，還要補充數項邏輯，保障輸入數據品質：

行情數據去重驗證重連之後有可能收到重複的Tick封包。建議使用時間戳或是成交編號做去重判斷，避免資料庫重複寫入，防止重複數據汙染樣本庫，造成回測、統計指標出現偏差。
完整維護多標的訂閱清單多商品策略需要持久化全部訂閱標的資訊，避免重連後部分標的行情遺失，導致策略局部數據缺口。
合理控制重連重試頻率不要使用無間隔的迴圈重試連線。高頻重連會增加API伺服器負擔，同時消耗本機運算資源，影響策略主邏輯執行，建議設定固定休眠間隔提升穩定性。
建議擴充：異常告警機制可額外加入時間戳檢查邏輯，當長時間沒有新的行情封包，觸發日誌告警，及時捕捉極端異常，避免策略基於過期數據運算。

結語

在量化研究與實盤部署之中，底層數據來源的穩定性擁有很高優先級。回測是否可複現、實盤訊號是否可靠，很大程度取決於行情數據的完整度。

WebSocket斷線自動復原屬於底層基礎能力，卻直接決定採集資料集的品質。在開發採集模組的階段，就把連線狀態管理、訂閱資訊留存、封包驗證去重納入設計，才能為因子研究、回測驗證、實盤策略打下可靠的數據基礎。原型測試階段，可以透過 AllTick API 快速驗證這套容錯復原邏輯，把更多精力聚焦在策略本身的研究。

若你在行情採集過程，遇過其他影響量化數據品質的底層問題，歡迎留言交流討論。

CC BY-NC-ND 4.0 授权