如果 WebSocket 断开了，交易所一般怎么处理行情和订单同步补偿？_mbedtls长连接断网后需要重新连接吗-CSDN博客

本文链接：https://blog.csdn.net/qq_41893505/article/details/147573966

在真实币圈交易中，WebSocket 断开是很常见的，特别是：

网络波动
客户端宕机
服务器推送压力大导致踢连接

所以，交易所必须提供一套补偿机制，来保证行情数据（比如盘口）和订单数据（比如挂单、成交、撤单）能够补齐、同步上来。

下面给你系统讲一下，币圈主流交易所（像币安、OKX、火币）都是怎么处理这个问题的。

1.通常的补偿机制思路

▶ 先断开识别：

客户端如果发现WebSocket断了，需要马上重新连接（重连机制一般自动做）。
连接上后，客户端必须主动拉取一份最新的快照（snapshot）数据。

▶ 补快照+重放增量：

客户端拿到最新快照，比如订单簿、自己的挂单列表。
再用快照之后发生的WebSocket增量更新（diff）数据，把本地状态补到最新。

这就是快照（snapshot）+增量（diff）同步机制。

2.举个实际例子（以币安为例）

假设你在币安通过WebSocket订阅了某个交易对的深度行情（比如BTC/USDT的盘口），订阅的是depthUpdate推送。

正常推送时

WebSocket每秒推送多条 depthUpdate 增量消息（如买单挂了/卖单撤了）。
每条增量消息里面有一个连续递增的 u（update id）。

你的客户端应该根据 u，一条一条地应用这些变化到本地的订单簿上。

如果断了，怎么办？

币安官方给的标准流程是这样的：

① 重新连接WebSocket

断线重连后，你不能直接信任新推送的增量消息。
因为中间有一段断开的消息流，可能漏了。

② 拉取一个完整的快照（通过HTTP接口）

用HTTP API，拉取完整深度快照（比如最近500条盘口挂单信息）。
这个快照接口是专门提供的，比如 /api/v3/depth?symbol=BTCUSDT&limit=1000。

③ 衔接快照和WebSocket流

HTTP快照里有一个 lastUpdateId 字段，告诉你这是到哪个位置的深度数据。
WebSocket收到的增量消息的 U 和 u（first update id / final update id）可以对齐快照。
应用所有 u > lastUpdateId 的WebSocket消息，补上中间断掉的部分。

④ 补齐同步

当本地盘口跟服务器状态一致时，继续实时应用后续WebSocket推送。

这样即使WebSocket断开了，也能把丢失期间的盘口变化补回来，保证本地是正确的、同步的。

3. 订单系统也是同样道理

如果你订阅的是自己账户的订单更新流（account/order update stream），比如：

成交通知
撤单通知
挂单失败通知

一旦WebSocket断了，一样的：

重连后，重新通过REST API拉取自己最新的活跃订单列表、成交记录。
补充丢失的那一段交易数据。

这样才能保证：你本地看到的订单状态是最新的，不漏单、不错单。

4. 为什么要这样设计？

原因很简单：

WebSocket断开是常态，不是异常（网络、服务器限流都会导致短时间断开）。
TCP虽然保证消息顺序和可靠传输，但连接断开后，中间的消息就可能丢失。
补快照是最保险的方法，避免由于漏了一条关键消息（比如成交通知）而导致严重后果（比如资金账不对）。

🔥 总结一下

步骤	处理方法
发现断开	立即重连WebSocket
补拉快照	用HTTP API拉最新快照（订单簿或账户信息）
衔接增量	应用快照后收到的WebSocket增量消息
补齐同步	本地数据和服务器一致后继续实时推送

✅ 这样就算WebSocket断了，也能完整同步，不漏数据。
✅ 这是币圈交易所设计稳定跟单系统、做市系统时必须要做的防护措施。

怎么通过设置 WebSocket 心跳（Ping/Pong机制）+ Session复用，来减少断连和丢单的风险？

1. WebSocket 心跳（Ping/Pong机制）是什么？

在WebSocket协议里，心跳是指：

客户端（或者服务器）定期发送一个Ping帧
对方收到后要立即回复一个Pong帧

这样双方可以确认：

TCP连接是不是还活着
网络链路是不是通的
如果几次Ping没有Pong，就可以判定连接已经断了（即使TCP本身可能没立刻感知到）

▶ 正常情况下，币圈交易所都会：

要求客户端每隔 N秒主动发Ping
或者交易所服务器主动定期给你发Ping，你收到了就回Pong

如果心跳超时（比如超过3次Ping没收到Pong），服务器就会主动断开连接，客户端也应该重连。

2. 为什么心跳重要？

因为TCP连接如果中断了，应用层不一定立刻知道（特别是 NAT、防火墙、路由器有问题时）。

如果不发心跳，可能连接早就挂了，你还以为是连着的，结果消息一直丢。
发心跳可以快速检测到假死连接，及时重连，避免交易漏单！

3. 什么是 Session 复用？

Session复用，也叫连接恢复（session resume），是指：

你WebSocket断开后，重新连接时，不用从头订阅所有内容。
而是带上上次会话的Session ID或者Token，告诉服务器：“我是之前那条连接的继续者”。
服务器就可以把丢失期间的消息补给你，而不是重新发全量数据。

▶ 币圈一些大所（比如Binance、OKX）在交易接口中支持：

连接时可以传 listenKey 或 sessionId
如果在有效期内（比如30分钟、1小时），可以直接恢复上次的订阅状态
避免重新建立大量频道/订阅，减少恢复时间，降低丢单风险。

4. 实战场景总结：怎么做才能减少断连和丢单？

✅ 设置心跳

客户端定时（比如15秒一次）主动发WebSocket Ping帧
收到服务器Ping帧，马上回复Pong帧
监控心跳超时，超时就立刻断开并重连

✅ 合理的Reconnect策略

检测断开后，快速重连
尝试指数退避（第一次重连间隔短，后面逐步拉长），避免过载服务器

✅ 支持Session恢复（如果交易所支持）

连接时带上 listenKey / sessionId
如果是自动续期机制（比如Binance listenKey每30分钟要续一次），定时用HTTP接口去续期
恢复连接时用老Session，避免重新拉快照/重新订阅

✅ 必要时，补拉快照

如果Session恢复失败（比如listenKey超时失效），就必须走“HTTP拉快照+增量补充”的流程（之前讲过）

5. 更专业一点：WebSocket心跳设计示意（伪代码）

// 定时发送Ping心跳
ScheduledExecutorService heartbeatScheduler = Executors.newScheduledThreadPool(1);
heartbeatScheduler.scheduleAtFixedRate(() -> {
    if (webSocketSession.isOpen()) {
        webSocketSession.sendPing(ByteBuffer.wrap(new byte[]{0x9}));
    }
}, 0, 15, TimeUnit.SECONDS);

// 监听Pong响应
webSocketSession.setPongMessageHandler(pongMessage -> {
    lastPongTimestamp = System.currentTimeMillis();
});

// 定时检查Pong响应
ScheduledExecutorService checkScheduler = Executors.newScheduledThreadPool(1);
checkScheduler.scheduleAtFixedRate(() -> {
    if (System.currentTimeMillis() - lastPongTimestamp > 60000) {
        webSocketSession.close();  // 认为连接异常，主动断开
        reconnect();               // 触发重连
    }
}, 0, 30, TimeUnit.SECONDS);

（当然，生产环境下代码还要加异常处理、重试控制。）

🔥 总结一张大表：

技术	作用	目的
WebSocket Ping/Pong心跳	保活检测，及时发现假死连接	防止TCP挂了还傻等，快速重连
Session复用（Resume）	重连时恢复上次订阅状态	避免全量重新订阅、减少数据丢失
断线后自动补快照	彻底补齐期间丢失的消息	保证订单、行情状态100%同步

所以，一个专业级跟单系统或交易系统，心跳+Session管理+断线重连补偿，这些必须都有，否则一旦市场波动大，掉线+漏单就是灾难。

断线重连后如何恢复订单簿。

在实际的交易系统中，HTTP拉取快照 + WebSocket增量补充是一种非常高效的方式来实现恢复内存订单簿的操作。

问题背景：为什么需要恢复订单簿？

在交易所系统中，常常发生一些不可避免的网络波动、客户端重启或断线等情况。
一旦断开与交易所的连接，内存中的订单簿会丢失，此时需要从可靠的来源重新同步订单簿状态。

通常来说，恢复订单簿有两种方式：

拉取订单簿的快照（HTTP请求）
通过WebSocket增量数据补充（实时推送）

组合方案：HTTP拉取快照 + WebSocket增量补充

具体流程：

1. 断线重连后，首先通过 HTTP 请求拉取最新的订单簿快照

步骤：
1. 客户端在重新连接后，首先通过HTTP接口向交易所请求最新的订单簿快照数据（比如获取/orderbook接口的数据）。
2. 该接口通常返回的是当前的完整订单簿状态，包括最优买卖价格、挂单数量等，格式类似：
```
{
  "symbol": "BTC/USDT",
  "timestamp": "2025-04-28T12:00:00Z",
  "bids": [
    [64000, 1.25],
    [63999.5, 0.8],
    ...
  ],
  "asks": [
    [64001, 2.1],
    [64001.5, 0.9],
    ...
  ]
}
```
这里的bids是买盘挂单，asks是卖盘挂单。
作用：这一步将恢复最新的订单簿状态，确保你的系统内存中有一个准确的、完整的订单簿快照。

2. 然后，通过 WebSocket 监听增量数据来进行实时补充

步骤：
1. 在拉取完完整的订单簿快照后，客户端继续通过WebSocket连接监听来自交易所的实时增量数据。
2. 增量数据通常是部分订单簿的更新（比如某个价格的挂单量变化，新的挂单，成交的订单等），格式可能类似：
```
{
  "event": "order_book_update",
  "symbol": "BTC/USDT",
  "bids": [
    [64001, 1.0]  // 买盘更新
  ],
  "asks": [
    [64001.5, 1.5]  // 卖盘更新
  ],
  "timestamp": "2025-04-28T12:01:00Z"
}
```
作用：WebSocket推送的数据将补充在拉取的快照基础上进行增量更新，保持订单簿的实时性。这样就能确保你保持与交易所一致的、实时的订单簿数据，而不需要每次都完整拉取。

3. 补充细节：拉取快照与增量同步策略

为了确保客户端恢复后的订单簿数据尽可能精确，HTTP快照和WebSocket增量补充需要有一定的同步机制：

增量一致性：增量数据通常由交易所保证顺序一致性。即：假设你收到一个快照和随后的多个增量数据，它们应该是按时间顺序递增的。
- 比如，断线重连后快照时间是2025-04-28T12:00:00Z，那么随后通过WebSocket接收的更新应该是从这个时间点开始的数据。
防止丢单：在一些极端的网络条件下（例如大规模的行情波动），WebSocket可能会发生数据丢失。为了防止丢单，交易所通常会提供补发机制：
- 比如，WebSocket连接断开后，恢复连接时，交易所会从某个时间点重新发送增量数据，或者提供一个增量数据的序列号，确保客户端从上次断开后能获取到所有丢失的更新。
快照与增量数据的时间窗口：一般来说，交易所的WebSocket增量数据是基于快照后的最新时间进行推送的。所以，快照拉取后，客户端通过WebSocket获得的增量数据会基于快照的基础来执行增量更新。

4. 示例流程

假设你是一个做高频跟单系统的客户端，当前在断线后恢复：

你先发出HTTP请求，获取最新的订单簿快照（比如/orderbook?symbol=BTC/USDT），收到一个完整的订单簿：

{
  "symbol": "BTC/USDT",
  "timestamp": "2025-04-28T12:00:00Z",
  "bids": [
    [64000, 1.25],
    [63999.5, 0.8]
  ],
  "asks": [
    [64001, 2.1],
    [64001.5, 0.9]
  ]
}

然后你重新连接WebSocket，开始监听增量更新。假设收到第一个增量更新：

{
  "event": "order_book_update",
  "symbol": "BTC/USDT",
  "bids": [
    [64001, 1.0]  // 买盘更新
  ],
  "asks": [
    [64001.5, 1.5]  // 卖盘更新
  ],
  "timestamp": "2025-04-28T12:01:00Z"
}

你将增量数据应用到本地内存订单簿中，继续监听并处理随后的增量推送。

5. 小结：恢复订单簿的工作流程

步骤	操作	目的
1	通过HTTP请求拉取订单簿快照	获取最新、完整的订单簿状态
2	通过WebSocket增量推送进行实时更新	保持订单簿与交易所状态同步
3	处理增量数据并更新本地内存订单簿	保持内存中订单簿的实时性

🧠 总结

通过HTTP拉取完整的订单簿快照 + WebSocket增量数据补充的方式，是交易所客户端在重连后恢复订单簿的高效解决方案。

HTTP拉取快照保证了快速恢复最新订单簿状态，
WebSocket增量补充确保了恢复后数据的实时更新，避免了丢单和延迟。

本地订单簿

“本地的订单簿”，一般不是指数据库，而是指在内存（memory）里维护的一份实时订单簿数据结构。

为什么不是数据库？

数据库操作（比如插入、更新）是很慢的，特别是高频行情推送（几百毫秒一条增量）。
如果每来一条 WebSocket 推送都写数据库，速度跟不上，延迟就大了，本地订单簿会严重滞后。
跟单系统、做市系统、量化系统，对实时性要求极高，毫秒级内存更新是必须的。

所以，本地维护的订单簿，是直接存在内存里的一个对象（通常是高效的数据结构），比如：

红黑树
有序跳表（SkipList）
堆
简单的Map+链表
自定义高效结构

目的是：

来一条增量，马上在内存更新
几乎无延迟（微秒到毫秒级）
查询、匹配、跟单都可以很快

本地订单簿一般怎么设计？

以一个币圈典型的盘口（Depth Book）来说：
通常设计成两棵有序树：

bidBook （买盘挂单）按价格从高到低排序
askBook（卖盘挂单）按价格从低到高排序

每个价格点（price level）下面挂着一堆挂单（数量 volume）。

伪代码示例（Java风格）：

// 买盘，价格高优先
TreeMap<BigDecimal, BigDecimal> bidBook = new TreeMap<>(Collections.reverseOrder());
// 卖盘，价格低优先
TreeMap<BigDecimal, BigDecimal> askBook = new TreeMap<>();

// 处理增量更新
void applyUpdate(OrderBookUpdate update) {
    for (UpdateItem item : update.getBids()) {
        if (item.getQuantity().compareTo(BigDecimal.ZERO) == 0) {
            bidBook.remove(item.getPrice()); // 0数量 => 删除挂单
        } else {
            bidBook.put(item.getPrice(), item.getQuantity()); // 更新/新增挂单
        }
    }
    for (UpdateItem item : update.getAsks()) {
        if (item.getQuantity().compareTo(BigDecimal.ZERO) == 0) {
            askBook.remove(item.getPrice());
        } else {
            askBook.put(item.getPrice(), item.getQuantity());
        }
    }
}

这样每次收到 WebSocket 推送的增量（比如某个价格卖了一笔），只需要在TreeMap里面快速插入、更新、删除就行了，非常快。

那数据库什么时候用呢？

一般会异步、批量地把关键时刻的本地订单簿快照保存到数据库，用来
- 审计
- 出错时回滚
- 断电恢复
也就是说，数据库是用来做持久化备份（snapshot backup），不是实时维护的。

比如可以每分钟、每5秒钟，把当前内存订单簿状态打包成一条记录异步写数据库。

（但绝对不能每条WebSocket增量都操作数据库，不然性能崩了。）

🔥 总结一句话

概念	实现方式
本地订单簿（实时内存版）	维护在内存的数据结构（TreeMap、SkipList、Heap等），毫秒级更新
数据库存储（持久化版）	异步批量保存快照到数据库，只做备份或恢复使用

✅ WebSocket增量更新是直接打到内存订单簿，不是数据库。
✅ 数据库是做定期快照持久化的，断线/故障时可以从快照恢复。

本地订单簿在币圈真实交易系统里，到底怎么控制？

本地订单簿是"流式"、"不断刷新的"内存结构，而且有明确的「控制大小」策略。

✅ 不是无限累积的，而是流式、动态变化的。

具体来说：

1. 订单簿是实时滚动的

撮合系统、交易所推送的本身就是最新的一部分订单簿快照。
每来一个增量（比如挂单、新成交、撤单），就修改本地内存的状态。
成交了、撤销了、0数量了的挂单，就从内存中移除。
这样，内存里只保存当前真实有效的挂单状态。

▶ 也就是说：
挂了就加，
成交了就减，
撤了就删，
数量变了就改。

所以，内存里的订单簿是不断地被刷新、更新的，而不是堆积越来越大的！

2. 本地只保存「前N档」深度（Depth Limit）

比如币圈交易所推送的是100档深度（也就是买卖各100个价格层级），或者500档。
那么在本地，也只需要维护这么多：

买盘最多保存前100个价位
卖盘最多保存前100个价位

再多的远端挂单（比如价格太偏离的挂单）就不需要保存到本地了。
（极端情况下，如果你是做极深盘口分析，比如需要保存上万档，可以按需增加。）

3. 有序数据结构自动控大小

比如用TreeMap（红黑树）或者自定义跳表维护价格顺序，每次来新数据：

如果价格在你关注的价位范围之内（比如最优100档以内），就保留。
如果挂单价格太偏离（比如买单价格远低于市场价，或者卖单价格远高于市场价），直接丢弃或者不存。

▶ 这样，本地内存永远控制在「几百条挂单」以内，非常轻巧。

🔥 举个真实的例子

比如币安BTC/USDT订单簿：

最优买价：64000
最优卖价：64001
买盘前100档价格从 64000 -> 63000（价格越来越低）
卖盘前100档价格从 64001 -> 65000（价格越来越高）

那么本地订单簿维护的就是这几百个价格节点+每个节点对应的挂单量。

如果有挂单在60000的地方，已经超出我们关注范围了，可以选择不存（或者后台存，前台不用管）。

4. 为什么要这么做？

✅ 控制内存开销（每个交易对只用几MB）
✅ 保证更新速度快（内存结构，O(logN)更新复杂度）
✅ 保持数据实时性（行情快速变化时，不至于堆积、阻塞）

否则，如果什么都不丢，价格远端几百万个挂单，加起来可能几十GB内存，那是绝对扛不住的！

🛡️ 总结一下

问题	解决方法
内存不能无限大怎么办？	只保留流动区域的挂单（如Top 100/500档），成交/撤单/0数量自动删除
订单簿是不是流水形式？	是的，实时滚动刷新，增删改，保持当前状态
数据结构怎么选？	有序TreeMap / 跳表，按价格排序快速增删改查
超大行情波动呢？	动态调整内存订单簿大小或开启分层存储（比如活跃区、非活跃区分开）

✅ 本地订单簿是轻量级实时数据结构，绝不是数据库那种持久化表。
✅ 它更像一个**“活的对象”**，不停地呼吸更新！

📚 数据库存的是什么？

数据库里一般不是存的全量实时订单簿数据，而是：

定时在某些固定时间点
对当前内存中的订单簿做一次快照（Snapshot）
只存这个快照的状态到数据库

这样你存的是当时那个时间点的局部视图（snapshot sample），
而不是每一笔挂单变化、成交变化的全部历史。

🛠️ 为什么只存快照，而不是全量变化？

原因非常现实：

问题	影响
实时变化太多（比如BTC一天有几十万笔更新）	如果每笔变化都存，数据库爆了
存储和写入压力太大	盘子大的币对，几秒就有上千次挂单变化
查询效率变低	以后查询订单簿历史特别慢，效率灾难
大部分变化是无意义的微小抖动	没必要为每次微调都存储

所以，实际设计里会选择：

定时存快照（比如每1分钟、5分钟）
或者重大事件时存快照（比如爆仓时、极端行情时）
快照可以只存前N档价格和挂单量（比如买卖各100档）

🧠 快照数据一般长什么样？

一般保存成这样的一条结构：

{
  "symbol": "BTC/USDT",
  "timestamp": "2025-04-28T12:00:00Z",
  "bids": [
    [64000, 1.25],
    [63999.5, 0.8],
    ...
  ],
  "asks": [
    [64001, 2.1],
    [64001.5, 0.9],
    ...
  ]
}

symbol：交易对
timestamp：快照时间
bids：买盘挂单列表（价格+数量）
asks：卖盘挂单列表（价格+数量）

存储格式可以是JSON，压缩存Blob，或者分字段存SQL结构表。

▶ 快照是"一个时间点上订单簿的样子"，
▶ 而不是"每一次挂单变更的细节"！

🔥 小补充：什么情况下会存更多？

如果你是做：

高频交易分析（HFT）
盘口微观结构研究（OrderBook Dynamics）
流动性挖掘
这种情况，可能需要更高频率（比如每秒1次、甚至毫秒级）保存快照。

但即便如此，也不会傻傻地每一条都存，而是压缩存、采样存！

🧹 小结一张表：

内容	是否存入数据库？	备注
每一笔挂单增量更新（u）	❌ 不存	只应用在内存订单簿
固定时间点订单簿快照	✅ 存	存数据库，供审计、回溯
异常事件（极端行情）时的快照	✅ 存	特殊标记，供分析

🎯 一句话总结

数据库存的是"抽样后的快照"，不是"订单簿的全量变动历史"。

✅ 内存维护实时订单簿，快速跟单、交易
✅ 数据库存阶段性快照，用于审计、分析、补偿

归档和删除

✅ 数据库存的订单簿快照数据，不会永远保存不删。
✅ 正常做法是：定期归档 + 历史清理（物理删除）。

1. 快照数据会不会永不删除？

绝大多数交易所、量化平台，快照数据最终是要清理或者归档的。

原因是：

	为什么
数据量太大	订单簿变化极频繁，就算1分钟1个快照，几年下来也是海量数据
成本太高	存储硬盘、备份带宽、查询资源消耗非常大
法规合规要求	金融/加密领域通常只要求保留一定年限（比如2年、5年），而不是永久保存
业务需求变化	很久以前的盘口深度，对实际交易决策帮助很小，保存意义下降

所以一般不会一直堆着不动。

2. 通常怎么处理这些快照数据？

一般有两步：

【第一步】定期归档（Archive）

把老的数据（比如6个月前、1年前的订单簿快照）
转移到冷存储（低频访问的大仓库，比如对象存储S3、冷备份磁带等）
格式可能变更（压缩，比如存成.parquet/.orc/.zip）
仅在需要审计、回溯分析时拉回。

✅ 归档后还能找回来，但不是实时可用的。

【第二步】物理删除（Purge）

设定策略，比如：
- 订单簿快照保留最近1年
- 超过1年的快照在归档后物理删除
直接从数据库/文件系统中彻底清理
节省存储资源，降低运维压力

✅ 删除后的数据，不再占用生产存储空间。

3. 删除、归档策略怎么配置？

常见策略是这样的（示例）：

类型	保存时长	处理方式
热数据（最近1个月）	本地数据库	直接可查询
温数据（1个月 ~ 6个月）	存到归档存储	偶尔需要分析时还原
冷数据（6个月以上）	归档 + 压缩，或删除	特殊审计才恢复

有些交易所遵循的是法律法规，比如：

美国CFTC/NFA要求交易数据至少保留5年
欧盟MiFID II要求部分金融交易数据保留7年
币圈交易所（比较规范的，比如Binance、Coinbase Pro）也通常设3-5年数据保留策略

当然，小型交易所可能会更短（6个月-1年）。

4. 物理删除真的彻底吗？

一般是这样：

数据库里执行DELETE或分区表DROP
文件系统上执行冷数据删除
定期清理备份副本

但合规要求下，一般要保留"删除日志"，证明什么时间清理了什么数据。

（比如MySQL binlog、归档系统日志）

🔥 总结一张表

问题	答案
订单簿快照永不删除吗？	❌ 正常会定期归档+清理
为什么不永远保存？	成本高、合规要求有限年限
快照怎么处理？	热存储 ➔ 归档 ➔ 冷存储 ➔ 删除
删除后还能恢复吗？	已归档的可以恢复，彻底清理就恢复不了