7.8 KiB
7.8 KiB
多用户（多账号）架构评估与落地方案（草案）
本文档基于你提出的多用户需求，给出数据隔离边界、并发模型、Redis/DB 设计、以及 2核4G 服务器负载评估与分阶段落地路线。
目标与约束
目标（对应你的 6 点）
- 每个用户使用自己的 API KEY
- 每个用户独立自动交易、独立持仓
- 每个用户独立配置
- 交易推荐全局共用
- 订单/交易记录独立
- 错误日志全局共用
关键约束
- 币安限频是关键瓶颈：公共行情接口通常按 IP 限频，单纯“多 key”无法线性扩容；必须通过共享行情缓存降低请求。
- 隔离优先级：下单/持仓/配置/订单记录必须强隔离；推荐/行情/错误日志可以共享。
数据归属与隔离（Data Ownership）
A. 全局共享（所有用户共用）
- 推荐（Recommendations）：一份全局 Redis Snapshot/List
- 建议 Key：
ats:recommendations:snapshot - 后端/前端只读（不在请求中触发扫描/生成）
- 建议 Key：
- 行情热数据（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）
- DB：
- 自动交易运行态/热数据（可选但推荐）
ats:positions:{account_id}（更快的 UI 展示/减少后端压力）ats:orders:pending:{account_id}（挂单/入场状态）ats:stats:{account_id}:*（每日下单数、成交数、撤单数等）
- 交易/订单记录：按账号独立
- DB 表：
trades增加account_id；统计/查询均按账号过滤
- DB 表：
并发模型：是否需要多线程/多进程？
结论：不推荐多线程。更推荐以下两种模型之一：
方案 1（推荐先落地）：每个账号一个 trading_system 进程（Supervisor 管理）
- 优点
- 隔离强：某个账号异常/限频/崩溃不影响其他账号
- 上线快：对现有单账号 trading_system 改动最少
- 运维简单：Supervisor 一账号一进程
- 缺点
- 进程数随账号增长（内存占用会上升）
- 若每进程都重复拉行情，会触发 IP 限频（必须配合“全局行情缓存”）
方案 2（后期优化）：单进程 + asyncio 多账号 worker
- 优点
- 资源更省，便于共享行情缓存/HTTP Session
- 缺点
- 隔离弱：某个账号阻塞/异常可能影响整体
- 实现复杂：需要更严格的超时/限频/异常隔离与任务监控
Redis 用法：减轻后端与交易系统压力的关键
建议将 Redis 分为四层：
- 全局行情缓存层（降低公共接口请求）
- 全局推荐层（只读 snapshot，避免“刷新=触发扫描”）
- 账号配置层（
ats:cfg:{account_id}） - 账号运行态层（positions/pending/stats）
额外建议：
- 使用短 TTL + 分布式锁（你已有 lock 设计），避免并发刷新造成浪涌。
数据库改造（最小必要变更）
- 新增
accounts表：id, name, api_key_enc, api_secret_enc, status, created_at ...- API Key 必须加密存储（服务端用 master key 解密）
trading_config增加account_id（或新表trading_config_accounts）trades增加account_idaccount_snapshots增加account_id- 其余按需：positions、signals（signals 可全局，positions 必须私有）
2核4G 负载评估（粗略）
负载主要来自两块：
- 公共行情拉取/指标计算（全局）
- 每账号的下单/持仓同步/风控计算（私有）
不做共享行情（不推荐）
- 每账号都拉 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 缓存替代）
面向“更多用户”的演进战略准备（从现在就要做对的几件事）
你问“每账号一进程是不是终极方案”。我的建议是把它当作长期默认架构，并提前把“可演进”埋点做对，这样未来扩容不会推倒重来。
1）固定边界：所有“私有数据”必须天然带 account_id
- 数据库：
trades / trading_config / account_snapshots / positions(若有)都必须有account_id，且所有查询默认按account_id过滤。 - Redis：账号私有数据统一命名空间：
ats:cfg:{account_id}或trading_config:{account_id}（一账号一份配置 hash）ats:positions:{account_id}、ats:orders:pending:{account_id}等
- API：所有与交易/配置/统计相关的接口都要支持
account_id（Header 或 Path），哪怕当前只有一个账号。
这一步一旦做对，未来从“多进程”演进到“多 worker/分布式”几乎不改数据层。
2）把“共享层”单独做成服务：推荐/行情永远不绑定账号
- 推荐：一份全局 snapshot（你已拆成独立推荐进程/服务），后面可水平扩容但要有锁。
- 行情：建议尽早演进为全局 MarketDataService（单实例拉取 + Redis 分发），账号 worker 只消费缓存。
这一步是从 10~30 账号走向 100+ 账号的关键，否则会先撞 Binance IP 限频。
3）演进路线（从易到难，逐步替换，不做“重写”）
- 阶段A（现在）：每账号一个进程（Supervisor）
- 最稳、隔离最好、上线快
- 阶段B（账号增多）：引入“控制器 + worker”但仍可单机
- 控制器负责：调度、限频预算、健康检查、任务重启
- worker 负责：每账号决策/下单/同步（可仍按进程隔离）
- 阶段C（规模更大）：队列化/分布式（K8s/多机）
- 账号按
account_id分片到不同节点（sharding） - 共享服务（行情/推荐）做成单独部署，或按区域分片
- 账号按
4）安全策略提前统一：API Key/Secret 必须与“普通配置”分离
- 强烈建议：API Key/Secret 存
accounts表，加密存储（服务端 master key 解密），前端永不回传 secret 明文。 - 交易进程只拿到自己账号的解密结果（进程隔离的优势）。
风险提示与建议
- 安全：API Key 必须加密存储；前端永远不返回明文 secret。
- 限频：公共接口一定要共享缓存；多账号并发拉行情会让整体不可用。
- 隔离：交易执行建议多进程优先；后期再做单进程多 worker 的资源优化。