数据源与采集：主流交易所API对比
做订单簿数据校验，第一步就是搞清楚数据从哪来。我见过不少团队，一上来就写代码，结果数据源选错了，后面全白干。今天咱们就聊聊主流交易所的API怎么选，以及WebSocket和REST接口到底该怎么用。
三大交易所API概览
目前市场上，Binance、OKX、Coinbase这三家是绕不开的。它们的数据质量、接口稳定性，直接决定了你的校验流程能不能跑通。
| 特性 | Binance | OKX | Coinbase |
|---|---|---|---|
| REST限频 | 1200次/分钟（权重制） | 600次/分钟（权重制） | 10000次/小时（按端点） |
| WebSocket深度 | 5/10/20/50/100/500/1000档 | 1/5/400档（可选增量） | 全量快照+增量更新 |
| 数据格式 | JSON，毫秒时间戳 | JSON，毫秒时间戳 | JSON，纳秒时间戳 |
| 历史数据 | 支持（最多1000条） | 支持（最多500条） | 支持（最多300条） |
你看，Binance的限频最宽松，适合高频校验。OKX的增量更新机制很实用。Coinbase的时间戳精度最高，但限频最严格。
REST接口：什么时候用？
REST接口说白了就是「你问一句，它答一句」。适合做快照校验、历史数据回查。
我个人习惯，在系统启动时先用REST拉一次全量快照。为什么？因为WebSocket刚连上时，数据可能不完整。先拿个基准，后面才好对比。
核心用法：REST接口用于获取订单簿的「基准快照」。
// Binance REST 获取深度数据示例
GET /api/v3/depth?symbol=BTCUSDT&limit=100
// 返回示例
{
"lastUpdateId": 1027024,
"bids": [
["0.0024", "10"], // [价格, 数量]
["0.0023", "20"]
],
"asks": [
["0.0026", "15"],
["0.0027", "5"]
]
}这里要注意，REST接口返回的lastUpdateId很重要。它是你后续校验WebSocket数据的关键锚点。我曾经因为没保存这个ID，导致数据对不上，排查了整整一天。
WebSocket接口：实时数据的命脉
WebSocket是长连接，数据主动推给你。适合做实时校验、增量更新。
你想想看，如果每秒都在变化，用REST轮询根本来不及。WebSocket才是正解。
我的建议：WebSocket只用来接收增量更新，不要依赖它做全量快照。增量数据容易丢包，必须配合REST定期校准。
// Binance WebSocket 深度流示例
// 订阅地址: wss://stream.binance.com:9443/ws/btcusdt@depth
// 接收到的增量数据
{
"e": "depthUpdate", // 事件类型
"E": 123456789, // 事件时间
"s": "BTCUSDT", // 交易对
"U": 157, // 第一更新ID
"u": 160, // 最后更新ID
"b": [ // 买单变更
["0.0024", "10"]
],
"a": [ // 卖单变更
["0.0026", "15"]
]
}嗯，这里要注意U和u这两个字段。它们表示这次更新覆盖的ID范围。你本地维护的订单簿，必须根据这个范围来更新。如果中间有断档，数据就乱了。
如何选择？我的实战经验
说实话，没有完美的方案。我做过几个项目，踩过不少坑，总结下来就三条：
- 数据校验场景：用REST做基准，WebSocket做实时校验。两者结合，缺一不可。
- 高频交易场景：优先选Binance，它的WebSocket深度档位最多，延迟最低。
- 合规要求高的场景：Coinbase更靠谱，它的时间戳精度高，审计时好追溯。
避坑指南：我曾经在OKX上遇到WebSocket断连后重连，增量数据丢失的问题。后来我加了一个定时任务，每5分钟用REST拉一次全量快照做校准。这个习惯一直保留到现在。
核心逻辑流程图
下面这张图，是我自己总结的数据采集与校验流程。你看一眼就明白了：
这张图的核心逻辑很简单：REST拿基准，WebSocket收增量，本地合并后做校验。每一步都要记录序列号，方便回溯。
接口选择的几个关键点
最后，我再说几个容易忽略的细节：
- 时间戳对齐：不同交易所的时间戳精度不一样。Binance是毫秒，Coinbase是纳秒。校验时一定要统一单位，不然差之毫厘谬以千里。
- 限频策略：别把REST接口当WebSocket用。我见过有人每秒轮询一次，结果被交易所封了IP。合理设置间隔，比如每5-10秒拉一次快照就够了。
- 断连重连：WebSocket一定会断。写代码时一定要实现自动重连，并且重连后要重新拉一次全量快照。
小技巧：我习惯在本地维护一个「数据健康度」指标。如果连续3次WebSocket增量更新与REST快照对不上，就触发告警。这个机制帮我发现过好几次数据异常。
好了，数据源这块就聊到这。记住一句话：没有完美的接口，只有合适的组合。REST做基准，WebSocket做实时，两者配合才能保证数据质量。