我主做的港股日内策略需要同时覆盖全部港股通标的，光是成分股就超过500只。量化初期我写过一个REST轮询脚本，跑完全量行情普遍需要90秒以上，日内回测时发现信号产生时间与实际行情触发时间存在明显偏离，根源就在于数据到达存在系统性滞后。
后来我把行情接收模块重构为基于WebSocket的推送架构，全市场tick从产生到被我的策略主程序消费，延迟控制在50毫秒以内。对于做tick级因子和盘口异动策略的个人量化交易者而言，这意味着信号质量得到了根本性提升。
轮询的天花板与推送的优势
轮询模型下，数据延迟=轮询周期/2 + 网络往返时间，标的越多延迟越大。同时，接口限流会进一步拉长有效更新时间。WebSocket推送则把模型倒转：服务端在成交发生的瞬间即向订阅客户端广播，单个连接可承载数百个标的的订阅，无需轮询周期。实践中我选用了AllTick的行情推送接口，港股通全量标的都能通过WebSocket实时订阅，文档完善，适合量化工作流集成。
批量行情抓取的系统设计
我的数据系统由四个功能层构成：
- 标的同步层：定期更新港股通成分股列表，代码标准化为
.HK格式。 - 订阅管理层：按接口限制分批发送订阅帧，连接建立后维持心跳保活。
- 数据解析层：对推送的JSON进行实时解析，提取symbol、price、volume、turnover、time等量化所需字段。
- 缓存与存储层：解析后的数据放入无锁队列，消费者线程批量写入数据库，供策略引擎和回测系统调用。
| 层级 | 功能 | 要点 |
|---|---|---|
| 标的同步 | 维护最新港股通成分股列表 | 后缀处理与停牌过滤 |
| 订阅管理 | WebSocket分批订阅与保活 | 单次订阅数量按接口规范 |
| 数据解析 | JSON转结构化tick | 字段动态兼容，防止异常中断 |
| 缓存存储 | 队列缓冲，批量入库 | 解耦接收与写入，降低延迟 |
核心代码片段
import websocket
import json
def on_message(ws, message):
# 实时解析港股通tick数据
data = json.loads(message)
for tick in data.get("ticks", []):
# 实际量化环境中将数据压入消息队列
print(f"{tick['symbol']} 最新价: {tick['price']} 成交量: {tick['volume']}")
def on_open(ws):
# 批量订阅目标标的
tickers = ["00700.HK", "09988.HK", "02628.HK"]
ws.send(json.dumps({"action": "subscribe", "symbols": tickers}))
ws = websocket.WebSocketApp("wss://api.alltick.co/stock/ws",
on_message=on_message,
on_open=on_open)
ws.run_forever()
从数据痛点到策略增益
重构后最大的改变是tick时间戳与策略触发时间的对齐程度大幅提高，我基于实时tick构建的买卖盘口强度因子和异常放量信号不再滞后。同时，稳定的数据流让我得以安心将更多时间花在因子研究与参数优化上，而不是像过去那样反复核对数据是否掉线。对于个人量化交易者来说，一条可靠的全量行情管线就是策略迭代的底气。
