3、数据源分析：主流交易所API对比

做量化交易，第一步就是选数据源。说白了，你的策略再牛，数据源不行，一切都是白搭。

我个人习惯把交易所API分成三类：Binance、OKX、Bybit。这三家是目前全球流动性最好的现货和合约交易所。今天我们就来拆解一下它们的API差异，以及WebSocket协议的基础。

3.1 三大交易所API对比

先看一张对比表，心里有个底：

特性	Binance	OKX	Bybit
WebSocket地址	wss://stream.binance.com:9443/ws	wss://ws.okx.com:8443/ws/v5/public	wss://stream.bybit.com/v5/public/spot
订阅格式	JSON数组，简洁	JSON对象，带op字段	JSON对象，带req_id
Tick推送频率	100ms（最快）	200ms	200ms
深度数据	5/10/20档	5/10/20档	5/10/20档
历史数据	免费，有限制	免费，有限制	免费，有限制
文档质量	★★★★★	★★★★☆	★★★★☆

嗯，这里要注意：Binance的Tick推送频率是100ms，比另外两家快一倍。我在做高频策略时，首选就是Binance。但OKX和Bybit的文档也不差，尤其是OKX的REST API，字段命名很规范。

3.2 WebSocket协议基础

WebSocket说白了就是一条长连接。你连上交易所的服务器，然后一直收数据，不用反复发HTTP请求。

为什么会这样？因为Tick数据是高频的，每秒可能来几十次。如果用REST轮询，带宽和延迟都扛不住。

我建议你记住WebSocket的几个核心概念：

• 连接建立：通过HTTP Upgrade握手，从http://变成ws://
• 心跳机制：每隔一段时间发一个ping，服务器回pong，保持连接
• 订阅/取消订阅：发送JSON格式的订阅消息，告诉服务器你要哪些数据
• 数据推送：服务器实时推送Tick数据，你只管收

我曾经踩过一个坑：忘记做心跳重连。结果程序跑了两个小时，连接断了，数据停了，我还傻等着。后来我加了一个定时器，每30秒发一次ping，问题就解决了。

3.3 Tick数据字段解析

Tick数据长什么样？我们来看一个Binance的实时Tick示例：

{
  "e": "trade",       // 事件类型
  "E": 1678901234567, // 事件时间（毫秒时间戳）
  "s": "BTCUSDT",     // 交易对
  "t": 123456789,     // 交易ID
  "p": "50000.00",    // 成交价格
  "q": "0.001",       // 成交数量
  "T": 1678901234567, // 成交时间
  "m": true,          // 是否主动卖出（true=卖单吃买单）
  "M": true           // 是否做市商
}

这里有几个关键字段，我重点说一下：

• price（p）：成交价格，字符串类型。注意，交易所为了精度，价格和数量都用字符串传，别用浮点数直接算。
• volume（q）：成交数量，也是字符串。我习惯在收到数据后，用Decimal类型转一下，避免精度丢失。
• timestamp（E/T）：时间戳，毫秒级。E是事件时间，T是成交时间。大部分情况下两者一样，但偶尔会有几毫秒的偏差。
• isBuyerMaker（m）：这个字段很关键。true表示这笔Tick是卖单主动吃买单，false表示买单主动吃卖单。做盘口分析时，这个字段能帮你判断买卖力量。

3.4 核心逻辑：Tick数据采集流程

下面这张图是我自己画的，展示了从WebSocket连接到数据落库的完整流程：

这张图里，我特别标注了心跳重连。你想想看，如果网络断了，程序不会自动重连，那后面的步骤全废了。所以我在实际项目中，会在步骤1和步骤3之间加一个心跳检测线程，每30秒检查一次连接状态。

3.5 避坑指南

最后分享几个我踩过的坑：

• 时间戳精度：交易所给的是毫秒时间戳，但有些数据库只支持秒级。我建议统一用毫秒存储，避免精度丢失。
• 数据乱序：WebSocket是异步的，偶尔会出现后发的Tick先到。我习惯在解析时加一个序列号校验，或者用时间戳排序。
• 订阅限制：Binance单个连接最多订阅1024个stream。如果你要监控很多交易对，记得拆成多个连接。
• 字段类型：价格和数量都是字符串，别直接用float解析。我吃过这个亏，0.1+0.2不等于0.3，你懂的。

好了，数据源分析就到这里。下一节我们会动手写一个WebSocket客户端，真正开始采集Tick数据。

---