1、行情数据源探秘：认识交易所API、WebSocket协议与REST接口的差异
做实时行情流处理，第一步就是跟数据源打交道。说白了，你得知道数据从哪来，怎么来，来了之后长什么样。我刚开始接触这块时，也踩过不少坑——比如用REST接口去拉高频行情，结果延迟高得离谱，还被交易所限流封了IP。嗯，今天咱们就把这三个东西掰开揉碎讲清楚。
1.1 交易所API：你与市场的“对话窗口”
每个交易所都会提供一套API，让你能获取行情、下单、查账户。我个人习惯把API理解成“交易所开的一扇门”。门后面是海量的市场数据，但怎么敲门、敲多快，交易所说了算。
常见的交易所API分两类：
- REST API：你发一个HTTP请求，交易所返回一个响应。一问一答，像发微信消息。
- WebSocket API：你连上交易所的服务器，然后数据会主动推给你。像打电话，随时能听到对方说话。
你想想看，如果你要实时监控比特币的价格变化，用REST接口每秒请求一次，跟用WebSocket订阅一个“价格更新”频道，体验完全不一样。前者是你主动去问，后者是交易所主动告诉你。
核心区别一句话总结：REST是“拉”，WebSocket是“推”。实时行情场景下，推比拉香得多。
1.2 REST接口：简单但不够“实时”
REST接口是最常见的。你发一个GET请求到类似 https://api.exchange.com/v1/ticker/btcusdt 的地址，就能拿到当前的最新行情。
举个例子，请求币安的REST接口获取BTC/USDT的最新价：
GET https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT
响应：
{
"symbol": "BTCUSDT",
"price": "67500.00"
}看起来很简单对吧？但问题来了——
- 延迟高：每次请求都要建立TCP连接、发送HTTP头、等待响应。一轮下来几百毫秒就没了。
- 无法实时：你每隔1秒请求一次，那中间这1秒内的价格变化你就错过了。万一行情剧烈波动，你拿到的可能是“过期数据”。
- 容易被限流：交易所通常限制每分钟的请求次数。比如币安REST接口限制1200次/分钟。你想想看，每秒只能请求20次，对于高频场景根本不够用。
我曾经踩过的坑：刚开始做行情采集时，我用REST接口每200ms请求一次，结果跑了不到5分钟，IP就被交易所封了。后来才知道，人家限流是按“权重”算的，不是简单的次数。所以，REST接口只适合做“定时快照”或“非实时查询”，千万别用来做高频行情。
1.3 WebSocket协议：实时行情的“高速公路”
WebSocket跟REST完全不同。它建立一条长连接，然后数据源源不断地从交易所推送到你这边。没有请求-响应的来回折腾，延迟能降到10毫秒以内。
还是以币安为例，用WebSocket订阅BTC/USDT的实时行情：
// 连接WebSocket
wss://stream.binance.com:9443/ws/btcusdt@trade
// 收到推送数据（每成交一笔就推送一次）
{
"e": "trade", // 事件类型
"E": 1620000000000, // 事件时间
"s": "BTCUSDT", // 交易对
"p": "67500.00", // 成交价格
"q": "0.001", // 成交量
"T": 1620000000000 // 成交时间
}看到没？每发生一笔交易，交易所就推一条数据过来。你不需要主动问，数据自己就来了。这才是真正的“实时”。
WebSocket的几个关键特点：
- 全双工通信：客户端和服务器可以同时发消息，不像REST那样一问一答。
- 低延迟：建立连接后，数据推送延迟通常在个位数毫秒。
- 节省带宽：没有HTTP头部开销，只传有效数据。
- 需要心跳维持：连接久了可能会断开，需要定期发ping/pong保活。
我的个人习惯：在生产环境中，我会同时维护多个WebSocket连接，订阅不同的交易对。万一某个连接断了，其他连接还能继续工作。另外，一定要实现自动重连机制——网络波动导致断连是家常便饭。
1.4 REST vs WebSocket：一张表看懂差异
| 对比维度 | REST接口 | WebSocket协议 |
|---|---|---|
| 通信模式 | 请求-响应（一问一答） | 全双工推送（实时推送） |
| 延迟 | 几百毫秒到秒级 | 毫秒级（通常<10ms） |
| 实时性 | 差，取决于轮询频率 | 强，数据产生即推送 |
| 带宽消耗 | 高（每次请求带HTTP头） | 低（只传有效数据） |
| 连接数 | 每次请求新建连接 | 长连接，复用 |
| 适用场景 | 查询历史数据、账户信息 | 实时行情、订单簿更新 |
| 限流风险 | 高（按请求次数限流） | 低（按连接数限流） |
1.5 知识体系：行情数据源的核心逻辑
下面这张图，是我自己总结的行情数据源接入的核心逻辑。你看一眼就能明白整个流程：
1.6 实际项目中的选择策略
你可能会问：那我到底该用哪个？
我的建议是——别二选一，两个都用。我在搭建实时行情系统时，通常这样搭配：
- WebSocket做主数据源：订阅所有需要的交易对，接收实时成交、订单簿、K线更新。
- REST接口做补充：启动时先拉一次全量数据（比如24小时涨跌幅、历史K线），WebSocket断连时用REST兜底查询。
避坑指南：我曾经遇到过WebSocket连接突然断开，重连后中间缺失了5秒的行情数据。后来我加了一个“REST补数据”的逻辑——断连期间用REST接口拉取缺失时间段的成交记录，再回填到流处理系统中。这样数据就不会丢了。
1.7 小结
行情数据源这块，说白了就两个核心点：
- REST接口：简单、通用，但延迟高、不适合实时场景。适合做“快照查询”和“兜底方案”。
- WebSocket协议：实时、高效，是实时行情系统的首选。但需要处理连接管理、心跳保活、自动重连等问题。
嗯，这一章的内容就到这。记住一句话：实时行情，WebSocket是主角，REST是配角。下一章咱们会深入WebSocket的细节，聊聊怎么优雅地管理连接、处理数据。
公众号:蓝海资料掘金营，微信deep3321