feat: 实现 NBA 量化交易系统
- 后端实现： - 实现 NBA 比赛数据服务，从 Polymarket API 获取数据 - 实现数据库存储和增量拉取逻辑（优先从 DB 获取，数据不足时增量拉取） - 使用 sports_market_types 参数直接筛选 moneyline 类型 - 实现分页拉取逻辑（基于 gameStartTime 和 createdAt） - 移除 nba_markets 相关的外键约束（V12 迁移） - 修复数据拉取逻辑：超过 3 天的数据不拉取 - 前端实现： - 实现策略创建/编辑/列表页面 - 实现交易信号展示页面和统计页面 - 修复重复请求问题（使用 useCallback 包装 fetchGames） - 支持选择单场比赛进行配置 - 使用西8区时间格式化显示 - 数据库： - 创建 NBA 量化交易相关表（V11 迁移） - 移除外键约束（V12 迁移） - 文档： - 添加产品需求文档、技术方案、算法文档等
This commit is contained in:
WrBug
@@ -0,0 +1,999 @@
|
||||
# NBA 量化交易系统技术方案
|
||||
|
||||
## 一、概述
|
||||
|
||||
### 1.1 产品定位
|
||||
|
||||
本系统是一个基于 NBA 比赛数据的量化交易系统，用户在前端配置量化策略参数，系统后台实时获取 NBA 比赛数据，根据配置的策略参数进行量化分析，自动生成买入/卖出信号，并通过 WebSocket 实时推送给前端展示。
|
||||
|
||||
### 1.2 产品流程
|
||||
|
||||
```
|
||||
用户在前端配置策略参数
|
||||
↓
|
||||
后台保存配置并启动量化任务
|
||||
↓
|
||||
后台实时获取 NBA 比赛数据
|
||||
↓
|
||||
后台执行量化分析逻辑
|
||||
↓
|
||||
生成买入/卖出信号
|
||||
↓
|
||||
通过 WebSocket 推送给前端
|
||||
↓
|
||||
前端展示交易信号和结果
|
||||
```
|
||||
|
||||
### 1.3 核心功能
|
||||
|
||||
1. **策略配置管理**：用户在前端配置量化策略参数（如触发条件、买入卖出规则、风险控制参数等）
|
||||
2. **数据获取**：后台实时获取 NBA 比赛数据、球队统计、球员统计等
|
||||
3. **量化分析**：根据配置的策略参数和实时数据，执行量化分析逻辑
|
||||
4. **信号生成**：生成买入/卖出信号，包含市场、方向、价格、数量等信息
|
||||
5. **实时推送**：通过 WebSocket 将交易信号实时推送给前端
|
||||
6. **结果展示**：前端展示交易信号、执行结果、统计数据等
|
||||
|
||||
### 1.4 技术栈
|
||||
|
||||
- **后端框架**: Spring Boot 3.2.0 + Kotlin
|
||||
- **HTTP 客户端**: Retrofit 2.9.0 + OkHttp 4.12.0
|
||||
- **数据存储**: MySQL 8.2.0（结构化数据）+ Redis（缓存）
|
||||
- **爬虫框架**: Jsoup（用于 Basketball Reference）
|
||||
- **任务调度**: Spring Scheduler（定时任务）
|
||||
- **WebSocket**: Spring WebSocket（实时推送）
|
||||
|
||||
---
|
||||
|
||||
## 二、系统架构设计
|
||||
|
||||
### 2.1 整体架构
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 前端层 (Frontend Layer) │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ 策略配置页面 │ │ 交易信号展示 │ │ 结果统计页面 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│ HTTP API / WebSocket
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 应用层 (Application Layer) │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ 策略配置API │ │ 量化任务API │ │ WebSocket │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 服务层 (Service Layer) │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ 策略配置服务 │ │ 量化分析服务 │ │ 数据推送服务 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ NBA数据服务 │ │ 信号生成服务 │ │ 任务调度服务 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 数据层 (Data Layer) │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ NBA API │ │ 数据存储 │ │ 缓存服务 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 模块划分
|
||||
|
||||
#### 2.2.1 前端模块
|
||||
|
||||
- **策略配置模块**：用户配置量化策略参数
|
||||
- **交易信号展示模块**：实时展示买入/卖出信号
|
||||
- **结果统计模块**：展示交易结果和统计数据
|
||||
|
||||
#### 2.2.2 后端模块
|
||||
|
||||
- **策略配置管理模块**：管理用户配置的策略参数
|
||||
- **NBA 数据获取模块**：从 NBA Stats API 和 Basketball Reference 获取数据
|
||||
- **量化分析模块**：执行量化分析逻辑，生成交易信号
|
||||
- **信号推送模块**：通过 WebSocket 推送交易信号
|
||||
- **任务调度模块**：管理量化任务的启动、停止、调度
|
||||
|
||||
---
|
||||
|
||||
## 三、产品功能设计
|
||||
|
||||
### 3.1 策略配置功能
|
||||
|
||||
#### 3.1.1 配置参数
|
||||
|
||||
用户在前端可以配置以下参数：
|
||||
|
||||
**基础配置**：
|
||||
- 策略名称：用户自定义策略名称
|
||||
- 启用状态：是否启用该策略
|
||||
- 关联账户：选择用于交易的账户
|
||||
|
||||
**触发条件配置**：
|
||||
- 比赛筛选：选择关注的比赛（可按球队、日期、重要性等筛选）
|
||||
- 数据指标：选择用于分析的指标（如分差、剩余时间、球队实力等）
|
||||
- 触发阈值：设置触发买入/卖出的阈值条件
|
||||
|
||||
**交易规则配置**：
|
||||
- 买入规则：配置买入条件、买入金额、买入时机等
|
||||
- 卖出规则：配置卖出条件、卖出金额、卖出时机等
|
||||
- 价格策略：配置价格计算方式（如固定价格、动态价格等）
|
||||
|
||||
**风险控制配置**：
|
||||
- 最大持仓：单次最大买入金额
|
||||
- 最小持仓：单次最小买入金额
|
||||
- 每日亏损限制：每日最大亏损金额
|
||||
- 每日订单限制：每日最大订单数量
|
||||
- 价格容忍度：允许的价格偏差范围
|
||||
|
||||
**高级配置**：
|
||||
- 数据更新频率：NBA 数据更新频率（如 30 秒、1 分钟等）
|
||||
- 分析频率：量化分析执行频率
|
||||
- 推送设置：是否推送失败订单、推送频率等
|
||||
|
||||
#### 3.1.2 配置管理
|
||||
|
||||
- **创建策略**：用户在前端创建新的量化策略配置
|
||||
- **编辑策略**：用户可以修改已有策略的配置参数
|
||||
- **删除策略**：用户可以删除不需要的策略
|
||||
- **启用/禁用策略**：用户可以启用或禁用策略，禁用后停止执行量化分析
|
||||
- **策略列表**：展示所有策略配置，支持搜索、筛选、排序
|
||||
|
||||
### 3.2 量化分析功能
|
||||
|
||||
#### 3.2.1 数据获取
|
||||
|
||||
系统后台实时获取以下数据：
|
||||
|
||||
**比赛数据**：
|
||||
- 实时比分和分差
|
||||
- 比赛状态（未开始/进行中/已结束）
|
||||
- 当前节次和剩余时间
|
||||
- Play-by-Play 数据（每个回合的详细记录）
|
||||
|
||||
**统计数据**：
|
||||
- 球队统计数据（进攻效率、防守效率、净效率值等）
|
||||
- 球员统计数据（得分、篮板、助攻、真实命中率等）
|
||||
- 高级统计数据（PER、BPM、VORP、DRPM 等）
|
||||
|
||||
**历史数据**：
|
||||
- 历史比赛数据
|
||||
- 历史对战记录
|
||||
- 历史统计数据
|
||||
|
||||
#### 3.2.2 量化分析逻辑
|
||||
|
||||
系统根据用户配置的策略参数和实时获取的 NBA 数据，执行量化分析：
|
||||
|
||||
**核心思想**：
|
||||
- 不是简单的条件判断（如"主队落后买入"）
|
||||
- 而是综合分析两支队伍的实力、状态、对位关系等因素
|
||||
- 计算每支队伍的综合评分和获胜概率
|
||||
- 评估交易价值和风险
|
||||
- 选择最优的交易方向和时机
|
||||
|
||||
**数据预处理**：
|
||||
- 数据清洗和验证
|
||||
- 数据标准化和归一化
|
||||
- 特征工程（提取关键特征）
|
||||
|
||||
**综合评分计算**：
|
||||
- 计算主队和客队的基础实力评分（净效率值、攻防效率、节奏等）
|
||||
- 计算近期状态评分（近期胜率、净效率值变化、势头等）
|
||||
- 计算阵容完整度评分（基于缺失球员的VORP）
|
||||
- 计算球星状态评分（PER、TS%、健康状况等）
|
||||
- 计算环境因素评分（主客场、休息天数、背靠背等）
|
||||
- 综合计算主队和客队的综合评分
|
||||
|
||||
**对位分析**：
|
||||
- 分析球星对位优势（防守限制效果、历史对位数据）
|
||||
- 分析阵容克制关系（内线、外线、快攻优势）
|
||||
- 计算对位综合评分
|
||||
|
||||
**实时状态分析**（比赛进行中）：
|
||||
- 分析当前分差和剩余时间
|
||||
- 分析势头动量（过去N回合的净胜分）
|
||||
- 实时调整综合评分
|
||||
|
||||
**获胜概率计算**：
|
||||
- 基于综合评分计算基础获胜概率
|
||||
- 根据对位优势调整概率
|
||||
- 根据实时状态调整概率（比赛进行中）
|
||||
- 最终得到主队和客队的获胜概率
|
||||
|
||||
**交易价值计算**：
|
||||
- 计算预期收益（基于获胜概率和价格）
|
||||
- 计算风险调整收益（考虑不确定性、价格波动、流动性）
|
||||
- 计算交易价值评分
|
||||
|
||||
**策略执行**：
|
||||
- 根据配置的触发条件（最小获胜概率差异、最小交易价值等），判断是否满足买入/卖出条件
|
||||
- 根据配置的交易规则，计算买入/卖出价格和数量
|
||||
- 根据配置的风险控制参数，验证交易是否合规
|
||||
|
||||
**信号生成**：
|
||||
- 生成买入信号：包含市场 ID、方向（YES/NO，由系统自动判断）、价格、数量、原因等
|
||||
- 生成卖出信号：包含市场 ID、方向、价格、数量、原因等
|
||||
- 信号验证：验证信号的有效性和合规性
|
||||
|
||||
### 3.3 信号推送功能
|
||||
|
||||
#### 3.3.1 推送方式
|
||||
|
||||
系统通过 WebSocket 实时推送交易信号给前端：
|
||||
|
||||
**推送内容**：
|
||||
- 买入信号：市场信息、方向、价格、数量、触发原因、时间戳等
|
||||
- 卖出信号：市场信息、方向、价格、数量、触发原因、时间戳等
|
||||
- 信号状态：信号生成、信号执行中、信号执行成功、信号执行失败等
|
||||
|
||||
**推送频率**：
|
||||
- 实时推送：信号生成后立即推送
|
||||
- 批量推送：多个信号可以批量推送（减少网络开销）
|
||||
|
||||
#### 3.3.2 订阅管理
|
||||
|
||||
前端通过 WebSocket 订阅交易信号：
|
||||
|
||||
**订阅方式**：
|
||||
- 订阅所有策略的信号
|
||||
- 订阅特定策略的信号
|
||||
- 订阅特定市场的信号
|
||||
|
||||
**订阅管理**：
|
||||
- 前端可以动态订阅/取消订阅
|
||||
- 支持多个前端客户端同时订阅
|
||||
- 连接断开后自动重连和恢复订阅
|
||||
|
||||
### 3.4 结果展示功能
|
||||
|
||||
#### 3.4.1 实时信号展示
|
||||
|
||||
前端实时展示交易信号：
|
||||
|
||||
**信号列表**：
|
||||
- 展示所有生成的交易信号
|
||||
- 支持按策略、市场、时间等筛选
|
||||
- 支持按时间、价格等排序
|
||||
|
||||
**信号详情**：
|
||||
- 展示信号的详细信息（市场、方向、价格、数量、原因等）
|
||||
- 展示信号的执行状态和结果
|
||||
- 展示信号的历史记录
|
||||
|
||||
#### 3.4.2 统计展示
|
||||
|
||||
前端展示交易统计：
|
||||
|
||||
**策略统计**：
|
||||
- 每个策略的信号数量
|
||||
- 每个策略的成功率
|
||||
- 每个策略的盈亏情况
|
||||
|
||||
**总体统计**：
|
||||
- 总信号数量
|
||||
- 总成功率
|
||||
- 总盈亏情况
|
||||
- 每日/每周/每月统计
|
||||
|
||||
---
|
||||
|
||||
## 四、数据源集成方案
|
||||
|
||||
### 4.1 NBA Stats API 集成
|
||||
|
||||
#### 4.1.1 API 基础信息
|
||||
|
||||
- **Base URL**: `https://stats.nba.com/stats/`
|
||||
- **认证**: 无需认证，但需要设置正确的请求头
|
||||
- **请求限制**: 建议 < 10 请求/秒
|
||||
- **数据格式**: JSON
|
||||
|
||||
#### 4.1.2 请求头配置
|
||||
|
||||
需要设置以下请求头：
|
||||
- User-Agent: 浏览器标识
|
||||
- Referer: 来源页面
|
||||
- Accept: 接受 JSON 格式
|
||||
- Accept-Language: 语言设置
|
||||
|
||||
#### 4.1.3 主要接口
|
||||
|
||||
**比赛数据接口**：
|
||||
- 赛程和比分接口：获取指定日期的所有比赛
|
||||
- 比赛统计接口：获取比赛的详细统计数据
|
||||
- Play-by-Play 接口：获取比赛的回合数据
|
||||
|
||||
**统计数据接口**：
|
||||
- 球队统计面板接口：获取球队的统计数据
|
||||
- 球队关键时刻数据接口：获取球队关键时刻的表现
|
||||
- 球员统计面板接口：获取球员的统计数据
|
||||
- 球员单场数据接口：获取球员的单场数据
|
||||
|
||||
#### 4.1.4 数据获取策略
|
||||
|
||||
**实时数据获取**：
|
||||
- 比赛进行时：每 30 秒轮询一次比赛数据
|
||||
- 比赛未开始：每 5 分钟轮询一次（检查比赛状态）
|
||||
- 比赛结束：每 10 分钟轮询一次（确保数据完整）
|
||||
|
||||
**统计数据获取**：
|
||||
- 每天更新一次球队和球员统计数据
|
||||
- 比赛结束后立即更新相关统计数据
|
||||
|
||||
### 4.2 Basketball Reference 爬虫集成
|
||||
|
||||
#### 4.2.1 数据来源
|
||||
|
||||
- **Base URL**: `https://www.basketball-reference.com`
|
||||
- **数据格式**: HTML 页面
|
||||
- **优势**: 提供高级统计数据（PER、BPM、VORP、DRPM 等）
|
||||
|
||||
#### 4.2.2 爬取策略
|
||||
|
||||
**请求频率控制**：
|
||||
- 请求间隔：至少 1 秒（避免反爬虫）
|
||||
- 请求队列：使用队列管理请求，控制并发数
|
||||
|
||||
**数据爬取**：
|
||||
- 球员高级统计数据：从球员页面爬取 PER、BPM、VORP、DRPM 等
|
||||
- 球队高级统计数据：从球队页面爬取相关数据
|
||||
- 阵容统计数据：从阵容页面爬取阵容组合数据
|
||||
|
||||
**数据缓存**：
|
||||
- 爬取的数据存储到数据库，避免重复请求
|
||||
- 高级统计数据更新频率较低，可以缓存较长时间
|
||||
|
||||
### 4.3 数据存储方案
|
||||
|
||||
#### 4.3.1 数据库设计
|
||||
|
||||
**策略配置表**：
|
||||
- 存储用户配置的策略参数
|
||||
- 包含策略名称、配置参数、启用状态等字段
|
||||
|
||||
**比赛数据表**：
|
||||
- 存储比赛基本信息（比赛 ID、日期、主客场、比分等）
|
||||
- 存储比赛状态（未开始/进行中/已结束）
|
||||
- 存储当前节次和剩余时间
|
||||
|
||||
**统计数据表**：
|
||||
- 球队统计表：存储球队的统计数据
|
||||
- 球员统计表：存储球员的统计数据
|
||||
- Play-by-Play 表：存储比赛的回合数据
|
||||
|
||||
**交易信号表**：
|
||||
- 存储生成的交易信号
|
||||
- 包含市场信息、方向、价格、数量、状态等字段
|
||||
- 包含信号的执行结果和统计信息
|
||||
|
||||
#### 4.3.2 缓存策略
|
||||
|
||||
**Redis 缓存**：
|
||||
- 比赛数据缓存：缓存 5 分钟（实时数据）
|
||||
- 统计数据缓存：缓存 1 小时（统计数据更新较慢）
|
||||
- 高级统计缓存：缓存 24 小时（Basketball Reference 更新较慢）
|
||||
|
||||
**缓存更新**：
|
||||
- 数据更新时同步更新缓存
|
||||
- 缓存过期后自动从数据库或 API 重新获取
|
||||
|
||||
---
|
||||
|
||||
## 五、实时性保证策略
|
||||
|
||||
### 5.1 数据实时性要求
|
||||
|
||||
不同数据类型的实时性要求：
|
||||
|
||||
| 数据类型 | 实时性要求 | 更新频率 | 延迟容忍度 |
|
||||
|---------|-----------|---------|-----------|
|
||||
| **比赛比分** | 极高 | 30秒 | < 1分钟 |
|
||||
| **Play-by-Play** | 极高 | 30秒 | < 1分钟 |
|
||||
| **比赛状态** | 高 | 30秒 | < 2分钟 |
|
||||
| **统计数据** | 中 | 5分钟 | < 10分钟 |
|
||||
| **历史数据** | 低 | 每天 | 无要求 |
|
||||
|
||||
### 5.2 实时性保证方案
|
||||
|
||||
#### 5.2.1 多层级数据更新策略
|
||||
|
||||
**第一层：数据源层**
|
||||
- HTTP 轮询：从 NBA Stats API 轮询获取数据
|
||||
- 第三方 WebSocket API：如果可用，使用 WebSocket 实时接收数据
|
||||
- 数据缓存：使用 Redis 缓存数据，减少 API 调用
|
||||
|
||||
**第二层：数据处理层**
|
||||
- 数据变化检测：只处理变化的数据，减少不必要的处理
|
||||
- 数据验证：验证数据的有效性和完整性
|
||||
- 增量更新：只更新变化的数据，提高效率
|
||||
|
||||
**第三层：数据推送层**
|
||||
- WebSocket 推送：通过 WebSocket 实时推送数据给前端
|
||||
- 订阅管理：管理前端的订阅，只推送订阅的数据
|
||||
- 批量推送：多个数据可以批量推送，减少网络开销
|
||||
|
||||
**第四层：前端展示层**
|
||||
- 实时更新：前端实时接收和展示数据
|
||||
- 降级轮询：WebSocket 失败时降级到 HTTP 轮询
|
||||
- 数据缓存：前端缓存数据，减少重复请求
|
||||
|
||||
#### 5.2.2 数据变化检测机制
|
||||
|
||||
**数据快照比较**：
|
||||
- 保存上次的数据快照
|
||||
- 比较新数据和快照，只处理变化的数据
|
||||
- 更新快照，用于下次比较
|
||||
|
||||
**增量更新**：
|
||||
- 只保存和推送新增或变化的数据
|
||||
- 减少数据库写入和网络传输
|
||||
- 提高系统性能
|
||||
|
||||
#### 5.2.3 动态轮询频率调整
|
||||
|
||||
根据比赛状态动态调整轮询频率：
|
||||
|
||||
- **比赛未开始**：5 分钟轮询一次
|
||||
- **比赛进行中**：30 秒轮询一次
|
||||
- **最后 5 分钟**：15 秒轮询一次（关键时刻）
|
||||
- **加时赛**：20 秒轮询一次
|
||||
- **比赛结束**：10 分钟轮询一次（确保数据完整）
|
||||
|
||||
#### 5.2.4 WebSocket 连接管理
|
||||
|
||||
**连接保活**：
|
||||
- 定期发送心跳消息，保持连接活跃
|
||||
- 检测连接状态，及时处理断开情况
|
||||
|
||||
**自动重连**：
|
||||
- 连接断开后自动重连
|
||||
- 使用指数退避策略，避免频繁重连
|
||||
- 重连后恢复订阅，确保数据不丢失
|
||||
|
||||
**连接监控**：
|
||||
- 监控连接健康状态
|
||||
- 记录连接统计信息
|
||||
- 异常情况告警
|
||||
|
||||
#### 5.2.5 前端降级策略
|
||||
|
||||
**WebSocket 失败降级**：
|
||||
- WebSocket 连接失败时，自动降级到 HTTP 轮询
|
||||
- 前端定期轮询获取数据，确保数据不中断
|
||||
- WebSocket 恢复后，自动切换回 WebSocket
|
||||
|
||||
**数据缓存**：
|
||||
- 前端缓存最近的数据
|
||||
- 网络中断时，使用缓存数据展示
|
||||
- 网络恢复后，同步最新数据
|
||||
|
||||
### 5.3 实时性监控
|
||||
|
||||
#### 5.3.1 数据延迟监控
|
||||
|
||||
**延迟统计**：
|
||||
- 记录数据从获取到推送的延迟时间
|
||||
- 统计平均延迟、最大延迟等指标
|
||||
- 延迟超过阈值时触发告警
|
||||
|
||||
**性能指标**：
|
||||
- API 调用响应时间
|
||||
- 数据处理时间
|
||||
- WebSocket 推送延迟
|
||||
|
||||
#### 5.3.2 告警机制
|
||||
|
||||
**告警条件**：
|
||||
- 数据延迟超过阈值（如 1 分钟）
|
||||
- API 调用失败率超过阈值
|
||||
- WebSocket 连接断开
|
||||
- 数据更新异常
|
||||
|
||||
**告警方式**：
|
||||
- 日志记录
|
||||
- 系统通知
|
||||
- 邮件/短信通知（可选）
|
||||
|
||||
---
|
||||
|
||||
## 六、量化分析逻辑设计
|
||||
|
||||
### 6.1 分析流程
|
||||
|
||||
#### 6.1.1 数据准备
|
||||
|
||||
**数据获取**：
|
||||
- 获取实时比赛数据（比分、分差、剩余时间等）
|
||||
- 获取统计数据（球队统计、球员统计等）
|
||||
- 获取历史数据（历史比赛、历史统计等）
|
||||
|
||||
**数据预处理**：
|
||||
- 数据清洗：去除异常值和缺失值
|
||||
- 数据验证：验证数据的有效性和完整性
|
||||
- 数据标准化：将数据标准化为统一的格式
|
||||
|
||||
#### 6.1.2 特征提取
|
||||
|
||||
**基础特征**：
|
||||
- 当前分差
|
||||
- 剩余时间
|
||||
- 当前节次
|
||||
- 比赛状态
|
||||
|
||||
**统计特征**：
|
||||
- 球队实力指标（净效率值、攻防效率等）
|
||||
- 球员表现指标（PER、TS%、USG% 等）
|
||||
- 历史对战数据
|
||||
|
||||
**衍生特征**：
|
||||
- 分差/剩余时间比
|
||||
- 球队实力差
|
||||
- 势头动量（过去 N 回合的净胜分）
|
||||
- 球星爆发因子（本场表现 vs 赛季平均）
|
||||
|
||||
#### 6.1.3 策略执行
|
||||
|
||||
**综合评分和对位分析**：
|
||||
- 计算主队和客队的综合评分（基础实力、近期状态、阵容完整度、球星状态、环境因素）
|
||||
- 分析对位优势（球星对位、阵容克制）
|
||||
- 计算实时状态调整（分差、势头动量，仅比赛进行中）
|
||||
|
||||
**获胜概率和交易价值计算**：
|
||||
- 基于综合评分计算基础获胜概率
|
||||
- 根据对位优势和实时状态调整概率
|
||||
- 计算预期收益和风险调整收益
|
||||
- 计算交易价值评分
|
||||
|
||||
**触发条件判断**：
|
||||
- 判断获胜概率差异是否达到阈值（如主队获胜概率 > 0.55 或 < 0.45）
|
||||
- 判断交易价值评分是否达到阈值（如 > 0.05）
|
||||
- 判断其他触发条件（剩余时间、价格等）
|
||||
|
||||
**交易规则计算**：
|
||||
- 根据获胜概率确定买入方向（YES 或 NO）
|
||||
- 根据配置的交易规则，计算买入/卖出价格（固定价格/市场价格/动态价格）
|
||||
- 根据配置的交易规则，计算买入/卖出数量（固定金额/按比例/动态计算）
|
||||
- 根据配置的风险控制参数，验证交易是否合规
|
||||
|
||||
**信号生成**：
|
||||
- 生成买入信号：包含市场 ID、方向（由系统自动判断）、价格、数量、原因（包含综合评分、获胜概率、交易价值等）等
|
||||
- 生成卖出信号：包含市场 ID、方向、价格、数量、原因等
|
||||
- 信号验证：验证信号的有效性和合规性
|
||||
|
||||
### 6.2 策略配置映射
|
||||
|
||||
#### 6.2.1 配置参数到分析逻辑的映射
|
||||
|
||||
**触发条件配置**：
|
||||
- 比赛筛选 → 数据过滤逻辑
|
||||
- 数据指标 → 特征提取逻辑
|
||||
- 触发阈值 → 条件判断逻辑
|
||||
|
||||
**交易规则配置**：
|
||||
- 买入规则 → 买入信号生成逻辑
|
||||
- 卖出规则 → 卖出信号生成逻辑
|
||||
- 价格策略 → 价格计算逻辑
|
||||
|
||||
**风险控制配置**：
|
||||
- 最大/最小持仓 → 数量限制逻辑
|
||||
- 每日亏损限制 → 风险检查逻辑
|
||||
- 每日订单限制 → 订单计数逻辑
|
||||
- 价格容忍度 → 价格验证逻辑
|
||||
|
||||
### 6.3 信号生成规则
|
||||
|
||||
#### 6.3.1 买入信号生成
|
||||
|
||||
**触发条件**：
|
||||
- 满足配置的买入触发条件
|
||||
- 通过风险控制检查
|
||||
- 市场状态正常（可交易）
|
||||
|
||||
**信号内容**：
|
||||
- 市场 ID：目标市场的唯一标识
|
||||
- 方向：YES 或 NO
|
||||
- 价格：买入价格（根据价格策略计算）
|
||||
- 数量：买入数量（根据交易规则计算）
|
||||
- 原因：触发买入的原因（如"分差达到阈值"）
|
||||
- 时间戳：信号生成时间
|
||||
|
||||
#### 6.3.2 卖出信号生成
|
||||
|
||||
**触发条件**：
|
||||
- 满足配置的卖出触发条件
|
||||
- 通过风险控制检查
|
||||
- 市场状态正常（可交易）
|
||||
|
||||
**信号内容**：
|
||||
- 市场 ID：目标市场的唯一标识
|
||||
- 方向：YES 或 NO
|
||||
- 价格：卖出价格（根据价格策略计算）
|
||||
- 数量：卖出数量（根据交易规则计算）
|
||||
- 原因：触发卖出的原因（如"达到止盈条件"）
|
||||
- 时间戳：信号生成时间
|
||||
|
||||
---
|
||||
|
||||
## 七、WebSocket 推送方案
|
||||
|
||||
### 7.1 推送架构
|
||||
|
||||
#### 7.1.1 推送流程
|
||||
|
||||
```
|
||||
量化分析服务生成交易信号
|
||||
↓
|
||||
信号推送服务接收信号
|
||||
↓
|
||||
检查订阅关系（哪些前端订阅了该策略）
|
||||
↓
|
||||
通过 WebSocket 推送给订阅的前端
|
||||
↓
|
||||
前端接收并展示信号
|
||||
```
|
||||
|
||||
#### 7.1.2 订阅管理
|
||||
|
||||
**订阅方式**：
|
||||
- 前端通过 WebSocket 发送订阅消息
|
||||
- 支持订阅所有策略的信号
|
||||
- 支持订阅特定策略的信号
|
||||
- 支持订阅特定市场的信号
|
||||
|
||||
**订阅存储**：
|
||||
- 后端维护订阅关系（策略 ID → 前端会话列表）
|
||||
- 支持多个前端同时订阅同一策略
|
||||
- 支持前端动态订阅/取消订阅
|
||||
|
||||
**订阅恢复**：
|
||||
- 前端连接断开后，自动清理订阅关系
|
||||
- 前端重连后，可以重新订阅
|
||||
|
||||
### 7.2 推送消息格式
|
||||
|
||||
#### 7.2.1 买入信号消息
|
||||
|
||||
包含以下字段：
|
||||
- 消息类型：买入信号
|
||||
- 策略 ID：生成信号的策略标识
|
||||
- 市场 ID：目标市场标识
|
||||
- 方向：YES 或 NO
|
||||
- 价格：买入价格
|
||||
- 数量：买入数量
|
||||
- 原因：触发原因
|
||||
- 时间戳：信号生成时间
|
||||
|
||||
#### 7.2.2 卖出信号消息
|
||||
|
||||
包含以下字段：
|
||||
- 消息类型：卖出信号
|
||||
- 策略 ID：生成信号的策略标识
|
||||
- 市场 ID：目标市场标识
|
||||
- 方向：YES 或 NO
|
||||
- 价格：卖出价格
|
||||
- 数量：卖出数量
|
||||
- 原因：触发原因
|
||||
- 时间戳：信号生成时间
|
||||
|
||||
#### 7.2.3 信号状态更新消息
|
||||
|
||||
包含以下字段：
|
||||
- 消息类型：状态更新
|
||||
- 信号 ID：信号的唯一标识
|
||||
- 状态：执行中/执行成功/执行失败
|
||||
- 结果：执行结果详情
|
||||
- 时间戳：状态更新时间
|
||||
|
||||
### 7.3 推送优化
|
||||
|
||||
#### 7.3.1 批量推送
|
||||
|
||||
**批量策略**：
|
||||
- 多个信号可以批量推送，减少网络开销
|
||||
- 批量大小可配置（如每批 10 个信号）
|
||||
- 批量推送间隔可配置（如每 1 秒推送一次）
|
||||
|
||||
**批量格式**：
|
||||
- 单个消息包含多个信号
|
||||
- 前端解析后分别处理每个信号
|
||||
|
||||
#### 7.3.2 推送频率控制
|
||||
|
||||
**频率限制**：
|
||||
- 每个策略的信号推送频率可配置
|
||||
- 避免过于频繁的推送，影响前端性能
|
||||
- 支持优先级：重要信号立即推送，普通信号批量推送
|
||||
|
||||
#### 7.3.3 推送失败处理
|
||||
|
||||
**失败重试**：
|
||||
- 推送失败时，记录失败信息
|
||||
- 支持重试机制（如重试 3 次）
|
||||
- 重试失败后，记录到数据库，后续可以查询
|
||||
|
||||
**降级策略**：
|
||||
- WebSocket 推送失败时，可以降级到 HTTP 轮询
|
||||
- 前端定期轮询获取信号，确保不丢失
|
||||
|
||||
---
|
||||
|
||||
## 八、错误处理和容错机制
|
||||
|
||||
### 8.1 数据获取错误处理
|
||||
|
||||
#### 8.1.1 API 调用失败
|
||||
|
||||
**重试策略**：
|
||||
- API 调用失败时，自动重试（如重试 3 次）
|
||||
- 使用指数退避策略，避免频繁重试
|
||||
- 重试失败后，记录错误日志
|
||||
|
||||
**降级策略**：
|
||||
- API 调用失败时，使用缓存数据
|
||||
- 缓存数据过期时，使用数据库数据
|
||||
- 所有数据源都失败时，记录错误并告警
|
||||
|
||||
#### 8.1.2 数据解析错误
|
||||
|
||||
**错误处理**：
|
||||
- 数据格式异常时，记录错误日志
|
||||
- 跳过异常数据，继续处理其他数据
|
||||
- 数据缺失时，使用默认值或历史数据
|
||||
|
||||
### 8.2 量化分析错误处理
|
||||
|
||||
#### 8.2.1 分析逻辑错误
|
||||
|
||||
**错误捕获**：
|
||||
- 分析逻辑执行时，捕获所有异常
|
||||
- 记录错误日志，包含错误详情和上下文
|
||||
- 错误不影响其他策略的执行
|
||||
|
||||
**错误恢复**：
|
||||
- 错误发生后，跳过本次分析
|
||||
- 等待下次分析周期，重新执行
|
||||
- 连续错误时，触发告警
|
||||
|
||||
#### 8.2.2 信号生成错误
|
||||
|
||||
**错误处理**：
|
||||
- 信号生成失败时，记录错误日志
|
||||
- 不生成无效信号，避免误导用户
|
||||
- 错误原因推送给前端（可选）
|
||||
|
||||
### 8.3 推送错误处理
|
||||
|
||||
#### 8.3.1 WebSocket 推送失败
|
||||
|
||||
**失败处理**：
|
||||
- 推送失败时，记录失败信息
|
||||
- 支持重试机制（如重试 3 次）
|
||||
- 重试失败后，记录到数据库
|
||||
|
||||
**降级策略**：
|
||||
- WebSocket 推送失败时，可以降级到 HTTP 轮询
|
||||
- 前端定期轮询获取信号，确保不丢失
|
||||
|
||||
#### 8.3.2 前端连接断开
|
||||
|
||||
**连接管理**：
|
||||
- 检测前端连接断开，清理订阅关系
|
||||
- 前端重连后，可以重新订阅
|
||||
- 连接断开期间，信号暂存到数据库
|
||||
|
||||
---
|
||||
|
||||
## 九、性能优化方案
|
||||
|
||||
### 9.1 数据获取优化
|
||||
|
||||
#### 9.1.1 请求频率控制
|
||||
|
||||
**频率限制**：
|
||||
- 控制 API 请求频率，避免触发速率限制
|
||||
- 使用请求队列，管理并发请求
|
||||
- 请求失败时，使用指数退避策略
|
||||
|
||||
#### 9.1.2 数据缓存
|
||||
|
||||
**缓存策略**：
|
||||
- 实时数据缓存 5 分钟
|
||||
- 统计数据缓存 1 小时
|
||||
- 高级统计缓存 24 小时
|
||||
|
||||
**缓存更新**：
|
||||
- 数据更新时同步更新缓存
|
||||
- 缓存过期后自动刷新
|
||||
|
||||
### 9.2 量化分析优化
|
||||
|
||||
#### 9.2.1 增量分析
|
||||
|
||||
**变化检测**：
|
||||
- 只分析变化的数据，减少不必要的计算
|
||||
- 使用数据快照比较，检测数据变化
|
||||
- 只处理变化的数据，提高分析效率
|
||||
|
||||
#### 9.2.2 并行分析
|
||||
|
||||
**并行策略**：
|
||||
- 多个策略可以并行分析
|
||||
- 使用线程池管理分析任务
|
||||
- 避免资源竞争，确保分析准确性
|
||||
|
||||
### 9.3 推送优化
|
||||
|
||||
#### 9.3.1 批量推送
|
||||
|
||||
**批量策略**：
|
||||
- 多个信号批量推送，减少网络开销
|
||||
- 批量大小和间隔可配置
|
||||
- 重要信号可以立即推送
|
||||
|
||||
#### 9.3.2 推送频率控制
|
||||
|
||||
**频率限制**：
|
||||
- 控制推送频率，避免前端性能问题
|
||||
- 支持优先级：重要信号立即推送
|
||||
- 普通信号批量推送
|
||||
|
||||
---
|
||||
|
||||
## 十、监控和日志
|
||||
|
||||
### 10.1 系统监控
|
||||
|
||||
#### 10.1.1 性能监控
|
||||
|
||||
**监控指标**：
|
||||
- API 调用响应时间
|
||||
- 数据处理时间
|
||||
- WebSocket 推送延迟
|
||||
- 系统资源使用率（CPU、内存等）
|
||||
|
||||
**监控方式**：
|
||||
- 定期记录性能指标
|
||||
- 性能指标超过阈值时触发告警
|
||||
- 提供性能统计报表
|
||||
|
||||
#### 10.1.2 业务监控
|
||||
|
||||
**监控指标**：
|
||||
- 策略执行次数
|
||||
- 信号生成数量
|
||||
- 信号推送成功率
|
||||
- 数据更新延迟
|
||||
|
||||
**监控方式**：
|
||||
- 记录业务指标到数据库
|
||||
- 提供业务统计报表
|
||||
- 异常情况触发告警
|
||||
|
||||
### 10.2 日志管理
|
||||
|
||||
#### 10.2.1 日志级别
|
||||
|
||||
**日志分类**：
|
||||
- 错误日志：记录系统错误和异常
|
||||
- 警告日志：记录警告信息
|
||||
- 信息日志：记录关键操作信息
|
||||
- 调试日志：记录详细调试信息
|
||||
|
||||
#### 10.2.2 日志内容
|
||||
|
||||
**关键操作日志**：
|
||||
- 策略配置变更
|
||||
- 量化分析执行
|
||||
- 信号生成和推送
|
||||
- API 调用和错误
|
||||
|
||||
**日志格式**：
|
||||
- 统一日志格式，便于解析和分析
|
||||
- 包含时间戳、日志级别、模块、消息等字段
|
||||
- 支持结构化日志（JSON 格式）
|
||||
|
||||
---
|
||||
|
||||
## 十一、实施步骤
|
||||
|
||||
### 11.1 第一阶段：基础功能开发（2-3 周）
|
||||
|
||||
**任务清单**：
|
||||
- 完成策略配置管理功能（前端配置页面 + 后端 API）
|
||||
- 完成 NBA 数据获取功能（API 集成 + 数据存储）
|
||||
- 完成基础量化分析功能（简单策略逻辑）
|
||||
- 完成信号推送功能（WebSocket 推送）
|
||||
|
||||
### 11.2 第二阶段：量化分析完善（2-3 周）
|
||||
|
||||
**任务清单**：
|
||||
- 完善量化分析逻辑（支持复杂策略）
|
||||
- 完善特征提取和数据处理
|
||||
- 完善信号生成和验证
|
||||
- 完善错误处理和容错机制
|
||||
|
||||
### 11.3 第三阶段：实时性优化（1-2 周）
|
||||
|
||||
**任务清单**：
|
||||
- 优化数据获取频率和策略
|
||||
- 优化 WebSocket 推送机制
|
||||
- 实现数据变化检测和增量更新
|
||||
- 实现前端降级策略
|
||||
|
||||
### 11.4 第四阶段：性能优化和监控（1-2 周）
|
||||
|
||||
**任务清单**：
|
||||
- 性能优化（缓存、并行处理等）
|
||||
- 系统监控和日志完善
|
||||
- 压力测试和性能调优
|
||||
- 文档完善
|
||||
|
||||
---
|
||||
|
||||
## 十二、注意事项
|
||||
|
||||
### 12.1 API 限制
|
||||
|
||||
- **NBA Stats API**: 建议请求频率 < 10 请求/秒
|
||||
- **Basketball Reference**: 建议请求频率 < 1 请求/秒
|
||||
- 需要设置正确的请求头，避免被拒绝
|
||||
|
||||
### 12.2 数据质量
|
||||
|
||||
- API 返回的数据格式可能不一致，需要做好异常处理
|
||||
- Basketball Reference 的 HTML 结构可能变化，需要定期检查
|
||||
- 需要验证数据的合理性（如得分不超过 200 分）
|
||||
|
||||
### 12.3 法律合规
|
||||
|
||||
- 遵守 NBA Stats API 的使用条款
|
||||
- 遵守 Basketball Reference 的爬虫协议（robots.txt）
|
||||
- 不要过度请求，避免对服务器造成负担
|
||||
|
||||
### 12.4 风险提示
|
||||
|
||||
- 量化交易存在风险，需要做好风险控制
|
||||
- 信号仅供参考，不构成投资建议
|
||||
- 需要明确告知用户风险和使用条款
|
||||
|
||||
---
|
||||
|
||||
## 十三、扩展建议
|
||||
|
||||
### 13.1 功能扩展
|
||||
|
||||
**策略模板**：
|
||||
- 提供预定义的策略模板
|
||||
- 用户可以基于模板快速创建策略
|
||||
- 支持策略模板的导入和导出
|
||||
|
||||
**回测功能**：
|
||||
- 支持历史数据回测
|
||||
- 评估策略的历史表现
|
||||
- 优化策略参数
|
||||
|
||||
**多账户支持**：
|
||||
- 支持多个交易账户
|
||||
- 每个账户可以配置不同的策略
|
||||
- 统一管理和监控
|
||||
|
||||
### 13.2 技术扩展
|
||||
|
||||
**机器学习集成**：
|
||||
- 使用机器学习模型优化策略
|
||||
- 自动学习和优化参数
|
||||
- 提高信号准确性
|
||||
|
||||
**多数据源整合**：
|
||||
- 整合多个数据源（如 ESPN、Sportradar 等）
|
||||
- 提高数据完整性和准确性
|
||||
- 降低对单一数据源的依赖
|
||||
|
||||
**分布式部署**：
|
||||
- 支持分布式部署，提高系统性能
|
||||
- 支持负载均衡和容错
|
||||
- 支持水平扩展
|
||||
@@ -0,0 +1,158 @@
|
||||
# NBA Stats API 验证检查清单
|
||||
|
||||
## 一、API 接口定义检查
|
||||
|
||||
### 1.1 接口路径
|
||||
- ✅ **路径**: `/Scoreboard`
|
||||
- ✅ **Base URL**: `https://stats.nba.com/stats/`
|
||||
- ✅ **完整 URL**: `https://stats.nba.com/stats/Scoreboard`
|
||||
|
||||
### 1.2 请求参数
|
||||
- ✅ **GameDate**: 日期格式 `YYYY-MM-DD`（如 `2024-12-15`）
|
||||
- ✅ **LeagueID**: 联盟ID，默认 `"00"` (NBA)
|
||||
- ✅ **DayOffset**: 日期偏移，默认 `0`
|
||||
|
||||
**注意**: NBA Stats API 的参数名称是**大小写敏感**的：
|
||||
- ✅ `GameDate` (正确)
|
||||
- ❌ `gameDate` (错误)
|
||||
- ✅ `LeagueID` (正确)
|
||||
- ❌ `leagueId` (错误)
|
||||
|
||||
### 1.3 请求头设置
|
||||
- ✅ **User-Agent**: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36`
|
||||
- ✅ **Referer**: `https://www.nba.com/`
|
||||
- ✅ **Accept**: `application/json`
|
||||
- ✅ **Accept-Language**: `en-US,en;q=0.9`
|
||||
- ✅ **Origin**: `https://www.nba.com`
|
||||
|
||||
## 二、响应格式检查
|
||||
|
||||
### 2.1 响应结构
|
||||
NBA Stats API 返回的 JSON 结构：
|
||||
```json
|
||||
{
|
||||
"resultSets": [
|
||||
{
|
||||
"name": "GameHeader",
|
||||
"headers": ["GAME_DATE_EST", "GAME_SEQUENCE", "GAME_ID", ...],
|
||||
"rowSet": [[...], [...]]
|
||||
},
|
||||
{
|
||||
"name": "LineScore",
|
||||
"headers": ["GAME_DATE_EST", "GAME_SEQUENCE", "GAME_ID", "TEAM_ID", ...],
|
||||
"rowSet": [[...], [...]]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 ResultSet 名称
|
||||
- ✅ **GameHeader**: 比赛基本信息
|
||||
- ✅ **LineScore**: 比分信息（每支球队一行）
|
||||
|
||||
### 2.3 GameHeader 字段顺序
|
||||
根据注释，字段顺序应该是：
|
||||
```
|
||||
[0] GAME_DATE_EST
|
||||
[1] GAME_SEQUENCE
|
||||
[2] GAME_ID
|
||||
[3] GAME_STATUS_ID
|
||||
[4] GAME_STATUS_TEXT
|
||||
[5] GAMECODE
|
||||
[6] HOME_TEAM_ID
|
||||
[7] VISITOR_TEAM_ID
|
||||
[8] SEASON
|
||||
[9] LIVE_PERIOD
|
||||
[10] LIVE_PC_TIME
|
||||
[11] NATL_TV_BROADCASTER_ABBREV
|
||||
[12] LIVE_PERIOD_TIME_BCAST
|
||||
[13] WH_STATUS
|
||||
```
|
||||
|
||||
### 2.4 LineScore 字段顺序
|
||||
根据注释，字段顺序应该是：
|
||||
```
|
||||
[0] GAME_DATE_EST
|
||||
[1] GAME_SEQUENCE
|
||||
[2] GAME_ID
|
||||
[3] TEAM_ID
|
||||
[4] TEAM_ABBREVIATION
|
||||
[5] TEAM_NAME
|
||||
[6] PTS_QTR1
|
||||
[7] PTS_QTR2
|
||||
[8] PTS_QTR3
|
||||
[9] PTS_QTR4
|
||||
[10] PTS_OT1
|
||||
[11] PTS_OT2
|
||||
[12] PTS_OT3
|
||||
[13] PTS_OT4
|
||||
[14] PTS
|
||||
[15] FG_PCT
|
||||
[16] FT_PCT
|
||||
[17] FG3_PCT
|
||||
[18] AST
|
||||
[19] REB
|
||||
[20] TOV
|
||||
```
|
||||
|
||||
## 三、代码实现检查
|
||||
|
||||
### 3.1 接口定义 ✅
|
||||
```kotlin
|
||||
@GET("Scoreboard")
|
||||
suspend fun getScoreboard(
|
||||
@Query("GameDate") gameDate: String? = null,
|
||||
@Query("LeagueID") leagueId: String = "00",
|
||||
@Query("DayOffset") dayOffset: Int = 0
|
||||
): Response<ScoreboardResponse>
|
||||
```
|
||||
- ✅ 参数名称大小写正确
|
||||
- ✅ 参数类型正确
|
||||
|
||||
### 3.2 请求头设置 ✅
|
||||
- ✅ 已设置所有必需的请求头
|
||||
- ✅ User-Agent 格式正确
|
||||
|
||||
### 3.3 响应解析 ⚠️
|
||||
**潜在问题**：
|
||||
1. **ResultSet 查找方式**: 使用 `firstOrNull { it.name == "GameHeader" }` 可能不够准确
|
||||
- 建议：使用索引 `resultSets[0]` 或 `resultSets.getOrNull(0)`
|
||||
- 或者：先检查 `resultSets.size >= 2`
|
||||
|
||||
2. **字段索引**: 当前代码假设字段顺序固定
|
||||
- 建议：根据 `headers` 数组动态查找字段索引，而不是硬编码索引
|
||||
|
||||
3. **错误处理**: 当前有基本的错误处理，但可以更详细
|
||||
|
||||
## 四、建议的改进
|
||||
|
||||
### 4.1 使用 headers 动态查找字段
|
||||
```kotlin
|
||||
// 根据 headers 查找字段索引，而不是硬编码
|
||||
val gameDateIndex = headers.indexOf("GAME_DATE_EST")
|
||||
val gameIdIndex = headers.indexOf("GAME_ID")
|
||||
// ...
|
||||
```
|
||||
|
||||
### 4.2 增强错误处理
|
||||
- 记录完整的响应内容（用于调试）
|
||||
- 验证 headers 数量是否匹配
|
||||
- 验证 rowSet 数据是否完整
|
||||
|
||||
### 4.3 添加响应验证
|
||||
- 验证 resultSets 数量
|
||||
- 验证每个 resultSet 的 name
|
||||
- 验证 headers 和 rowSet 的对应关系
|
||||
|
||||
## 五、测试建议
|
||||
|
||||
1. **单元测试**: 测试 API 调用和响应解析
|
||||
2. **集成测试**: 测试完整的获取流程
|
||||
3. **错误场景测试**: 测试 API 失败、数据不完整等情况
|
||||
|
||||
## 六、已知问题
|
||||
|
||||
1. **API 限制**: NBA Stats API 可能需要特定的请求头，否则可能返回 403 或空数据
|
||||
2. **数据格式**: 响应格式可能因日期而异（有比赛 vs 无比赛）
|
||||
3. **时区问题**: `GAME_DATE_EST` 是 EST 时区，需要注意时区转换
|
||||
|
||||
@@ -0,0 +1,218 @@
|
||||
# NBA 量化交易系统后端实现总结
|
||||
|
||||
## 已完成部分
|
||||
|
||||
### 1. 数据库设计 ✅
|
||||
|
||||
**迁移文件**: `V11__create_nba_quantitative_trading_tables.sql`
|
||||
|
||||
创建了以下表：
|
||||
- `nba_markets`: NBA 市场表（Polymarket 市场信息）
|
||||
- `nba_games`: NBA 比赛表
|
||||
- `nba_quantitative_strategies`: 量化策略配置表
|
||||
- `nba_trading_signals`: 交易信号表
|
||||
- `nba_strategy_statistics`: 策略执行统计表
|
||||
|
||||
### 2. 实体类 ✅
|
||||
|
||||
已创建以下实体类：
|
||||
- `NbaMarket.kt`: NBA 市场实体
|
||||
- `NbaGame.kt`: NBA 比赛实体
|
||||
- `NbaQuantitativeStrategy.kt`: 量化策略配置实体
|
||||
- `NbaTradingSignal.kt`: 交易信号实体
|
||||
- `NbaStrategyStatistics.kt`: 策略统计实体
|
||||
|
||||
### 3. Repository 层 ✅
|
||||
|
||||
已创建以下 Repository：
|
||||
- `NbaMarketRepository.kt`
|
||||
- `NbaGameRepository.kt`
|
||||
- `NbaQuantitativeStrategyRepository.kt`
|
||||
- `NbaTradingSignalRepository.kt`
|
||||
- `NbaStrategyStatisticsRepository.kt`
|
||||
|
||||
### 4. DTO 层 ✅
|
||||
|
||||
已创建：
|
||||
- `NbaQuantitativeStrategyDto.kt`: 包含创建、更新、列表请求和响应 DTO
|
||||
|
||||
### 5. Service 层（部分完成）✅
|
||||
|
||||
已创建：
|
||||
- `NbaQuantitativeStrategyService.kt`: 策略管理服务
|
||||
- 创建策略
|
||||
- 更新策略
|
||||
- 获取策略列表
|
||||
- 获取策略详情
|
||||
- 删除策略
|
||||
- 获取启用的策略列表
|
||||
|
||||
### 6. Controller 层（部分完成）✅
|
||||
|
||||
已创建：
|
||||
- `NbaQuantitativeStrategyController.kt`: 策略管理 API
|
||||
- `POST /api/nba/strategies/create`: 创建策略
|
||||
- `POST /api/nba/strategies/update`: 更新策略
|
||||
- `POST /api/nba/strategies/list`: 获取策略列表
|
||||
- `POST /api/nba/strategies/detail`: 获取策略详情
|
||||
- `POST /api/nba/strategies/delete`: 删除策略
|
||||
|
||||
---
|
||||
|
||||
## 待完成部分
|
||||
|
||||
### 1. NBA 市场数据获取服务 ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaMarketService.kt`:
|
||||
- 从 Polymarket API 获取市场列表
|
||||
- 同步市场数据到数据库
|
||||
- 根据条件查询市场
|
||||
- 匹配 NBA 比赛和市场
|
||||
|
||||
**参考文档**: `docs/zh/polymarket-nba-markets-fetching-solution.md`
|
||||
|
||||
### 2. NBA 比赛数据获取服务 ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaGameService.kt`:
|
||||
- 从 NBA API 获取比赛数据
|
||||
- 同步比赛数据到数据库
|
||||
- 实时更新比赛状态
|
||||
- 匹配比赛和市场
|
||||
|
||||
**需要集成**: NBA Stats API 或第三方 NBA 数据 API
|
||||
|
||||
### 3. 量化分析服务 ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaQuantitativeAnalysisService.kt`:
|
||||
- 综合评分计算
|
||||
- 对位分析
|
||||
- 实时状态分析
|
||||
- 获胜概率计算
|
||||
- 交易价值计算
|
||||
|
||||
**参考文档**: `docs/zh/nba-quantitative-strategy-algorithm.md`
|
||||
|
||||
### 4. 交易信号生成服务 ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaTradingSignalService.kt`:
|
||||
- 生成买入信号
|
||||
- 生成卖出信号
|
||||
- 风险控制检查
|
||||
- 信号验证
|
||||
|
||||
### 5. WebSocket 推送服务 ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaTradingSignalPushService.kt`:
|
||||
- WebSocket 连接管理
|
||||
- 信号推送
|
||||
- 订阅管理
|
||||
|
||||
**参考**: 现有的 `OrderPushService.kt`
|
||||
|
||||
### 6. 定时任务和同步服务 ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaMarketSyncScheduler.kt`: 同步 NBA 市场数据
|
||||
- `NbaGameSyncScheduler.kt`: 同步 NBA 比赛数据
|
||||
- `NbaQuantitativeAnalysisScheduler.kt`: 定时执行量化分析
|
||||
|
||||
### 7. 其他 Controller ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaMarketController.kt`: 市场数据 API
|
||||
- `NbaGameController.kt`: 比赛数据 API
|
||||
- `NbaTradingSignalController.kt`: 交易信号 API
|
||||
- `NbaStatisticsController.kt`: 统计 API
|
||||
|
||||
### 8. 其他 DTO ⏳
|
||||
|
||||
**需要创建**:
|
||||
- `NbaMarketDto.kt`
|
||||
- `NbaGameDto.kt`
|
||||
- `NbaTradingSignalDto.kt`
|
||||
- `NbaStatisticsDto.kt`
|
||||
|
||||
---
|
||||
|
||||
## 实现优先级
|
||||
|
||||
### 第一阶段（核心功能）
|
||||
1. ✅ 数据库设计和实体类
|
||||
2. ✅ 策略管理服务（CRUD）
|
||||
3. ⏳ NBA 市场数据获取服务
|
||||
4. ⏳ NBA 比赛数据获取服务
|
||||
|
||||
### 第二阶段（量化分析）
|
||||
5. ⏳ 量化分析服务
|
||||
6. ⏳ 交易信号生成服务
|
||||
7. ⏳ 风险控制逻辑
|
||||
|
||||
### 第三阶段（实时推送）
|
||||
8. ⏳ WebSocket 推送服务
|
||||
9. ⏳ 定时任务和同步服务
|
||||
|
||||
### 第四阶段（完善功能）
|
||||
10. ⏳ 统计服务
|
||||
11. ⏳ 其他 API 接口
|
||||
12. ⏳ 错误处理和日志
|
||||
|
||||
---
|
||||
|
||||
## 技术要点
|
||||
|
||||
### 1. 数据同步策略
|
||||
- 市场数据：每天全量同步，每小时增量同步
|
||||
- 比赛数据：实时更新（比赛进行中）
|
||||
- 分析频率：根据策略配置（默认 30 秒）
|
||||
|
||||
### 2. 量化分析算法
|
||||
- 综合评分计算（基础实力、近期状态、阵容完整度等）
|
||||
- 对位分析（球星对位、阵容克制）
|
||||
- 实时状态分析（分差、势头）
|
||||
- 获胜概率计算
|
||||
- 交易价值计算
|
||||
|
||||
### 3. 风险控制
|
||||
- 持仓限制检查
|
||||
- 每日限制检查
|
||||
- 价格容忍度检查
|
||||
- 概率置信度检查
|
||||
|
||||
### 4. WebSocket 推送
|
||||
- 实时推送交易信号
|
||||
- 支持订阅/取消订阅
|
||||
- 连接管理和重连机制
|
||||
|
||||
---
|
||||
|
||||
## 下一步工作
|
||||
|
||||
1. **实现 NBA 市场数据获取服务**
|
||||
- 参考 `polymarket-nba-markets-fetching-solution.md`
|
||||
- 实现批量查询和过滤逻辑
|
||||
|
||||
2. **实现 NBA 比赛数据获取服务**
|
||||
- 集成 NBA Stats API
|
||||
- 实现比赛数据同步和更新
|
||||
|
||||
3. **实现量化分析服务**
|
||||
- 参考 `nba-quantitative-strategy-algorithm.md`
|
||||
- 实现综合评分、对位分析、概率计算等核心算法
|
||||
|
||||
4. **实现交易信号生成服务**
|
||||
- 集成量化分析结果
|
||||
- 实现买入/卖出信号生成逻辑
|
||||
|
||||
5. **实现 WebSocket 推送服务**
|
||||
- 参考现有的 `OrderPushService`
|
||||
- 实现信号推送和订阅管理
|
||||
|
||||
---
|
||||
|
||||
**文档结束**
|
||||
|
||||
@@ -0,0 +1,100 @@
|
||||
# NBA 比赛数据来源对比
|
||||
|
||||
## 一、数据来源对比
|
||||
|
||||
### 1.1 NBA Stats API
|
||||
|
||||
**优势**：
|
||||
- ✅ 官方数据源，数据准确可靠
|
||||
- ✅ 包含完整的比赛数据（实时比分、状态、统计等）
|
||||
- ✅ 实时更新，数据最新
|
||||
- ✅ 免费使用
|
||||
- ✅ 支持历史数据查询
|
||||
|
||||
**劣势**：
|
||||
- ❌ 不包含 Polymarket 市场信息
|
||||
- ❌ 需要额外的匹配逻辑来关联 Polymarket 市场
|
||||
|
||||
**适用场景**：
|
||||
- 获取比赛基本信息（球队、日期、时间）
|
||||
- 获取实时比分和比赛状态
|
||||
- 获取比赛统计数据
|
||||
|
||||
### 1.2 Polymarket API
|
||||
|
||||
**优势**：
|
||||
- ✅ 直接获取交易市场信息
|
||||
- ✅ 包含市场 ID、价格、流动性等交易相关数据
|
||||
- ✅ 市场名称可能包含比赛信息
|
||||
|
||||
**劣势**：
|
||||
- ❌ 不包含实时比分和比赛状态
|
||||
- ❌ 无法直接搜索或筛选 NBA 市场（需要知道 condition_ids）
|
||||
- ❌ 市场名称格式不统一，解析困难
|
||||
- ❌ 数据不完整（缺少比赛详细信息）
|
||||
|
||||
**适用场景**：
|
||||
- 获取可交易的市场列表
|
||||
- 获取市场价格和流动性信息
|
||||
- 匹配比赛和交易市场
|
||||
|
||||
## 二、推荐方案
|
||||
|
||||
### 2.1 混合方案（推荐）
|
||||
|
||||
**策略**：结合两种数据源，发挥各自优势
|
||||
|
||||
**实现方式**：
|
||||
1. **主要数据源：NBA Stats API**
|
||||
- 获取完整的比赛数据（球队、日期、时间、比分、状态等）
|
||||
- 实时更新比赛状态
|
||||
|
||||
2. **补充数据源：Polymarket API**
|
||||
- 获取市场信息（市场 ID、价格、流动性等）
|
||||
- 通过球队名称和日期匹配比赛和市场
|
||||
|
||||
3. **数据匹配**
|
||||
- 使用球队名称和比赛日期匹配
|
||||
- 建立比赛和市场的关联关系
|
||||
|
||||
### 2.2 数据流程
|
||||
|
||||
```
|
||||
1. 从 NBA Stats API 获取比赛列表
|
||||
↓
|
||||
2. 从 Polymarket API 获取市场列表（如果知道 condition_ids）
|
||||
↓
|
||||
3. 解析市场名称，提取球队和日期信息
|
||||
↓
|
||||
4. 匹配比赛和市场（通过球队名称和日期）
|
||||
↓
|
||||
5. 合并数据，返回完整的比赛和市场信息
|
||||
```
|
||||
|
||||
## 三、当前实现
|
||||
|
||||
当前系统使用 **NBA Stats API** 作为主要数据源，原因：
|
||||
- 数据完整可靠
|
||||
- 实时更新
|
||||
- 免费使用
|
||||
- 无需预先知道 condition_ids
|
||||
|
||||
如果需要 Polymarket 市场信息，可以：
|
||||
1. 在获取比赛数据后，通过球队名称和日期匹配 Polymarket 市场
|
||||
2. 或者单独维护一个 Polymarket 市场列表，定期同步
|
||||
|
||||
## 四、建议
|
||||
|
||||
**对于获取比赛数据**：
|
||||
- ✅ 使用 NBA Stats API（当前实现）
|
||||
- ✅ 实时、准确、完整
|
||||
|
||||
**对于获取市场信息**：
|
||||
- ✅ 使用 Polymarket API（需要知道 condition_ids）
|
||||
- ✅ 或者从市场名称解析（如果格式统一）
|
||||
|
||||
**最佳实践**：
|
||||
- 主要使用 NBA Stats API 获取比赛数据
|
||||
- 使用 Polymarket API 获取市场信息并匹配
|
||||
- 建立比赛和市场的关联关系
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
# NBA 比赛数据获取实现
|
||||
|
||||
## 一、概述
|
||||
|
||||
本系统从 NBA Stats API 实时获取 NBA 比赛数据：
|
||||
- **数据源**：NBA Stats API（官方数据源，实时、准确、完整）
|
||||
- **不依赖数据库**：所有数据从 API 实时获取
|
||||
|
||||
## 二、实现架构
|
||||
|
||||
### 2.1 数据流程
|
||||
|
||||
```
|
||||
1. 从 NBA Stats API 获取比赛列表（实时）
|
||||
↓
|
||||
2. 解析 API 响应，转换为 DTO
|
||||
↓
|
||||
3. 返回比赛数据给前端
|
||||
```
|
||||
|
||||
### 2.2 关于 Polymarket 市场匹配
|
||||
|
||||
**当前实现**：
|
||||
- 不进行市场匹配（因为 Polymarket API 限制）
|
||||
- 比赛数据中的 `polymarketMarketId` 字段为 `null`
|
||||
|
||||
**未来扩展**：
|
||||
- 如果将来有办法获取 condition_ids，可以从 Polymarket API 实时获取市场信息
|
||||
- 已保留 `NbaMarketNameParser` 工具类，可用于市场名称解析
|
||||
|
||||
### 2.2 核心组件
|
||||
|
||||
#### 1. NbaGameService
|
||||
- **功能**：从 NBA Stats API 实时获取比赛数据
|
||||
- **数据源**：NBA Stats API（官方数据源）
|
||||
- **特点**：
|
||||
- 实时获取，不依赖数据库
|
||||
- 支持日期范围查询
|
||||
- 支持按状态过滤
|
||||
|
||||
#### 2. NbaMarketNameParser（保留，供将来使用）
|
||||
- **功能**：解析 Polymarket 市场名称，提取球队和日期信息
|
||||
- **支持格式**：
|
||||
- "Team1 vs Team2"
|
||||
- "Team1 @ Team2"
|
||||
- "Will Team1 beat Team2"
|
||||
- "Team1 win"
|
||||
- **日期格式**：
|
||||
- "Dec 15, 2024"
|
||||
- "2024-12-15"
|
||||
- "12/15/2024"
|
||||
- **说明**：当前未使用，保留以备将来扩展
|
||||
|
||||
## 三、实现细节
|
||||
|
||||
### 3.1 比赛数据获取
|
||||
|
||||
**获取流程**：
|
||||
1. 根据日期范围，每天调用一次 NBA Stats API
|
||||
2. 解析 Scoreboard 响应，提取比赛信息
|
||||
3. 组合 GameHeader 和 LineScore 数据
|
||||
4. 转换为 NbaGameDto 返回
|
||||
|
||||
**数据字段**：
|
||||
- 比赛基本信息（球队、日期、时间）
|
||||
- 实时比分和状态
|
||||
- 比赛节次和剩余时间
|
||||
- 球队统计信息
|
||||
|
||||
### 3.2 关于市场匹配（未来扩展）
|
||||
|
||||
**当前状态**：
|
||||
- 不进行市场匹配
|
||||
- `polymarketMarketId` 字段为 `null`
|
||||
|
||||
**未来扩展方案**：
|
||||
如果将来需要匹配市场，可以考虑：
|
||||
1. 从其他来源获取 condition_ids（如爬取、手动维护等）
|
||||
2. 使用 Polymarket API 实时查询这些市场
|
||||
3. 使用 `NbaMarketNameParser` 解析市场名称并匹配
|
||||
|
||||
### 3.3 数据返回
|
||||
|
||||
**NbaGameDto** 包含：
|
||||
- 比赛基本信息（从 NBA Stats API）
|
||||
- `polymarketMarketId`：当前为 `null`（未来可扩展）
|
||||
|
||||
## 四、使用方式
|
||||
|
||||
### 4.1 API 调用
|
||||
|
||||
```kotlin
|
||||
// 获取比赛列表（自动匹配市场）
|
||||
val request = NbaGameListRequest(
|
||||
startDate = "2024-12-15",
|
||||
endDate = "2024-12-22"
|
||||
)
|
||||
val result = nbaGameService.getNbaGames(request)
|
||||
```
|
||||
|
||||
### 4.2 返回数据
|
||||
|
||||
```kotlin
|
||||
data class NbaGameDto(
|
||||
val nbaGameId: String?,
|
||||
val homeTeam: String,
|
||||
val awayTeam: String,
|
||||
val gameDate: LocalDate,
|
||||
val gameStatus: String,
|
||||
val homeScore: Int,
|
||||
val awayScore: Int,
|
||||
val polymarketMarketId: String? // 匹配的市场 ID
|
||||
)
|
||||
```
|
||||
|
||||
## 五、优势
|
||||
|
||||
1. **数据完整**：从 NBA Stats API 获取完整的比赛数据
|
||||
2. **实时更新**：比赛数据实时获取，不依赖数据库
|
||||
3. **简单高效**：直接调用 API，无需维护数据库
|
||||
4. **官方数据源**：数据准确可靠
|
||||
|
||||
## 六、注意事项
|
||||
|
||||
1. **API 限制**：
|
||||
- NBA Stats API 需要设置正确的请求头
|
||||
- 建议控制请求频率（< 10 请求/秒）
|
||||
|
||||
2. **市场匹配**：
|
||||
- 当前不进行市场匹配
|
||||
- 如果需要匹配，需要解决 Polymarket API 的限制（需要知道 condition_ids）
|
||||
|
||||
3. **性能考虑**：
|
||||
- 日期范围查询会多次调用 API（每天一次）
|
||||
- 建议合理设置日期范围，避免查询过长的时间段
|
||||
|
||||
## 七、后续优化
|
||||
|
||||
1. **缓存机制**：
|
||||
- 缓存 API 响应，减少重复请求
|
||||
- 设置合理的缓存时间（如 30 秒）
|
||||
|
||||
2. **错误处理**：
|
||||
- 实现重试机制（指数退避）
|
||||
- 处理 API 临时不可用的情况
|
||||
|
||||
3. **市场匹配（可选）**：
|
||||
- 如果将来有办法获取 condition_ids，可以实现市场匹配
|
||||
- 使用 `NbaMarketNameParser` 进行市场名称解析
|
||||
|
||||
@@ -0,0 +1,834 @@
|
||||
# NBA 量化交易策略算法文档
|
||||
|
||||
## 一、算法概述
|
||||
|
||||
### 1.1 算法目标
|
||||
|
||||
本算法基于 NBA 比赛数据，通过量化分析两支队伍的实力、状态、对位关系等因素，计算出哪支队伍具有更高的获胜概率和交易价值，从而生成买入/卖出交易信号。
|
||||
|
||||
### 1.2 算法流程
|
||||
|
||||
```
|
||||
获取比赛数据（主队 vs 客队）
|
||||
↓
|
||||
数据预处理和特征提取
|
||||
↓
|
||||
计算两队综合评分
|
||||
↓
|
||||
计算获胜概率和预期收益
|
||||
↓
|
||||
生成交易信号（买入/卖出）
|
||||
↓
|
||||
风险控制检查
|
||||
↓
|
||||
输出交易信号
|
||||
```
|
||||
|
||||
### 1.3 核心思想
|
||||
|
||||
**不是简单的"主队落后买入"，而是**：
|
||||
- 综合分析两支队伍的各项指标
|
||||
- 计算每支队伍的相对优势和劣势
|
||||
- 评估交易价值和风险
|
||||
- 选择最优的交易方向和时机
|
||||
|
||||
---
|
||||
|
||||
## 二、数据预处理
|
||||
|
||||
### 2.1 基础数据获取
|
||||
|
||||
**比赛基本信息**：
|
||||
- 比赛 ID、日期、主客场
|
||||
- 当前比分、分差、节次、剩余时间
|
||||
- 比赛状态（未开始/进行中/已结束）
|
||||
|
||||
**球队基础数据**：
|
||||
- 主队和客队的基本信息
|
||||
- 当前赛季的统计数据
|
||||
- 近期表现数据（近 5 场/10 场）
|
||||
|
||||
**球员数据**：
|
||||
- 核心球员的统计数据
|
||||
- 球员健康状况和轮休情况
|
||||
- 球员近期表现
|
||||
|
||||
### 2.2 数据清洗
|
||||
|
||||
**异常值处理**：
|
||||
- 检查数据合理性（如得分不超过 200 分）
|
||||
- 处理缺失值（使用历史平均值或默认值）
|
||||
- 处理异常数据（如负分差、超时时间等）
|
||||
|
||||
**数据标准化**：
|
||||
- 将不同量纲的数据标准化到统一范围
|
||||
- 使用 Z-score 或 Min-Max 归一化
|
||||
- 确保数据在 [0, 1] 或 [-1, 1] 范围内
|
||||
|
||||
### 2.3 特征工程
|
||||
|
||||
**基础特征**：
|
||||
- 当前分差（主队得分 - 客队得分）
|
||||
- 剩余时间（分钟）
|
||||
- 当前节次（1-4，加时）
|
||||
- 比赛状态
|
||||
|
||||
**统计特征**：
|
||||
- 球队净效率值（进攻效率 - 防守效率）
|
||||
- 球队比赛节奏（Pace）
|
||||
- 球队关键时刻表现（Clutch 数据）
|
||||
- 球队主客场表现差异
|
||||
|
||||
**动态特征**：
|
||||
- 势头动量（过去 N 回合的净胜分）
|
||||
- 手感热度（近期命中率）
|
||||
- 阵容对位优势
|
||||
- 球星爆发因子
|
||||
|
||||
---
|
||||
|
||||
## 三、综合评分算法
|
||||
|
||||
### 3.1 球队实力评分
|
||||
|
||||
#### 3.1.1 基础实力评分
|
||||
|
||||
**计算公式**：
|
||||
```
|
||||
基础实力评分 = 净效率值评分 × W1 + 攻防效率评分 × W2 + 节奏评分 × W3
|
||||
```
|
||||
|
||||
**评分组成**：
|
||||
- **净效率值评分**：基于球队赛季平均净效率值，归一化到 [0, 1]
|
||||
- 评分 = (净效率值 - 联盟最低值) / (联盟最高值 - 联盟最低值)
|
||||
- **攻防效率评分**：综合考虑进攻效率和防守效率
|
||||
- 进攻效率评分 = (进攻效率排名 - 1) / (总球队数 - 1)，排名越靠前评分越高
|
||||
- 防守效率评分 = (防守效率排名 - 1) / (总球队数 - 1)，排名越靠前评分越高
|
||||
- 攻防效率评分 = (进攻效率评分 + 防守效率评分) / 2
|
||||
- **节奏评分**：基于比赛节奏（Pace）
|
||||
- 节奏评分 = (Pace - 联盟最低值) / (联盟最高值 - 联盟最低值)
|
||||
|
||||
**权重设置**：
|
||||
- W1 = 0.5（净效率值权重最高）
|
||||
- W2 = 0.3（攻防效率权重）
|
||||
- W3 = 0.2（节奏权重）
|
||||
|
||||
#### 3.1.2 近期状态评分
|
||||
|
||||
**计算公式**：
|
||||
```
|
||||
近期状态评分 = 近期胜率评分 × W1 + 近期净效率值变化 × W2 + 势头评分 × W3
|
||||
```
|
||||
|
||||
**评分组成**：
|
||||
- **近期胜率评分**：近 5 场或 10 场胜率
|
||||
- 评分 = 近期胜率（0-1）
|
||||
- **近期净效率值变化**：近期净效率值与赛季平均的差值
|
||||
- 变化 = (近期净效率值 - 赛季平均净效率值) / 赛季平均净效率值
|
||||
- 评分 = (变化 + 1) / 2（归一化到 [0, 1]）
|
||||
- **势头评分**：基于连胜/连败场次
|
||||
- 连胜：评分 = min(连胜场次 / 5, 1)
|
||||
- 连败：评分 = max(1 - 连败场次 / 5, 0)
|
||||
|
||||
**权重设置**：
|
||||
- W1 = 0.4（胜率权重）
|
||||
- W2 = 0.4（净效率值变化权重）
|
||||
- W3 = 0.2（势头权重）
|
||||
|
||||
#### 3.1.3 阵容完整度评分
|
||||
|
||||
**计算公式**：
|
||||
```
|
||||
阵容完整度评分 = 1 - (缺失球员总VORP / 球队总VORP)
|
||||
```
|
||||
|
||||
**评分说明**：
|
||||
- 如果所有核心球员都在，评分为 1.0
|
||||
- 如果有核心球员缺席，根据缺失球员的 VORP 值降低评分
|
||||
- 缺失球员越多、重要性越高，评分越低
|
||||
|
||||
#### 3.1.4 球星状态评分
|
||||
|
||||
**计算公式**：
|
||||
```
|
||||
球星状态评分 = 核心球星PER评分 × W1 + 核心球星TS%评分 × W2 + 核心球星健康评分 × W3
|
||||
```
|
||||
|
||||
**评分组成**：
|
||||
- **核心球星 PER 评分**：基于近期 PER 与赛季平均的对比
|
||||
- 评分 = (近期PER - 赛季平均PER) / 赛季平均PER + 1，归一化到 [0, 1]
|
||||
- **核心球星 TS% 评分**：基于近期真实命中率
|
||||
- 评分 = (近期TS% - 赛季平均TS%) / 赛季平均TS% + 1，归一化到 [0, 1]
|
||||
- **核心球星健康评分**：
|
||||
- 健康：1.0
|
||||
- 出战成疑：0.7
|
||||
- 缺席：0.3
|
||||
|
||||
**权重设置**：
|
||||
- W1 = 0.4（PER 权重）
|
||||
- W2 = 0.4（TS% 权重）
|
||||
- W3 = 0.2（健康权重）
|
||||
|
||||
#### 3.1.5 环境因素评分
|
||||
|
||||
**计算公式**：
|
||||
```
|
||||
环境因素评分 = 主客场优势评分 × W1 + 休息天数评分 × W2 + 背靠背影响评分 × W3
|
||||
```
|
||||
|
||||
**评分组成**：
|
||||
- **主客场优势评分**：
|
||||
- 主场：1.0
|
||||
- 客场：基于客场胜率，评分 = 客场胜率 / 主场胜率
|
||||
- **休息天数评分**：
|
||||
- 休息 1 天：0.9
|
||||
- 休息 2 天：1.0（最优）
|
||||
- 休息 3 天以上：0.95
|
||||
- **背靠背影响评分**：
|
||||
- 非背靠背：1.0
|
||||
- 背靠背第二场：0.85
|
||||
|
||||
**权重设置**：
|
||||
- W1 = 0.5（主客场权重最高）
|
||||
- W2 = 0.3（休息天数权重）
|
||||
- W3 = 0.2（背靠背权重）
|
||||
|
||||
### 3.2 综合评分计算
|
||||
|
||||
**主队综合评分**：
|
||||
```
|
||||
主队综合评分 = 基础实力评分 × 0.3
|
||||
+ 近期状态评分 × 0.25
|
||||
+ 阵容完整度评分 × 0.2
|
||||
+ 球星状态评分 × 0.15
|
||||
+ 环境因素评分 × 0.1
|
||||
```
|
||||
|
||||
**客队综合评分**：
|
||||
```
|
||||
客队综合评分 = 基础实力评分 × 0.3
|
||||
+ 近期状态评分 × 0.25
|
||||
+ 阵容完整度评分 × 0.2
|
||||
+ 球星状态评分 × 0.15
|
||||
+ 环境因素评分 × 0.1
|
||||
```
|
||||
|
||||
**相对优势评分**：
|
||||
```
|
||||
主队相对优势 = 主队综合评分 - 客队综合评分
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、对位分析算法
|
||||
|
||||
### 4.1 球星对位分析
|
||||
|
||||
**对位优势评分**：
|
||||
```
|
||||
对位优势评分 = 防守限制效果评分 × W1 + 历史对位数据评分 × W2
|
||||
```
|
||||
|
||||
**评分组成**：
|
||||
- **防守限制效果评分**：基于防守球员的 DRPM 和进攻球员的 ORPM
|
||||
- 如果防守球员 DRPM 高，且进攻球员 ORPM 高，则限制效果好
|
||||
- 评分 = (防守球员DRPM - 联盟平均DRPM) / (联盟最高DRPM - 联盟平均DRPM)
|
||||
- **历史对位数据评分**：基于历史对位时的表现
|
||||
- 对位效率差 = (对位时进攻球员TS% - 赛季平均TS%)
|
||||
- 评分 = 1 - (对位效率差 / 最大可能效率差)，归一化到 [0, 1]
|
||||
|
||||
**权重设置**：
|
||||
- W1 = 0.6（防守限制效果权重）
|
||||
- W2 = 0.4（历史对位数据权重）
|
||||
|
||||
### 4.2 阵容克制分析
|
||||
|
||||
**阵容克制评分**：
|
||||
```
|
||||
阵容克制评分 = 内线优势评分 × W1 + 外线优势评分 × W2 + 快攻优势评分 × W3
|
||||
```
|
||||
|
||||
**评分组成**：
|
||||
- **内线优势评分**：
|
||||
- 如果主队内线得分占比高，且客队内线防守效率低，则主队有优势
|
||||
- 评分 = (主队内线得分占比 - 客队内线防守效率排名归一化) / 2
|
||||
- **外线优势评分**：
|
||||
- 如果主队三分出手占比高，且客队三分防守效率低，则主队有优势
|
||||
- 评分 = (主队三分出手占比 - 客队三分防守效率排名归一化) / 2
|
||||
- **快攻优势评分**：
|
||||
- 如果主队快攻得分占比高，且客队快攻防守效率低，则主队有优势
|
||||
- 评分 = (主队快攻得分占比 - 客队快攻防守效率排名归一化) / 2
|
||||
|
||||
**权重设置**：
|
||||
- W1 = 0.4（内线权重）
|
||||
- W2 = 0.4（外线权重）
|
||||
- W3 = 0.2（快攻权重）
|
||||
|
||||
### 4.3 对位综合评分
|
||||
|
||||
**主队对位优势**：
|
||||
```
|
||||
主队对位优势 = 主队球星对位优势 - 客队球星对位优势
|
||||
+ 主队阵容克制优势 - 客队阵容克制优势
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、实时状态分析算法
|
||||
|
||||
### 5.1 比赛进行中的实时分析
|
||||
|
||||
#### 5.1.1 当前分差分析
|
||||
|
||||
**分差优势评分**：
|
||||
```
|
||||
分差优势评分 = (当前分差 / 最大可能分差) × 时间调整系数
|
||||
```
|
||||
|
||||
**时间调整系数**：
|
||||
- 比赛早期（第1-2节）：系数 = 0.3（分差影响较小）
|
||||
- 比赛中期（第3节）：系数 = 0.6（分差影响中等）
|
||||
- 比赛后期（第4节）：系数 = 1.0（分差影响最大）
|
||||
- 最后5分钟：系数 = 1.2（分差影响极大）
|
||||
|
||||
#### 5.1.2 势头动量分析
|
||||
|
||||
**势头动量评分**：
|
||||
```
|
||||
势头动量 = (过去N回合净胜分) / (N × 平均单回合得分)
|
||||
```
|
||||
|
||||
**评分说明**：
|
||||
- 如果主队过去 10 回合净胜 +8 分，则主队势头强劲
|
||||
- 势头动量 > 0.3：势头强劲
|
||||
- 势头动量 < -0.3：势头疲软
|
||||
|
||||
#### 5.1.3 实时综合评分调整
|
||||
|
||||
**实时调整公式**：
|
||||
```
|
||||
实时调整评分 = 基础综合评分
|
||||
+ 分差优势评分 × 0.3
|
||||
+ 势头动量评分 × 0.2
|
||||
- 时间衰减系数 × 0.1
|
||||
```
|
||||
|
||||
**时间衰减系数**：
|
||||
- 比赛越接近结束，基础评分的影响越小，实时状态的影响越大
|
||||
- 时间衰减系数 = (剩余时间 / 总时间) × 0.5
|
||||
|
||||
### 5.2 比赛未开始时的预测分析
|
||||
|
||||
**预测综合评分**：
|
||||
```
|
||||
预测综合评分 = 基础综合评分
|
||||
+ 对位优势评分 × 0.2
|
||||
+ 环境因素评分 × 0.1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、获胜概率计算
|
||||
|
||||
### 6.1 基础获胜概率
|
||||
|
||||
**基于综合评分的概率**：
|
||||
```
|
||||
基础获胜概率 = 1 / (1 + exp(-k × (主队综合评分 - 客队综合评分)))
|
||||
```
|
||||
|
||||
**参数说明**：
|
||||
- k 为调整系数，通常取 5-10
|
||||
- 如果主队综合评分 > 客队综合评分，则主队获胜概率 > 0.5
|
||||
- 如果主队综合评分 = 客队综合评分，则主队获胜概率 = 0.5
|
||||
|
||||
### 6.2 对位调整概率
|
||||
|
||||
**对位调整**：
|
||||
```
|
||||
调整后概率 = 基础获胜概率 + 对位优势调整值
|
||||
```
|
||||
|
||||
**对位优势调整值**：
|
||||
- 如果主队对位优势 > 0.1，则调整值 = +0.05
|
||||
- 如果主队对位优势 < -0.1，则调整值 = -0.05
|
||||
- 调整值范围：[-0.1, +0.1]
|
||||
|
||||
### 6.3 实时状态调整概率
|
||||
|
||||
**实时调整**（仅比赛进行中）：
|
||||
```
|
||||
最终概率 = 调整后概率
|
||||
+ 分差调整值 × 0.3
|
||||
+ 势头调整值 × 0.2
|
||||
```
|
||||
|
||||
**分差调整值**：
|
||||
- 如果主队领先，且剩余时间充足，则调整值 = +0.05
|
||||
- 如果主队落后，且剩余时间不足，则调整值 = -0.05
|
||||
|
||||
**势头调整值**：
|
||||
- 如果主队势头强劲，则调整值 = +0.03
|
||||
- 如果主队势头疲软，则调整值 = -0.03
|
||||
|
||||
### 6.4 概率归一化
|
||||
|
||||
**确保概率在 [0, 1] 范围内**：
|
||||
```
|
||||
最终概率 = max(0, min(1, 最终概率))
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 七、交易价值计算
|
||||
|
||||
### 7.1 预期收益计算
|
||||
|
||||
**预期收益公式**：
|
||||
```
|
||||
预期收益 = (获胜概率 × 获胜收益) - ((1 - 获胜概率) × 失败损失)
|
||||
```
|
||||
|
||||
**收益和损失**：
|
||||
- 如果买入主队获胜（YES），价格为 P
|
||||
- 获胜收益 = (1 - P) × 投入金额
|
||||
- 失败损失 = P × 投入金额
|
||||
- 如果买入主队失败（NO），价格为 P
|
||||
- 获胜收益 = P × 投入金额
|
||||
- 失败损失 = (1 - P) × 投入金额
|
||||
|
||||
### 7.2 风险调整收益
|
||||
|
||||
**风险调整公式**：
|
||||
```
|
||||
风险调整收益 = 预期收益 × (1 - 风险系数)
|
||||
```
|
||||
|
||||
**风险系数计算**：
|
||||
```
|
||||
风险系数 = 概率不确定性 × 0.5 + 价格波动风险 × 0.3 + 流动性风险 × 0.2
|
||||
```
|
||||
|
||||
**风险组成**：
|
||||
- **概率不确定性**：如果获胜概率接近 0.5，则不确定性高
|
||||
- 不确定性 = 1 - |获胜概率 - 0.5| × 2
|
||||
- **价格波动风险**：基于市场价格的波动性
|
||||
- 如果价格波动大，则风险高
|
||||
- **流动性风险**：基于市场的流动性
|
||||
- 如果市场流动性低，则风险高
|
||||
|
||||
### 7.3 交易价值评分
|
||||
|
||||
**交易价值评分**：
|
||||
```
|
||||
交易价值评分 = 风险调整收益 / 投入金额
|
||||
```
|
||||
|
||||
**评分说明**：
|
||||
- 交易价值评分 > 0.1：高价值交易，强烈推荐
|
||||
- 交易价值评分 > 0.05：中等价值交易，推荐
|
||||
- 交易价值评分 > 0：低价值交易，可考虑
|
||||
- 交易价值评分 <= 0：无价值交易，不推荐
|
||||
|
||||
---
|
||||
|
||||
## 八、交易信号生成算法
|
||||
|
||||
### 8.1 信号生成条件
|
||||
|
||||
**买入信号生成条件**：
|
||||
1. **获胜概率条件**：
|
||||
- 主队获胜概率 > 阈值（如 0.55）或 < 阈值（如 0.45）
|
||||
- 如果主队获胜概率 > 0.55，买入主队获胜（YES）
|
||||
- 如果主队获胜概率 < 0.45，买入主队失败（NO）
|
||||
|
||||
2. **交易价值条件**：
|
||||
- 交易价值评分 > 用户配置的最小交易价值（如 0.05）
|
||||
|
||||
3. **价格条件**：
|
||||
- 当前市场价格在合理范围内
|
||||
- 价格偏差在用户配置的容忍度内
|
||||
|
||||
4. **时间条件**：
|
||||
- 比赛未结束
|
||||
- 剩余时间充足（如果用户配置了最小剩余时间）
|
||||
|
||||
### 8.2 信号方向确定
|
||||
|
||||
**方向判断逻辑**：
|
||||
```
|
||||
如果 主队获胜概率 > 0.55：
|
||||
方向 = YES（买入主队获胜）
|
||||
目标价格 = 市场价格（如果合理）
|
||||
|
||||
如果 主队获胜概率 < 0.45：
|
||||
方向 = NO（买入主队失败）
|
||||
目标价格 = 1 - 市场价格（如果合理）
|
||||
|
||||
如果 0.45 <= 主队获胜概率 <= 0.55：
|
||||
不生成信号（概率太接近，不确定性高）
|
||||
```
|
||||
|
||||
### 8.3 信号价格计算
|
||||
|
||||
**价格计算策略**：
|
||||
|
||||
**策略一：固定价格**（用户配置）
|
||||
```
|
||||
信号价格 = 用户配置的固定价格
|
||||
```
|
||||
|
||||
**策略二：市场价格**（默认）
|
||||
```
|
||||
信号价格 = 当前市场价格
|
||||
```
|
||||
|
||||
**策略三：动态价格**（基于概率）
|
||||
```
|
||||
如果 方向 = YES：
|
||||
信号价格 = 主队获胜概率 × (1 + 价格偏移)
|
||||
|
||||
如果 方向 = NO：
|
||||
信号价格 = (1 - 主队获胜概率) × (1 + 价格偏移)
|
||||
```
|
||||
|
||||
**价格偏移**：
|
||||
- 价格偏移 = 用户配置的价格偏移百分比（如 ±5%）
|
||||
- 用于调整价格，提高交易成功率
|
||||
|
||||
### 8.4 信号数量计算
|
||||
|
||||
**数量计算策略**：
|
||||
|
||||
**策略一：固定金额**（用户配置）
|
||||
```
|
||||
信号数量 = 用户配置的固定金额 / 信号价格
|
||||
```
|
||||
|
||||
**策略二：按比例**（用户配置）
|
||||
```
|
||||
信号数量 = 账户余额 × 用户配置的比例 / 信号价格
|
||||
```
|
||||
|
||||
**策略三：动态计算**（基于交易价值）
|
||||
```
|
||||
基础数量 = 用户配置的基础金额 / 信号价格
|
||||
调整系数 = min(交易价值评分 / 0.1, 2.0) // 最多放大2倍
|
||||
信号数量 = 基础数量 × 调整系数
|
||||
```
|
||||
|
||||
### 8.5 信号原因生成
|
||||
|
||||
**触发原因说明**：
|
||||
```
|
||||
触发原因 = "主队综合评分: {主队评分}, 客队综合评分: {客队评分}, "
|
||||
+ "获胜概率: {获胜概率}, 交易价值: {交易价值评分}, "
|
||||
+ "主要优势: {主要优势项}"
|
||||
```
|
||||
|
||||
**主要优势项识别**：
|
||||
- 如果基础实力评分差异最大，则主要优势 = "基础实力"
|
||||
- 如果近期状态评分差异最大，则主要优势 = "近期状态"
|
||||
- 如果对位优势明显，则主要优势 = "对位优势"
|
||||
- 如果实时状态优势明显，则主要优势 = "实时状态"
|
||||
|
||||
---
|
||||
|
||||
## 九、卖出信号生成算法
|
||||
|
||||
### 9.1 卖出条件
|
||||
|
||||
**卖出信号生成条件**：
|
||||
1. **止盈条件**：
|
||||
- 当前持仓的预期收益达到用户配置的止盈阈值（如 20%）
|
||||
- 或市场价格达到用户配置的目标价格
|
||||
|
||||
2. **止损条件**：
|
||||
- 当前持仓的预期亏损达到用户配置的止损阈值（如 -10%）
|
||||
- 或市场价格跌破用户配置的止损价格
|
||||
|
||||
3. **概率反转条件**：
|
||||
- 获胜概率发生反转（如从 0.6 降到 0.4）
|
||||
- 反转幅度超过用户配置的阈值（如 0.15）
|
||||
|
||||
4. **时间条件**：
|
||||
- 比赛接近结束（剩余时间 < 用户配置的最小剩余时间）
|
||||
- 或比赛已结束
|
||||
|
||||
### 9.2 卖出价格计算
|
||||
|
||||
**卖出价格**：
|
||||
```
|
||||
卖出价格 = 当前市场价格
|
||||
```
|
||||
|
||||
**价格调整**（可选）：
|
||||
```
|
||||
如果 止盈卖出：
|
||||
卖出价格 = min(当前市场价格, 目标价格)
|
||||
|
||||
如果 止损卖出：
|
||||
卖出价格 = max(当前市场价格, 止损价格)
|
||||
```
|
||||
|
||||
### 9.3 卖出数量计算
|
||||
|
||||
**卖出数量**：
|
||||
```
|
||||
如果 全部卖出：
|
||||
卖出数量 = 当前持仓数量
|
||||
|
||||
如果 部分卖出：
|
||||
卖出数量 = 当前持仓数量 × 用户配置的卖出比例
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 十、风险控制算法
|
||||
|
||||
### 10.1 持仓限制检查
|
||||
|
||||
**最大持仓检查**：
|
||||
```
|
||||
如果 信号数量 × 信号价格 > 用户配置的最大持仓：
|
||||
信号数量 = 用户配置的最大持仓 / 信号价格
|
||||
记录警告：超过最大持仓限制，已调整数量
|
||||
```
|
||||
|
||||
**最小持仓检查**：
|
||||
```
|
||||
如果 信号数量 × 信号价格 < 用户配置的最小持仓：
|
||||
不生成信号
|
||||
记录原因：金额低于最小持仓限制
|
||||
```
|
||||
|
||||
### 10.2 每日限制检查
|
||||
|
||||
**每日亏损限制**：
|
||||
```
|
||||
今日已亏损 = 今日所有交易的累计亏损
|
||||
|
||||
如果 今日已亏损 + 预期最大亏损 > 用户配置的每日亏损限制：
|
||||
不生成信号
|
||||
记录原因：超过每日亏损限制
|
||||
```
|
||||
|
||||
**每日订单限制**：
|
||||
```
|
||||
今日订单数 = 今日已生成的信号数量
|
||||
|
||||
如果 今日订单数 >= 用户配置的每日订单限制：
|
||||
不生成信号
|
||||
记录原因：超过每日订单限制
|
||||
```
|
||||
|
||||
### 10.3 价格容忍度检查
|
||||
|
||||
**价格偏差检查**：
|
||||
```
|
||||
价格偏差 = |信号价格 - 当前市场价格| / 当前市场价格
|
||||
|
||||
如果 价格偏差 > 用户配置的价格容忍度：
|
||||
不生成信号
|
||||
记录原因：价格偏差超过容忍度
|
||||
```
|
||||
|
||||
### 10.4 概率置信度检查
|
||||
|
||||
**概率置信度**：
|
||||
```
|
||||
如果 0.45 <= 获胜概率 <= 0.55：
|
||||
不生成信号
|
||||
记录原因：获胜概率太接近，不确定性高
|
||||
```
|
||||
|
||||
**最小概率阈值**（可选）：
|
||||
```
|
||||
如果 获胜概率 < 用户配置的最小概率阈值：
|
||||
不生成信号
|
||||
记录原因：获胜概率低于最小阈值
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 十一、算法参数配置
|
||||
|
||||
### 11.1 用户可配置参数
|
||||
|
||||
**触发条件参数**：
|
||||
- 最小获胜概率差异：主队和客队获胜概率的最小差异（如 0.1）
|
||||
- 最小交易价值：交易价值评分的最小值（如 0.05）
|
||||
- 最小剩余时间：生成信号时的最小剩余时间（如 5 分钟）
|
||||
|
||||
**交易规则参数**：
|
||||
- 买入金额策略：固定金额/按比例/动态计算
|
||||
- 买入金额：固定金额或比例值
|
||||
- 价格策略：固定价格/市场价格/动态价格
|
||||
- 价格偏移：价格偏移百分比（如 ±5%）
|
||||
|
||||
**风险控制参数**：
|
||||
- 最大持仓：单次最大买入金额
|
||||
- 最小持仓：单次最小买入金额
|
||||
- 每日亏损限制：每日最大亏损金额
|
||||
- 每日订单限制：每日最大订单数量
|
||||
- 价格容忍度：允许的价格偏差百分比
|
||||
|
||||
**卖出规则参数**：
|
||||
- 止盈阈值：预期收益达到多少时卖出（如 20%）
|
||||
- 止损阈值：预期亏损达到多少时卖出（如 -10%）
|
||||
- 概率反转阈值：概率反转多少时卖出（如 0.15）
|
||||
- 卖出比例：部分卖出时的比例（如 50%）
|
||||
|
||||
### 11.2 系统默认参数
|
||||
|
||||
**评分权重**（可根据历史数据优化）：
|
||||
- 基础实力权重：0.3
|
||||
- 近期状态权重：0.25
|
||||
- 阵容完整度权重：0.2
|
||||
- 球星状态权重：0.15
|
||||
- 环境因素权重：0.1
|
||||
|
||||
**概率计算参数**：
|
||||
- k 值（逻辑回归系数）：7.5
|
||||
- 对位调整范围：[-0.1, +0.1]
|
||||
- 实时调整权重：分差 0.3，势头 0.2
|
||||
|
||||
**风险系数权重**：
|
||||
- 概率不确定性权重：0.5
|
||||
- 价格波动风险权重：0.3
|
||||
- 流动性风险权重：0.2
|
||||
|
||||
---
|
||||
|
||||
## 十二、算法优化建议
|
||||
|
||||
### 12.1 参数优化
|
||||
|
||||
**历史回测优化**：
|
||||
- 使用历史数据回测不同参数组合
|
||||
- 找到最优的参数配置
|
||||
- 定期重新优化参数
|
||||
|
||||
**A/B 测试**：
|
||||
- 同时运行多组参数配置
|
||||
- 对比不同参数的效果
|
||||
- 选择最优参数组合
|
||||
|
||||
### 12.2 模型优化
|
||||
|
||||
**机器学习集成**：
|
||||
- 使用机器学习模型预测获胜概率
|
||||
- 使用梯度提升决策树（XGBoost/LightGBM）
|
||||
- 定期重新训练模型
|
||||
|
||||
**特征工程优化**：
|
||||
- 添加更多特征（如历史对战数据、伤病信息等）
|
||||
- 使用特征选择技术筛选重要特征
|
||||
- 使用特征交互提高预测准确性
|
||||
|
||||
### 12.3 实时优化
|
||||
|
||||
**动态权重调整**：
|
||||
- 根据比赛阶段动态调整权重
|
||||
- 比赛早期：基础实力权重高
|
||||
- 比赛后期：实时状态权重高
|
||||
|
||||
**自适应阈值**：
|
||||
- 根据市场情况动态调整阈值
|
||||
- 如果市场波动大，提高概率阈值
|
||||
- 如果市场稳定，降低概率阈值
|
||||
|
||||
---
|
||||
|
||||
## 十三、算法输出
|
||||
|
||||
### 13.1 信号输出格式
|
||||
|
||||
**买入信号**：
|
||||
```
|
||||
{
|
||||
"signalType": "BUY",
|
||||
"strategyId": "策略ID",
|
||||
"gameId": "比赛ID",
|
||||
"marketId": "市场ID",
|
||||
"direction": "YES" | "NO",
|
||||
"price": 0.65,
|
||||
"quantity": 10.0,
|
||||
"totalAmount": 6.5,
|
||||
"reason": "主队综合评分: 0.72, 客队综合评分: 0.58, 获胜概率: 0.62, 交易价值: 0.08, 主要优势: 基础实力",
|
||||
"winProbability": 0.62,
|
||||
"tradeValue": 0.08,
|
||||
"timestamp": 1234567890
|
||||
}
|
||||
```
|
||||
|
||||
**卖出信号**：
|
||||
```
|
||||
{
|
||||
"signalType": "SELL",
|
||||
"strategyId": "策略ID",
|
||||
"gameId": "比赛ID",
|
||||
"marketId": "市场ID",
|
||||
"direction": "YES" | "NO",
|
||||
"price": 0.75,
|
||||
"quantity": 10.0,
|
||||
"totalAmount": 7.5,
|
||||
"reason": "止盈卖出，预期收益: 15%",
|
||||
"profit": 1.0,
|
||||
"profitRate": 0.15,
|
||||
"timestamp": 1234567890
|
||||
}
|
||||
```
|
||||
|
||||
### 13.2 算法执行日志
|
||||
|
||||
**执行日志格式**：
|
||||
```
|
||||
{
|
||||
"timestamp": 1234567890,
|
||||
"strategyId": "策略ID",
|
||||
"gameId": "比赛ID",
|
||||
"step": "数据获取" | "特征提取" | "评分计算" | "信号生成",
|
||||
"status": "SUCCESS" | "FAILED" | "SKIPPED",
|
||||
"message": "执行信息",
|
||||
"data": {} // 相关数据
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 十四、算法验证
|
||||
|
||||
### 14.1 回测验证
|
||||
|
||||
**回测流程**：
|
||||
1. 使用历史比赛数据
|
||||
2. 模拟算法执行过程
|
||||
3. 计算信号生成情况
|
||||
4. 计算交易结果和盈亏
|
||||
5. 评估算法效果
|
||||
|
||||
**评估指标**：
|
||||
- 信号生成数量
|
||||
- 信号准确率（实际获胜 vs 预测获胜）
|
||||
- 总盈亏金额
|
||||
- 盈亏比率
|
||||
- 最大回撤
|
||||
|
||||
### 14.2 实时验证
|
||||
|
||||
**实时监控**：
|
||||
- 监控算法执行情况
|
||||
- 记录信号生成和交易结果
|
||||
- 对比预测和实际结果
|
||||
- 评估算法实时表现
|
||||
|
||||
**持续优化**：
|
||||
- 根据实时表现调整参数
|
||||
- 优化算法逻辑
|
||||
- 提高预测准确性
|
||||
|
||||
---
|
||||
|
||||
**文档结束**
|
||||
|
||||
@@ -0,0 +1,732 @@
|
||||
# NBA 量化交易系统产品需求文档
|
||||
|
||||
## 文档信息
|
||||
|
||||
- **文档版本**: v1.0
|
||||
- **创建日期**: 2024-12
|
||||
- **文档类型**: 产品需求文档 (PRD)
|
||||
- **目标用户**: 产品经理、开发团队、测试团队
|
||||
|
||||
---
|
||||
|
||||
## 一、产品概述
|
||||
|
||||
### 1.1 产品定位
|
||||
|
||||
NBA 量化交易系统是一个基于 NBA 比赛数据的智能量化交易平台，帮助用户通过配置量化策略参数，自动分析 NBA 比赛数据，生成买入/卖出交易信号，实现自动化交易决策。
|
||||
|
||||
### 1.2 产品目标
|
||||
|
||||
**核心目标**：
|
||||
- 提供简单易用的策略配置界面，降低量化交易门槛
|
||||
- 实时获取和分析 NBA 比赛数据，提供及时的交易信号
|
||||
- 支持多种量化策略，满足不同用户需求
|
||||
- 提供完善的风险控制机制，保障交易安全
|
||||
|
||||
**用户价值**：
|
||||
- **自动化决策**：无需人工盯盘，系统自动分析并生成交易信号
|
||||
- **数据驱动**：基于专业的 NBA 数据分析，提高决策准确性
|
||||
- **风险可控**：完善的风险控制参数，降低交易风险
|
||||
- **实时响应**：实时数据更新和信号推送，不错过交易机会
|
||||
|
||||
### 1.3 目标用户
|
||||
|
||||
**主要用户群体**：
|
||||
1. **量化交易爱好者**：对 NBA 和量化交易都有兴趣的用户
|
||||
2. **NBA 数据分析师**：希望将数据分析转化为交易信号的用户
|
||||
3. **自动化交易用户**：希望通过自动化系统进行交易的用户
|
||||
|
||||
**用户特征**：
|
||||
- 对 NBA 比赛有一定了解
|
||||
- 对量化交易有基本认知
|
||||
- 希望通过数据驱动的方式进行交易决策
|
||||
- 需要自动化工具提高交易效率
|
||||
|
||||
---
|
||||
|
||||
## 二、产品功能需求
|
||||
|
||||
### 2.1 策略配置管理
|
||||
|
||||
#### 2.1.1 策略创建
|
||||
|
||||
**功能描述**：
|
||||
用户可以在前端创建新的量化策略，配置策略的各项参数。
|
||||
|
||||
**功能点**：
|
||||
- **策略基本信息**：
|
||||
- 策略名称：用户自定义策略名称（必填，1-50 字符）
|
||||
- 策略描述：策略的简要说明（可选，最多 200 字符）
|
||||
- 关联账户：选择用于交易的账户（必填）
|
||||
- 启用状态：创建时默认启用，可后续修改
|
||||
|
||||
- **触发条件配置**：
|
||||
- 比赛筛选：
|
||||
- 按球队筛选：选择关注的球队（可选，不选择则分析所有比赛）
|
||||
- 按日期筛选：选择关注的日期范围
|
||||
- 按重要性筛选：选择比赛重要性（常规赛/季后赛/关键战）
|
||||
- 数据指标选择：
|
||||
- 基础指标：分差、剩余时间、当前节次、比赛状态
|
||||
- 统计指标：球队净效率值、球员 PER、真实命中率等
|
||||
- 高级指标：势头动量、球星爆发因子、阵容对位系数等
|
||||
- 说明：系统会综合分析两支队伍的各项指标，计算综合评分和获胜概率
|
||||
- 触发阈值设置：
|
||||
- 最小获胜概率差异：主队和客队获胜概率的最小差异（如 0.1 表示至少 10% 的差异）
|
||||
- 最小交易价值：交易价值评分的最小值（如 0.05）
|
||||
- 最小剩余时间：生成信号时的最小剩余时间（如 5 分钟，可选）
|
||||
- 说明：只有当系统计算出某支队伍获胜概率明显高于对手，且交易价值达到阈值时，才会生成买入信号
|
||||
|
||||
- **交易规则配置**：
|
||||
- 买入规则：
|
||||
- 买入条件：系统自动分析两支队伍，当某支队伍获胜概率明显高于对手且交易价值达到阈值时触发买入
|
||||
- 买入金额：固定金额或按比例计算或动态计算（基于交易价值）
|
||||
- 买入时机：立即买入或延迟买入
|
||||
- 买入方向：由系统自动判断（YES 或 NO，基于获胜概率高的队伍）
|
||||
- 说明：系统会综合分析两支队伍，选择获胜概率更高、交易价值更大的方向进行买入
|
||||
- 卖出规则：
|
||||
- 卖出条件：满足止盈、止损或概率反转条件时触发卖出
|
||||
- 卖出金额：全部卖出或部分卖出
|
||||
- 卖出时机：立即卖出或延迟卖出
|
||||
- 价格策略：
|
||||
- 固定价格：使用固定价格
|
||||
- 市场价格：使用当前市场价格
|
||||
- 动态价格：根据获胜概率和市场情况动态计算价格
|
||||
- 价格偏移：允许的价格偏差范围（用于调整价格，提高交易成功率）
|
||||
|
||||
- **风险控制配置**：
|
||||
- 持仓限制：
|
||||
- 最大持仓：单次最大买入金额（必填，>= 1 USDC）
|
||||
- 最小持仓：单次最小买入金额（必填，>= 1 USDC）
|
||||
- 每日限制：
|
||||
- 每日亏损限制：每日最大亏损金额（可选）
|
||||
- 每日订单限制：每日最大订单数量（可选）
|
||||
- 价格容忍度：
|
||||
- 价格偏差范围：允许的价格偏差百分比（可选，0-100%）
|
||||
|
||||
- **高级配置**：
|
||||
- 数据更新频率：NBA 数据更新频率（30 秒/1 分钟/5 分钟）
|
||||
- 分析频率：量化分析执行频率（30 秒/1 分钟/5 分钟）
|
||||
- 推送设置：
|
||||
- 是否推送失败订单：默认关闭
|
||||
- 推送频率：实时推送/批量推送
|
||||
|
||||
**交互流程**：
|
||||
1. 用户点击"创建策略"按钮
|
||||
2. 进入策略配置页面
|
||||
3. 填写策略基本信息
|
||||
4. 配置触发条件（可添加多个条件）
|
||||
5. 配置交易规则
|
||||
6. 配置风险控制参数
|
||||
7. 配置高级选项
|
||||
8. 点击"保存"按钮，系统验证配置
|
||||
9. 保存成功，返回策略列表
|
||||
|
||||
**验证规则**：
|
||||
- 策略名称不能为空，不能重复
|
||||
- 必须选择关联账户
|
||||
- 必须配置至少一个触发条件
|
||||
- 必须配置买入或卖出规则
|
||||
- 最大持仓必须 >= 最小持仓
|
||||
- 价格容忍度必须在 0-100% 范围内
|
||||
|
||||
#### 2.1.2 策略编辑
|
||||
|
||||
**功能描述**：
|
||||
用户可以编辑已有策略的配置参数。
|
||||
|
||||
**功能点**：
|
||||
- 支持修改策略的所有配置参数
|
||||
- 支持启用/禁用策略
|
||||
- 修改后立即生效（如果策略正在运行，会重新加载配置）
|
||||
|
||||
**交互流程**：
|
||||
1. 用户在策略列表中点击"编辑"按钮
|
||||
2. 进入策略编辑页面（与创建页面类似）
|
||||
3. 修改配置参数
|
||||
4. 点击"保存"按钮
|
||||
5. 系统验证并保存配置
|
||||
6. 返回策略列表
|
||||
|
||||
#### 2.1.3 策略删除
|
||||
|
||||
**功能描述**：
|
||||
用户可以删除不需要的策略。
|
||||
|
||||
**功能点**：
|
||||
- 删除前需要确认（防止误删）
|
||||
- 删除策略时，会停止该策略的所有量化任务
|
||||
- 删除后，该策略的历史信号记录会保留（用于统计分析）
|
||||
|
||||
**交互流程**：
|
||||
1. 用户在策略列表中点击"删除"按钮
|
||||
2. 弹出确认对话框
|
||||
3. 用户确认删除
|
||||
4. 系统删除策略并停止相关任务
|
||||
5. 返回策略列表
|
||||
|
||||
#### 2.1.4 策略列表
|
||||
|
||||
**功能描述**：
|
||||
展示所有策略配置，支持搜索、筛选、排序。
|
||||
|
||||
**功能点**：
|
||||
- **列表展示**：
|
||||
- 策略名称
|
||||
- 关联账户
|
||||
- 启用状态（启用/禁用）
|
||||
- 创建时间
|
||||
- 最后更新时间
|
||||
- 操作按钮（编辑/删除/启用/禁用）
|
||||
|
||||
- **搜索功能**：
|
||||
- 按策略名称搜索
|
||||
- 按账户名称搜索
|
||||
|
||||
- **筛选功能**：
|
||||
- 按启用状态筛选（全部/启用/禁用）
|
||||
- 按账户筛选
|
||||
|
||||
- **排序功能**：
|
||||
- 按创建时间排序（最新/最旧）
|
||||
- 按更新时间排序（最新/最旧）
|
||||
- 按策略名称排序（A-Z/Z-A）
|
||||
|
||||
- **分页功能**：
|
||||
- 每页显示 20 条记录
|
||||
- 支持翻页
|
||||
|
||||
**交互流程**：
|
||||
1. 用户进入策略列表页面
|
||||
2. 系统加载策略列表
|
||||
3. 用户可以搜索、筛选、排序
|
||||
4. 用户可以点击操作按钮进行编辑、删除、启用/禁用
|
||||
|
||||
### 2.2 交易信号展示
|
||||
|
||||
#### 2.2.1 实时信号列表
|
||||
|
||||
**功能描述**：
|
||||
实时展示系统生成的交易信号。
|
||||
|
||||
**功能点**：
|
||||
- **信号展示**：
|
||||
- 信号类型（买入/卖出）
|
||||
- 策略名称
|
||||
- 市场信息（市场 ID、市场标题）
|
||||
- 方向（YES/NO）
|
||||
- 价格
|
||||
- 数量
|
||||
- 触发原因
|
||||
- 生成时间
|
||||
- 信号状态（已生成/执行中/执行成功/执行失败）
|
||||
|
||||
- **实时更新**：
|
||||
- 通过 WebSocket 实时接收新信号
|
||||
- 新信号自动添加到列表顶部
|
||||
- 信号状态更新时实时刷新
|
||||
|
||||
- **筛选功能**：
|
||||
- 按信号类型筛选（全部/买入/卖出）
|
||||
- 按策略筛选
|
||||
- 按状态筛选（全部/已生成/执行中/成功/失败）
|
||||
- 按时间范围筛选
|
||||
|
||||
- **排序功能**：
|
||||
- 按生成时间排序（最新/最旧）
|
||||
- 按价格排序（高到低/低到高）
|
||||
|
||||
- **分页功能**：
|
||||
- 每页显示 50 条记录
|
||||
- 支持翻页
|
||||
|
||||
**交互流程**：
|
||||
1. 用户进入交易信号页面
|
||||
2. 系统建立 WebSocket 连接
|
||||
3. 系统订阅交易信号推送
|
||||
4. 实时接收并展示信号
|
||||
5. 用户可以筛选、排序、查看详情
|
||||
|
||||
#### 2.2.2 信号详情
|
||||
|
||||
**功能描述**：
|
||||
展示信号的详细信息。
|
||||
|
||||
**功能点**：
|
||||
- **基本信息**：
|
||||
- 信号 ID
|
||||
- 信号类型（买入/卖出）
|
||||
- 策略名称
|
||||
- 生成时间
|
||||
|
||||
- **市场信息**：
|
||||
- 市场 ID
|
||||
- 市场标题
|
||||
- 市场描述
|
||||
- 市场分类
|
||||
|
||||
- **交易信息**：
|
||||
- 方向（YES/NO）
|
||||
- 价格
|
||||
- 数量
|
||||
- 总金额
|
||||
|
||||
- **触发信息**：
|
||||
- 触发原因（详细说明）
|
||||
- 触发条件（展示满足的条件）
|
||||
- 触发时的比赛数据（分差、剩余时间等）
|
||||
|
||||
- **执行信息**：
|
||||
- 执行状态
|
||||
- 执行结果
|
||||
- 执行时间
|
||||
- 错误信息（如果执行失败）
|
||||
|
||||
**交互流程**：
|
||||
1. 用户在信号列表中点击某个信号
|
||||
2. 弹出信号详情对话框
|
||||
3. 展示信号的详细信息
|
||||
4. 用户可以关闭对话框
|
||||
|
||||
### 2.3 结果统计
|
||||
|
||||
#### 2.3.1 策略统计
|
||||
|
||||
**功能描述**：
|
||||
展示每个策略的统计信息。
|
||||
|
||||
**功能点**：
|
||||
- **统计指标**：
|
||||
- 信号总数：该策略生成的信号总数
|
||||
- 买入信号数：买入信号数量
|
||||
- 卖出信号数：卖出信号数量
|
||||
- 成功率：执行成功的信号占比
|
||||
- 总盈亏：该策略的总盈亏金额
|
||||
- 平均盈亏：平均每个信号的盈亏金额
|
||||
|
||||
- **时间维度**：
|
||||
- 今日统计
|
||||
- 本周统计
|
||||
- 本月统计
|
||||
- 全部统计
|
||||
|
||||
- **可视化展示**：
|
||||
- 使用图表展示统计趋势
|
||||
- 使用饼图展示信号类型分布
|
||||
- 使用柱状图展示每日信号数量
|
||||
|
||||
**交互流程**：
|
||||
1. 用户进入策略统计页面
|
||||
2. 系统加载策略列表和统计信息
|
||||
3. 用户选择某个策略查看详细统计
|
||||
4. 用户可以切换时间维度查看不同时期的统计
|
||||
|
||||
#### 2.3.2 总体统计
|
||||
|
||||
**功能描述**：
|
||||
展示所有策略的总体统计信息。
|
||||
|
||||
**功能点**：
|
||||
- **总体指标**：
|
||||
- 总策略数：启用的策略数量
|
||||
- 总信号数：所有策略生成的信号总数
|
||||
- 总成功率：所有信号的平均成功率
|
||||
- 总盈亏：所有策略的总盈亏金额
|
||||
- 平均盈亏：平均每个信号的盈亏金额
|
||||
|
||||
- **趋势分析**：
|
||||
- 信号数量趋势（按日/周/月）
|
||||
- 成功率趋势（按日/周/月）
|
||||
- 盈亏趋势（按日/周/月）
|
||||
|
||||
- **排行榜**：
|
||||
- 信号数量排行榜（按策略）
|
||||
- 成功率排行榜（按策略）
|
||||
- 盈亏排行榜（按策略）
|
||||
|
||||
**交互流程**：
|
||||
1. 用户进入总体统计页面
|
||||
2. 系统加载总体统计信息
|
||||
3. 用户可以查看趋势图表和排行榜
|
||||
4. 用户可以切换时间维度查看不同时期的统计
|
||||
|
||||
### 2.4 NBA 数据展示（可选功能）
|
||||
|
||||
#### 2.4.1 比赛数据展示
|
||||
|
||||
**功能描述**：
|
||||
展示 NBA 比赛的实时数据。
|
||||
|
||||
**功能点**：
|
||||
- **比赛列表**：
|
||||
- 展示今日/本周/本月的比赛
|
||||
- 显示比赛状态（未开始/进行中/已结束）
|
||||
- 显示比分和分差
|
||||
|
||||
- **比赛详情**：
|
||||
- 比赛基本信息（日期、主客场、比分等）
|
||||
- 实时比分和分差
|
||||
- 当前节次和剩余时间
|
||||
- Play-by-Play 数据
|
||||
|
||||
**交互流程**：
|
||||
1. 用户进入 NBA 数据页面
|
||||
2. 系统加载比赛列表
|
||||
3. 用户可以查看比赛详情
|
||||
4. 实时更新比赛数据（如果比赛正在进行）
|
||||
|
||||
---
|
||||
|
||||
## 三、用户场景
|
||||
|
||||
### 3.1 场景一：创建量化策略
|
||||
|
||||
**用户**：量化交易爱好者
|
||||
|
||||
**场景描述**：
|
||||
用户希望创建一个量化策略，系统自动分析比赛的两支队伍，根据综合评分和获胜概率，选择可盈利的队伍进行买入。
|
||||
|
||||
**操作流程**：
|
||||
1. 用户登录系统，进入策略配置页面
|
||||
2. 点击"创建策略"按钮
|
||||
3. 填写策略名称："综合实力分析策略"
|
||||
4. 选择关联账户
|
||||
5. 配置触发条件：
|
||||
- 比赛筛选：选择关注的比赛（可按球队、日期筛选）
|
||||
- 数据指标选择：选择用于分析的指标
|
||||
- 基础指标：分差、剩余时间、当前节次
|
||||
- 统计指标：球队净效率值、球员PER、真实命中率
|
||||
- 高级指标：势头动量、球星爆发因子、阵容对位系数
|
||||
- 触发阈值设置：
|
||||
- 最小获胜概率差异：0.1（主队和客队获胜概率差异至少 10%）
|
||||
- 最小交易价值：0.05（交易价值评分至少 0.05）
|
||||
6. 配置买入规则：
|
||||
- 买入条件：当系统计算出某支队伍获胜概率明显高于对手，且交易价值评分达到阈值时触发买入
|
||||
- 买入金额：固定金额 10 USDC
|
||||
- 买入方向：由系统自动判断（YES 或 NO，基于获胜概率）
|
||||
- 价格策略：动态价格（基于获胜概率和市场情况）
|
||||
7. 配置风险控制：
|
||||
- 最大持仓：50 USDC
|
||||
- 最小持仓：5 USDC
|
||||
- 每日亏损限制：100 USDC
|
||||
8. 点击"保存"按钮
|
||||
9. 系统验证配置并保存
|
||||
10. 策略创建成功，自动启用
|
||||
|
||||
**预期结果**：
|
||||
- 策略创建成功并启用
|
||||
- 系统开始监控 NBA 比赛数据
|
||||
- 当满足条件时，自动生成买入信号
|
||||
|
||||
### 3.2 场景二：查看交易信号
|
||||
|
||||
**用户**：量化交易爱好者
|
||||
|
||||
**场景描述**：
|
||||
用户希望实时查看系统生成的交易信号，了解策略的执行情况。
|
||||
|
||||
**操作流程**：
|
||||
1. 用户登录系统，进入交易信号页面
|
||||
2. 系统自动建立 WebSocket 连接
|
||||
3. 系统订阅交易信号推送
|
||||
4. 实时接收并展示新信号
|
||||
5. 用户可以查看信号详情：
|
||||
- 点击某个信号，查看详细信息
|
||||
- 查看触发原因和触发时的比赛数据
|
||||
- 查看执行状态和结果
|
||||
6. 用户可以筛选信号：
|
||||
- 按策略筛选：只查看特定策略的信号
|
||||
- 按类型筛选：只查看买入或卖出信号
|
||||
- 按状态筛选：只查看成功或失败的信号
|
||||
|
||||
**预期结果**：
|
||||
- 实时接收并展示交易信号
|
||||
- 可以查看信号的详细信息
|
||||
- 可以按需筛选和排序信号
|
||||
|
||||
### 3.3 场景三：查看策略统计
|
||||
|
||||
**用户**：量化交易爱好者
|
||||
|
||||
**场景描述**：
|
||||
用户希望查看策略的执行效果，了解策略的盈亏情况。
|
||||
|
||||
**操作流程**：
|
||||
1. 用户登录系统，进入策略统计页面
|
||||
2. 系统加载所有策略的统计信息
|
||||
3. 用户选择某个策略查看详细统计：
|
||||
- 查看信号总数、成功率、总盈亏等指标
|
||||
- 查看信号数量趋势图
|
||||
- 查看盈亏趋势图
|
||||
4. 用户可以切换时间维度：
|
||||
- 查看今日统计
|
||||
- 查看本周统计
|
||||
- 查看本月统计
|
||||
- 查看全部统计
|
||||
5. 用户可以查看总体统计：
|
||||
- 查看所有策略的总体指标
|
||||
- 查看趋势分析图表
|
||||
- 查看排行榜
|
||||
|
||||
**预期结果**：
|
||||
- 清晰展示策略的执行效果
|
||||
- 提供多维度的时间统计
|
||||
- 帮助用户优化策略配置
|
||||
|
||||
---
|
||||
|
||||
## 四、界面设计说明
|
||||
|
||||
### 4.1 策略配置页面
|
||||
|
||||
#### 4.1.1 页面布局
|
||||
|
||||
**整体布局**：
|
||||
- 顶部：页面标题"创建策略"或"编辑策略"
|
||||
- 左侧：配置导航（基本信息、触发条件、交易规则、风险控制、高级配置）
|
||||
- 中间：配置表单区域
|
||||
- 底部：操作按钮（保存、取消）
|
||||
|
||||
**配置表单**：
|
||||
- 使用分步骤表单，引导用户逐步配置
|
||||
- 每个步骤有清晰的说明和示例
|
||||
- 必填项用红色星号标记
|
||||
- 提供实时验证和错误提示
|
||||
|
||||
#### 4.1.2 关键组件
|
||||
|
||||
**触发条件配置组件**：
|
||||
- 条件列表：展示已添加的触发条件
|
||||
- 添加条件按钮：点击后弹出条件配置对话框
|
||||
- 条件编辑：支持编辑和删除已有条件
|
||||
- 条件组合：支持设置条件之间的逻辑关系（AND/OR）
|
||||
|
||||
**交易规则配置组件**：
|
||||
- 买入规则配置区域
|
||||
- 卖出规则配置区域
|
||||
- 价格策略选择（固定价格/动态价格）
|
||||
- 价格偏移设置
|
||||
|
||||
**风险控制配置组件**：
|
||||
- 持仓限制输入框
|
||||
- 每日限制输入框
|
||||
- 价格容忍度滑块
|
||||
|
||||
### 4.2 交易信号页面
|
||||
|
||||
#### 4.2.1 页面布局
|
||||
|
||||
**整体布局**：
|
||||
- 顶部：筛选和搜索栏
|
||||
- 中间：信号列表（表格形式）
|
||||
- 底部：分页组件
|
||||
|
||||
**信号列表表格**：
|
||||
- 列：信号类型、策略名称、市场信息、方向、价格、数量、触发原因、生成时间、状态、操作
|
||||
- 支持列排序
|
||||
- 支持行点击查看详情
|
||||
|
||||
#### 4.2.2 关键组件
|
||||
|
||||
**实时信号提示**：
|
||||
- 新信号到达时，顶部显示提示消息
|
||||
- 信号列表自动滚动到顶部
|
||||
- 新信号高亮显示（3 秒后恢复正常）
|
||||
|
||||
**信号状态标签**：
|
||||
- 已生成：蓝色标签
|
||||
- 执行中：黄色标签
|
||||
- 执行成功：绿色标签
|
||||
- 执行失败：红色标签
|
||||
|
||||
**信号详情对话框**：
|
||||
- 模态对话框形式
|
||||
- 展示信号的完整信息
|
||||
- 支持关闭和复制信息
|
||||
|
||||
### 4.3 统计页面
|
||||
|
||||
#### 4.3.1 页面布局
|
||||
|
||||
**整体布局**：
|
||||
- 顶部：时间维度选择（今日/本周/本月/全部）
|
||||
- 左侧：策略列表（如果查看策略统计）
|
||||
- 中间：统计图表和数据表格
|
||||
- 右侧：关键指标卡片
|
||||
|
||||
**统计图表**：
|
||||
- 使用 ECharts 或类似图表库
|
||||
- 支持交互（缩放、筛选等）
|
||||
- 支持导出图片
|
||||
|
||||
#### 4.3.2 关键组件
|
||||
|
||||
**指标卡片**：
|
||||
- 大数字显示关键指标
|
||||
- 支持对比（与上期对比）
|
||||
- 支持趋势箭头（上升/下降）
|
||||
|
||||
**趋势图表**：
|
||||
- 折线图：展示趋势变化
|
||||
- 柱状图：展示数量对比
|
||||
- 饼图：展示分布情况
|
||||
|
||||
---
|
||||
|
||||
## 五、非功能性需求
|
||||
|
||||
### 5.1 性能需求
|
||||
|
||||
**响应时间**：
|
||||
- 页面加载时间：< 2 秒
|
||||
- API 响应时间：< 1 秒
|
||||
- WebSocket 推送延迟：< 100 毫秒
|
||||
|
||||
**并发性能**：
|
||||
- 支持至少 100 个并发用户
|
||||
- 支持至少 1000 个策略同时运行
|
||||
- 支持至少 10000 个信号/天的处理能力
|
||||
|
||||
### 5.2 可用性需求
|
||||
|
||||
**系统可用性**：
|
||||
- 系统可用性：>= 99.5%
|
||||
- 故障恢复时间：< 5 分钟
|
||||
|
||||
**数据实时性**：
|
||||
- NBA 数据更新延迟：< 1 分钟
|
||||
- 交易信号推送延迟：< 5 秒
|
||||
|
||||
### 5.3 安全性需求
|
||||
|
||||
**数据安全**：
|
||||
- 用户配置数据加密存储
|
||||
- API 接口需要身份认证
|
||||
- WebSocket 连接需要身份认证
|
||||
|
||||
**风险控制**：
|
||||
- 所有交易信号需要经过风险控制检查
|
||||
- 异常情况自动告警
|
||||
- 支持紧急停止策略
|
||||
|
||||
### 5.4 兼容性需求
|
||||
|
||||
**浏览器兼容**：
|
||||
- Chrome（最新 2 个版本）
|
||||
- Firefox（最新 2 个版本）
|
||||
- Safari（最新 2 个版本）
|
||||
- Edge（最新 2 个版本）
|
||||
|
||||
**设备兼容**：
|
||||
- 桌面端：1920x1080 及以上分辨率
|
||||
- 平板端：768x1024 及以上分辨率
|
||||
- 移动端：375x667 及以上分辨率（响应式设计）
|
||||
|
||||
---
|
||||
|
||||
## 六、产品特性
|
||||
|
||||
### 6.1 核心特性
|
||||
|
||||
1. **简单易用**：
|
||||
- 直观的配置界面，降低使用门槛
|
||||
- 清晰的步骤引导，帮助用户快速上手
|
||||
- 丰富的帮助文档和示例
|
||||
|
||||
2. **实时响应**：
|
||||
- 实时获取 NBA 比赛数据
|
||||
- 实时执行量化分析
|
||||
- 实时推送交易信号
|
||||
|
||||
3. **数据驱动**：
|
||||
- 基于专业的 NBA 数据分析
|
||||
- 支持多种数据指标和特征
|
||||
- 提供数据可视化展示
|
||||
|
||||
4. **风险可控**：
|
||||
- 完善的风险控制参数
|
||||
- 自动风险检查机制
|
||||
- 异常情况告警
|
||||
|
||||
### 6.2 扩展特性
|
||||
|
||||
1. **策略模板**：
|
||||
- 提供预定义的策略模板
|
||||
- 用户可以基于模板快速创建策略
|
||||
- 支持模板的导入和导出
|
||||
|
||||
2. **回测功能**：
|
||||
- 支持历史数据回测
|
||||
- 评估策略的历史表现
|
||||
- 优化策略参数
|
||||
|
||||
3. **多账户支持**：
|
||||
- 支持多个交易账户
|
||||
- 每个账户可以配置不同的策略
|
||||
- 统一管理和监控
|
||||
|
||||
---
|
||||
|
||||
## 七、产品路线图
|
||||
|
||||
### 7.1 第一阶段：MVP 版本（2-3 个月）
|
||||
|
||||
**核心功能**：
|
||||
- 策略配置管理（创建、编辑、删除、列表）
|
||||
- 基础量化分析（简单策略逻辑）
|
||||
- 交易信号生成和推送
|
||||
- 基础统计展示
|
||||
|
||||
**目标**：
|
||||
- 验证产品可行性
|
||||
- 收集用户反馈
|
||||
- 优化核心功能
|
||||
|
||||
### 7.2 第二阶段：功能完善（2-3 个月）
|
||||
|
||||
**新增功能**：
|
||||
- 完善量化分析逻辑（支持复杂策略）
|
||||
- 完善特征提取和数据处理
|
||||
- 完善统计和可视化
|
||||
- 策略模板功能
|
||||
|
||||
**目标**：
|
||||
- 提升产品功能完整性
|
||||
- 提升用户体验
|
||||
- 扩大用户群体
|
||||
|
||||
### 7.3 第三阶段：高级功能（3-4 个月）
|
||||
|
||||
**新增功能**：
|
||||
- 回测功能
|
||||
- 机器学习集成
|
||||
- 多账户支持
|
||||
- 高级统计分析
|
||||
|
||||
**目标**：
|
||||
- 提升产品竞争力
|
||||
- 满足高级用户需求
|
||||
- 建立产品壁垒
|
||||
|
||||
---
|
||||
|
||||
## 八、附录
|
||||
|
||||
### 8.1 术语表
|
||||
|
||||
- **量化策略**：基于数据分析和算法模型的交易策略
|
||||
- **交易信号**：系统生成的买入或卖出建议
|
||||
- **触发条件**：满足哪些条件时生成交易信号
|
||||
- **风险控制**：限制交易风险的各种参数和机制
|
||||
- **WebSocket**：一种实时通信协议，用于推送数据
|
||||
|
||||
### 8.2 参考文档
|
||||
|
||||
- NBA 比赛分析框架文档（NBA.md）
|
||||
- 技术方案文档（nba-api-integration-technical-solution.md）
|
||||
- API 接口文档（待补充）
|
||||
- 用户手册（待补充）
|
||||
|
||||
---
|
||||
|
||||
**文档结束**
|
||||
|
||||
@@ -0,0 +1,567 @@
|
||||
# NBA 量化策略前端可配置参数清单
|
||||
|
||||
## 一、参数分类
|
||||
|
||||
前端可配置参数分为以下几类：
|
||||
1. **策略基本信息**：策略名称、描述等
|
||||
2. **比赛筛选参数**：选择关注的比赛
|
||||
3. **触发条件参数**：控制何时生成交易信号
|
||||
4. **交易规则参数**：控制如何执行交易
|
||||
5. **风险控制参数**：限制交易风险
|
||||
6. **算法权重参数**（高级）：调整算法内部权重
|
||||
7. **系统配置参数**：数据更新频率、推送设置等
|
||||
|
||||
---
|
||||
|
||||
## 二、详细参数列表
|
||||
|
||||
### 2.1 策略基本信息（必填）
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|------|---------|
|
||||
| **策略名称** | String | ✅ | - | 用户自定义策略名称，1-50 字符 | Input |
|
||||
| **策略描述** | String | ❌ | - | 策略的简要说明，最多 200 字符 | TextArea |
|
||||
| **关联账户** | Long | ✅ | - | 选择用于交易的账户 | Select |
|
||||
| **启用状态** | Boolean | ❌ | true | 是否启用该策略 | Switch |
|
||||
|
||||
---
|
||||
|
||||
### 2.2 比赛筛选参数（可选）
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|------|---------|
|
||||
| **关注球队** | List\<String\> | ❌ | [] | 选择关注的球队（可选，不选择则分析所有比赛） | MultiSelect |
|
||||
| **日期范围** | DateRange | ❌ | 今日 | 选择关注的日期范围 | DateRangePicker |
|
||||
| **比赛重要性** | Enum | ❌ | 全部 | 选择比赛重要性（全部/常规赛/季后赛/关键战） | Select |
|
||||
| **主客场筛选** | Enum | ❌ | 全部 | 筛选主队或客队（全部/仅主队/仅客队） | Select |
|
||||
|
||||
---
|
||||
|
||||
### 2.3 触发条件参数（必填）
|
||||
|
||||
#### 2.3.1 概率阈值参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **最小获胜概率差异** | Decimal | ✅ | 0.1 | 0.05 - 0.5 | 主队和客队获胜概率的最小差异（如 0.1 表示至少 10% 的差异） | InputNumber (0-1, 步长 0.01) |
|
||||
| **最小获胜概率** | Decimal | ❌ | 0.55 | 0.5 - 1.0 | 生成买入信号时的最小获胜概率（可选，不设置则不限制） | InputNumber (0-1, 步长 0.01) |
|
||||
| **最大获胜概率** | Decimal | ❌ | - | 0.0 - 0.5 | 生成买入信号时的最大获胜概率（可选，用于反向策略） | InputNumber (0-1, 步长 0.01) |
|
||||
|
||||
#### 2.3.2 交易价值参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **最小交易价值** | Decimal | ✅ | 0.05 | 0.0 - 1.0 | 交易价值评分的最小值，只有达到此值才会生成信号 | InputNumber (0-1, 步长 0.01) |
|
||||
|
||||
#### 2.3.3 时间条件参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **最小剩余时间** | Integer | ❌ | 5 | 0 - 48 | 生成信号时的最小剩余时间（分钟），0 表示不限制 | InputNumber (0-48) |
|
||||
| **最大剩余时间** | Integer | ❌ | - | 0 - 48 | 生成信号时的最大剩余时间（分钟），可选 | InputNumber (0-48) |
|
||||
| **比赛阶段限制** | Enum | ❌ | 全部 | 全部/仅比赛前/仅比赛中/仅比赛后 | 限制在哪个阶段生成信号 | Select |
|
||||
|
||||
#### 2.3.4 分差条件参数（可选）
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **最小分差** | Integer | ❌ | - | -50 - 50 | 生成信号时的最小分差（主队得分 - 客队得分），可选 | InputNumber |
|
||||
| **最大分差** | Integer | ❌ | - | -50 - 50 | 生成信号时的最大分差，可选 | InputNumber |
|
||||
| **分差范围** | Enum | ❌ | 全部 | 全部/小分差(<5分)/中分差(5-15分)/大分差(>15分) | 限制分差范围 | Select |
|
||||
|
||||
---
|
||||
|
||||
### 2.4 交易规则参数
|
||||
|
||||
#### 2.4.1 买入规则参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **买入金额策略** | Enum | ✅ | FIXED | FIXED/RATIO/DYNAMIC | 买入金额计算方式 | Select |
|
||||
| **固定买入金额** | Decimal | 条件必填 | 10 | > 0 | 固定金额策略时的买入金额（USDC） | InputNumber |
|
||||
| **买入比例** | Decimal | 条件必填 | 0.1 | 0.01 - 1.0 | 按比例策略时的买入比例（账户余额的百分比） | InputNumber (0-1, 步长 0.01) |
|
||||
| **基础买入金额** | Decimal | 条件必填 | 10 | > 0 | 动态计算策略时的基础金额（USDC） | InputNumber |
|
||||
| **买入时机** | Enum | ✅ | IMMEDIATE | IMMEDIATE/DELAYED | 立即买入或延迟买入 | Select |
|
||||
| **延迟买入时间** | Integer | 条件必填 | 0 | 0 - 300 | 延迟买入的秒数（仅在延迟买入时生效） | InputNumber (0-300) |
|
||||
| **买入方向** | Enum | ✅ | AUTO | AUTO/YES/NO | 买入方向：AUTO=系统自动判断，YES/NO=固定方向 | Select |
|
||||
| **说明** | - | - | - | - | 系统会自动分析两支队伍，选择获胜概率更高、交易价值更大的方向 | Info |
|
||||
|
||||
#### 2.4.2 卖出规则参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **启用卖出** | Boolean | ✅ | true | - | 是否启用卖出功能 | Switch |
|
||||
| **止盈阈值** | Decimal | ❌ | 0.2 | 0.0 - 1.0 | 预期收益达到多少时卖出（如 0.2 表示 20%） | InputNumber (0-1, 步长 0.01) |
|
||||
| **止损阈值** | Decimal | ❌ | -0.1 | -1.0 - 0.0 | 预期亏损达到多少时卖出（如 -0.1 表示 -10%） | InputNumber (-1-0, 步长 0.01) |
|
||||
| **概率反转阈值** | Decimal | ❌ | 0.15 | 0.0 - 1.0 | 获胜概率反转多少时卖出（如 0.15 表示 15%） | InputNumber (0-1, 步长 0.01) |
|
||||
| **卖出比例** | Decimal | ✅ | 1.0 | 0.1 - 1.0 | 卖出时的比例（1.0 表示全部卖出） | InputNumber (0-1, 步长 0.1) |
|
||||
| **卖出时机** | Enum | ✅ | IMMEDIATE | IMMEDIATE/DELAYED | 立即卖出或延迟卖出 | Select |
|
||||
| **延迟卖出时间** | Integer | 条件必填 | 0 | 0 - 300 | 延迟卖出的秒数（仅在延迟卖出时生效） | InputNumber (0-300) |
|
||||
|
||||
#### 2.4.3 价格策略参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **价格策略** | Enum | ✅ | MARKET | FIXED/MARKET/DYNAMIC | 价格计算方式 | Select |
|
||||
| **固定价格** | Decimal | 条件必填 | - | 0.01 - 0.99 | 固定价格策略时的价格（仅在固定价格时生效） | InputNumber (0-1, 步长 0.01) |
|
||||
| **价格偏移** | Decimal | ❌ | 0.0 | -0.1 - 0.1 | 价格偏移百分比（用于调整价格，提高交易成功率，如 0.05 表示 +5%） | InputNumber (-0.1-0.1, 步长 0.01) |
|
||||
|
||||
---
|
||||
|
||||
### 2.5 风险控制参数
|
||||
|
||||
#### 2.5.1 持仓限制参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **最大持仓** | Decimal | ✅ | 50 | >= 1 | 单次最大买入金额（USDC） | InputNumber (>= 1) |
|
||||
| **最小持仓** | Decimal | ✅ | 5 | >= 1 | 单次最小买入金额（USDC） | InputNumber (>= 1) |
|
||||
| **单场比赛最大持仓** | Decimal | ❌ | - | >= 1 | 单场比赛的最大持仓金额（USDC），可选 | InputNumber (>= 1) |
|
||||
|
||||
#### 2.5.2 每日限制参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **每日亏损限制** | Decimal | ❌ | 100 | > 0 | 每日最大亏损金额（USDC），可选 | InputNumber (> 0) |
|
||||
| **每日订单限制** | Integer | ❌ | 20 | > 0 | 每日最大订单数量，可选 | InputNumber (> 0) |
|
||||
| **每日盈利目标** | Decimal | ❌ | - | > 0 | 每日盈利目标（USDC），达到后停止交易，可选 | InputNumber (> 0) |
|
||||
|
||||
#### 2.5.3 价格容忍度参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **价格容忍度** | Decimal | ❌ | 0.05 | 0.0 - 1.0 | 允许的价格偏差百分比（如 0.05 表示 5%） | InputNumber (0-1, 步长 0.01) |
|
||||
|
||||
#### 2.5.4 概率置信度参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **最小概率阈值** | Decimal | ❌ | - | 0.5 - 1.0 | 最小获胜概率阈值（可选，不设置则不限制） | InputNumber (0.5-1.0, 步长 0.01) |
|
||||
| **最大概率阈值** | Decimal | ❌ | - | 0.0 - 0.5 | 最大获胜概率阈值（可选，用于反向策略） | InputNumber (0-0.5, 步长 0.01) |
|
||||
|
||||
---
|
||||
|
||||
### 2.6 算法权重参数（高级，可选）
|
||||
|
||||
#### 2.6.1 综合评分权重参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **基础实力权重** | Decimal | ❌ | 0.3 | 0.0 - 1.0 | 基础实力评分在综合评分中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
| **近期状态权重** | Decimal | ❌ | 0.25 | 0.0 - 1.0 | 近期状态评分在综合评分中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
| **阵容完整度权重** | Decimal | ❌ | 0.2 | 0.0 - 1.0 | 阵容完整度评分在综合评分中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
| **球星状态权重** | Decimal | ❌ | 0.15 | 0.0 - 1.0 | 球星状态评分在综合评分中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
| **环境因素权重** | Decimal | ❌ | 0.1 | 0.0 - 1.0 | 环境因素评分在综合评分中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
| **说明** | - | - | - | - | 所有权重之和应该等于 1.0，系统会自动归一化 | Info |
|
||||
|
||||
#### 2.6.2 对位分析权重参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **对位优势权重** | Decimal | ❌ | 0.2 | 0.0 - 1.0 | 对位优势在获胜概率调整中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
|
||||
#### 2.6.3 实时状态权重参数（仅比赛进行中）
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **分差调整权重** | Decimal | ❌ | 0.3 | 0.0 - 1.0 | 分差调整在实时概率调整中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
| **势头调整权重** | Decimal | ❌ | 0.2 | 0.0 - 1.0 | 势头调整在实时概率调整中的权重 | InputNumber (0-1, 步长 0.05) |
|
||||
|
||||
---
|
||||
|
||||
### 2.7 系统配置参数
|
||||
|
||||
#### 2.7.1 数据更新参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **数据更新频率** | Integer | ✅ | 30 | 10/30/60/300 | NBA 数据更新频率（秒） | Select |
|
||||
| **分析频率** | Integer | ✅ | 30 | 10/30/60/300 | 量化分析执行频率（秒） | Select |
|
||||
|
||||
#### 2.7.2 推送设置参数
|
||||
|
||||
| 参数名称 | 类型 | 必填 | 默认值 | 取值范围 | 说明 | UI 组件 |
|
||||
|---------|------|------|--------|----------|------|---------|
|
||||
| **推送失败订单** | Boolean | ❌ | false | - | 是否推送失败订单 | Switch |
|
||||
| **推送频率** | Enum | ❌ | REALTIME | REALTIME/BATCH | 实时推送或批量推送 | Select |
|
||||
| **批量推送间隔** | Integer | 条件必填 | 1 | 1 - 60 | 批量推送的时间间隔（秒，仅在批量推送时生效） | InputNumber (1-60) |
|
||||
|
||||
---
|
||||
|
||||
## 三、参数分组和页面布局建议
|
||||
|
||||
### 3.1 参数分组
|
||||
|
||||
**基础配置组**（第一页）：
|
||||
- 策略基本信息
|
||||
- 比赛筛选参数
|
||||
|
||||
**触发条件组**（第二页）：
|
||||
- 概率阈值参数
|
||||
- 交易价值参数
|
||||
- 时间条件参数
|
||||
- 分差条件参数
|
||||
|
||||
**交易规则组**（第三页）：
|
||||
- 买入规则参数
|
||||
- 卖出规则参数
|
||||
- 价格策略参数
|
||||
|
||||
**风险控制组**（第四页）：
|
||||
- 持仓限制参数
|
||||
- 每日限制参数
|
||||
- 价格容忍度参数
|
||||
- 概率置信度参数
|
||||
|
||||
**高级配置组**（第五页，可折叠）：
|
||||
- 算法权重参数
|
||||
- 系统配置参数
|
||||
|
||||
### 3.2 UI 组件建议
|
||||
|
||||
**表单布局**：
|
||||
- 使用分步骤表单（Stepper），引导用户逐步配置
|
||||
- 每个步骤有清晰的标题和说明
|
||||
- 必填项用红色星号标记
|
||||
- 提供实时验证和错误提示
|
||||
|
||||
**参数展示**：
|
||||
- 使用折叠面板（Collapse）组织相关参数
|
||||
- 高级参数默认折叠，用户可展开查看
|
||||
- 提供参数说明和示例
|
||||
- 提供参数推荐值（基于历史数据）
|
||||
|
||||
**交互优化**：
|
||||
- 条件显示：某些参数只在特定条件下显示（如固定价格只在价格策略=固定时显示）
|
||||
- 联动验证：相关参数之间进行联动验证（如最大持仓 >= 最小持仓）
|
||||
- 实时预览：显示参数配置后的预期效果（如预期信号数量、预期交易频率等）
|
||||
|
||||
---
|
||||
|
||||
## 四、参数验证规则
|
||||
|
||||
### 4.1 必填参数验证
|
||||
|
||||
- 策略名称：不能为空，1-50 字符，不能重复
|
||||
- 关联账户：必须选择
|
||||
- 最小获胜概率差异：必须 > 0
|
||||
- 最小交易价值：必须 >= 0
|
||||
- 最大持仓：必须 >= 1
|
||||
- 最小持仓：必须 >= 1
|
||||
- 数据更新频率：必须选择
|
||||
- 分析频率：必须选择
|
||||
|
||||
### 4.2 数值范围验证
|
||||
|
||||
- 概率相关参数：必须在 [0, 1] 范围内
|
||||
- 金额相关参数：必须 > 0
|
||||
- 时间相关参数：必须在合理范围内（如 0-48 分钟）
|
||||
- 权重相关参数：必须在 [0, 1] 范围内，且总和应该接近 1.0
|
||||
|
||||
### 4.3 逻辑关系验证
|
||||
|
||||
- 最大持仓 >= 最小持仓
|
||||
- 最大剩余时间 >= 最小剩余时间（如果都设置了）
|
||||
- 最大分差 >= 最小分差（如果都设置了）
|
||||
- 最大概率阈值 <= 最小概率阈值（如果都设置了）
|
||||
- 权重总和应该在 0.9 - 1.1 范围内（系统会自动归一化）
|
||||
|
||||
### 4.4 条件依赖验证
|
||||
|
||||
- 如果买入金额策略 = FIXED，则固定买入金额必填
|
||||
- 如果买入金额策略 = RATIO，则买入比例必填
|
||||
- 如果买入金额策略 = DYNAMIC，则基础买入金额必填
|
||||
- 如果价格策略 = FIXED，则固定价格必填
|
||||
- 如果买入时机 = DELAYED，则延迟买入时间必填
|
||||
- 如果卖出时机 = DELAYED，则延迟卖出时间必填
|
||||
- 如果推送频率 = BATCH，则批量推送间隔必填
|
||||
|
||||
---
|
||||
|
||||
## 五、参数默认值建议
|
||||
|
||||
### 5.1 新手推荐配置
|
||||
|
||||
**保守策略**（适合新手）：
|
||||
- 最小获胜概率差异：0.15（更严格的条件）
|
||||
- 最小交易价值：0.08（更高的价值要求）
|
||||
- 最大持仓：20 USDC（较小的持仓）
|
||||
- 最小持仓：5 USDC
|
||||
- 每日亏损限制：50 USDC
|
||||
- 价格容忍度：0.03（3%，较严格）
|
||||
|
||||
**稳健策略**（推荐）：
|
||||
- 最小获胜概率差异：0.1（标准条件）
|
||||
- 最小交易价值：0.05（标准价值）
|
||||
- 最大持仓：50 USDC
|
||||
- 最小持仓：5 USDC
|
||||
- 每日亏损限制：100 USDC
|
||||
- 价格容忍度：0.05（5%）
|
||||
|
||||
**激进策略**（适合有经验的用户）：
|
||||
- 最小获胜概率差异：0.05（较宽松的条件）
|
||||
- 最小交易价值：0.03（较低的价值要求）
|
||||
- 最大持仓：100 USDC（较大的持仓）
|
||||
- 最小持仓：10 USDC
|
||||
- 每日亏损限制：200 USDC
|
||||
- 价格容忍度：0.1（10%，较宽松）
|
||||
|
||||
### 5.2 参数模板
|
||||
|
||||
系统可以提供预定义的参数模板：
|
||||
- **保守模板**：使用保守策略的默认值
|
||||
- **稳健模板**：使用稳健策略的默认值
|
||||
- **激进模板**：使用激进策略的默认值
|
||||
- **自定义模板**：用户保存的自定义配置
|
||||
|
||||
### 5.3 基于历史数据的推荐值
|
||||
|
||||
#### 5.3.1 推荐值功能概述
|
||||
|
||||
系统可以根据历史数据分析和回测结果，为每个可配置参数提供智能推荐值，帮助用户快速配置策略，提高策略效果。
|
||||
|
||||
#### 5.3.2 推荐值计算方式
|
||||
|
||||
**方式一：基于历史回测的推荐值**
|
||||
|
||||
**计算流程**：
|
||||
1. 使用历史比赛数据（如过去 1-3 个赛季）
|
||||
2. 对不同的参数组合进行回测
|
||||
3. 评估每个参数组合的效果（准确率、盈亏、风险等）
|
||||
4. 选择最优的参数组合作为推荐值
|
||||
|
||||
**评估指标**：
|
||||
- 信号准确率：预测获胜 vs 实际获胜的比例
|
||||
- 总盈亏：累计盈亏金额
|
||||
- 盈亏比率：盈利信号的平均盈亏 / 亏损信号的平均盈亏
|
||||
- 最大回撤：最大连续亏损
|
||||
- 夏普比率：风险调整后的收益
|
||||
|
||||
**推荐值选择**：
|
||||
- 选择综合评分最高的参数组合
|
||||
- 综合评分 = 准确率 × 0.3 + 盈亏比率 × 0.3 + 夏普比率 × 0.2 + (1 - 最大回撤率) × 0.2
|
||||
|
||||
**方式二：基于用户策略的推荐值**
|
||||
|
||||
**计算方式**：
|
||||
- 分析用户已有策略的参数配置
|
||||
- 统计表现最好的策略的参数分布
|
||||
- 计算参数的平均值或中位数作为推荐值
|
||||
|
||||
**适用场景**：
|
||||
- 新用户：使用所有用户的最佳策略参数
|
||||
- 老用户：使用该用户自己的最佳策略参数
|
||||
|
||||
**方式三：基于市场环境的推荐值**
|
||||
|
||||
**动态调整**：
|
||||
- 根据当前市场环境（波动性、流动性等）动态调整推荐值
|
||||
- 市场波动大时：提高概率阈值，降低持仓
|
||||
- 市场稳定时：降低概率阈值，提高持仓
|
||||
|
||||
**环境因素**：
|
||||
- 市场波动性：基于近期价格的波动率
|
||||
- 市场流动性：基于订单深度和交易量
|
||||
- 比赛重要性：季后赛 vs 常规赛
|
||||
|
||||
#### 5.3.3 推荐值展示方式
|
||||
|
||||
**在参数输入框中的展示**：
|
||||
- 在参数输入框旁边显示推荐值按钮（如"使用推荐值"图标）
|
||||
- 点击后自动填充推荐值
|
||||
- 推荐值用不同颜色标识（如蓝色高亮）
|
||||
- 显示推荐值的来源标签（如"基于历史回测"、"基于您的策略"、"基于市场环境"）
|
||||
- 显示推荐值的置信度（如"高置信度"、"中置信度"、"低置信度"）
|
||||
|
||||
**推荐值详细说明**：
|
||||
- 点击推荐值按钮后，弹出推荐值说明卡片
|
||||
- 显示推荐值的计算依据
|
||||
- 显示使用该推荐值的预期效果（如"预期准确率 65%"、"预期盈亏比 1.5"）
|
||||
- 显示推荐值的适用场景（如"适合保守策略"、"适合激进策略"）
|
||||
- 显示推荐值的验证数据（如"基于 500 场历史比赛验证"）
|
||||
|
||||
**参数对比展示**：
|
||||
- 在参数配置页面底部显示"推荐值对比"面板
|
||||
- 显示当前配置值 vs 推荐值的对比
|
||||
- 显示预期效果对比（如准确率、盈亏等）
|
||||
- 提供"应用所有推荐值"按钮，一键应用所有推荐值
|
||||
- 提供"应用部分推荐值"选项，让用户选择应用哪些推荐值
|
||||
|
||||
#### 5.3.4 推荐值更新机制
|
||||
|
||||
**更新频率**：
|
||||
- 每周更新一次：基于最新的历史数据
|
||||
- 每月深度更新：重新进行完整的回测分析
|
||||
- 实时更新：根据市场环境变化实时调整（仅市场环境相关参数）
|
||||
|
||||
**触发更新**：
|
||||
- 新赛季开始：使用新赛季的数据重新计算
|
||||
- 市场环境变化：检测到市场环境显著变化时更新
|
||||
- 用户请求：用户手动触发更新
|
||||
|
||||
**更新通知**：
|
||||
- 在策略配置页面显示"推荐值已更新"提示
|
||||
- 显示更新内容（哪些参数有变化）
|
||||
- 提供"查看更新"按钮，查看详细的更新说明
|
||||
- 提供"应用更新"按钮，一键应用更新的推荐值
|
||||
|
||||
#### 5.3.5 推荐值个性化
|
||||
|
||||
**基于用户偏好的推荐**：
|
||||
|
||||
**偏好设置**：
|
||||
- 风险偏好：保守/稳健/激进
|
||||
- 交易频率偏好：低频/中频/高频
|
||||
- 持仓偏好：小持仓/中持仓/大持仓
|
||||
|
||||
**个性化推荐**：
|
||||
- 根据用户偏好筛选推荐值
|
||||
- 优先推荐符合用户偏好的参数组合
|
||||
- 提供多个推荐选项（保守推荐、稳健推荐、激进推荐）
|
||||
|
||||
**基于策略类型的推荐**：
|
||||
|
||||
**策略类型**：
|
||||
- 保守策略：高概率阈值、小持仓、严格风险控制
|
||||
- 稳健策略：中等概率阈值、中等持仓、标准风险控制
|
||||
- 激进策略：低概率阈值、大持仓、宽松风险控制
|
||||
|
||||
**类型推荐**：
|
||||
- 用户选择策略类型后，自动推荐该类型的参数值
|
||||
- 提供策略类型模板，一键应用
|
||||
|
||||
#### 5.3.6 推荐值验证和反馈
|
||||
|
||||
**推荐值验证**：
|
||||
|
||||
**验证方式**：
|
||||
- 使用历史数据验证推荐值的有效性
|
||||
- 计算推荐值的回测准确率
|
||||
- 评估推荐值的风险水平
|
||||
|
||||
**验证结果展示**：
|
||||
- 显示推荐值的验证状态（如"已验证"、"待验证"）
|
||||
- 显示验证数据（如"基于 500 场历史比赛验证"）
|
||||
- 显示验证指标（如准确率、盈亏比等）
|
||||
- 显示验证时间（如"2024-12-01 验证"）
|
||||
|
||||
**用户反馈机制**：
|
||||
|
||||
**反馈收集**：
|
||||
- 用户使用推荐值后，可以反馈效果
|
||||
- 收集用户对推荐值的满意度（1-5 星）
|
||||
- 收集用户的实际使用效果数据（准确率、盈亏等）
|
||||
|
||||
**反馈应用**：
|
||||
- 根据用户反馈调整推荐算法
|
||||
- 优化推荐值的准确性
|
||||
- 提高推荐值的适用性
|
||||
|
||||
#### 5.3.7 推荐值功能实现
|
||||
|
||||
**前端实现**：
|
||||
|
||||
**UI 组件**：
|
||||
- 推荐值按钮：在参数输入框旁边显示推荐值图标按钮
|
||||
- 推荐值卡片：点击后显示推荐值的详细说明
|
||||
- 推荐值对比面板：显示当前值 vs 推荐值的对比
|
||||
- 推荐值应用按钮：一键应用所有推荐值
|
||||
|
||||
**交互流程**：
|
||||
1. 用户进入策略配置页面
|
||||
2. 系统异步加载推荐值（不阻塞页面加载）
|
||||
3. 在参数输入框旁边显示推荐值按钮（如果该参数有推荐值）
|
||||
4. 用户点击推荐值按钮，查看推荐值详情
|
||||
5. 用户可以选择应用推荐值或手动调整
|
||||
6. 用户可以在底部查看所有推荐值的对比
|
||||
|
||||
**后端实现**：
|
||||
|
||||
**推荐值计算服务**：
|
||||
- 历史回测服务：执行历史数据回测
|
||||
- 推荐值计算服务：计算推荐值
|
||||
- 推荐值缓存服务：缓存推荐值，提高响应速度
|
||||
|
||||
**API 接口**：
|
||||
- 获取推荐值接口：根据参数类型和用户偏好返回推荐值
|
||||
- 更新推荐值接口：触发推荐值更新
|
||||
- 推荐值验证接口：验证推荐值的有效性
|
||||
- 用户反馈接口：收集用户反馈
|
||||
|
||||
**数据存储**：
|
||||
|
||||
**推荐值存储**：
|
||||
- 存储推荐值计算结果
|
||||
- 存储推荐值的计算依据和验证结果
|
||||
- 存储用户反馈数据
|
||||
|
||||
**缓存策略**：
|
||||
- 推荐值缓存 24 小时（每天更新一次）
|
||||
- 市场环境变化时立即更新缓存
|
||||
- 用户请求时优先使用缓存，异步更新
|
||||
|
||||
#### 5.3.8 推荐值参数列表
|
||||
|
||||
以下参数支持推荐值功能：
|
||||
|
||||
**触发条件参数**：
|
||||
- 最小获胜概率差异：基于历史回测的最优值
|
||||
- 最小交易价值：基于历史回测的最优值
|
||||
- 最小剩余时间：基于历史回测的最优值
|
||||
|
||||
**交易规则参数**：
|
||||
- 买入金额策略：基于用户策略的推荐
|
||||
- 固定买入金额：基于用户策略的推荐
|
||||
- 买入比例：基于用户策略的推荐
|
||||
- 价格策略：基于市场环境的推荐
|
||||
- 价格偏移：基于历史回测的最优值
|
||||
|
||||
**风险控制参数**：
|
||||
- 最大持仓：基于用户偏好和账户余额的推荐
|
||||
- 最小持仓：基于用户偏好和账户余额的推荐
|
||||
- 每日亏损限制：基于用户账户余额的推荐
|
||||
- 每日订单限制：基于历史数据的推荐
|
||||
- 价格容忍度：基于市场环境的推荐
|
||||
|
||||
**卖出规则参数**：
|
||||
- 止盈阈值：基于历史回测的最优值
|
||||
- 止损阈值：基于历史回测的最优值
|
||||
- 概率反转阈值：基于历史回测的最优值
|
||||
|
||||
**算法权重参数**（高级）：
|
||||
- 综合评分权重：基于历史回测的最优值
|
||||
- 对位分析权重：基于历史回测的最优值
|
||||
- 实时状态权重：基于历史回测的最优值
|
||||
|
||||
---
|
||||
|
||||
## 六、参数说明和帮助
|
||||
|
||||
### 6.1 参数说明
|
||||
|
||||
每个参数都应该有清晰的说明：
|
||||
- **参数名称**：简洁明了的名称
|
||||
- **参数说明**：详细说明参数的作用和影响
|
||||
- **取值范围**：明确的范围和单位
|
||||
- **推荐值**：基于历史数据的推荐值
|
||||
- **示例**：具体的使用示例
|
||||
|
||||
### 6.2 帮助文档
|
||||
|
||||
提供以下帮助内容：
|
||||
- **参数说明文档**：详细的参数说明文档
|
||||
- **策略配置指南**：如何配置策略的指南
|
||||
- **常见问题**：常见配置问题和解答
|
||||
- **最佳实践**：配置策略的最佳实践
|
||||
|
||||
### 6.3 实时提示
|
||||
|
||||
在配置过程中提供实时提示：
|
||||
- **参数影响提示**：说明参数调整对策略的影响
|
||||
- **风险提示**：高风险配置的警告提示
|
||||
- **优化建议**：基于当前配置的优化建议
|
||||
|
||||
---
|
||||
|
||||
**文档结束**
|
||||
|
||||
@@ -0,0 +1,886 @@
|
||||
# Polymarket NBA 赛事列表获取方案
|
||||
|
||||
## 一、概述
|
||||
|
||||
本文档描述了如何从 Polymarket 获取 NBA 赛事列表，用于量化交易系统中的比赛筛选和市场匹配。
|
||||
|
||||
---
|
||||
|
||||
## 二、Polymarket API 接口分析
|
||||
|
||||
### 2.1 Gamma API 接口
|
||||
|
||||
**Base URL**: `https://gamma-api.polymarket.com`
|
||||
|
||||
**当前接口**：
|
||||
- `/markets`: 根据 condition IDs 获取市场信息
|
||||
- 不支持直接按分类筛选
|
||||
|
||||
**接口限制**：
|
||||
- 只能通过 condition_ids 参数查询特定市场
|
||||
- 不支持按分类、标签、关键词等筛选
|
||||
|
||||
### 2.2 市场数据结构
|
||||
|
||||
**MarketResponse 字段**：
|
||||
- `id`: 市场 ID
|
||||
- `question`: 市场名称（如 "Will the Lakers win?"）
|
||||
- `conditionId`: Condition ID（16 进制）
|
||||
- `slug`: 市场 slug（用于生成链接）
|
||||
- `category`: 分类（如 "sports"）
|
||||
- `active`: 是否活跃
|
||||
- `closed`: 是否已关闭
|
||||
- `archived`: 是否已归档
|
||||
- `endDate`: 结束日期
|
||||
- `startDate`: 开始日期
|
||||
- `outcomes`: 结果选项（JSON 字符串）
|
||||
- `volume`: 交易量
|
||||
- `liquidity`: 流动性
|
||||
|
||||
---
|
||||
|
||||
## 三、获取 NBA 赛事列表的方案
|
||||
|
||||
### 3.1 方案一：通过 Events API 获取（推荐）
|
||||
|
||||
**接口信息**：
|
||||
- **Base URL**: `https://gamma-api.polymarket.com`
|
||||
- **接口路径**: `/events` 或 `/series`
|
||||
- **说明**: Polymarket 可能提供 Events API 或 Series API，可以按分类获取事件列表
|
||||
|
||||
**实现方式**：
|
||||
1. 调用 Events API，筛选分类为 "sports" 的事件
|
||||
2. 进一步筛选包含 "NBA" 关键词的事件
|
||||
3. 获取每个事件关联的市场列表
|
||||
|
||||
**优点**：
|
||||
- 可以直接按分类筛选
|
||||
- 数据结构更清晰（事件 -> 市场）
|
||||
- 可以获取事件级别的信息
|
||||
|
||||
**缺点**：
|
||||
- 需要确认 API 是否支持分类筛选
|
||||
- 可能需要额外的 API 调用
|
||||
|
||||
### 3.2 方案二：通过搜索接口获取
|
||||
|
||||
**接口信息**：
|
||||
- **Base URL**: `https://gamma-api.polymarket.com`
|
||||
- **接口路径**: `/search` 或 `/markets/search`
|
||||
- **说明**: 使用搜索接口，通过关键词 "NBA" 搜索市场
|
||||
|
||||
**实现方式**：
|
||||
1. 调用搜索接口，搜索关键词 "NBA"
|
||||
2. 过滤结果，确保分类为 "sports"
|
||||
3. 进一步过滤，确保市场名称或描述中包含 NBA 相关信息
|
||||
|
||||
**优点**：
|
||||
- 可以直接搜索 NBA 相关市场
|
||||
- 实现简单
|
||||
|
||||
**缺点**：
|
||||
- 可能遗漏一些市场（如果名称不包含 "NBA"）
|
||||
- 搜索结果可能包含不相关的市场
|
||||
|
||||
### 3.3 方案三：获取所有市场后过滤（备选）
|
||||
|
||||
**实现方式**：
|
||||
1. 调用 `/markets` 接口，不传 condition_ids（如果支持）
|
||||
2. 或者定期爬取 Polymarket 网站，获取所有市场
|
||||
3. 在本地过滤：分类 = "sports" 且包含 NBA 相关信息
|
||||
|
||||
**优点**：
|
||||
- 不依赖特定 API 接口
|
||||
- 可以获取完整的数据
|
||||
|
||||
**缺点**：
|
||||
- 需要获取大量数据，效率低
|
||||
- 需要定期更新
|
||||
- 如果 API 不支持获取所有市场，需要爬取网站
|
||||
|
||||
### 3.4 方案四：通过 Subgraph API 获取（如果可用）
|
||||
|
||||
**接口信息**：
|
||||
- **Base URL**: Polymarket Subgraph API
|
||||
- **说明**: 使用 GraphQL 查询，可以灵活筛选
|
||||
|
||||
**实现方式**：
|
||||
1. 使用 GraphQL 查询，筛选分类为 "sports" 的市场
|
||||
2. 进一步筛选包含 "NBA" 的市场
|
||||
3. 可以按时间、状态等条件筛选
|
||||
|
||||
**优点**：
|
||||
- 查询灵活，可以精确筛选
|
||||
- 可以获取关联数据（如事件、系列等）
|
||||
|
||||
**缺点**：
|
||||
- 需要确认 Subgraph API 是否可用
|
||||
- 需要学习 GraphQL 查询语法
|
||||
|
||||
---
|
||||
|
||||
## 四、推荐实现方案
|
||||
|
||||
### 4.1 混合方案（推荐）
|
||||
|
||||
**策略**：结合多种方式，确保数据完整性
|
||||
|
||||
**实现步骤**：
|
||||
|
||||
1. **主要方式：Events/Series API**
|
||||
- 优先使用 Events API 或 Series API
|
||||
- 按分类 "sports" 筛选
|
||||
- 按关键词 "NBA" 筛选事件
|
||||
|
||||
2. **补充方式：搜索接口**
|
||||
- 如果 Events API 不可用，使用搜索接口
|
||||
- 搜索关键词 "NBA"
|
||||
- 过滤分类为 "sports" 的结果
|
||||
|
||||
3. **数据缓存和更新**
|
||||
- 将获取的 NBA 赛事列表缓存到数据库
|
||||
- 定期更新（如每天更新一次）
|
||||
- 实时监控新市场（通过 WebSocket 或轮询）
|
||||
|
||||
### 4.2 数据存储设计
|
||||
|
||||
**NBA 赛事表 (nba_games)**：
|
||||
```sql
|
||||
CREATE TABLE nba_games (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
polymarket_market_id VARCHAR(100) UNIQUE NOT NULL COMMENT 'Polymarket 市场 ID',
|
||||
condition_id VARCHAR(100) UNIQUE NOT NULL COMMENT 'Condition ID',
|
||||
market_slug VARCHAR(255) COMMENT '市场 slug',
|
||||
market_question TEXT COMMENT '市场名称/问题',
|
||||
market_description TEXT COMMENT '市场描述',
|
||||
home_team VARCHAR(100) COMMENT '主队名称',
|
||||
away_team VARCHAR(100) COMMENT '客队名称',
|
||||
game_date DATE COMMENT '比赛日期',
|
||||
game_time BIGINT COMMENT '比赛时间（时间戳）',
|
||||
category VARCHAR(50) DEFAULT 'sports' COMMENT '分类',
|
||||
active BOOLEAN DEFAULT true COMMENT '是否活跃',
|
||||
closed BOOLEAN DEFAULT false COMMENT '是否已关闭',
|
||||
volume VARCHAR(50) COMMENT '交易量',
|
||||
liquidity VARCHAR(50) COMMENT '流动性',
|
||||
outcomes TEXT COMMENT '结果选项（JSON）',
|
||||
created_at BIGINT NOT NULL,
|
||||
updated_at BIGINT NOT NULL,
|
||||
INDEX idx_game_date (game_date),
|
||||
INDEX idx_active (active),
|
||||
INDEX idx_closed (closed),
|
||||
INDEX idx_category (category)
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='NBA赛事表（Polymarket市场）';
|
||||
```
|
||||
|
||||
### 4.3 数据获取服务实现
|
||||
|
||||
**服务接口设计**：
|
||||
|
||||
```kotlin
|
||||
interface NbaMarketService {
|
||||
/**
|
||||
* 获取 NBA 赛事列表
|
||||
* @param date 比赛日期（可选，不传则获取所有）
|
||||
* @param activeOnly 是否只获取活跃的市场
|
||||
* @return NBA 赛事列表
|
||||
*/
|
||||
suspend fun getNbaMarkets(
|
||||
date: LocalDate? = null,
|
||||
activeOnly: Boolean = true
|
||||
): Result<List<NbaMarketDto>>
|
||||
|
||||
/**
|
||||
* 同步 NBA 赛事列表（从 Polymarket API 获取并更新数据库）
|
||||
* @return 同步结果
|
||||
*/
|
||||
suspend fun syncNbaMarkets(): Result<SyncResult>
|
||||
|
||||
/**
|
||||
* 根据比赛信息匹配 Polymarket 市场
|
||||
* @param gameId NBA 比赛 ID
|
||||
* @param homeTeam 主队名称
|
||||
* @param awayTeam 客队名称
|
||||
* @param gameDate 比赛日期
|
||||
* @return 匹配的市场列表
|
||||
*/
|
||||
suspend fun matchMarketsByGame(
|
||||
gameId: String,
|
||||
homeTeam: String,
|
||||
awayTeam: String,
|
||||
gameDate: LocalDate
|
||||
): Result<List<NbaMarketDto>>
|
||||
}
|
||||
```
|
||||
|
||||
**实现逻辑**：
|
||||
|
||||
1. **从 Polymarket 获取市场列表**
|
||||
- 调用 Events API 或搜索接口
|
||||
- 筛选分类为 "sports" 且包含 "NBA" 的市场
|
||||
- 解析市场名称，提取比赛信息（主队、客队、日期等）
|
||||
|
||||
2. **数据解析和匹配**
|
||||
- 解析市场名称（question），提取球队名称和比赛日期
|
||||
- 匹配 NBA 比赛数据（通过球队名称和日期）
|
||||
- 建立 NBA 比赛和 Polymarket 市场的关联关系
|
||||
|
||||
3. **数据存储**
|
||||
- 保存到数据库
|
||||
- 建立索引，提高查询效率
|
||||
- 定期更新，确保数据最新
|
||||
|
||||
---
|
||||
|
||||
## 五、市场名称解析规则
|
||||
|
||||
### 5.1 市场名称格式
|
||||
|
||||
Polymarket 的 NBA 市场名称通常包含以下信息：
|
||||
- 球队名称（主队 vs 客队）
|
||||
- 比赛日期或时间
|
||||
- 比赛结果预测（如 "Will the Lakers win?"）
|
||||
|
||||
**常见格式示例**：
|
||||
- "Will the Lakers beat the Warriors on Dec 15?"
|
||||
- "Lakers vs Warriors - Dec 15, 2024"
|
||||
- "NBA: Lakers @ Warriors - Dec 15"
|
||||
|
||||
### 5.2 解析算法
|
||||
|
||||
**解析步骤**：
|
||||
1. 提取球队名称：使用正则表达式或关键词匹配
|
||||
2. 提取比赛日期：解析日期格式（如 "Dec 15, 2024"）
|
||||
3. 提取比赛结果：判断是 "win" 还是 "lose"
|
||||
4. 匹配 NBA 比赛：通过球队名称和日期匹配
|
||||
|
||||
**球队名称映射**：
|
||||
- 建立球队名称映射表（Polymarket 名称 -> 标准名称）
|
||||
- 处理缩写（如 "LAL" -> "Lakers"）
|
||||
- 处理别名（如 "Lakers" -> "Los Angeles Lakers"）
|
||||
|
||||
---
|
||||
|
||||
## 六、数据同步策略
|
||||
|
||||
### 6.1 同步频率
|
||||
|
||||
**定期同步**：
|
||||
- 每天同步一次：获取所有 NBA 相关市场
|
||||
- 每小时增量同步：检查新市场
|
||||
- 实时监控：通过 WebSocket 或轮询监控新市场
|
||||
|
||||
### 6.2 同步流程
|
||||
|
||||
1. **全量同步**（每天一次）
|
||||
- 从 Polymarket API 获取所有 sports 分类的市场
|
||||
- 筛选包含 NBA 相关信息的市场
|
||||
- 更新数据库
|
||||
|
||||
2. **增量同步**（每小时一次）
|
||||
- 获取最近 24 小时的新市场
|
||||
- 只更新新增和变化的市场
|
||||
- 标记已关闭的市场
|
||||
|
||||
3. **实时监控**（可选）
|
||||
- 通过 WebSocket 订阅新市场
|
||||
- 或每 5 分钟轮询一次新市场
|
||||
- 实时更新数据库
|
||||
|
||||
### 6.3 数据去重和更新
|
||||
|
||||
**去重策略**：
|
||||
- 使用 condition_id 作为唯一标识
|
||||
- 如果市场已存在，更新信息
|
||||
- 如果市场不存在，插入新记录
|
||||
|
||||
**更新策略**：
|
||||
- 更新活跃状态（active、closed）
|
||||
- 更新交易量和流动性
|
||||
- 更新结束日期（如果变化）
|
||||
|
||||
---
|
||||
|
||||
## 七、API 接口扩展
|
||||
|
||||
### 7.1 扩展 Gamma API 接口
|
||||
|
||||
**添加新的接口方法**：
|
||||
|
||||
```kotlin
|
||||
interface PolymarketGammaApi {
|
||||
// ... 现有方法
|
||||
|
||||
/**
|
||||
* 搜索市场（如果 API 支持）
|
||||
* @param query 搜索关键词
|
||||
* @param category 分类筛选
|
||||
* @param limit 返回数量限制
|
||||
* @param offset 偏移量
|
||||
* @return 市场列表
|
||||
*/
|
||||
@GET("/markets/search")
|
||||
suspend fun searchMarkets(
|
||||
@Query("query") query: String? = null,
|
||||
@Query("category") category: String? = null,
|
||||
@Query("limit") limit: Int? = null,
|
||||
@Query("offset") offset: Int? = null
|
||||
): Response<List<MarketResponse>>
|
||||
|
||||
/**
|
||||
* 获取事件列表（如果 API 支持）
|
||||
* @param category 分类筛选
|
||||
* @param limit 返回数量限制
|
||||
* @param offset 偏移量
|
||||
* @return 事件列表
|
||||
*/
|
||||
@GET("/events")
|
||||
suspend fun listEvents(
|
||||
@Query("category") category: String? = null,
|
||||
@Query("limit") limit: Int? = null,
|
||||
@Query("offset") offset: Int? = null
|
||||
): Response<List<EventResponse>>
|
||||
|
||||
/**
|
||||
* 获取系列列表（如果 API 支持）
|
||||
* @param category 分类筛选
|
||||
* @param limit 返回数量限制
|
||||
* @param offset 偏移量
|
||||
* @return 系列列表
|
||||
*/
|
||||
@GET("/series")
|
||||
suspend fun listSeries(
|
||||
@Query("category") category: String? = null,
|
||||
@Query("limit") limit: Int? = null,
|
||||
@Query("offset") offset: Int? = null
|
||||
): Response<List<SeriesResponse>>
|
||||
}
|
||||
```
|
||||
|
||||
### 7.2 后端服务实现
|
||||
|
||||
**创建 NBA 市场服务**：
|
||||
|
||||
```kotlin
|
||||
@Service
|
||||
class NbaMarketService(
|
||||
private val gammaApi: PolymarketGammaApi,
|
||||
private val nbaGameRepository: NbaGameRepository
|
||||
) {
|
||||
/**
|
||||
* 获取 NBA 赛事列表
|
||||
*/
|
||||
suspend fun getNbaMarkets(
|
||||
date: LocalDate? = null,
|
||||
activeOnly: Boolean = true
|
||||
): Result<List<NbaMarketDto>> {
|
||||
// 实现逻辑
|
||||
}
|
||||
|
||||
/**
|
||||
* 同步 NBA 赛事列表
|
||||
*/
|
||||
suspend fun syncNbaMarkets(): Result<SyncResult> {
|
||||
// 实现逻辑
|
||||
}
|
||||
|
||||
/**
|
||||
* 匹配市场
|
||||
*/
|
||||
suspend fun matchMarketsByGame(
|
||||
gameId: String,
|
||||
homeTeam: String,
|
||||
awayTeam: String,
|
||||
gameDate: LocalDate
|
||||
): Result<List<NbaMarketDto>> {
|
||||
// 实现逻辑
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 7.3 前端 API 接口
|
||||
|
||||
**添加市场列表接口**：
|
||||
|
||||
```kotlin
|
||||
@RestController
|
||||
@RequestMapping("/api/nba/markets")
|
||||
class NbaMarketController(
|
||||
private val nbaMarketService: NbaMarketService
|
||||
) {
|
||||
/**
|
||||
* 获取 NBA 赛事列表
|
||||
*/
|
||||
@PostMapping("/list")
|
||||
fun getNbaMarkets(@RequestBody request: NbaMarketListRequest): ResponseEntity<ApiResponse<List<NbaMarketDto>>> {
|
||||
// 实现逻辑
|
||||
}
|
||||
|
||||
/**
|
||||
* 同步 NBA 赛事列表
|
||||
*/
|
||||
@PostMapping("/sync")
|
||||
fun syncNbaMarkets(): ResponseEntity<ApiResponse<SyncResult>> {
|
||||
// 实现逻辑
|
||||
}
|
||||
|
||||
/**
|
||||
* 根据比赛匹配市场
|
||||
*/
|
||||
@PostMapping("/match")
|
||||
fun matchMarkets(@RequestBody request: MatchMarketRequest): ResponseEntity<ApiResponse<List<NbaMarketDto>>> {
|
||||
// 实现逻辑
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 八、实施步骤
|
||||
|
||||
### 8.1 第一阶段：API 调研和测试（1 周）
|
||||
|
||||
**任务清单**：
|
||||
- [ ] 调研 Polymarket API 文档，确认可用的接口
|
||||
- [ ] 测试 Events API 或 Series API（如果存在）
|
||||
- [ ] 测试搜索接口（如果存在）
|
||||
- [ ] 确认最佳的数据获取方式
|
||||
|
||||
### 8.2 第二阶段：数据获取实现（1-2 周）
|
||||
|
||||
**任务清单**：
|
||||
- [ ] 扩展 PolymarketGammaApi 接口
|
||||
- [ ] 实现 NBA 市场数据获取服务
|
||||
- [ ] 实现市场名称解析算法
|
||||
- [ ] 实现 NBA 比赛和市场匹配逻辑
|
||||
|
||||
### 8.3 第三阶段：数据存储和同步（1 周）
|
||||
|
||||
**任务清单**：
|
||||
- [ ] 创建数据库表（nba_games）
|
||||
- [ ] 实现数据存储逻辑
|
||||
- [ ] 实现数据同步服务
|
||||
- [ ] 实现定时同步任务
|
||||
|
||||
### 8.4 第四阶段：API 接口开发（1 周）
|
||||
|
||||
**任务清单**：
|
||||
- [ ] 创建后端 API 接口
|
||||
- [ ] 实现前端 API 调用
|
||||
- [ ] 实现前端页面展示
|
||||
- [ ] 测试和优化
|
||||
|
||||
---
|
||||
|
||||
## 九、注意事项
|
||||
|
||||
### 9.1 API 限制
|
||||
|
||||
- **请求频率**：注意 API 的请求频率限制
|
||||
- **数据量**：NBA 相关市场可能很多，需要分页获取
|
||||
- **数据更新**：市场状态可能频繁变化，需要定期更新
|
||||
|
||||
### 9.2 数据匹配
|
||||
|
||||
- **球队名称**：Polymarket 的球队名称可能与标准名称不一致，需要建立映射表
|
||||
- **比赛日期**：需要处理时区问题
|
||||
- **市场状态**：需要实时更新市场的活跃状态
|
||||
|
||||
### 9.3 错误处理
|
||||
|
||||
- **API 失败**：实现重试机制
|
||||
- **数据解析失败**：记录错误日志，跳过无法解析的市场
|
||||
- **匹配失败**：如果无法匹配 NBA 比赛，仍然保存市场数据，后续可以手动匹配
|
||||
|
||||
---
|
||||
|
||||
## 十、实际实现方案（基于当前 API 限制）
|
||||
|
||||
### 10.1 当前 API 限制分析
|
||||
|
||||
**现状**：
|
||||
- Polymarket Gamma API 的 `/markets` 接口只支持通过 `condition_ids` 查询
|
||||
- 不支持按分类、关键词、日期等筛选
|
||||
- 没有提供搜索接口或 Events API
|
||||
|
||||
**解决方案**：
|
||||
由于 API 限制，需要采用以下策略：
|
||||
1. **建立 NBA 市场 condition_ids 数据库**：手动或通过其他方式收集 NBA 市场的 condition_ids
|
||||
2. **定期更新 condition_ids 列表**：通过爬取或监控获取新的 NBA 市场
|
||||
3. **批量查询市场信息**：使用收集到的 condition_ids 批量查询市场详情
|
||||
|
||||
### 10.2 实现步骤
|
||||
|
||||
#### 步骤 1：收集 NBA 市场 condition_ids
|
||||
|
||||
**方式一：手动收集**
|
||||
- 访问 Polymarket 网站，搜索 "NBA" 相关市场
|
||||
- 从市场 URL 中提取 condition_id（如 `https://polymarket.com/event/xxx`）
|
||||
- 保存到数据库或配置文件
|
||||
|
||||
**方式二：通过爬取获取**
|
||||
- 爬取 Polymarket 网站的市场列表页面
|
||||
- 解析 HTML，提取 condition_ids
|
||||
- 筛选分类为 "sports" 且包含 "NBA" 的市场
|
||||
|
||||
**方式三：通过监控获取**
|
||||
- 监控 Polymarket 的新市场创建
|
||||
- 通过 WebSocket 或轮询获取新市场
|
||||
- 筛选 NBA 相关市场
|
||||
|
||||
#### 步骤 2：批量查询市场信息
|
||||
|
||||
**实现代码**：
|
||||
|
||||
```kotlin
|
||||
@Service
|
||||
class NbaMarketService(
|
||||
private val gammaApi: PolymarketGammaApi,
|
||||
private val nbaGameRepository: NbaGameRepository
|
||||
) {
|
||||
private val logger = LoggerFactory.getLogger(NbaMarketService::class.java)
|
||||
|
||||
/**
|
||||
* 批量获取 NBA 市场信息
|
||||
* @param conditionIds condition ID 列表
|
||||
* @return 市场列表
|
||||
*/
|
||||
suspend fun batchGetMarkets(conditionIds: List<String>): Result<List<MarketResponse>> {
|
||||
return try {
|
||||
// Polymarket API 可能对批量查询有限制，需要分批查询
|
||||
val batchSize = 50 // 每批查询 50 个
|
||||
val allMarkets = mutableListOf<MarketResponse>()
|
||||
|
||||
conditionIds.chunked(batchSize).forEach { batch ->
|
||||
val response = gammaApi.listMarkets(
|
||||
conditionIds = batch,
|
||||
includeTag = true
|
||||
)
|
||||
|
||||
if (response.isSuccessful && response.body() != null) {
|
||||
val markets = response.body()!!
|
||||
// 过滤 NBA 相关市场
|
||||
val nbaMarkets = markets.filter { market ->
|
||||
isNbaMarket(market)
|
||||
}
|
||||
allMarkets.addAll(nbaMarkets)
|
||||
} else {
|
||||
logger.warn("批量查询市场失败: ${response.code()} ${response.message()}")
|
||||
}
|
||||
|
||||
// 避免请求过快，添加延迟
|
||||
kotlinx.coroutines.delay(100)
|
||||
}
|
||||
|
||||
Result.success(allMarkets)
|
||||
} catch (e: Exception) {
|
||||
logger.error("批量获取市场信息异常: ${e.message}", e)
|
||||
Result.failure(e)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 判断是否为 NBA 市场
|
||||
*/
|
||||
private fun isNbaMarket(market: MarketResponse): Boolean {
|
||||
// 检查分类
|
||||
if (market.category?.lowercase() != "sports") {
|
||||
return false
|
||||
}
|
||||
|
||||
// 检查市场名称或描述中是否包含 NBA 相关关键词
|
||||
val question = market.question?.lowercase() ?: ""
|
||||
val description = market.description?.lowercase() ?: ""
|
||||
|
||||
val nbaKeywords = listOf(
|
||||
"nba", "basketball", "lakers", "warriors", "celtics", "heat",
|
||||
"bulls", "knicks", "nets", "76ers", "bucks", "suns", "nuggets"
|
||||
)
|
||||
|
||||
return nbaKeywords.any { keyword ->
|
||||
question.contains(keyword) || description.contains(keyword)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 同步 NBA 市场列表
|
||||
*/
|
||||
suspend fun syncNbaMarkets(): Result<SyncResult> {
|
||||
return try {
|
||||
// 1. 从数据库获取所有已知的 condition_ids
|
||||
val knownConditionIds = nbaGameRepository.findAllConditionIds()
|
||||
|
||||
// 2. 批量查询市场信息
|
||||
val marketsResult = batchGetMarkets(knownConditionIds)
|
||||
|
||||
if (!marketsResult.isSuccess) {
|
||||
return Result.failure(marketsResult.exceptionOrNull() ?: Exception("获取市场失败"))
|
||||
}
|
||||
|
||||
val markets = marketsResult.getOrNull() ?: emptyList()
|
||||
|
||||
// 3. 解析市场信息，提取比赛数据
|
||||
val nbaGames = markets.mapNotNull { market ->
|
||||
parseMarketToNbaGame(market)
|
||||
}
|
||||
|
||||
// 4. 保存到数据库
|
||||
nbaGameRepository.saveAll(nbaGames)
|
||||
|
||||
Result.success(
|
||||
SyncResult(
|
||||
total = markets.size,
|
||||
success = nbaGames.size,
|
||||
failed = markets.size - nbaGames.size
|
||||
)
|
||||
)
|
||||
} catch (e: Exception) {
|
||||
logger.error("同步 NBA 市场列表异常: ${e.message}", e)
|
||||
Result.failure(e)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析市场信息为 NBA 比赛数据
|
||||
*/
|
||||
private fun parseMarketToNbaGame(market: MarketResponse): NbaGame? {
|
||||
return try {
|
||||
// 解析市场名称，提取球队名称和日期
|
||||
val (homeTeam, awayTeam, gameDate) = parseMarketQuestion(market.question ?: "")
|
||||
?: return null
|
||||
|
||||
NbaGame(
|
||||
polymarketMarketId = market.id,
|
||||
conditionId = market.conditionId ?: return null,
|
||||
marketSlug = market.slug,
|
||||
marketQuestion = market.question,
|
||||
marketDescription = market.description,
|
||||
homeTeam = homeTeam,
|
||||
awayTeam = awayTeam,
|
||||
gameDate = gameDate,
|
||||
gameTime = parseGameTime(market.startDate),
|
||||
category = market.category ?: "sports",
|
||||
active = market.active ?: true,
|
||||
closed = market.closed ?: false,
|
||||
volume = market.volume,
|
||||
liquidity = market.liquidity,
|
||||
outcomes = market.outcomes,
|
||||
createdAt = System.currentTimeMillis(),
|
||||
updatedAt = System.currentTimeMillis()
|
||||
)
|
||||
} catch (e: Exception) {
|
||||
logger.warn("解析市场信息失败: ${market.question}, error: ${e.message}")
|
||||
null
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析市场名称，提取球队名称和日期
|
||||
* 示例: "Will the Lakers beat the Warriors on Dec 15?" -> ("Lakers", "Warriors", 2024-12-15)
|
||||
*/
|
||||
private fun parseMarketQuestion(question: String): Triple<String, String, LocalDate>? {
|
||||
// 实现解析逻辑
|
||||
// 使用正则表达式或 NLP 方法提取信息
|
||||
// 这里简化处理，实际需要更复杂的解析逻辑
|
||||
return null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 步骤 3：定时同步任务
|
||||
|
||||
**实现代码**：
|
||||
|
||||
```kotlin
|
||||
@Component
|
||||
class NbaMarketSyncScheduler(
|
||||
private val nbaMarketService: NbaMarketService
|
||||
) {
|
||||
private val logger = LoggerFactory.getLogger(NbaMarketSyncScheduler::class.java)
|
||||
|
||||
/**
|
||||
* 每天凌晨 2 点同步一次
|
||||
*/
|
||||
@Scheduled(cron = "0 0 2 * * ?")
|
||||
fun syncNbaMarketsDaily() {
|
||||
logger.info("开始同步 NBA 市场列表...")
|
||||
runBlocking {
|
||||
val result = nbaMarketService.syncNbaMarkets()
|
||||
result.fold(
|
||||
onSuccess = { syncResult ->
|
||||
logger.info("同步 NBA 市场列表成功: total=${syncResult.total}, success=${syncResult.success}, failed=${syncResult.failed}")
|
||||
},
|
||||
onFailure = { e ->
|
||||
logger.error("同步 NBA 市场列表失败: ${e.message}", e)
|
||||
}
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 每小时增量同步一次
|
||||
*/
|
||||
@Scheduled(cron = "0 0 * * * ?")
|
||||
fun syncNbaMarketsHourly() {
|
||||
logger.info("开始增量同步 NBA 市场列表...")
|
||||
runBlocking {
|
||||
// 只同步最近 24 小时的新市场
|
||||
val result = nbaMarketService.syncNbaMarketsIncremental()
|
||||
result.fold(
|
||||
onSuccess = { syncResult ->
|
||||
logger.info("增量同步 NBA 市场列表成功: total=${syncResult.total}, success=${syncResult.success}")
|
||||
},
|
||||
onFailure = { e ->
|
||||
logger.error("增量同步 NBA 市场列表失败: ${e.message}", e)
|
||||
}
|
||||
)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 10.3 数据模型定义
|
||||
|
||||
**实体类**：
|
||||
|
||||
```kotlin
|
||||
@Entity
|
||||
@Table(name = "nba_games")
|
||||
data class NbaGame(
|
||||
@Id
|
||||
@GeneratedValue(strategy = GenerationType.IDENTITY)
|
||||
val id: Long? = null,
|
||||
|
||||
@Column(name = "polymarket_market_id", unique = true, nullable = false, length = 100)
|
||||
val polymarketMarketId: String,
|
||||
|
||||
@Column(name = "condition_id", unique = true, nullable = false, length = 100)
|
||||
val conditionId: String,
|
||||
|
||||
@Column(name = "market_slug", length = 255)
|
||||
val marketSlug: String? = null,
|
||||
|
||||
@Column(name = "market_question", columnDefinition = "TEXT")
|
||||
val marketQuestion: String? = null,
|
||||
|
||||
@Column(name = "market_description", columnDefinition = "TEXT")
|
||||
val marketDescription: String? = null,
|
||||
|
||||
@Column(name = "home_team", length = 100)
|
||||
val homeTeam: String? = null,
|
||||
|
||||
@Column(name = "away_team", length = 100)
|
||||
val awayTeam: String? = null,
|
||||
|
||||
@Column(name = "game_date")
|
||||
val gameDate: LocalDate? = null,
|
||||
|
||||
@Column(name = "game_time")
|
||||
val gameTime: Long? = null,
|
||||
|
||||
@Column(name = "category", length = 50)
|
||||
val category: String = "sports",
|
||||
|
||||
@Column(name = "active")
|
||||
val active: Boolean = true,
|
||||
|
||||
@Column(name = "closed")
|
||||
val closed: Boolean = false,
|
||||
|
||||
@Column(name = "volume", length = 50)
|
||||
val volume: String? = null,
|
||||
|
||||
@Column(name = "liquidity", length = 50)
|
||||
val liquidity: String? = null,
|
||||
|
||||
@Column(name = "outcomes", columnDefinition = "TEXT")
|
||||
val outcomes: String? = null,
|
||||
|
||||
@Column(name = "created_at", nullable = false)
|
||||
val createdAt: Long = System.currentTimeMillis(),
|
||||
|
||||
@Column(name = "updated_at", nullable = false)
|
||||
var updatedAt: Long = System.currentTimeMillis()
|
||||
)
|
||||
```
|
||||
|
||||
### 10.4 API 接口实现
|
||||
|
||||
**Controller**：
|
||||
|
||||
```kotlin
|
||||
@RestController
|
||||
@RequestMapping("/api/nba/markets")
|
||||
class NbaMarketController(
|
||||
private val nbaMarketService: NbaMarketService,
|
||||
private val messageSource: MessageSource
|
||||
) {
|
||||
private val logger = LoggerFactory.getLogger(NbaMarketController::class.java)
|
||||
|
||||
/**
|
||||
* 获取 NBA 赛事列表
|
||||
*/
|
||||
@PostMapping("/list")
|
||||
fun getNbaMarkets(@RequestBody request: NbaMarketListRequest): ResponseEntity<ApiResponse<List<NbaMarketDto>>> {
|
||||
return try {
|
||||
val result = runBlocking {
|
||||
nbaMarketService.getNbaMarkets(
|
||||
date = request.date,
|
||||
activeOnly = request.activeOnly ?: true
|
||||
)
|
||||
}
|
||||
|
||||
result.fold(
|
||||
onSuccess = { markets ->
|
||||
ResponseEntity.ok(ApiResponse.success(markets))
|
||||
},
|
||||
onFailure = { e ->
|
||||
logger.error("获取 NBA 赛事列表失败: ${e.message}", e)
|
||||
ResponseEntity.ok(ApiResponse.error(ErrorCode.SERVER_ERROR, e.message, messageSource))
|
||||
}
|
||||
)
|
||||
} catch (e: Exception) {
|
||||
logger.error("获取 NBA 赛事列表异常: ${e.message}", e)
|
||||
ResponseEntity.ok(ApiResponse.error(ErrorCode.SERVER_ERROR, e.message, messageSource))
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 同步 NBA 赛事列表
|
||||
*/
|
||||
@PostMapping("/sync")
|
||||
fun syncNbaMarkets(): ResponseEntity<ApiResponse<SyncResult>> {
|
||||
return try {
|
||||
val result = runBlocking {
|
||||
nbaMarketService.syncNbaMarkets()
|
||||
}
|
||||
|
||||
result.fold(
|
||||
onSuccess = { syncResult ->
|
||||
ResponseEntity.ok(ApiResponse.success(syncResult))
|
||||
},
|
||||
onFailure = { e ->
|
||||
logger.error("同步 NBA 赛事列表失败: ${e.message}", e)
|
||||
ResponseEntity.ok(ApiResponse.error(ErrorCode.SERVER_ERROR, e.message, messageSource))
|
||||
}
|
||||
)
|
||||
} catch (e: Exception) {
|
||||
logger.error("同步 NBA 赛事列表异常: ${e.message}", e)
|
||||
ResponseEntity.ok(ApiResponse.error(ErrorCode.SERVER_ERROR, e.message, messageSource))
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 十一、参考资源
|
||||
|
||||
- [Polymarket API 文档](https://docs.polymarket.com/)
|
||||
- [Polymarket Gamma API 文档](https://docs.polymarket.com/api-reference/markets/list-markets)
|
||||
- [NBA 球队名称标准](https://www.nba.com/teams)
|
||||
- [Polymarket 网站](https://polymarket.com/)（用于手动收集 condition_ids）
|
||||
|
||||
---
|
||||
|
||||
**文档结束**
|
||||
|
||||
Reference in New Issue
Block a user