|
|
|
|
|
# Design: Config to MySQL
|
|
|
|
|
|
|
|
|
|
|
|
## 架构决策
|
|
|
|
|
|
|
|
|
|
|
|
### 决策 1：统一配置管理模块
|
|
|
|
|
|
|
|
|
|
|
|
**决策**：创建 `app/config_store.py` 作为所有配置读写的唯一入口。
|
|
|
|
|
|
|
|
|
|
|
|
**理由**：
|
|
|
|
|
|
- 消除多处重复的文件读取逻辑
|
|
|
|
|
|
- 集中管理降级策略
|
|
|
|
|
|
- 便于后续扩展（如缓存、审计）
|
|
|
|
|
|
|
|
|
|
|
|
### 决策 2：单表存储键值对
|
|
|
|
|
|
|
|
|
|
|
|
**决策**：使用单表 `app_config` 存储所有配置，以 `config_key` 区分 `symbols` 和 `ai`。
|
|
|
|
|
|
|
|
|
|
|
|
**表结构**：
|
|
|
|
|
|
```sql
|
|
|
|
|
|
CREATE TABLE app_config (
|
|
|
|
|
|
id INT PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
|
config_key VARCHAR(64) UNIQUE NOT NULL, -- 'symbols' 或 'ai'
|
|
|
|
|
|
config_value JSON NOT NULL,
|
|
|
|
|
|
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
|
|
|
|
|
|
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
|
|
|
|
|
)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**理由**：
|
|
|
|
|
|
- 与现有 JSON schema 兼容
|
|
|
|
|
|
- 减少表数量
|
|
|
|
|
|
- 未来新增配置无需改表结构
|
|
|
|
|
|
|
|
|
|
|
|
### 决策 3：MySQL + JSON 文件降级
|
|
|
|
|
|
|
|
|
|
|
|
**决策**：MySQL 可用时优先读写数据库；MySQL 不可用时回退到 JSON 文件。
|
|
|
|
|
|
|
|
|
|
|
|
**理由**：
|
|
|
|
|
|
- 用户明确要求无需 Redis
|
|
|
|
|
|
- JSON 文件作为 fallback 简单可靠
|
|
|
|
|
|
- 与现有配置读取方式兼容
|
|
|
|
|
|
|
|
|
|
|
|
## 数据流
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
业务代码
|
|
|
|
|
|
↓
|
|
|
|
|
|
app/config_store.py
|
|
|
|
|
|
↓
|
|
|
|
|
|
MySQL 可用？
|
|
|
|
|
|
↓ 是 ↓ 否
|
|
|
|
|
|
读/写 app_config 读/写 JSON 文件
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
## 配置键设计
|
|
|
|
|
|
|
|
|
|
|
|
| config_key | 对应文件 | 用途 |
|
|
|
|
|
|
|------------|----------|------|
|
|
|
|
|
|
| `symbols` | `config/symbols_config.json` | 品种合约映射 |
|
|
|
|
|
|
| `ai` | `config/ai_config.json` | AI 模型配置 |
|
|
|
|
|
|
|
|
|
|
|
|
## 降级策略
|
|
|
|
|
|
|
|
|
|
|
|
### 读取流程
|
|
|
|
|
|
|
|
|
|
|
|
1. 检查 MySQL 可用性
|
|
|
|
|
|
2. MySQL 可用则查询 `app_config`
|
|
|
|
|
|
3. 数据库无数据则读取 JSON 文件并回填数据库
|
|
|
|
|
|
4. MySQL 不可用则直接读取 JSON 文件
|
|
|
|
|
|
|
|
|
|
|
|
### 写入流程
|
|
|
|
|
|
|
|
|
|
|
|
1. 检查 MySQL 可用性
|
|
|
|
|
|
2. MySQL 可用则写入 `app_config`
|
|
|
|
|
|
3. 无论数据库是否成功，同步写入 JSON 文件（保持一致性）
|
|
|
|
|
|
4. MySQL 不可用则只写入 JSON 文件
|
|
|
|
|
|
|
|
|
|
|
|
## 兼容性
|
|
|
|
|
|
|
|
|
|
|
|
- 保持 `symbols_config.json` 和 `ai_config.json` 的 schema 不变
|
|
|
|
|
|
- API 接口签名不变
|
|
|
|
|
|
- 文件路径不变，作为 fallback 使用
|
|
|
|
|
|
|
|
|
|
|
|
## 数据迁移
|
|
|
|
|
|
|
|
|
|
|
|
启动时执行一次性迁移：
|
|
|
|
|
|
|
|
|
|
|
|
1. 检测 `app_config` 表是否已有 `symbols` 和 `ai` 配置
|
|
|
|
|
|
2. 缺失则从 JSON 文件读取并写入数据库
|
|
|
|
|
|
3. 迁移幂等：已存在则跳过
|
|
|
|
|
|
|
|
|
|
|
|
## 测试策略
|
|
|
|
|
|
|
|
|
|
|
|
1. 单元测试：
|
|
|
|
|
|
- `ConfigStore.get_config` 从 MySQL 读取
|
|
|
|
|
|
- `ConfigStore.get_config` 在 MySQL 不可用时读取 JSON
|
|
|
|
|
|
- `ConfigStore.set_config` 写入 MySQL 和 JSON
|
|
|
|
|
|
- 迁移幂等性
|
|
|
|
|
|
2. 集成测试：
|
|
|
|
|
|
- 启动时自动创建表并迁移
|
|
|
|
|
|
- API 接口正常工作
|
