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