量化交易系统

技术标签：Golang / Spring Boot / React / MySQL / Redis / 阿里云
项目角色：资深研发工程师

面向中心化交易所的策略执行与运营平台，支持多交易所行情分析、策略配置、自动化交易执行和收益统计。管理后台负责配置与运营，Golang 交易机器人负责行情检测、机会识别、订单执行、任务调度及交易状态维护。

文档依据项目负责人提供的项目描述与技术亮点整理，尚未核验该系统源码。下文中的模块能力来自项目描述；接口边界、细化状态、数据字段及异常处理细节作为设计说明和核验建议，不代表已确认的代码实现。未提供的性能数值、消息队列产品和云服务部署细节不作推定。

一、项目概述

系统把策略配置转化为持续运行的交易任务，并将行情判断、挂撤单、成交记录与收益统计连接起来。运营人员通过后台管理交易所授权与策略参数，机器人根据任务状态启动或停止策略实例，执行过程产生的订单事件异步进入持久化与统计链路。

核心功能包括：

密钥配置：管理不同交易所 API Key，支持账户资产查询和订单操作所需授权。
币种分析：对比交易对价格、盘口和潜在利润空间，为机会判断提供输入。
策略配置：配置交易阈值、任务启停和仓位规则，适应不同市场条件。
利润统计：查看历史交易、收益与策略结果，支持复盘和参数调整。

行情价差只是机会线索，实际执行结果还受手续费、成交深度、滑点、订单部分成交等因素影响。文档中的“套利机会”表示策略识别结果，不代表确定收益。

二、系统架构与模块职责

React 管理界面
    → Spring Boot 管理服务
        → 密钥配置 / 币种分析 / 策略配置 / 任务管理 / 利润统计
        → MySQL、Redis

Golang 交易机器人
    → 生命周期与依赖装配
    → 数据库任务轮询 → 策略实例 / 插件式 Runner
    → 行情检测 → 价格判断 → 订单状态机
    → 交易所接入层 → OKX / Binance 等交易所
    → 订单事件 → 消息队列 → 批量落库 → 统计与对账
    → 结构化日志 / Telegram 告警

这是逻辑架构，消息生产、消费与持久化服务的实际部署位置需要结合源码确认。

模块	主要职责	关键边界
React 界面	展示配置、任务与交易结果	展示状态应区分请求已提交与机器人已生效
Spring Boot 后台	配置管理、运营入口、统计查询	校验权限、参数与配置版本
Golang 框架	生命周期、依赖装配、调度与 Runner 管理	控制策略实例数量与退出过程
策略 Runner	检测行情、判断阈值、推进订单执行	避免重复动作，维护执行上下文
交易所接入层	余额、盘口、下单、撤单和查单	保留交易所差异和原始错误信息
订单持久化链路	消费订单事件并批量落库	处理重复、乱序与写入失败
日志与告警	关联任务、订单与异常	避免暴露凭证，控制重复通知

三、管理后台与运营流程

从配置到运行

运营人员选择交易所并配置授权，查看币种与盘口分析结果，配置策略参数和仓位规则，创建任务并请求启动。机器人检测到待运行任务后装配策略实例，持续回写运行状态和交易结果，后台再展示实际执行进度。

配置与运行态分开

建议区分策略定义、参数版本、任务期望状态和机器人实际状态。后台点击停止后，先展示“待停止”；机器人完成收尾后再显示已停止。运行过程中调整阈值或阶梯仓位，需要明确立即生效、下一轮生效或重启生效，避免同一轮交易使用混合参数。

币种分析

对比多交易所同一资产时，先确认交易对、计价币、数量精度与盘口时间。机会分析应结合可成交深度及执行成本，保留行情快照时间，防止旧盘口推动新的交易。

四、自研 Golang 机器人框架

框架封装应用生命周期、依赖装配、守护调度、优雅停机与插件式 Runner 接入，让不同策略复用运行基础设施。

生命周期

启动阶段加载配置并装配数据库、Redis、交易所客户端、事件生产器和告警组件；运行阶段由调度器管理策略实例；退出阶段停止领取新任务，向运行实例传播取消信号，处理在途订单状态并释放资源。

Runner 边界

Runner 负责一类策略的执行循环，接收稳定的配置、取消上下文和公共依赖。行情获取、交易所调用、订单记录与告警不应在每个策略中重复实现。实际 Runner 接口、注册方式和依赖容器实现待源码核验。

守护与退出

守护机制应区分可恢复的运行异常和需要人工处理的交易异常。实例崩溃后先恢复订单上下文，再决定是否继续。优雅停机表示有序结束本地工作；已在交易所生效的订单仍需查单、撤单或由恢复流程继续管理。

五、策略任务调度

项目以数据库状态轮询驱动“待运行 / 运行 / 待停止”的任务流转，并使用协程隔离不同策略实例。

状态	调度行为	需要核对的执行结果
待运行	校验参数和依赖，尝试领取并创建实例	确认实例启动后推进到运行
运行	维护实例与任务对应关系	持续观察心跳、错误及订单状态
待停止	通知实例退出，处理在途工作	收尾完成后写入实际停止结果

最终停止态、失败态和恢复态的具体枚举未提供，应与数据库定义对齐。

实例隔离与领取

一个任务对应独立执行上下文，慢策略不阻塞其他策略。若部署多个机器人进程，仅靠“查到待运行任务”不能保证唯一执行；建议采用条件更新、版本或租约确认领取权，并记录任务所属实例。

资源与恢复

轮询间隔、并行任务数和交易所请求并发需要分别限制。应用重启时核对数据库任务与交易所活跃订单，再恢复实例，避免将进程退出前已提交的订单重复下单。

六、价格触发与订单状态机

项目使用“价格触发 + 订单状态机”模型，支持秒级行情检测、阈值挂撤单、基准价更新、阶梯仓位、超时撤单与异常告警。“秒级检测”为项目描述中的能力目标，具体延迟与吞吐未提供测量数据。

价格触发链路

读取盘口 → 检查行情时效 → 对照基准价与阈值
    → 计算本阶梯目标仓位 → 检查余额和交易规则
    → 创建订单意图 → 下单 / 查单 / 撤单
    → 汇总已成交数量与费用 → 更新策略上下文

基准价应在明确定义的业务节点更新，例如某一成交条件达成后。它的具体更新规则需以策略实现为准，不能把下单成功直接等同于完成一次仓位调整。

建议订单状态划分

以下为说明性状态，不代表项目现有枚举：

状态	含义	后续动作
待提交	已生成订单意图	校验执行权与参数后提交
提交中	下单请求进行中	按响应记录已受理、拒绝或未知
活跃 / 部分成交	订单仍有未成交量	查单、等待或触发撤单
待撤销	已发送撤单请求	继续查询最终成交与撤单状态
已成交 / 已撤销 / 已拒绝	已知终态	更新订单记录与策略上下文
结果未知	无法确认是否受理或完成	查询原订单并保留待处理上下文

阶梯仓位与超时撤单

每个阶梯关联目标数量、实际成交数量和活跃订单。部分成交后继续下单时，按剩余目标计算，避免重复计算原目标。超时撤单必须考虑撤单与成交同时发生：撤单响应后仍应核对最终成交量，再更新基准价及仓位。

七、交易所接入层

统一封装余额查询、盘口获取、下单、撤单、查单，支持 OKX、Binance 等交易所扩展。公共层表达业务动作，具体实现负责参数转换、错误映射、超时与限流处理。

公共能力	需要保留的差异
余额查询	可用、冻结、账户类型与更新时间
盘口查询	交易对命名、深度档位与时间戳
下单	价格精度、数量步长、最小金额与订单类型
撤单与查单	订单标识、最终状态和部分成交明细
错误处理	限流、业务拒绝、网络失败和结果未知

这些是接入核验项，具体规则以实际交易所接口及代码为准。

超时与重试

只读查询可以在总预算内退避重试；下单超时需要先查原订单。建议保留客户端订单标识，并在对应交易所支持的范围内用于关联查询，避免通用重试器重复下单。撤单失败也要区分请求未送达、订单已成交和明确拒绝。

多交易所执行

跨交易所的多笔订单不会天然原子完成。策略应明确一侧成交、另一侧失败或部分成交时的后续动作及暴露上限；这属于策略规则，当前描述未提供具体对冲或补偿算法。

八、消息队列与订单持久化

通过消息队列解耦交易执行与订单落库，消费端批量写入订单事件。MySQL 与 Redis 共同支撑策略配置、任务状态、收益数据和交易记录，具体表结构、Redis Key 与消息队列产品未提供。

建议事件内容

关联事件 ID、任务 ID、策略版本、交易所、账户逻辑标识、客户端订单号、交易所订单号、状态、成交数量、费用和观测时间。记录结构应支持追踪同一订单的多次状态变化。

批量写入与重复事件

批量落库需要处理部分失败和重放。建议用唯一事件标识防重复写入，并对状态更新作版本或顺序检查，避免迟到事件把已成交订单覆盖为早期状态。成交明细与订单快照应分开理解：同一订单可能产生多笔成交。

持久化失败窗口

“消息已发送”与“交易所已接收”是不同事实。发送失败、消费后未确认、数据库提交后消费者退出都需要恢复规则。若执行端不能保证事件可靠投递，应通过交易所查单与对账补齐，不能单靠异步队列宣称没有遗漏。

九、利润统计与对账

后台展示历史交易、收益和策略执行结果。统计首先需要定义范围：按策略任务、交易所账户、交易对和时间窗口分别统计，明确统计使用成交时间还是订单创建时间。

建议区分的指标

已实现收益：基于可匹配的实际成交与成本口径计算。
持仓浮动结果：按选定估值时间和价格展示，与已实现部分区分。
手续费：记录原币种与换算依据，避免直接累加不同币种。
运行指标：任务运行时间、成交次数、拒单及异常次数。

具体盈亏算法、成本分摊方式和汇率来源未提供，不能直接以订单价格差替代净收益。

结果对账

将本地订单、成交明细与交易所查询结果核对，再核对费用和账户变化。处理部分成交撤单、费用使用第三方币种、人工交易及资金划转时，应区分策略收益与账户总资产变化。异步批量落库期间标明统计更新时间，避免把短时延迟误认为数据丢失。

十、密钥管理、日志与 Telegram 告警

项目集成密钥加解密、结构化日志和 Telegram 告警，为授权管理、执行追踪与异常响应提供支持。

密钥配置

API Key 和 Secret 的存储与使用需要加解密机制配合访问权限。建议界面只显示脱敏值，机器人按任务权限读取；加密主密钥与密文分开管理。具体加密算法、密钥轮换和权限模型未提供，不把技术标签等同于安全验证结论。

结构化日志

用任务 ID、策略版本、交易所、订单标识、状态变化、耗时和错误类别连接运行链路。不要记录 Secret、完整签名参数或认证请求头。排查下单异常时保留业务错误码与可复现的非敏感参数。

Telegram 告警

对机器人异常退出、任务长时间待停止、下单结果未知、撤单失败、持久化积压和对账差异发送明确告警。建议按任务与故障类型合并重复通知，附上时间、任务、订单和下一步检查入口；告警发送失败不得影响交易状态保存。

十一、部署、恢复与验证

项目使用阿里云；具体计算实例、数据库、缓存、消息服务和网络拓扑未提供。本章按逻辑组件说明运行检查，不指定未经确认的云产品或容量。

启动与退出

启动时确认配置、数据库、Redis、消息通道与交易所连接可用，再开始领取任务。退出时停止接收新任务，通知 Runner 收尾，保存可恢复上下文，等待订单事件提交并关闭连接。未完成订单交由恢复流程继续核对。

验证场景

场景	重点检查
两个机器人同时发现待运行任务	同一任务是否只产生一个有效执行实例
行情停止更新或盘口过旧	是否暂停新的价格触发动作
下单已受理但响应丢失	是否查询原订单而非重复下单
部分成交后触发撤单	最终成交量与剩余仓位是否一致
实例退出时仍有活跃订单	是否保留订单并在恢复后继续追踪
消息重复或乱序	订单状态与成交明细是否正确收敛
批量落库失败后恢复	是否补齐事件且没有重复统计收益
策略参数在运行期间调整	是否使用明确的配置版本
Telegram 不可用	是否保留日志与可恢复的告警记录

先以模拟交易所响应验证状态分支，再在适用的测试环境验证接口；本文档尚未代表真实账户集成测试结果。

十二、项目角色与技术价值

项目角色为资深研发工程师。技术工作围绕 Golang 机器人框架、数据库驱动的任务调度、价格触发与订单状态机、交易所接口抽象、异步订单持久化，以及密钥与运维追踪能力展开。

框架复用减少策略重复开发；协程隔离让策略独立运行；统一接入层降低交易所扩展时的重复工作；订单事件和统计链路便于复盘与运营。这些是设计目的与能力说明，服务器资源降低、执行效率提升等效果需要以实际对照测量补充。

与多链策略系统相比，本系统主要围绕中心化交易所的账户、行情与订单 API 组织执行；两者可以复用任务编排和可观测性的设计思路，具体交易协议与状态语义分别实现。