auto_trade_sys/docs/common/WebSocket共用与限频评估.md

WebSocket 共用与币安限频评估

一、币安合约 WS 限制（摘要）

• Base URL：wss://fstream.binance.com
• 单 stream：/ws/<streamName>
• 组合 stream：/stream?streams=/<streamName1>/<streamName2>/...
• 单连接最多订阅：1024 个 Streams
• 订阅限速：每秒最多 10 条订阅消息，超限会断连；反复断连的 IP 可能被屏蔽
• 连接有效期：单连接不超过 24 小时，需断线重连
• Ping/Pong：服务端约 3 分钟发 ping，客户端需在 10 分钟内回复 pong（当前 aiohttp heartbeat 已满足）

---

二、当前系统 WS 使用方式（按进程）

当前为 一进程一账户（如 supervisor 按 ATS_ACCOUNT_ID 起多个 trading_system 进程），每个进程内：

用途	连接数/进程	订阅内容	是否公开	可否多账户共用
UserDataStream	1	listenKey（订单/持仓/余额）	否（需 listenKey）	否，每账户必须独立
Ticker24hStream	1	!ticker@arr（全市场 24h ticker）	是	可共用，全市场一份即可
BookTickerStream	1	!bookTicker（全市场最优买卖）	是	可共用，全市场一份即可
KlineStream	1	/stream + 动态 SUBSCRIBE：<symbol>@kline_<interval>	是	可共用，按需订阅，单连接 ≤1024 streams
持仓价格监控（position_manager）	每持仓 1 条	每连接 /ws/<symbol>@ticker	是	可共用，可合并为一条组合流

即：每账户 4 条固定连接 + 持仓数个单独连接。

---

三、多账户时的连接与订阅量（当前架构）

设账户数为 N，单账户最大持仓数为 M（如 10）：

• UserDataStream：N 条（每账户 1，不能省）
• Ticker24hStream：N 条 → 若共用为 1 条
• BookTickerStream：N 条 → 若共用为 1 条
• KlineStream：N 条，每连接动态订阅若干 symbol@kline_interval → 若共用为 1 条，总 streams 数为「所有账户用到的 (symbol, interval) 并集」
• 持仓监控：N × M 条（每持仓一个 /ws/<symbol>@ticker）→ 若合并为一条组合流，为 1 条连接，streams 数为「所有账户持仓的 symbol 并集」，且 ≤1024

当前是否超限：

• 1024 streams/连接：单条 KlineStream 当前按「扫描/策略用到的 symbol×interval」订阅，通常几十～小几百级，远低于 1024；持仓监控若合并为一条组合流，symbol 数一般也远小于 1024。正常使用不会超。
• 10 条订阅/秒：KlineStream 在扫描时可能对多个 symbol×interval 连续调用 subscribe，若并发高会短时间多发订阅消息，有超过 10 条/秒的风险，存在被断连、进而 IP 被限的风险。需要限速（见下文实现）。

---

四、可共用的流与建议

1. 强烈建议共用（公开、全市场一份即可）

• Ticker24hStream（!ticker@arr）

  • 全市场 24h 行情，与账户无关。
  • 建议：单机多进程时，可由一个「行情进程」或主进程单独起 1 条连接，写入 Redis/共享缓存，其他进程只读缓存；或若已用 Redis 等共享缓存，仅一个进程负责拉 WS 并更新缓存。

• BookTickerStream（!bookTicker）

  • 全市场最优买卖，与账户无关。
  • 建议：同上，共用 1 条连接 + 共享缓存。

2. 建议共用（减少连接与 stream 总数）

• KlineStream（<symbol>@kline_<interval>）

  • 按 (symbol, interval) 动态订阅，单连接最多 1024 streams。
  • 多账户共用 1 条连接时，订阅集合为「各账户用到的 (symbol, interval) 并集」，通常仍远小于 1024。
  • 建议：单机多进程时，可只在一个进程内起 KlineStream，其他进程通过 Redis/共享内存读 K 线缓存；或部署一个共享「K 线 WS 服务」供多进程使用。

• 持仓监控（<symbol>@ticker）

  • 当前实现为「每持仓 1 条 /ws/<symbol>@ticker」，多账户×多持仓会变成 N×M 条连接。
  • 建议：改为一条组合流：/stream?streams=s1@ticker/s2@ticker/...，把所有需要监控的 symbol 放在一起，总 symbol 数 <1024 即可。多账户可共用这一条连接（订阅「所有账户持仓 symbol 的并集」），每个账户只消费自己关心的 symbol 即可。

3. 不能共用

• UserDataStream（listenKey）
  • 与账户绑定，每账户独立 listenKey、独立连接。必须每账户 1 条连接。

---

五、限频与实现建议

1. 订阅消息 ≤10 条/秒（必须遵守）

• KlineStream 在 subscribe(symbol, interval) 时向同一连接发送 SUBSCRIBE。
• 若扫描阶段并发请求多个 symbol×interval，会在短时间连续发送多条订阅，容易超过 10 条/秒。
• 实现：在 KlineStream 内做订阅限速：例如维护「最近 1 秒内已发送的订阅次数」，若已达 10 次则 sleep 到「满 1 秒」后再发；或批量排队，按每秒最多 8～10 条发送。
• 已在代码中为 KlineStream 增加限速逻辑（见下节）。

2. 单连接 1024 streams

• 当前 KlineStream 与持仓监控的 stream 数量均远低于 1024，只需在后续若「预订阅」大量 symbol×interval 或大量持仓时，确保单连接订阅数 ≤1024 即可（可做订阅数统计与上限检查）。

3. 连接 24 小时

• 现有各 WS 均有断线重连，满足「不超过 24 小时」的文档要求；保持即可。

---

六、结论与风险

项目	当前是否可能超限	说明
单连接 1024 streams	否	当前 K 线与持仓监控订阅量远低于 1024
10 条订阅/秒	是（有风险）	KlineStream 扫描时可能短时大量 subscribe，已加限速
连接数	否	多账户时连接数线性增长，共用后可显著下降
24h / Ping-Pong	否	已重连 + heartbeat

已实现：

1. KlineStream 订阅限速：发送 SUBSCRIBE 时控制在 ≤10 条/秒。
2. 多进程/多账户共用 Ticker24h、BookTicker、KlineStream：
   • 使用 Redis 选主（market_ws_leader）：仅 Leader 进程建立上述三条 WS 连接并写入 Redis。
   • 非 Leader 进程不建这三条连接，通过 Redis 刷新任务（Ticker24h/BookTicker 每 2 秒从 Redis 拉取）和 get_klines 时读 Redis 获取数据。
   • 配置项 USE_SHARED_MARKET_WS（默认 true）：有 Redis 时启用共用；关闭则每进程独立建连接。
3. 持仓监控：仍为每进程按持仓建多条 /ws/<symbol>@ticker；后续可改为单连接组合流并共享（未实现）。