147 lines
5.5 KiB
Markdown
147 lines
5.5 KiB
Markdown
## 多用户（多账号）架构评估与落地方案（草案）
|
||
|
||
本文档基于你提出的多用户需求，给出数据隔离边界、并发模型、Redis/DB 设计、以及 2核4G 服务器负载评估与分阶段落地路线。
|
||
|
||
---
|
||
|
||
## 目标与约束
|
||
|
||
### 目标（对应你的 6 点）
|
||
|
||
1. **每个用户使用自己的 API KEY**
|
||
2. **每个用户独立自动交易、独立持仓**
|
||
3. **每个用户独立配置**
|
||
4. **交易推荐全局共用**
|
||
5. **订单/交易记录独立**
|
||
6. **错误日志全局共用**
|
||
|
||
### 关键约束
|
||
|
||
- **币安限频是关键瓶颈**：公共行情接口通常按 IP 限频，单纯“多 key”无法线性扩容；必须通过共享行情缓存降低请求。
|
||
- **隔离优先级**：下单/持仓/配置/订单记录必须强隔离；推荐/行情/错误日志可以共享。
|
||
|
||
---
|
||
|
||
## 数据归属与隔离（Data Ownership）
|
||
|
||
### A. 全局共享（所有用户共用）
|
||
|
||
- **推荐（Recommendations）**：一份全局 Redis Snapshot/List
|
||
- 建议 Key：`ats:recommendations:snapshot`
|
||
- 后端/前端只读（不在请求中触发扫描/生成）
|
||
- **行情热数据（Market Data）**：全局缓存（Redis）
|
||
- `ats:md:mark_price:all`（短 TTL，比如 2~5s）
|
||
- `ats:md:ticker_24h:all`（TTL 10~30s）
|
||
- `ats:md:klines:{symbol}:{interval}:{limit}`（TTL 30~120s）
|
||
- **错误日志（Logs）**：全局流
|
||
- 继续使用 `ats:logs:{error|warning|info}`
|
||
- 每条日志建议增加字段：`account_id`（便于筛选定位）
|
||
|
||
### B. 用户私有（必须隔离）
|
||
|
||
- **API KEY/SECRET（敏感）**：按账号独立存储（必须加密）
|
||
- **交易配置**：按账号独立
|
||
- DB：`(account_id, config_key)` 唯一
|
||
- Redis：`ats:cfg:{account_id}`（hash）
|
||
- **自动交易运行态/热数据（可选但推荐）**
|
||
- `ats:positions:{account_id}`（更快的 UI 展示/减少后端压力）
|
||
- `ats:orders:pending:{account_id}`（挂单/入场状态）
|
||
- `ats:stats:{account_id}:*`（每日下单数、成交数、撤单数等）
|
||
- **交易/订单记录**：按账号独立
|
||
- DB 表：`trades` 增加 `account_id`；统计/查询均按账号过滤
|
||
|
||
---
|
||
|
||
## 并发模型：是否需要多线程/多进程？
|
||
|
||
结论：**不推荐多线程**。更推荐以下两种模型之一：
|
||
|
||
### 方案 1（推荐先落地）：每个账号一个 `trading_system` 进程（Supervisor 管理）
|
||
|
||
- **优点**
|
||
- 隔离强：某个账号异常/限频/崩溃不影响其他账号
|
||
- 上线快：对现有单账号 trading_system 改动最少
|
||
- 运维简单：Supervisor 一账号一进程
|
||
- **缺点**
|
||
- 进程数随账号增长（内存占用会上升）
|
||
- 若每进程都重复拉行情，会触发 IP 限频（必须配合“全局行情缓存”）
|
||
|
||
### 方案 2（后期优化）：单进程 + asyncio 多账号 worker
|
||
|
||
- **优点**
|
||
- 资源更省，便于共享行情缓存/HTTP Session
|
||
- **缺点**
|
||
- 隔离弱：某个账号阻塞/异常可能影响整体
|
||
- 实现复杂：需要更严格的超时/限频/异常隔离与任务监控
|
||
|
||
---
|
||
|
||
## Redis 用法：减轻后端与交易系统压力的关键
|
||
|
||
建议将 Redis 分为四层：
|
||
|
||
1. **全局行情缓存层**（降低公共接口请求）
|
||
2. **全局推荐层**（只读 snapshot，避免“刷新=触发扫描”）
|
||
3. **账号配置层**（`ats:cfg:{account_id}`）
|
||
4. **账号运行态层**（positions/pending/stats）
|
||
|
||
额外建议：
|
||
- 使用短 TTL + 分布式锁（你已有 lock 设计），避免并发刷新造成浪涌。
|
||
|
||
---
|
||
|
||
## 数据库改造（最小必要变更）
|
||
|
||
1. 新增 `accounts` 表：
|
||
- `id, name, api_key_enc, api_secret_enc, status, created_at ...`
|
||
- API Key 必须加密存储（服务端用 master key 解密）
|
||
2. `trading_config` 增加 `account_id`（或新表 `trading_config_accounts`）
|
||
3. `trades` 增加 `account_id`
|
||
4. `account_snapshots` 增加 `account_id`
|
||
5. 其余按需：positions、signals（signals 可全局，positions 必须私有）
|
||
|
||
---
|
||
|
||
## 2核4G 负载评估（粗略）
|
||
|
||
负载主要来自两块：
|
||
|
||
1. **公共行情拉取/指标计算（全局）**
|
||
2. **每账号的下单/持仓同步/风控计算（私有）**
|
||
|
||
### 不做共享行情（不推荐）
|
||
|
||
- 每账号都拉 klines/mark price/ticker：会先撞到 **币安 IP 限频**，2c4g 也撑不住。
|
||
|
||
### 做共享行情 + 推荐全局（推荐）
|
||
|
||
- 公共行情只拉 1 份（Redis 分发），账号 worker 只消费缓存 + 下单/持仓同步。
|
||
- 2c4g 在“波段低频”（如 15min 扫描、每账号持仓 0~5）场景下，通常可支撑 **10~30 个账号**（视持仓监控方式与限频策略而定）。
|
||
- 若每个账号都对每个持仓开 WebSocket 监控，上限会明显降低（更建议用全局 mark price + 定时校验替代/降频）。
|
||
|
||
---
|
||
|
||
## 分阶段落地路线（推荐）
|
||
|
||
### Phase 1：最快上线（强隔离、成本最低）
|
||
|
||
- accounts + account_id 改造（DB/API/前端）
|
||
- 每账号一个 trading_system 进程（Supervisor）
|
||
- 推荐/行情继续全局缓存（Redis）
|
||
- 日志全局流（带 account_id）
|
||
|
||
### Phase 2：提升承载与稳定性
|
||
|
||
- 抽全局 MarketDataService（行情/klines 统一刷新一次）
|
||
- 每账号 worker 只做决策/下单，减少公共 API 调用
|
||
- 降低 per-position websocket 数量（用 mark price 缓存替代）
|
||
|
||
---
|
||
|
||
## 风险提示与建议
|
||
|
||
- **安全**：API Key 必须加密存储；前端永远不返回明文 secret。
|
||
- **限频**：公共接口一定要共享缓存；多账号并发拉行情会让整体不可用。
|
||
- **隔离**：交易执行建议多进程优先；后期再做单进程多 worker 的资源优化。
|
||
|