1. 为什么单靠REST API做交易机器人迟早会出问题先把结论摆在前面做交易机器人REST API负责做事Websocket负责看路两者缺一不可。我见过太多人一开始图省事只用REST轮询结果要么被限频卡死要么行情延迟到信号早就失效了才反应过来。这篇文章就把我实际搭建OKX交易机器人时REST和Websocket双轨协同的完整思路、踩过的坑、以及能直接抄的代码结构讲清楚。先说说这个机器人到底要干什么。简单讲它需要同时完成两件事一是实时感知市场——盘口价格、成交明细、K线更新、账户余额变动、订单状态变化二是执行交易动作——下单、撤单、改单、查持仓、查历史成交。前者对时效性要求极高后者对准确性和幂等性要求极高。这两类需求天然对应两种通信方式。REST API的本质是请求-响应模型。你发一个HTTP请求服务器回一个结果然后连接就结束了。它适合做那些我明确知道要做什么现在就要结果的操作。比如我要市价买入0.01个BTC发个POST请求拿到订单ID完事。但如果你用它来轮询行情比如每秒请求一次ticker接口问题就来了第一OKX对REST有频率限制不同接口的限频不一样超了会被封IP一段时间第二轮询间隔内发生的价格变化你完全看不到等下一轮请求回来价格可能已经跑出去好几个点了第三每次请求都有网络往返延迟几十毫秒到几百毫秒不等高频场景下根本不够用。Websocket则是长连接推送模型。你连上OKX的Websocket服务器订阅你关心的频道之后服务器会主动把数据推给你延迟通常在毫秒级。它适合做行情监控、订单状态跟踪、账户变动通知这类需要实时性的场景。但Websocket不适合做交易执行因为它的请求-响应语义不如REST清晰而且连接可能断断了之后你发出去的下单指令到底有没有成功很难确认。所以双轨协同的核心逻辑就是Websocket管感知REST管执行两者通过一个共享的状态层来协同。下面我按实际搭建顺序把每个环节拆开讲。1.1 先搞清楚OKX两类接口的能力边界在动手之前必须把OKX的接口能力摸清楚。我整理了一张对照表这是整个架构设计的基础能力维度REST APIWebsocket行情获取支持但需轮询有延迟支持实时推送延迟毫秒级下单/撤单支持语义清晰有明确返回不推荐确认机制弱账户查询支持按需查询支持余额变动实时推送订单状态支持需轮询支持状态变化实时推送频率限制严格按接口限频相对宽松但订阅频道数有限连接稳定性每次请求独立无状态长连接可能断线需重连适用场景交易执行、批量查询实时监控、事件驱动这张表的关键结论是不要把Websocket当REST用也不要把REST当Websocket用。我见过有人试图通过Websocket发送下单请求技术上OKX的Websocket确实支持部分交易指令但确认机制远不如REST可靠一旦连接抖动你根本不知道订单有没有成交。反过来用REST轮询订单状态在高频策略下会产生大量无效请求既浪费配额又增加延迟。1.2 双轨协同的架构长什么样我最终采用的架构分三层第一层是数据接入层。Websocket客户端负责订阅以下频道tickers行情、books5五档盘口、trades成交明细、orders订单状态、account账户余额。这些频道的数据通过一个消息队列我用的是Python的asyncio.Queue推给上层处理。第二层是状态管理层。维护一份内存中的实时状态包括最新价格、当前持仓、挂单列表、账户余额。Websocket推来的数据更新这份状态REST查询的结果也用来校准这份状态。关键点是所有交易决策都基于这份内存状态而不是每次去请求REST。第三层是交易执行层。当策略模块根据内存状态做出决策后通过REST API发送下单/撤单请求。请求结果回来后更新内存状态同时等待Websocket推送的订单状态变化来做最终确认。这个架构的核心优势是决策基于实时状态执行通过可靠通道确认通过推送完成。三者形成闭环既保证了时效性又保证了可靠性。2. Websocket连接OKX的实操细节与断线重连机制Websocket这部分是整个机器人最容易出问题的地方。OKX的Websocket服务器有多个接入点公共频道和私有频道分开连接管理不当会导致数据丢失或频繁断线。我把自己踩过的坑和最终稳定的方案完整讲一遍。2.1 公共频道与私有频道的连接差异OKX的Websocket分两类公共频道行情、盘口、成交不需要认证直接连wss://ws.okx.com:8443/ws/v5/public即可私有频道订单、账户需要登录认证连wss://ws.okx.com:8443/ws/v5/private连接后要发送登录请求包含API Key、签名和时间戳。登录请求的构造是第一个坑。OKX要求签名用HMAC-SHA256签名内容是timestamp GET /users/self/verify然后Base64编码。时间戳必须是ISO格式的UTC时间且与服务器时间偏差不能超过30秒。我第一次写的时候用了本地时间结果一直登录失败后来才发现服务器时间比本地快了十几秒。import hmac import base64 import hashlib import time from datetime import datetime, timezone def get_login_params(api_key, secret_key, passphrase): timestamp datetime.now(timezone.utc).strftime(%Y-%m-%dT%H:%M:%S.%f)[:-3] Z message timestamp GET /users/self/verify mac hmac.new(secret_key.encode(), message.encode(), hashlib.sha256) sign base64.b64encode(mac.digest()).decode() return { op: login, args: [{ apiKey: api_key, passphrase: passphrase, timestamp: timestamp, sign: sign }] }登录成功后服务器会返回{event: login, code: 0}。如果code不是0说明认证失败常见原因就是时间戳偏差或签名错误。2.2 订阅频道的选择与数据格式处理订阅频道时不要贪多。OKX对单个连接的订阅频道数有限制而且订阅太多会导致消息处理不过来。我的经验是行情类订阅tickers和books5就够了成交明细trades按需订阅订单和账户频道必须订阅。订阅请求的格式是subscribe_msg { op: subscribe, args: [ {channel: tickers, instId: BTC-USDT}, {channel: books5, instId: BTC-USDT}, {channel: orders, instId: BTC-USDT}, {channel: account} ] }数据推来的格式要注意tickers频道推的是最新成交价、买一卖一价等books5推的是五档盘口包含价格和数量orders推的是订单状态变化包括live、partially_filled、filled、canceled等状态。关键点是订单状态推送可能重复也可能乱序必须用订单ID和更新时间戳做去重和排序。我遇到过一个坑orders频道推送的订单状态有时候会先推filled再推live如果直接按推送顺序处理会把已成交的订单又当成挂单。解决办法是维护一个订单状态字典每次收到推送时比较时间戳只处理比当前状态更新的消息。2.3 断线重连与心跳保活Websocket连接不可能永远稳定。网络抖动、服务器维护、长时间无数据都可能导致断线。OKX的Websocket服务器会在30秒内没有收到任何消息时主动断开连接所以必须定期发送心跳。心跳的格式很简单ping_msg {op: ping}建议每20秒发一次留10秒余量。同时要监听pong响应如果连续几次没收到pong就主动重连。重连逻辑是第二个大坑。很多人重连后只重新建立连接忘了重新订阅频道和重新登录。正确的重连流程是检测到连接断开收到close事件或心跳超时等待一个退避时间第一次1秒第二次2秒第三次4秒最多30秒重新建立连接如果是私有频道重新发送登录请求重新发送所有订阅请求重连成功后通过REST API查询一次当前订单和账户状态校准内存状态第6步非常关键。因为断线期间可能有利率变化、订单成交、余额变动这些推送你都丢了。重连后必须用REST做一次全量校准否则内存状态就是错的。async def reconnect_loop(ws_url, login_params, subscribe_args): backoff 1 while True: try: async with websockets.connect(ws_url) as ws: if login_params: await ws.send(json.dumps(login_params)) resp await ws.recv() if json.loads(resp).get(code) ! 0: raise Exception(Login failed) await ws.send(json.dumps({op: subscribe, args: subscribe_args})) backoff 1 await handle_messages(ws) except Exception as e: print(fConnection lost: {e}, reconnecting in {backoff}s) await asyncio.sleep(backoff) backoff min(backoff * 2, 30) await calibrate_state_via_rest()2.4 消息处理不要阻塞接收循环这是很多人忽略的性能问题。Websocket的接收循环必须尽可能快地处理消息如果你在接收循环里做耗时操作比如发REST请求、写数据库会导致消息堆积最终被服务器断开。我的做法是接收循环只做一件事——把消息丢进asyncio.Queue然后立刻继续接收。另起一个或多个消费者协程从队列里取消息做解析、状态更新、策略计算。这样接收和处理解耦接收循环永远不会被阻塞。async def handle_messages(ws): while True: msg await ws.recv() await message_queue.put(msg) async def process_messages(): while True: msg await message_queue.get() data json.loads(msg) if data in data: update_state(data) await strategy_engine.on_data(data)队列要设一个上限比如10000条防止内存无限增长。如果队列满了说明处理速度跟不上需要考虑优化处理逻辑或减少订阅频道。3. REST API在下单、撤单与账户查询中的正确用法REST API这部分核心不是怎么发请求而是怎么发得可靠。交易指令发出去必须确认结果查询请求发出去必须处理限频和错误。我把实际使用中的关键点拆开讲。3.1 下单请求的构造与幂等性保证OKX的下单接口是POST /api/v5/trade/order。请求体包含instId交易对、tdMode交易模式如cash、cross、sidebuy/sell、ordTypemarket/limit、sz数量、px价格市价单不需要等字段。构造请求时签名是必须的。OKX的REST签名规则是timestamp method requestPath body用HMAC-SHA256签名后Base64编码。时间戳同样是ISO格式UTC时间偏差不能超过30秒。def sign_request(api_key, secret_key, passphrase, method, path, body): timestamp datetime.now(timezone.utc).strftime(%Y-%m-%dT%H:%M:%S.%f)[:-3] Z message timestamp method path body mac hmac.new(secret_key.encode(), message.encode(), hashlib.sha256) sign base64.b64encode(mac.digest()).decode() headers { OK-ACCESS-KEY: api_key, OK-ACCESS-SIGN: sign, OK-ACCESS-TIMESTAMP: timestamp, OK-ACCESS-PASSPHRASE: passphrase, Content-Type: application/json } return headers幂等性是下单环节最容易被忽略的问题。假设你发了一个下单请求但网络超时了你不知道订单有没有成功。如果你直接重试可能下两个单。OKX提供了clOrdId客户端订单ID字段你可以自己生成一个唯一ID同一个clOrdId重复下单OKX会拒绝第二个请求。这是保证幂等性的关键。我的做法是每次下单前生成一个UUID作为clOrdId如果请求超时先用GET /api/v5/trade/order?clOrdIdxxx查询这个订单是否存在存在就说明下单成功不存在再重试。3.2 撤单与改单的时机判断撤单接口是POST /api/v5/trade/cancel-order需要传instId和ordId或clOrdId。改单接口是POST /api/v5/trade/amend-order可以改价格或数量。撤单的时机很关键。我的策略是当Websocket推送的盘口价格偏离挂单价格超过一定阈值时触发撤单。比如我挂了一个买单在60000当前卖一价已经跌到59500说明市场在下跌我的买单可能很快成交但成交价不是最优的。这时候应该撤单重新挂一个更低的价格。但撤单不是越快越好。OKX的撤单请求也有延迟如果市场变化太快你撤单请求发出去的时候订单已经成交了撤单会失败。所以撤单逻辑要能处理撤单失败因为已成交的情况这时候应该把订单状态更新为已成交而不是继续重试撤单。改单比撤单重新下单更高效因为改单不丢失排队优先级。但OKX的改单接口有限制只能改价格和数量不能改交易对和方向。而且改单请求也可能失败失败原因可能是订单已成交或已撤销。3.3 账户查询与限频处理账户查询接口是GET /api/v5/account/balance返回各币种的余额、可用余额、冻结余额等。这个接口的限频是每2秒最多10次超过会被限流。限频处理的核心不是不要超而是超了怎么办。OKX返回限流错误时HTTP状态码是429响应体里有code和msg。我的做法是捕获429错误等待一个退避时间比如1秒然后重试。同时维护一个请求计数器如果短时间内频繁触发429说明请求频率确实太高需要降低查询频率。更好的做法是能用Websocket推送的数据就不要用REST查询。账户余额变动有account频道推送订单状态变化有orders频道推送。REST查询只用在两个场景一是初始化时做一次全量查询二是Websocket重连后做一次校准。这样REST请求量可以降到最低基本不会触发限频。3.4 错误处理与重试策略REST请求可能遇到各种错误网络超时、DNS解析失败、HTTP 5xx服务器错误、业务错误码等。不同错误要用不同策略错误类型表现处理策略网络超时请求无响应先查询确认状态再决定是否重试HTTP 429限频退避后重试降低频率HTTP 5xx服务器错误退避后重试最多3次业务错误码如余额不足、价格偏离不重试记录日志通知策略层签名错误时间戳偏差或密钥错误不重试检查配置关键原则交易类请求下单、撤单重试前必须先查询确认查询类请求可以直接重试。因为交易类请求重试可能导致重复操作查询类请求重试没有副作用。4. 双轨协同的核心状态同步与事件驱动策略前面讲了Websocket怎么连、REST怎么用现在讲最关键的部分两者怎么协同。这是整个机器人的大脑也是区分能跑和跑得好的分水岭。4.1 内存状态的设计与更新规则内存状态是整个机器人的单一数据源。我设计的状态结构包括class BotState: def __init__(self): self.tickers {} # instId - {bid, ask, last, ts} self.books {} # instId - {bids: [], asks: [], ts} self.orders {} # ordId - {status, px, sz, filled, ts} self.balance {} # ccy - {avail, frozen, total} self.positions {} # instId - {pos, avgPx, upl} self.last_update {} # channel - timestamp更新规则有三条第一条Websocket推送优先。任何来自Websocket的数据只要时间戳比当前状态新就更新状态。如果时间戳旧丢弃。第二条REST查询用于校准。初始化时和重连后用REST查询全量状态覆盖内存状态。但要注意REST查询返回的数据可能比Websocket推送的旧所以校准时要比较时间戳不能无脑覆盖。第三条交易请求的结果也更新状态。下单成功后把新订单加入orders字典状态设为live。撤单成功后把订单状态改为canceled。但最终确认还是要等Websocket推送。这三条规则的核心是时间戳是唯一的裁判。不管数据来自哪个通道新的覆盖旧的旧的丢弃。4.2 事件驱动策略引擎的设计策略引擎不主动轮询而是被动响应事件。事件来源有三个Websocket推送、REST请求结果、定时器。class StrategyEngine: async def on_ticker(self, instId, ticker): # 行情更新事件 if self.should_buy(instId, ticker): await self.execute_buy(instId, ticker) async def on_order_update(self, order): # 订单状态变化事件 if order.status filled: await self.on_order_filled(order) elif order.status canceled: await self.on_order_canceled(order) async def on_timer(self): # 定时事件用于定期检查 await self.check_risk()事件驱动的好处是策略逻辑只在需要的时候执行不浪费CPU。而且事件之间的因果关系清晰便于调试。但事件驱动也有坑事件可能乱序到达。比如你先收到订单成交推送再收到下单成功的REST响应。如果策略引擎按到达顺序处理可能会把已成交的订单又当成新订单。解决办法是每个事件带上时间戳策略引擎内部维护一个事件队列按时间戳排序后再处理。4.3 订单生命周期管理一个订单从创建到终结经历多个状态live挂单中、partially_filled部分成交、filled完全成交、canceled已撤销。每个状态变化都可能触发策略动作。我的订单生命周期管理逻辑是创建订单通过REST下单拿到ordId在内存中创建订单记录状态设为live。等待确认监听Websocket的orders频道收到该ordId的状态推送后更新订单状态。部分成交如果状态变为partially_filled记录已成交数量根据策略决定是否继续等待或撤单。完全成交状态变为filled更新持仓和余额触发后续策略如止盈止损。撤销如果主动撤单或策略触发撤单状态变为canceled从挂单列表中移除。关键点订单状态的最终确认必须以Websocket推送为准。REST下单返回的只是请求已接受不代表订单已生效。我遇到过REST返回成功但订单实际被拒绝的情况原因是价格偏离太大。所以下单后必须等Websocket推送确认。4.4 数据一致性校验与异常恢复双轨协同最大的风险是数据不一致Websocket推送的状态和REST查询的状态对不上。这种情况通常发生在断线重连、网络抖动、或者OKX服务器内部状态同步延迟时。我的校验策略是每隔一段时间比如5分钟用REST查询一次订单列表和账户余额与内存状态对比。如果发现不一致以REST为准修正内存状态并记录日志。async def consistency_check(): while True: await asyncio.sleep(300) rest_orders await query_open_orders() memory_orders {oid: o for oid, o in state.orders.items() if o.status live} # 检查REST有但内存没有的订单 for o in rest_orders: if o.ordId not in memory_orders: state.orders[o.ordId] o log.warning(fOrder {o.ordId} missing in memory, added from REST) # 检查内存有但REST没有的订单 for oid in memory_orders: if oid not in [o.ordId for o in rest_orders]: state.orders[oid].status unknown log.warning(fOrder {oid} missing in REST, marked unknown)异常恢复的关键是不要假设内存状态永远正确。任何异常情况断线、超时、错误码发生后都要用REST做一次校准。校准的频率可以根据策略的敏感度调整高频策略可以更频繁低频策略可以稀疏一些。5. 实战中踩过的坑与性能优化经验这部分讲一些文档里不会写、但实际跑起来一定会遇到的问题。每个都是我真金白银试出来的。5.1 时间戳偏差导致的签名失败这个问题我遇到不下五次。OKX要求请求时间戳与服务器时间偏差不超过30秒但很多人的服务器时间没有同步跑几天就偏了几十秒。表现是所有REST请求返回50102错误码提示时间戳无效。解决办法很简单服务器上配置NTP时间同步。Linux系统用timedatectl或ntpdateWindows系统在设置里开启自动同步。如果没法改服务器时间可以在每次请求前先调一次OKX的GET /api/v5/public/time接口拿到服务器时间计算本地时间与服务器时间的偏差然后在签名时用服务器时间。async def get_server_time_offset(): resp await http_get(/api/v5/public/time) server_ts int(resp[data][0][ts]) / 1000 local_ts time.time() return server_ts - local_ts这个偏差值缓存起来每次签名时用local_ts offset作为时间戳。偏差值每隔一段时间刷新一次。5.2 Websocket消息积压导致断线前面提到过接收循环不能阻塞。但即使不阻塞如果消息量太大队列还是会积压。我遇到过一种情况订阅了太多交易对的trades频道每秒推送几千条消息处理不过来队列爆满最终被服务器断开。解决办法有两个一是减少订阅频道只订阅策略真正需要的交易对二是优化消息处理逻辑把不必要的字段解析去掉。比如trades频道推送的每条消息包含价格、数量、方向、时间戳等如果策略只用价格就只解析价格字段其他字段跳过。另外可以用多个消费者协程并行处理队列消息。但要注意并行处理可能导致状态更新乱序。如果多个协程同时更新同一个订单状态可能后处理的旧消息覆盖了新消息。解决办法是按instId或ordId做哈希同一个订单的消息总是由同一个协程处理。5.3 REST请求超时与重试的陷阱REST请求超时后重试最大的陷阱是重复下单。我一开始没做幂等性超时后直接重试结果下了两个单一个成交一个挂着最后手动撤单才解决。后来我加了clOrdId幂等性但还有另一个问题重试时用的参数可能已经过期。比如第一次下单时价格是60000超时后重试价格已经变成60500如果还用60000下单可能直接成交在60500市价单或者挂单失败限价单价格偏离太大。解决办法是重试前重新获取最新价格重新计算下单参数。同时重试次数不要太多最多3次超过就放弃并通知策略层。5.4 内存状态与交易所状态不一致的排查方法数据不一致是最难排查的问题因为你不确定是Websocket丢了消息还是REST查询有延迟还是自己的状态更新逻辑有bug。我的排查方法是记录所有状态变更的日志包括变更来源、变更前后的值、时间戳。当发现不一致时回溯日志找到第一个不一致的时间点然后看那个时间点附近发生了什么事件断线、重连、错误码等。def update_state(key, new_value, source): old_value state.get(key) if old_value ! new_value: log.info(fState change: {key} from {old_value} to {new_value}, source{source}, ts{time.time()}) state[key] new_value日志要结构化方便用工具分析。我用的是JSON格式日志每条日志一行包含timestamp、level、event、key、old_value、new_value、source等字段。出问题时用grep或jq过滤很快就能定位。5.5 性能优化的几个实用技巧最后分享几个性能优化技巧都是实测有效的第一用orjson替代标准库的json。orjson的解析速度快3-5倍对于高频消息处理场景提升很明显。第二Websocket消息批量处理。如果队列里积压了多条消息不要一条一条处理批量取出比如一次取100条批量解析批量更新状态。这样可以减少函数调用开销和锁竞争。第三REST连接复用。用aiohttp的ClientSession保持长连接避免每次请求都重新建立TCP连接。ClientSession要设置合理的连接池大小太小会导致请求排队太大浪费资源。第四状态更新用不可变数据结构。每次更新状态时创建一个新的状态对象而不是修改原对象。这样可以避免并发读写问题也方便回滚和调试。Python里可以用dataclasses的replace方法。第五关键路径避免日志IO。日志写入是磁盘IO很慢。在消息处理的关键路径上不要直接写日志文件而是把日志丢进一个队列由单独的协程异步写入。这样不会阻塞消息处理。6. 从能跑到跑得稳监控、告警与日常维护机器人跑起来只是第一步跑得稳才是目标。这部分讲监控和告警的设计以及日常维护中要注意的事项。6.1 必须监控的核心指标我监控的指标分四类连接类指标Websocket连接状态连接/断开、重连次数、最后一次收到消息的时间。如果超过30秒没收到任何消息说明连接可能有问题触发告警。请求类指标REST请求成功率、平均延迟、429错误次数、超时次数。成功率低于95%或429错误频繁出现说明需要优化请求频率或检查网络。状态类指标内存中的挂单数量、持仓数量、账户余额。如果挂单数量异常增多比如超过策略设定的上限说明撤单逻辑可能有问题。策略类指标信号触发次数、下单次数、成交次数、盈亏。这些指标用于评估策略效果也用于发现异常比如下单次数突然暴增可能是策略逻辑有bug。监控数据我用的是Prometheus Grafana机器人暴露一个/metrics接口Prometheus定期抓取Grafana做可视化。告警用Alertmanager配置规则比如Websocket断开超过1分钟、REST成功率低于90%、5分钟内下单次数超过100等。6.2 告警渠道与告警分级告警不能一股脑全发要分级级别触发条件通知方式响应要求P0机器人进程崩溃、无法连接交易所电话短信立即处理P1Websocket断开超过5分钟、REST持续失败短信即时消息15分钟内处理P2单次请求失败、重连成功即时消息当天处理P3状态不一致、指标异常邮件次日处理P0和P1必须能叫醒人P2和P3可以攒着一起看。告警消息要包含足够的信息什么指标、当前值、阈值、可能的原因、建议的处理动作。6.3 日常维护清单机器人上线后每天要做的事检查告警记录看有没有P1以上的告警检查日志看有没有异常错误码检查账户余额和持仓与预期是否一致检查策略盈亏评估策略是否还有效每周要做的事回顾限频错误看是否需要调整请求频率检查Websocket重连次数如果频繁重连排查网络问题更新依赖库修复已知bug备份配置和状态数据每月要做的事全面回测策略看是否需要调整参数检查API Key权限撤销不必要的权限审查代码清理无用逻辑更新文档记录本月遇到的问题和解决方案6.4 策略失效的早期信号最后讲一个容易被忽略的点策略失效的早期信号。机器人跑得好好的突然开始亏钱往往不是代码问题而是市场环境变了。早期信号包括胜率下降原来70%的胜率降到50%盈亏比恶化原来赚3亏1变成赚1亏3信号频率异常原来每天10个信号变成每天100个或0个滑点增大成交价与预期价格偏差变大发现这些信号后不要急着改代码先暂停策略分析市场数据确认是策略问题还是市场问题。如果是市场问题可能需要调整策略参数或换策略如果是代码问题再排查bug。我个人在实际操作中的体会是交易机器人最难的不是写代码而是管理预期和风险。代码可以调试市场不会等你。任何时候都要有止损和熔断机制亏到一定程度自动停止保护本金。这是比任何技术细节都重要的原则。
