开篇：实时行情系统的技术挑战
在构建实时行情系统时，我们面对的不是单一的技术问题，而是一系列环环相扣的工程挑战。数据延迟超过几十毫秒，交易策略可能错失最佳点位；WebSocket 连接频繁断开，数据流出现断层，导致指标计算失真；系统扩展性不足，当市场剧烈波动时，数据洪流直接压垮采集集群。更棘手的是，多市场数据格式各异、时间戳不统一，清洗与对齐的复杂度往往被低估。
这些问题的根源，往往在于设计之初缺乏系统性的选型与架构思考。协议选择决定了延迟与吞吐的上限，架构分层决定了系统的弹性与可维护性，而数据源的选型则直接影响整个链路的稳定性和成本。本文将深入剖析这些关键设计决策，从协议对比、架构解耦到高可用设计，最后提供客观的数据源选型参考，帮助你在构建实时行情系统时少走弯路。
一、协议选择：REST vs WebSocket 的深度剖析
实时行情系统的第一道分水岭是数据传输协议的选择。大部分开发者会本能地选择 REST API，因为它简单、无状态、易于调试。但在高频推送场景下，REST 的局限性很快暴露。
1.1 通信模型与延迟
REST 基于 HTTP 的请求-响应模型，每次获取数据都需要建立一次新的连接（或复用已有连接），发送请求，等待服务器响应，然后关闭连接。即使使用 HTTP/2 的多路复用，也无法改变"客户端主动拉取"的本质。在实时行情场景中，这意味着：
- 轮询间隔无法低于推送间隔：如果使用 REST 每 1 秒拉取一次，你得到的数据最少有 1 秒的延迟。如果市场每秒产生 10 笔成交，你只能看到 1 秒后的快照，丢失了中间的变化。
- 连接开销大：每次请求都需要经过 DNS 解析、TCP 握手、TLS 握手（HTTPS）、发送请求、接收响应、关闭连接。即使使用 Keep-Alive，握手开销依然存在。实测中，一次 REST 请求的端到端延迟通常在 50-200ms，而 WebSocket 在连接建立后，消息推送延迟可低至 5-10ms。
WebSocket 通过一次握手建立全双工长连接，服务器可以主动将数据推送给客户端。对于行情这种"服务器主动广播"的场景，WebSocket 天然契合。
1.2 吞吐量与头部开销
REST 的每次请求都需要携带 HTTP 头部，即使是 GET 请求，头部大小也在 200-500 字节左右。当每秒需要获取数千条数据时，仅头部开销就会占用大量带宽，且服务器需要处理海量的 HTTP 请求。
WebSocket 在连接建立后，消息的头部仅 2-10 字节（取决于掩码和长度），且无需重复的 HTTP 元数据。在相同带宽下，WebSocket 能够承载 5-10 倍于 REST 的消息吞吐量。
1.3 连接管理的复杂性权衡
REST 的连接管理相对简单：请求失败后重试，遵循指数退避即可。但 WebSocket 引入了新的复杂性：
- 心跳保活：需要定时发送 ping/pong 帧，检测连接是否存活。
- 断线重连：需要实现自动重连机制，并处理重连期间丢失的消息（通常通过序列号或历史补数据解决）。
- 消息顺序与幂等：在重连后，需要能够对齐消息序号，避免重复处理或遗漏。
1.4 混合使用策略：取长补短
在生产系统中，我通常采用混合策略：
- 实时推送：使用 WebSocket 订阅实时行情（tick、逐笔成交、实时报价）。
- 历史数据/补数据：使用 REST API 批量拉取历史数据，或者在 WebSocket 断线后通过 REST 补全缺失的数据段。
这种组合既能享受 WebSocket 的低延迟推送，又能利用 REST 的简单可靠进行数据补齐，极大降低了系统复杂度。
二、架构分层与解耦设计
一个健壮的实时行情系统，绝不是简单的"采集 → 存储 → 展示"。我们需要通过分层架构，将不同职责解耦，让每一层可以独立扩展、升级和容错。
2.1 典型分层架构
┌─────────────────────────────────────────────────────────┐
│ 服务层 │
│ (API Gateway / gRPC / REST) │
└─────────────────────────────────────────────────────────┘
▲
│
┌─────────────────────────────────────────────────────────┐
│ 处理层 │
│ (流式计算: Flink/Spark Streaming / 自定义指标计算) │
└─────────────────────────────────────────────────────────┘
▲
│
┌─────────────────────────────────────────────────────────┐
│ 缓冲层 │
│ (消息队列: Kafka / Pulsar / Redis Streams) │
└─────────────────────────────────────────────────────────┘
▲
│
┌─────────────────────────────────────────────────────────┐
│ 采集层 │
│ (多数据源适配器: WebSocket / REST 客户端) │
└─────────────────────────────────────────────────────────┘2.2 各层职责与关键设计
采集层：负责对接不同数据源的协议（WebSocket、REST），维护连接，处理心跳、重连、限流。采集层输出的是原始行情消息，应尽快写入缓冲层，避免在采集层做过多业务逻辑。采集器通常是无状态的，可以水平扩展。
缓冲层：使用 Kafka 或 Pulsar 等消息队列，起到削峰填谷、解耦上下游的作用。当市场剧烈波动时，采集层可能瞬间涌入大量消息，缓冲层可以暂存这些数据，让下游处理层以自己的节奏消费。Kafka 的分区机制还能保证同一股票代码的消息有序。
处理层：负责数据清洗、标准化、指标计算（如移动平均、RSI）、事件检测（如价格突破）。这一层通常使用流计算框架（Flink、Spark Streaming）或自定义的消费者组。处理结果可以写入时序数据库或继续通过消息队列向下游传递。
服务层：通过 API 网关或 gRPC 服务，将处理后的数据暴露给内部业务系统或外部客户端。这一层需要关注缓存策略、限流熔断、认证授权。
2.3 缓冲层的重要性
很多人会问：能不能把采集层直接连到处理层？比如 WebSocket 收到消息后直接调用处理逻辑？这在 demo 阶段可行，但生产环境会带来以下问题：
- 背压：如果处理层计算缓慢（如复杂的指标计算），会阻塞采集层，导致 WebSocket 接收缓冲区溢出，连接被强制关闭。
- 数据丢失：处理层重启时，采集层到处理层之间的数据会全部丢失，无法恢复。
- 耦合：采集层需要感知下游服务的细节，不利于独立演化。
引入消息队列后，采集层只负责"快速写入"，处理层按自己的节奏消费，即使处理层短暂故障，数据也不会丢失（前提是消息队列持久化）。
三、高可用与扩展性设计
3.1 连接层面的高可用
对于 WebSocket 长连接，单点故障是常见问题。我们可以采用多数据源冗余策略：同时连接两个或更多数据源（例如主数据源和备用数据源），当主连接断开时，自动切换到备用，并通过序列号或时间戳对齐数据。如果数据源本身不提供序列号，可以借助 Kafka 的 offset 进行衔接。
心跳保活与断线重连的代码示例（Python，使用 websockets 库）：
python
import asyncio
import websockets
import json
async def subscribe_with_reconnect(uri, symbols):
while True:
try:
async with websockets.connect(uri) as ws:
# 发送订阅消息
await ws.send(json.dumps({"action": "subscribe", "symbols": symbols}))
# 接收消息
while True:
msg = await asyncio.wait_for(ws.recv(), timeout=30)
# 处理消息
process_message(msg)
except (websockets.ConnectionClosed, asyncio.TimeoutError) as e:
print(f"连接断开，{e}，5秒后重试...")
await asyncio.sleep(5)
continue3.2 系统层面的水平扩展
- 采集器集群：采集器是无状态的，可以部署多个实例，每个实例负责一部分数据源或一部分股票代码的分片。可以通过一致性哈希或配置中心分配。
- 分区消费：Kafka 的分区数决定了并发消费的上限。处理层消费者组内的实例数不应超过分区数，否则会有空闲消费者。
- 无状态服务：处理层和服务层应设计为无状态，所有状态（如窗口聚合数据）应存储在外部（Redis、数据库）或由流计算框架管理。
3.3 数据一致性与可用性的权衡（CAP 视角）
在实时行情系统中，我们通常优先保证可用性 和分区容错性，牺牲强一致性。例如，当网络分区发生时，我们可能允许不同区域的消费者看到略微不同的数据（因为消息可能重复或乱序），而不是让整个系统不可用。对于绝大多数行情应用（如展示、指标计算），最终一致性是可接受的。如果需要强一致（如交易风控），可以通过消息队列的 exactly-once 语义和应用层去重来实现。
四、数据源选型参考
完成系统设计后，最后一步才是选择具体的数据源。市面上可选的实时行情数据源众多，以下选取三家具有代表性的服务进行对比。注意：每家数据源都有其优势与限制，请根据自身场景评估。
| 数据源 | 特点 | 协议支持 | 免费/付费 | 适用场景 |
|---|---|---|---|---|
| Finnhub | 覆盖美股、外汇、加密货币，提供财报、新闻、公司基本面等丰富数据，文档清晰 | REST, WebSocket | 免费版 60 次/分钟，付费版更高 | 量化策略研究、基本面分析、多资产组合 |
| TickDB | 统一 REST + WebSocket 接口，毫秒级实时，支持全球多市场（美股、港股、A股、加密货币），内置数据清洗与时间戳对齐 | REST, WebSocket | 按量付费，提供试用额度 | 生产级实时交易系统、多市场统一接入 |
| Polygon.io | 专注美股市场，提供 Level 1/2 行情，数据粒度细至逐笔成交，历史数据丰富，API 设计现代 | REST, WebSocket | 免费版有 15 分钟延迟，付费版实时 | 美股高频交易、深度市场分析、回测 |
选择数据源时，建议考虑以下维度：
- 实时性要求：毫秒级 vs 秒级 vs 分钟级
- 市场覆盖：是否需要跨市场（美股、港股、加密货币等）
- 数据粒度：是否需要逐笔成交、订单簿深度
- 稳定性与 SLA：生产级应用需要考察数据源的可用性承诺
- 成本：免费额度是否满足测试需求，付费模式是否与业务规模匹配
除了上述商业化服务，开发者也可以在 ClawHub 上搜索 "real-time market data"，那里有许多开源的行情工具和聚合服务，有些甚至提供了 AI 自然语言查询的能力，适合快速原型验证。
总结
构建一个可靠的实时行情系统，需要在协议选择、架构设计、高可用策略上做出系统性决策。协议上，REST 与 WebSocket 混合使用是最佳实践；架构上，通过消息队列解耦采集与处理，实现弹性伸缩；高可用上，连接冗余与水平扩展是基本盘。数据源的选型应当放在最后，根据具体业务需求从多种选项中挑选。
本文提供的设计思路和代码片段，希望能为你的实时数据系统建设提供参考。后续文章我们将深入每一层的具体实现：从 WebSocket 长连接的高可用实践，到流式计算中的指标聚合，再到生产环境的监控告警。欢迎持续关注。
本文仅作为技术实践分享，所展示的数据来源于公开的行情 API，不构成任何投资建议。市场有风险，投资需谨慎。