1. 行情数据源概述：为什么需要聚合行情？

做量化交易，第一件事就是搞定行情数据。

你可能觉得，找个交易所接个WebSocket不就行了？嗯，我刚开始也这么想。但真正跑起来才发现，事情没那么简单。

1.1 为什么需要聚合行情？

说白了，单个交易所的数据不够用。

举个例子。你在Binance看到BTC价格是30000，但OKX上可能是30005，Coinbase上却是29998。哪个才是真实价格？

其实都是真实的。只是不同交易所的流动性、用户群体、撮合机制不一样，导致价格有细微差异。

聚合行情的核心价值在于：

• 价格发现更准确：取多个交易所的加权平均价，比单家更接近真实市场
• 数据容错：某家交易所宕机了，你还有备选
• 套利机会：价差就是利润，但前提是你得同时看到两边
• 流动性聚合：深度不够的交易所，合并起来看就够用了

我在项目中遇到过一件事。有一次我们只接了Binance的数据做策略，结果那天Binance的API突然延迟了3秒。我们的策略以为市场暴跌，疯狂开空单。等数据恢复，已经亏了6位数。嗯，从那以后，我再也不敢只依赖单一数据源了。

1.2 主流交易所API对比

目前做量化，绕不开这三家：Binance、OKX、Coinbase。我个人的经验是，每家都有自己的脾气。

对比维度	Binance	OKX	Coinbase
REST限频	1200次/分钟（权重制）	600次/分钟（权重制）	10次/秒（严格）
WebSocket	稳定，支持多流合并	需要订阅多个频道	单连接限制多
K线历史	最多1000根（可拉长周期）	最多1440根	最多300根
深度数据	支持增量推送	支持增量推送	全量推送为主
文档质量	优秀，社区活跃	良好，中文友好	一般，更新慢

你想想看，如果要做高频策略，Binance的权重制限频其实很灵活。你可以把权重留给深度订阅，减少不必要的REST请求。OKX呢，我习惯用它做辅助数据源，因为它的永续合约数据跟现货价差比较稳定。

Coinbase嘛...说实话，它的API限频太严了。10次/秒，稍微跑个策略就容易触发429。我一般只拿它做价格参考，不用于主力交易。

1.3 各交易所的接入要点

Binance

• WebSocket地址：wss://stream.binance.com:9443/ws
• 订阅格式：btcusdt@trade 或 btcusdt@kline_1m
• 注意：单连接最多订阅1024个流，超出需要拆连接

// 伪代码示例：Binance WebSocket订阅
ws.connect('wss://stream.binance.com:9443/ws')
ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ['btcusdt@trade', 'btcusdt@depth20'],
  id: 1
}))

OKX

• WebSocket地址：wss://ws.okx.com:8443/ws/v5/public
• 订阅格式：需要先登录（模拟盘不需要）
• 注意：OKX的频道名跟其他家不一样，比如K线叫candle1m

Coinbase

• WebSocket地址：wss://ws-feed.pro.coinbase.com
• 订阅格式：需要指定产品ID，如BTC-USD
• 注意：Coinbase的K线数据不是标准的时间戳对齐，需要自己做插值

// Coinbase订阅示例
{
  "type": "subscribe",
  "channels": [
    {
      "name": "ticker",
      "product_ids": ["BTC-USD"]
    }
  ]
}

1.4 聚合架构的核心逻辑

下面这张图是我自己总结的聚合行情架构。说白了，就是三层：接入层、对齐层、输出层。

这张图你看懂了吗？我简单解释一下：

• 接入层：负责跟各家交易所保持连接。这里最坑的是断线重连。我曾经因为没处理好重连逻辑，导致数据断了40分钟才发现。
• 对齐层：这是最核心的。不同交易所的时间戳可能有偏差，你得把它们对齐到同一个时间轴上。我习惯用微秒级的时间戳做对齐。
• 输出层：对外输出统一格式的数据。不管底层接了几家交易所，上层策略看到的都是一样的数据结构。

1.5 选型建议

如果你刚开始做聚合行情，我建议：

1. 主力数据源选Binance：文档好、社区活跃、API稳定
2. 辅助数据源选OKX：合约数据丰富，适合做价差分析
3. Coinbase作为参考：限频太严，不适合高频场景

当然，如果你主要做美股合规交易，Coinbase可能是首选。但做币圈量化，Binance+OKX的组合基本够用了。

---