WebSocket实时行情推送API实战：用iTick搭一个盯盘小工具

WebSocket实时行情推送API相比REST轮询有个明显优势：服务端主动推，不用客户端反复发请求去问"有新数据了吗"，既省请求次数又能保证数据到达的及时性。这篇文章用iTick的WebSocket接口实际搭一个简单的盯盘小工具，把整个流程走一遍。

为什么盯盘场景要用WebSocket

假设你要监控100只股票的实时报价，用REST轮询的话，就算每5秒查一次，一分钟也要发出去1200次请求，接口大概率会被限流，而且请求之间的间隔本身就意味着数据不是真正的"实时"。换成WebSocket，建好连接订阅这100只标的之后，有变化服务端就推过来，既省资源又保证时效性。

建立连接

java 复制代码

import io.itick.sdk.Client;

Client client = new Client("your_api_token");
client.setMessageHandler(msg -> {
    System.out.println("收到推送: " + msg);
    // 这里可以接自己的业务逻辑，比如更新界面、触发预警
});
client.setErrorHandler(err -> System.out.println("连接异常: " + err));
client.connectStockWebSocket();

订阅多个标的

java 复制代码

client.sendWebSocketMessage("{\"ac\":\"subscribe\",\"params\":\"AAPL$US,TSLA$US,MSFT$US\",\"types\":\"quote,tick\"}");

types这个参数比较灵活，quote是报价、tick是逐笔成交、depth是十档盘口、kline是K线推送（部分周期的kline推送在高级套餐才开放），根据自己盯盘小工具需要展示的内容来组合就行，不需要的类型不订阅，能省下不必要的流量和处理开销。

断线重连怎么处理

自己写WebSocket客户端最麻烦的地方往往不是建连接，而是处理各种异常情况：网络抖动、服务端主动断开、心跳超时等等。iTick的SDK把这部分逻辑内置好了，默认心跳间隔30秒，断线后按固定间隔自动重试，重连成功后之前订阅的标的会自动恢复订阅，业务代码基本不用感知这个过程，省了很多调式的功夫。

一个小工具的完整逻辑

把上面这些拼起来，一个简单的盯盘小工具大概长这样：连接建立 → 订阅一批标的 → 收到推送后更新本地缓存 → 前端定时读取缓存刷新界面 → 涨跌幅超过阈值触发一个提醒。这套逻辑跑起来之后，整个数据链路基本是"实时"的，从行情产生到界面刷新，中间的延时主要就是网络传输这一段，接口本身的处理速度不是瓶颈。

参考资料

WebSocket接口的完整参数说明和支持的订阅类型，可以查文档：https://docs.itick.org。官网：https://itick.org。Java SDK源码：https://github.com/itick-org/java-sdk。