行情 API 計費模型對比：WebSocket vs REST 成本實測

選行情數據 API 時，大多數團隊第一眼看單價：每百萬次請求多少錢。但對實時行情場景來說，計費模型對總成本的影響遠大於單價本身。原因不復雜——實時行情是持續推送型負載，不是查詢型負載。用查詢型的計費模型去承載推送型的負載，成本會隨標的數量和時間雙重膨脹。

兩種計費模型，兩種命運

市面上的計費方式基本分兩類：

按請求計費：每次 HTTP 調用消耗一次額度。適合歷史數據拉取、定時快照、低頻查詢。
按消息計費：WebSocket 每推送一條 tick 計一次費用。標的越多、行情越活躍，消息量增長越陡。

問題在於：不少平臺把流式推送也做成按條計費。而實時行情的消息量，天生就是天文數字。

算一筆賬：500 個標的的 REST 輪詢成本

假設你要監控 500 個標的，要求秒級刷新。

TIQEX 的多市場行情接口單次最多支持 50 個 codes，因此一輪完整輪詢需要 10 次請求：

10 次請求/秒 × 86,400 秒 = 864,000 次/天
月度約 2,592 萬次請求

這個數字意味著什麼？對照套餐額度：Growth 每月 50 萬次，Pro 每月 500 萬次——秒級輪詢 500 個標的，連 Pro 的額度都不夠。

同樣 500 個標的，換成 WebSocket 是多少

1 條 WebSocket 連接訂閱 500 個標的
假設每個標的平均每秒 2 條 tick → 1,000 條消息/秒
月度約 25.9 億條消息

現在把這個數字乘以你供應商的每消息單價。即使單價低到每百萬條 $0.5，月賬單也超過 $1,300；若單價是每百萬條 $5，月賬單就是 $12,960——而這只是 500 個標的。上千標的的組合監控，成本會直接失控。

關鍵在於：標的數量是業務需求，不會因為你的預算而減少。 所以按消息計費在實時行情場景裡，是一個會持續惡化的成本結構。

握手計費：唯一不會失控的成本結構

這正是 TIQEX 採用「握手計入額度、推送不計費」的原因：

WebSocket 建連握手計入每日額度與每分鐘速率（RPM）
握手之後的 tick 推送 不按條計費
因此 500 個標的和 5,000 個標的，流式成本幾乎恆定

換句話說：標的是可擴展的，成本不是。

兩種模型各用在哪

場景	推薦模型	原因
實時監控、交易終端、告警	WebSocket 流式	持續推送，握手計費後成本恆定
歷史 K 線回填、回測數據準備	REST 查詢	一次性批量拉取，請求數可控
低頻快照（分鐘級 / 小時級）	REST 查詢	請求量小，實現簡單
上千標的組合監控	WebSocket 流式	REST 輪詢成本會擊穿任何套餐

TIQEX 的定價頁把這條原則寫得很直白：Use WebSocket for live ticks; REST for queries and backfill.

延遲：另一個被忽略的差異

成本之外，兩種模型在延遲上的差異同樣明顯。

REST 輪詢的延遲由兩部分構成：輪詢間隔 + 網絡往返時間。秒級輪詢意味著平均延遲 500ms（最壞 1,000ms），再加上每次請求的 RTT。對分鐘級決策這無所謂，但對做市、套利、實時告警這類場景，500ms 已經足夠讓信號失效。

WebSocket 是服務端主動推送：行情一有變化立即下發，延遲只由服務端到客戶端的網絡路徑決定，不必為等待下一次輪詢付出額外代價。TIQEX 官方標註的數據延遲為 78ms。

換句話說，流式方案不只是更省，還更快——而這兩個優勢來自同一個設計決策。

用 Python 先驗證你的用量結構

在選套餐之前，先算清楚你的真實請求量。下面這段腳本按接口的批量上限反推月消耗：

Python

import math

symbols = 500
batch_size = 50        # /api/v1/market/quote 單次最多 50 個 codes
interval_sec = 1       # 秒級刷新

requests_per_poll = math.ceil(symbols / batch_size)
per_day = requests_per_poll * (86400 // interval_sec)
per_month = per_day * 30

print(f"每輪請求數: {requests_per_poll}")
print(f"每日請求數: {per_day:,}")
print(f"每月請求數: {per_month:,}")
# 每輪請求數: 10
# 每日請求數: 864,000
# 每月請求數: 25,920,000

把 symbols 改成你的真實標的數，就能立刻看出 REST 輪詢是否可行。如果月請求量已經超過套餐額度，正確的解法不是升級套餐，而是換成流式訂閱。

從 REST 輪詢遷移到流式：三步

遷移本身比想像中簡單。以 Python 為例，用 websockets 訂閱 TIQEX 的流式端點：

Python

import asyncio, json, os
import websockets

API_KEY = os.environ["TIQEX_API_KEY"]
SYMBOLS = ["BTCUSDT", "ETHUSDT", "AAPL", "EURUSD"]

async def main():
    async with websockets.connect(
        "wss://api.tiqex.io/api/v1/market/stream",
        additional_headers={"X-API-Key": API_KEY},   # websockets < 14 請用 extra_headers
    ) as ws:
        await ws.send(json.dumps({
            "action": "subscribe",     # 首條消息必須是 subscribe
            "market": "crypto",
            "symbols": SYMBOLS,
        }))
        async for raw in ws:
            frame = json.loads(raw)
            if not frame.get("succ"):
                print("error:", frame.get("code"), frame.get("msg"))
                continue
            data = frame["data"]
            if data.get("type") == "subscribed":
                print("subscribed:", data.get("symbols"))
            elif data.get("type") == "tick":
                tick = data["tick"]
                print(tick["symbol"], tick["last"], tick["at"])

asyncio.run(main())

三個關鍵點：

首條消息必須是 subscribe，並帶上 market 與 symbols。符號數量受套餐上限約束。
訂閱成功後會先收到一條 type=subscribed 的確認幀，之後才是連續的 type=tick 數據幀。生產代碼應等確認幀到達後再開始處理業務。
鑑權用 X-API-Key 頭（也接受 Authorization: Bearer）。WebSocket 與 REST 共用同一套密鑰。

完整的訂閱協議、字段定義與錯誤碼見 WebSocket 流式接口文檔；REST 與流式在語義上的差異可參考輪詢與流式對比。

遷移到流式的檢查清單

確認套餐權限：不同套餐開放的市場不同。實時行情需要對應套餐，否則會返回 MARKET_NOT_ENABLED（403）。
檢查 delayed 標誌：REST 響應裡的 delayed 字段為 true 表示該市場當前是延遲數據。生產環境務必校驗這個字段。
實現心跳與重連：長連接必須有重連與退避策略，參見 WebSocket 實時報價指南。
區分握手與推送的額度影響：握手計入額度，所以不要用頻繁重連來「刷新」連接。
處理 429：DAILY_LIMIT_EXCEEDED、MONTHLY_LIMIT_EXCEEDED、RATE_LIMIT_EXCEEDED 都返回 429，需要區分處理。
先用工具估算：配額計算器可以快速試算不同標的規模下的額度需求。

怎麼確認遷移成功

切換完成後，用三個信號驗證：

額度消耗曲線走平：握手計費下，日額度消耗應該只與連接次數相關，而不是隨行情活躍度波動。
端到端延遲下降：對比 tick 的 at 字段（RFC3339 時間戳）與本地接收時間。
429 消失：遷移後如果仍出現 DAILY_LIMIT_EXCEEDED，說明還有殘留的 REST 輪詢在跑。

常見問題

WebSocket 推送會計入 REST 額度嗎？

不會按條計入。建連握手會計入每日額度和 RPM，握手之後的 tick 推送不計費。這也是流式方案成本恆定的原因。

為什麼秒級輪詢 500 個標的會超額度？

因為批量上限是每次 50 個 codes，一輪需要 10 次請求。10 次/秒 × 86,400 秒 = 86.4 萬次/天，月度約 2,592 萬次，超過 Pro 套餐的 500 萬次月額度。

REST 和 WebSocket 可以同時用嗎？

可以，而且推薦這麼做：用 WebSocket 承載實時推送，用 REST 做歷史回填和低頻查詢。這也是 TIQEX 官方建議的用法。

標的規模擴大後成本會怎麼變？

走流式的話基本不變——握手計費與訂閱標的數量無關。走 REST 輪詢則是線性增長，標的翻倍、成本翻倍。

怎麼確認我拿到的是實時數據而不是延遲數據？

檢查 REST 響應中的 delayed 字段，以及套餐的市場權限。Growth 套餐的 crypto 和金屬是實時的，美股、A 股、港股等為延遲；Pro 套餐全市場實時。

下一步

先算清你的真實請求量，再決定計費模型。免費套餐包含延遲的 crypto、美股和金屬數據，無需信用卡即可驗證接入流程——用 Python 接入指南十分鐘就能跑通第一條請求。

按市場查看具體的實時 / 延遲權限：加密貨幣行情、美股行情、外匯行情。