3.7 KiB
3.7 KiB
WebSocket 迁移方案
当前问题分析
REST API 调用频率
- 价格查询 (
get_ticker_24h): 每个交易对每次扫描都调用 - K线数据 (
get_klines): 技术分析时频繁调用 - 账户余额 (
get_account_balance): 风险检查时调用 - 持仓信息 (
get_open_positions): 持仓管理时调用
已实现的优化
- ✅ 批量获取所有ticker (
get_all_tickers_24h) - ✅ API请求限流 (
_rate_limited_request) - ✅ 并发控制 (
asyncio.Semaphore) - ✅ Unicorn WebSocket 基础框架已集成
仍存在的问题
- ❌ 价格数据仍主要使用REST API
- ❌ K线数据仍使用REST API轮询
- ❌ 账户数据使用REST API
- ❌ 持仓数据使用REST API
WebSocket 优势
-
不占用REST API配额
- WebSocket流独立于REST API限流
- 可以实时接收数据，无需轮询
-
更低延迟
- 数据推送，无需等待HTTP请求
- 实时性更好
-
更高效率
- 一次订阅，持续接收
- 减少网络开销
-
避免限流
- 不会触发
-1003错误（请求过多）
- 不会触发
迁移方案
阶段1：价格数据 WebSocket 化（推荐优先实施）
影响范围：
market_scanner.py:_get_symbol_change()中的get_ticker_24h()position_manager.py: 持仓监控中的价格查询risk_manager.py: 风险计算中的价格查询
实现难度：⭐⭐ (简单)
- 已有
UnicornWebSocketManager基础 - 只需订阅ticker流并缓存价格
效果：
- 减少 80%+ 的REST API调用
- 价格数据实时性提升
阶段2：K线数据 WebSocket 化
影响范围：
market_scanner.py:_get_symbol_change()中的get_klines()indicators.py: 技术指标计算
实现难度：⭐⭐⭐ (中等)
- 需要订阅K线流
- 需要维护K线数据缓存
- 需要处理K线更新逻辑
效果：
- 减少K线数据相关的REST API调用
- K线数据实时更新
阶段3：账户数据 WebSocket 化（可选）
影响范围：
risk_manager.py: 账户余额查询position_manager.py: 账户余额查询
实现难度：⭐⭐⭐⭐ (较复杂)
- 需要实现User Data Stream
- 需要HMAC签名
- 需要处理账户更新事件
效果：
- 账户数据实时更新
- 减少账户查询API调用
实施建议
推荐方案：阶段1（价格数据WebSocket化）
原因：
- 实现简单，风险低
- 效果显著，能解决大部分限流问题
- 已有基础框架支持
实施步骤：
- 在系统启动时订阅所有USDT交易对的ticker流
- 维护价格缓存字典
- 修改价格查询方法，优先从缓存读取
- 保留REST API作为fallback
不推荐立即实施阶段3
原因：
- 实现复杂，需要处理签名和事件
- 账户数据更新频率相对较低
- 风险较高，可能影响交易逻辑
预期效果
阶段1实施后
- REST API调用减少：80-90%
- 价格数据延迟：<100ms (vs 500-1000ms)
- 限流风险：大幅降低
- 系统稳定性：显著提升
代码改动量
- 新增代码：~200行
- 修改代码：~100行
- 测试工作量：中等
风险评估
低风险
- ✅ 价格数据WebSocket化（已有fallback机制）
- ✅ 不影响交易逻辑
中风险
- ⚠️ K线数据WebSocket化（需要处理数据一致性）
- ⚠️ 需要处理WebSocket断线重连
高风险
- ❌ 账户数据WebSocket化（可能影响交易决策）
结论
建议优先实施阶段1（价格数据WebSocket化）：
- ✅ 实现简单，风险低
- ✅ 效果显著
- ✅ 可以快速解决限流问题
- ✅ 为后续优化打下基础
不建议立即实施阶段3：
- ❌ 复杂度高
- ❌ 风险大
- ❌ 收益相对有限