前言随着 MiniQMT 相关功能限制收紧大量依赖 MiniQMT 实现外部策略联动、自动化交易的量化交易者面临方案迁移。本文基于大 QMT 内置 Python 环境整理了三套成熟可落地的外部信号接入替代方案覆盖从轻量单机到分布式架构的不同需求帮助交易者快速完成自动化交易能力的替换与升级。方案一文件监控方案轻量快速接入文件监控是落地门槛最低、部署最快的替代方案通过本地文本文件作为信号载体实现外部策略与大 QMT 的联动尤其适合通达信等自带预警输出的工具快速接入自动化交易。1.1 核心流程信号生成由外部策略如通达信预警系统生成交易信号按固定格式输出到指定文本文件例如qmt_txt_min_rw_test.txt。QMT 监控大 QMT 内置 Python 通过定时轮询机制持续监听目标文件的内容更新。信号解析检测到文件变化后按行读取文件内容解析出股票代码、交易方向、委托价格等核心交易字段。执行交易调用 QMT 原生passorder函数执行限价或市价委托下单。1.2 优化要点异常处理针对文件被占用、读写冲突的场景加入重试机制避免信号漏单。性能优化毫秒级交易场景下建议将文件轮询间隔设置为≤1 秒平衡性能与系统资源消耗。1.3 实现步骤编写外部信号的文件写入代码确保交易信号以统一格式写入指定 TXT 文件。创建独立空文件夹作为信号文件存放目录避免其他文件干扰。在大 QMT 策略环境中编写文件读写逻辑验证文件写入、读取的闭环能力。打通读写后补充信号字段解析与passorder下单逻辑完成全流程联调。1.4 适用场景适合通达信用户快速接入自动化交易是无需复杂架构的轻量级解决方案适配低频、半自动交易场景。方案二Redis 实时信号方案低延迟高频场景Redis 方案基于内存数据库的消息队列 / 发布订阅能力实现毫秒级信号传递是对延迟要求较高的高频交易场景的首选方案。2.1 核心流程信号推送外部策略生成交易信号后写入 Redis 的 List 队列或发布到 Pub/Sub 消息通道。QMT 消费大 QMT 内置 Python 实时监听 Redis 通道接收到信号后即时触发交易执行。2.2 优化要点数据结构选择纯高频单消费者场景优先选用 List 队列保证信号有序不丢失多策略、多消费者场景选用 Pub/Sub 发布订阅模式。持久化机制启用 Redis 的 RDB/AOF 持久化配置防止程序宕机、服务器重启导致交易信号丢失。防重设计为每个交易信号添加唯一 ID大 QMT 消费时做去重校验避免重复下单。2.3 实现步骤以 Pub/Sub 模式为例本地部署并启动 Redis 服务端Windows 环境可参考对应系统安装指南。在大 QMT 中编写 Redis 订阅端代码监听指定消息频道如my-channel启动策略保持常驻监听状态。编写外部策略的发布端代码将交易信号推送到对应频道。验证消息实时收发能力补充信号解析与交易执行逻辑完成全链路联调。2.4 适用场景适用于延迟要求低于 50ms 的高频交易场景支持多策略、多终端的信号分发与联动。方案三HTTP API 接口方案分布式跨平台架构HTTP API 方案通过在大 QMT 内搭建 Web 服务以 RESTful 接口的形式对外暴露交易、行情、账户能力支持跨设备、跨平台的分布式交易架构。3.1 核心流程服务端搭建在大 QMT 内置 Python 中基于 Tornado 框架构建 RESTful API 服务接收外部信号与交易指令。QMT 调用外部策略 / 客户端通过 requests 库发起 HTTP 请求下发交易指令或查询数据大 QMT 接收后执行对应操作。3.2 安全与性能优化认证机制接入 JWT Token 认证或 IP 白名单机制校验请求合法性防范非法调用。异步处理解耦信号接收与交易执行逻辑避免请求阻塞导致的接口超时。限流保护设置每分钟请求阈值避免高频请求触发券商风控规则。3.3 核心接口能力基于大 QMT 底层能力可封装的典型接口如下接口路径功能说明/api/holding持仓查询/api/money/total总资金查询/api/money/available可用资金查询/api/order/buy买入委托/api/order/sell卖出委托/api/market/full_tick实时行情查询/api/order/status委托状态查询/api/order/cancel_all全部撤单/api/order/cancel_order指定撤单3.4 实现步骤在大 QMT 策略环境中编写 Tornado 服务端代码封装 QMT 原生交易、行情函数为 API 接口启动服务并监听指定端口如 9000 端口。在外部 Python 环境或其他平台中通过 requests 库发起 HTTP 请求测试账户查询、下单、撤单等核心接口。验证下单全链路外部发送指令→大 QMT 接收指令→调用 passorder 下单→委托成交完成全流程闭环测试。3.5 适用场景适用于跨平台跟单如聚宽策略→QMT 执行、云服务器策略与本地 QMT 协同的分布式架构支持多终端、多语言的策略接入。方案对比与选型建议三种方案在延迟、复杂度、适用场景上各有侧重可根据自身交易需求与技术能力选型方案名称延迟水平实现复杂度架构特点推荐适用场景文件监控方案秒级极低单机轻量无额外依赖通达信预警联动、低频半自动交易、新手快速落地Redis 实时信号方案毫秒级50ms中等内存消息队列低延迟日内高频交易、多策略信号分发、低延迟套利HTTP API 接口方案百毫秒级较高分布式服务跨平台云端策略联动、多账户管理、跨平台跟单系统总结以上三种方案均基于大 QMT 原生 Python 环境实现无需依赖额外交易接口可完整替代 MiniQMT 的外部信号接入能力。追求快速落地、技术基础薄弱的交易者优先选择文件监控方案做日内高频、对延迟敏感的交易者推荐部署Redis 实时信号方案需要搭建分布式架构、跨平台联动的交易者可采用HTTP API 接口方案。风险提示量化交易存在市场风险本文仅为技术方案分享不构成任何投资建议。实盘交易请充分测试策略与接口稳定性严格遵守券商相关业务规则。