229 lines
6.3 KiB
Markdown
229 lines
6.3 KiB
Markdown
# 扫描效率优化完成总结
|
||
|
||
## ✅ 已完成的优化
|
||
|
||
### 1. 增加 MAX_SCAN_SYMBOLS
|
||
|
||
**优化前**:`MAX_SCAN_SYMBOLS = 150`
|
||
**优化后**:`MAX_SCAN_SYMBOLS = 250`
|
||
|
||
**效果**:
|
||
- 覆盖率:从 27.6% 提升到 **46.0%**(增加 18.4%)
|
||
- 减少错过好机会的概率
|
||
|
||
**已更新的文件**:
|
||
1. `trading_system/config.py` - 默认配置
|
||
2. `backend/config_manager.py` - 配置管理器
|
||
3. `frontend/src/components/GlobalConfig.jsx` - 前端全局配置
|
||
4. `frontend/src/components/ConfigPanel.jsx` - 前端用户配置
|
||
|
||
---
|
||
|
||
### 2. 优化缓存机制
|
||
|
||
#### 2.1 增加24小时行情数据缓存TTL
|
||
|
||
**优化位置**:`trading_system/binance_client.py`
|
||
|
||
**优化前**:`TTL: 30秒`
|
||
**优化后**:`TTL: 60秒`
|
||
|
||
**理由**:
|
||
- 24小时行情数据变化较慢,可以缓存更长时间
|
||
- 多个账户可以共用同一个缓存,减少API请求
|
||
- 提升扫描效率
|
||
|
||
#### 2.2 添加技术指标计算结果缓存
|
||
|
||
**优化位置**:`trading_system/market_scanner.py`
|
||
|
||
**功能**:
|
||
- 缓存技术指标计算结果(RSI、MACD、布林带、ATR、EMA等)
|
||
- 基于K线数据的最后更新时间判断缓存是否有效
|
||
- 如果K线数据没有更新,直接使用缓存的技术指标
|
||
|
||
**缓存键**:`indicators:{symbol}:{primary_interval}:{confirm_interval}`
|
||
|
||
**缓存TTL**:30秒(与K线缓存一致)
|
||
|
||
**效果**:
|
||
- 减少重复计算技术指标的开销
|
||
- 多个账户可以共用同一个缓存
|
||
- 提升扫描效率(特别是扫描250个交易对时)
|
||
|
||
---
|
||
|
||
## 📊 性能提升
|
||
|
||
### 优化前
|
||
|
||
**扫描150个交易对**:
|
||
- 获取24小时行情:1次API请求(缓存30秒)
|
||
- 详细分析28个:28次K线API请求(有缓存)
|
||
- 计算技术指标:28次计算(无缓存,每次都计算)
|
||
- **总耗时**:约10-30秒
|
||
|
||
### 优化后
|
||
|
||
**扫描250个交易对**:
|
||
- 获取24小时行情:1次API请求(缓存60秒,多个账户共用)
|
||
- 详细分析50-60个:50-60次K线API请求(有缓存,多个账户共用)
|
||
- 计算技术指标:50-60次计算(有缓存,多个账户共用)
|
||
- **总耗时**:约15-40秒(虽然扫描数量增加,但缓存优化减少了实际计算时间)
|
||
|
||
**性能提升**:
|
||
- 24小时行情缓存TTL增加,减少API请求
|
||
- 技术指标计算结果缓存,减少重复计算
|
||
- 多个账户可以共用缓存,进一步提升效率
|
||
|
||
---
|
||
|
||
## 🎯 缓存策略
|
||
|
||
### 1. 24小时行情数据缓存
|
||
|
||
- **缓存键**:`ticker_24h:all`
|
||
- **TTL**:60秒
|
||
- **共享**:所有账户共用
|
||
- **更新频率**:每60秒更新一次
|
||
|
||
### 2. K线数据缓存
|
||
|
||
- **缓存键**:`klines:{symbol}:{interval}:{limit}`
|
||
- **TTL**:根据interval动态设置(1h=60秒,4h=300秒)
|
||
- **共享**:所有账户共用
|
||
- **更新频率**:根据interval动态更新
|
||
|
||
### 3. 技术指标计算结果缓存
|
||
|
||
- **缓存键**:`indicators:{symbol}:{primary_interval}:{confirm_interval}`
|
||
- **TTL**:30秒
|
||
- **共享**:所有账户共用
|
||
- **更新频率**:当K线数据更新时自动失效
|
||
|
||
---
|
||
|
||
## 📈 预期效果
|
||
|
||
### 1. 扫描覆盖率提升
|
||
|
||
- **优化前**:150/544 = 27.6%
|
||
- **优化后**:250/544 = **46.0%**(增加18.4%)
|
||
- **效果**:减少错过好机会的概率
|
||
|
||
### 2. 扫描效率提升
|
||
|
||
- **优化前**:每次扫描都需要重新计算技术指标
|
||
- **优化后**:技术指标计算结果缓存,减少重复计算
|
||
- **效果**:虽然扫描数量增加,但实际耗时增加不多
|
||
|
||
### 3. 多账户效率提升
|
||
|
||
- **优化前**:每个账户独立扫描,重复计算
|
||
- **优化后**:多个账户共用缓存,减少重复计算
|
||
- **效果**:多个账户同时扫描时,效率显著提升
|
||
|
||
---
|
||
|
||
## 🚀 下一步操作
|
||
|
||
1. **重启交易进程**:
|
||
```bash
|
||
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
|
||
```
|
||
|
||
2. **验证优化**:
|
||
```bash
|
||
# 查看日志,确认扫描数量增加到250
|
||
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep -E "限制扫描数量|排除主流币|扫描完成"
|
||
|
||
# 查看缓存使用情况
|
||
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep -E "使用缓存|已缓存|从Redis缓存"
|
||
```
|
||
|
||
3. **观察效果**:
|
||
- 观察扫描时间是否在可接受范围内(15-40秒)
|
||
- 观察是否找到了更多优质机会
|
||
- 观察缓存命中率
|
||
|
||
---
|
||
|
||
## ✅ 完成时间
|
||
|
||
2026-01-25
|
||
|
||
---
|
||
|
||
## 🔄 后续优化(2026-01-25)
|
||
|
||
### 1. 禁用扫描结果缓存
|
||
|
||
**问题**:扫描结果缓存(8个交易对)在不同账户间共享,可能导致使用过期数据。
|
||
|
||
**解决方案**:
|
||
- ✅ 完全禁用扫描结果缓存
|
||
- ✅ 每个账户都重新扫描,确保使用最新的市场数据
|
||
- ✅ 虽然中间数据(K线、技术指标)已经缓存,但最终扫描结果不缓存
|
||
|
||
**效果**:
|
||
- 避免使用过期交易对的风险
|
||
- 确保每个账户都基于最新市场数据扫描
|
||
- 性能影响很小(因为中间数据已经缓存)
|
||
|
||
### 2. 优化多用户性能
|
||
|
||
**问题**:确保后续增加用户时,扫描不会让系统难以承受。
|
||
|
||
**解决方案**:
|
||
- ✅ 降低并发数:从5个降低到3个,确保多用户时系统稳定
|
||
- ✅ 添加超时控制:单个交易对分析超时10秒,避免无限期阻塞
|
||
- ✅ 添加性能监控:记录扫描耗时,如果超过60秒会发出警告
|
||
|
||
**效果**:
|
||
- 即使有多个账户同时扫描,也不会对系统造成过大压力
|
||
- 扫描过程不会错过或耽误处理
|
||
- 通过日志可以监控扫描性能
|
||
|
||
### 3. 性能监控
|
||
|
||
**新增功能**:
|
||
- 扫描完成后记录耗时
|
||
- 如果扫描耗时超过60秒,会发出警告
|
||
- 方便监控多用户时的系统压力
|
||
|
||
---
|
||
|
||
## 📊 多用户场景下的性能保证
|
||
|
||
### 优化前
|
||
- 并发数:5个
|
||
- 无超时控制
|
||
- 无性能监控
|
||
|
||
### 优化后
|
||
- 并发数:3个(降低系统压力)
|
||
- 超时控制:10秒(避免阻塞)
|
||
- 性能监控:记录耗时,超过60秒警告
|
||
|
||
### 预期效果
|
||
|
||
**单用户场景**:
|
||
- 扫描耗时:15-40秒
|
||
- 系统压力:低
|
||
|
||
**多用户场景(4个账户)**:
|
||
- 扫描耗时:15-40秒(每个账户)
|
||
- 系统压力:中等(由于中间数据缓存,实际API请求不会大幅增加)
|
||
- 不会错过或耽误处理:✅(超时控制确保不会无限期阻塞)
|
||
|
||
---
|
||
|
||
## 📝 关于文档位置
|
||
|
||
**文档位置**:所有文档已统一放在 `docs/` 目录中
|
||
|
||
**说明**:
|
||
- ✅ 不会对分析处理造成困扰
|
||
- ✅ 文档结构更清晰,便于管理
|
||
- ✅ 我会优先在 `docs/` 目录查找相关文档
|