用 WebSocket 接欧易实时行情:进阶策略为什么要换掉 REST 轮询

策略跑久了,你大概会遇到这种尴尬:明明逻辑没错,实盘成交却总慢半拍。盯着代码看,问题往往不在策略本身,而在你拿行情的方式——还在用 REST 一遍遍地问「现在多少钱」。这种轮询天生有延迟,频率一高还撞限频。要让策略反应更快,通常该把行情接入从轮询换成 WebSocket 推送。

这篇我们(量化喵编辑组)讲清楚 WebSocket 在欧易上怎么用:它和 REST 轮询差在哪、为什么进阶策略要用它、欧易有哪些频道、怎么用 ccxt.pro 的 watch_ticker 和 watch_orders 写推送、断线重连和心跳怎么处理,以及——很重要的一句——它适合谁。提前说结论:这是进阶内容,新手的简单策略用 REST 就够,别为了「看起来专业」过早上 WS。

REST 轮询 vs WebSocket 推送

两者的区别,用一个生活类比就清楚了。REST 轮询像你每隔几秒就打个电话问对方「有新消息吗」,大多数时候得到的回答是「没有」,白打;WebSocket 像你和对方接通了一条不挂断的线,他一有消息就直接说给你听,你什么都不用问。

落到技术上:

简而言之:REST 简单但慢,WebSocket 快但要多写些代码。选哪个,取决于你的策略对「快」有多在意。

为什么策略要用 WS

把上面的对比浓缩成三个让策略受益的点:

• 延迟低,反应快。价格一变就推到你手里,策略能更早做出反应。对吃震荡、抢价差的策略,这点延迟差距可能就是赚和不赚的分界。
• 省请求,不撞限频。WS 是一条长连接,不像轮询那样反复发请求,自然不容易触发限频。想盯很多个交易对时,这个优势尤其明显。
• 实时知道自己的状态。私有频道会把你的订单成交、持仓变动、余额变化主动推给你,不用一遍遍 fetch_open_orders 去查。策略据此调整更及时,也更省接口。

但请注意「受益」是有前提的:你的策略得真的对时效敏感。如果你跑的是一小时检查一次的低频网格,WS 那点延迟优势对你毫无意义,反而平白引入了复杂度。

欧易 WS 的频道

欧易的 WebSocket(API v5)频道大致分两类,理解这个划分,后面写代码就顺了:

公有频道(Public)。推的是公开的市场数据,任何人都能订阅,不需要鉴权。常用的有:

• 行情(tickers):最新成交价、买一卖一、24 小时涨跌等。
• K 线(candles):各周期的 K 线更新。
• 盘口深度(books):买卖盘挂单深度。
• 逐笔成交(trades):市场上发生的每一笔成交。

私有频道(Private)。推的是你自己账户相关的数据,订阅前需要用 API Key 鉴权(同样是 apiKey、secret、Passphrase 三件套)。常用的有:

• 订单(orders):你的委托单状态变化、成交回报。
• 持仓(positions):合约持仓的变动。
• 账户(account):余额、保证金等变化。

一句话记:公有频道看市场,私有频道看自己。你既可以只订公有频道做行情驱动的策略,也可以同时订私有频道,实时跟踪自己的下单结果。

用 ccxt.pro 接行情(watch_ticker)

接 WS 最省事的方式还是走 ccxt——它的 WebSocket 扩展叫 ccxt.pro,如今已并入 ccxt 主包。普通 ccxt 走 REST,用 fetch_ 系列;ccxt.pro 走 WS,用 watch_ 系列。因为底层是长连接,代码要写成异步(async)的循环。

下面这段订阅 BTC/USDT 的行情,价格一更新就打印:

import asyncio
import ccxt.pro as ccxtpro     # WS 版,watch_ 系列

async def main():
    okx = ccxtpro.okx()        # 公有行情不需要鉴权
    symbol = 'BTC/USDT'
    try:
        while True:
            ticker = await okx.watch_ticker(symbol)   # 有新行情才返回
            print(ticker['symbol'], ticker['last'])
    finally:
        await okx.close()       # 退出时关掉长连接

asyncio.run(main())

和 REST 的关键区别在 await okx.watch_ticker(...):它不是你主动去拉,而是「挂在那儿等推送」,有新行情才返回。把它放在 while True 循环里,就成了一个持续接收行情的流。注意结尾的 await okx.close()——长连接用完要主动关,别让它悬着。

接私有订单频道(watch_orders)

公有行情之外,进阶玩法是同时盯自己的订单。watch_orders 会在你的委托单状态一有变化(部分成交、完全成交、撤单)就推给你,比反复 fetch_open_orders 及时得多。它属于私有频道,所以要带上凭证:

import asyncio
import ccxt.pro as ccxtpro

async def main():
    okx = ccxtpro.okx({
        'apiKey':   '你的_apiKey',
        'secret':   '你的_secret',
        'password': '你的_Passphrase',   # 私有频道需鉴权
    })
    try:
        while True:
            orders = await okx.watch_orders()    # 你的订单一有变化就推
            for o in orders:
                print(o['symbol'], o['side'], o['status'], o.get('filled'))
    finally:
        await okx.close()

asyncio.run(main())

有了这个,你的策略就能在订单一成交的瞬间拿到回报,据此立刻挂下一单或调整仓位,而不是等下一轮轮询才发现「哦,刚才那单成了」。这对网格、做市这类需要快速接力下单的策略很关键。私有频道用的还是你那把实盘 API Key(建 Key 见 API 量化入门),权限只勾「读取」和「交易」,别勾「提现」。

断线重连与心跳

长连接最大的现实问题是:它会断。网络抖一下、交易所例行重启,连接就没了。WS 策略写得稳不稳,很大程度看你怎么处理断线。两件事必须做:

心跳 / 保活。WebSocket 协议靠定期的 ping/pong 来确认连接还活着。如果一段时间没动静,交易所会把这条连接当成死连接掐掉。好在 ccxt.pro 内部一般帮你处理了保活,你主要确保别让程序长时间阻塞、卡住消息收发即可。

断线重连 + 重新订阅。连接断了要能自动重连,而且重连后要重新订阅频道、并补查一次当前真实状态(比如重新拉一遍当前挂单和持仓),因为断线期间发生的推送你是收不到的。常见写法是把 watch_ 调用包在 try/except 里,捕获连接类异常后重连重订:

import asyncio
import ccxt.pro as ccxtpro

async def main():
    okx = ccxtpro.okx()
    symbol = 'BTC/USDT'
    while True:
        try:
            ticker = await okx.watch_ticker(symbol)
            print(ticker['last'])
        except ccxtpro.NetworkError as e:
            print('连接异常,稍后重连重订:', e)
            await asyncio.sleep(2)          # 退一步再重连,别狂撞
            # 重连后视情况补查一次当前持仓/挂单的真实状态
        except Exception as e:
            print('其他异常:', e)
            await asyncio.sleep(2)

asyncio.run(main())

这里的重点不是代码多漂亮,而是那条原则:断线之后别假设状态没变,先补查再继续。这和我们在 量化风控 里讲的「重连后先查状态、再动作」是同一回事——失联期间市场可能已经动了,盲目接着跑容易出乱子。

实测:延迟对比

它适合谁

说回最该想清楚的问题:你需不需要 WebSocket。我们的判断标准很简单——

建议先用 REST 的情况:你是新手;策略是低频的(几分钟甚至几小时检查一次);逻辑简单、对延迟不敏感。REST 同步、直观、好调试,这些场景它完全够用,而且少了异步和断线重连的坑,你能把精力放在策略本身。

值得上 WS 的情况:策略对延迟敏感(吃震荡、做市、价差套利);你要同时盯很多交易对,轮询开始撞限频;你需要订单成交的实时回报来接力下单。到了这些场景,WS 带来的实时性和效率,值得你多写那些异步和重连的代码。

一句话总结:别为了显得专业而过早上 WS。先用 REST 把策略跑通跑顺,等你真的撞上轮询的天花板——慢了、或撞限频了——再升级到 WebSocket,这个顺序最省力,也最不容易在还没搞懂策略时就被技术复杂度绊住。无论用哪种,新代码都先丢 模拟盘 验证。

常见问题

WebSocket 是个好工具,但它是给「已经知道自己为什么需要它」的人准备的。如果你还在打基础,先把 API 量化入门 跑通,把 风控 装好,这些比换成 WS 重要得多。等策略真的快不起来了,再回来看这篇。