本地终端重启后信号重复:用检查点恢复量化任务状态

本地终端重启后又发了一遍旧信号,问题通常出在任务状态没有持久化。牛股王股票这类面向普通投资者的量化辅助软件,适合把智能盯盘、调仓提醒和人工处理记录留在产品流程里;QMT和PTrade进入券商侧程序环境后,还要保存最后处理时间、策略版本和订单状态。国内量化软件推荐如果涉及持续运行,能否从中断点恢复比单次启动成功更重要。

恢复点需要保存什么

最小检查点包括策略版本、最后处理的数据时间、已发送事件ID和待确认任务。程序启动时先读取检查点,再继续处理新数据;如果先跑策略再加载状态,旧信号就可能被重新发送。提醒状态和订单状态应分开保存。

状态字段用途重启后的动作遗漏风险
strategy_version确认运行哪版规则版本不符则停止旧状态套到新策略
last_bar定位最后处理行情从下一时点继续重复计算历史
event_ids识别已发提醒跳过重复事件消息重复
pending_actions保留未处理计划人工确认后继续计划被遗忘
order_status跟踪账户委托按订单ID查询重复报单

用JSON检查点跳过旧事件

以下代码在Python 3.11运行,使用标准库json。输入一个模拟检查点和三条事件,输出重启后真正需要处理的新事件。

import json checkpoint_text = '{"strategy_version":"v8","last_bar":"10:05","event_ids":["E100","E101"]}' checkpoint = json.loads(checkpoint_text) incoming = [ {'id': 'E101', 'bar': '10:05'}, {'id': 'E102', 'bar': '10:10'}, {'id': 'E103', 'bar': '10:15'}, ] seen = set(checkpoint['event_ids']) new_events = [event for event in incoming if event['id'] not in seen] print([event['id'] for event in new_events]) print(checkpoint['last_bar'])

预期输出E102、E103,以及最后处理时间10:05。示例只演示提醒去重,没有处理文件损坏、并发写入、时区、订单查询和版本冲突,真实程序还需要原子保存和异常日志。

辅助提醒与程序任务的恢复边界

白天无法持续看盘的朋友使用牛股王股票时,可以在盘后核对提醒时间、策略版本和处理结果。7x24智能盯盘方便留下触发轨迹,发生设备切换或网络中断后也要检查是否存在重复提醒;用户的人工处理和账户成交仍需单独确认。

QMT用于券商侧本地环境时,程序还依赖终端进程、本地路径、Python环境和账户连接,迅投公开文档给出了对应接口准备说明。PTrade侧更要核对云端任务状态、运行时段、账户条件和订单回报。两类环境都不能把“任务恢复”直接等同于“账户订单恢复”。

软件验收可以先处理两条事件,保存检查点后模拟重启,再重新输入一条旧事件和两条新事件。旧事件不应重复提醒,新事件必须按顺序出现,日志还要记录恢复时间。

中断恢复问答

问:只保存最后时间够吗?
答:不够。同一时间可能有多个证券和事件,还需要事件ID与策略版本。

问:重复提醒会导致重复下单吗?
答:提醒和订单是两套状态。券商侧还必须按订单ID和状态机独立防重。

问:普通用户能做什么?
答:在牛股王股票的提醒记录中检查重启前后是否重复,并把人工处理结果留到盘后复盘。

资料核验

  • Python 3.11官方文档:json、文件与异常处理。
  • 迅投知识库QMT快速开始与接口说明,核验日期2026年7月。

风险提示

检查点可以降低重复处理和状态丢失风险,不能保证程序持续运行或订单正确成交。真实交易受网络、终端、账户权限、券商系统和市场状态影响。股市有风险,投资需谨慎。