轮询拉行情太慢？学会WebSocket订阅指定交易对，数据就像自己长脚跑进程序

我是金融系的一名讲师，经常在实训课里带学生接触加密货币行情数据。许多同学刚开始都会走弯路：以为调个HTTP接口定时拉数据就是“实时行情”。直到模拟交易出现大幅度滑点，他们才真正意识到“数据迟到”对于策略的伤害有多大。今天这篇手记，我想还原课堂上的一次演示，告诉你如何订阅指定交易对的实时成交推送，让数据主动流进你的策略。

一次“轮询 vs 推送”的课堂现场对比

我在大屏幕上开了两个终端。左侧是一个轮询脚本，每2秒请求一次BTCUSDT的成交记录；右侧是一个WebSocket客户端，订阅同一交易对的实时成交。我要求同学们盯着两条打印流。不到一分钟就有人喊：“老师，右边已经打印了二十几条了，左边才更新了三次。”这就是拉取模式的天生劣势：你不知道交易在询问间隔里发生了多少次，而且HTTP握手和解析的开销在频率高时会显著累加。

把精力放在真正需要的交易对上

接下来我让同学们尝试一次性订阅平台上所有的USDT交易对。结果，终端瞬间被海量消息淹没，PyCharm都出现了卡顿。我们马上改回只订阅BTCUSDT和ETHUSDT两个交易对，流量立刻变得可控，策略线程能从容地对每一笔到达的数据做波动率计算。所以“只订阅关心的交易对”并不是限制，而是一种资源聚焦策略：第一可以避免无意义的反序列化开销；第二能让你的策略不被打断；第三在计算相关指标时数据更纯粹，不需要额外过滤步骤。

拆开一条成交消息，看懂推动市场的原子事件

我用AllTick的WebSocket API作为例子，拿到一条典型的推送消息，展示它的内在结构：

{
  "symbol": "BTCUSDT",
  "price": "30500.12",
  "quantity": "0.05",
  "side": "buy",
  "timestamp": 1686327890000
}

我告诉学生，symbol是你在多交易对订阅时的分拣标签；price和quantity是核心；side可以帮助判断主动成交方向，是构建订单流分析的基础；timestamp既能排序，又能做时延监控。这五个字段已经够做很多有趣的事情了，比如实时成交量加权均价、大单预警、甚至是简单的做市策略仿真。

一个连接，承载多个交易对

实际策略往往需要同时监控多个交易对。我在同一个WebSocket连接里发送包含两个symbol的订阅请求，推送回来的每条消息通过symbol字段路由到对应的处理队列。为了避免高频推送导致处理堆积，我用Python的asyncio.Queue做了缓冲，策略协程从队列中取数据，做到消峰。连接断开是不可避免的，我在on_close里设置重连逻辑，重连后重新发送订阅请求，并用消息timestamp去重，保证不重复触发信号。

编写你自己的第一个实时成交订阅器

下面这段代码可以让你在本地立刻体验实时成交推送。我选用了ALLTICK API 的公开WebSocket地址，因为它免去了复杂的自建网关步骤，很适合教学：

import websocket
import json

def on_message(ws, message):
    data = json.loads(message)
    print(f"成交: {data['symbol']} {data['price']} 数量 {data['quantity']}")

def on_open(ws):
    subscribe = {
        "action": "subscribe",
        "symbol": "BTCUSDT",
        "type": "trade",
        "id": 1
    }
    ws.send(json.dumps(subscribe))

ws = websocket.WebSocketApp("wss://api.alltick.co/ws",
                            on_message=on_message,
                            on_open=on_open)
ws.run_forever()

跑起来后，你会看到数据如流水般进入程序。这个Demo已经可以当作策略或监控系统的数据入口。如果想要进一步学习，可以访问对应API的文档页面，里面有更详细的订阅参数说明。