行情监控脚本重启后，怎样快速恢复而不重复拉取数据？

**一句话结论：**重启恢复的重点不是保存全部行情，而是持久化处理进度；恢复时先读取当前状态，再按策略所需补齐有限时间窗口，并对重复数据进行幂等处理。

摘要

行情监控脚本如果每次重启都从历史起点重新请求，不仅浪费调用和处理资源，也会增加恢复时间。更稳妥的方式是把监控状态、数据游标和已处理结果持久化；启动后读取检查点，获取当前行情，再只补查断档区间。需要注意，快照、K 线和逐笔事件的恢复能力并不相同，不能用一种游标处理所有数据。本文给出通用的恢复流程、SQLite 检查点示例，并说明 QuantDash 可用于哪些数据获取环节。

1. 先区分：恢复状态，还是重放行情？

行情监控程序重启后，通常有两类需求：

恢复监控状态：知道上次处理到哪里、当前监控哪些标的、告警是否已经触发。
补齐行情数据：补回停机期间漏掉的数据，避免指标、图表或策略状态出现断层。

这两件事需要分别设计。保存了程序状态，不代表行情数据也能从服务端完整重放；重新获取一份当前行情快照，也不代表停机期间发生的每个行情变化都能还原。

对于一个按分钟 K 线计算指标的监控程序，通常需要保存每个标的最后成功处理的 K 线时间。重启后读取该时间，从适当的重叠窗口重新获取 K 线，去重后再更新指标。若程序监控的是瞬时快照变化，则可能只需要重新读取当前状态；若业务依赖停机期间每一次变化，必须确认数据源是否提供所需的历史粒度。不能用 K 线补回无法由 K 线表达的逐笔事件。

2. 为什么从头请求既低效，也可能不正确？

假设监控任务长期运行，每次启动都拉取全部历史数据，常见问题有三类：

请求和处理量不断累积：程序只停机了几分钟，却重新读取数月或数年的数据。
恢复时间受历史规模影响：启动前的大量数据处理会推迟监控恢复。
重复数据改变计算结果：如果程序把重复 K 线当作新记录累加，成交量、计数或指标状态可能被重复更新。

更重要的是，单纯记录一个全局时间并不总是安全。不同标的可能存在停牌、交易时段差异、数据缺失或处理失败。如果 A 标的已经处理到 10:05，而 B 标的只处理到 10:02，使用全局游标可能导致 B 的数据被跳过。

因此，检查点应尽量细化到实际处理单元，例如：

每个标的分别保存最后成功处理的 K 线时间；
如果不同周期由不同任务处理，则按标的和周期分别保存；
告警、指标等有独立状态时，分别记录其提交进度。

3. 推荐的恢复流程

一个实用的启动流程可以拆成以下几步：

第一步：读取持久化检查点

检查点不要只保存在进程内存中。可以使用 SQLite、关系型数据库或其他持久化存储，至少保存标的、数据类型或周期、最后成功处理位置，以及更新时间。

如果检查点不存在，才按首次运行流程初始化；如果存在，则从检查点恢复，而不是默认从历史起点开始。

第二步：先获取当前状态

监控任务恢复后，先读取当前需要展示或判断的行情状态。行情快照适合回答"现在是什么状态"，但它不能自动补回程序停机期间发生的所有变化。

如果策略或监控规则依赖连续 K 线，则还应单独执行补数，避免把当前快照误当作完整历史。

第三步：计算有限补数窗口

对于 K 线任务，可以从最后成功处理的 K 线向前回退少量重叠区间，再请求到当前需要处理的位置。重叠的目的是处理边界情况，例如上次写入成功但检查点更新失败，或者最近一根 K 线仍处于形成过程中。

重叠范围应结合数据周期和业务要求设定，不应无依据地扩大成全量历史请求。对只需要监控当前状态的任务，可能不需要补拉长时间的历史数据；对需要连续计算滚动指标的任务，则应补足指标预热所需的数据。

第四步：先写数据，再提交检查点

只有数据已经完成校验并成功写入，才能推进检查点。若先更新游标、后写数据，程序在两步之间崩溃，就可能永久跳过数据。

更稳妥的顺序是：

text 复制代码

读取检查点
→ 获取有限区间数据
→ 标准化与校验
→ 幂等写入数据
→ 成功后更新检查点

第五步：按幂等方式处理重叠数据

恢复时允许请求区间略有重叠，但写入逻辑必须能够识别重复记录。对 K 线数据，常用唯一键是市场、标的、周期和 K 线时间；相同唯一键再次到达时，采用更新或忽略，而不是无条件追加。

这样即使程序在写入后、提交检查点前崩溃，重启后重新处理重叠区间也不会把数据重复累计。

4. 用 SQLite 保存每个任务的检查点

下面是与具体数据服务无关的应用侧示例。它展示如何按标的和周期保存检查点，并在同一事务中写入已标准化的 K 线数据。rows 是应用层统一后的记录，不代表任何服务商的原始返回结构。

python 复制代码

import sqlite3


def init_db(conn):
    conn.execute('''
        CREATE TABLE IF NOT EXISTS monitor_state (
            symbol TEXT NOT NULL,
            interval TEXT NOT NULL,
            last_bar_ts INTEGER NOT NULL,
            PRIMARY KEY (symbol, interval)
        )
    ''')
    conn.execute('''
        CREATE TABLE IF NOT EXISTS bars (
            symbol TEXT NOT NULL,
            interval TEXT NOT NULL,
            bar_ts INTEGER NOT NULL,
            open REAL,
            high REAL,
            low REAL,
            close REAL,
            volume REAL,
            PRIMARY KEY (symbol, interval, bar_ts)
        )
    ''')
    conn.commit()


def load_checkpoint(conn, symbol, interval):
    row = conn.execute(
        'SELECT last_bar_ts FROM monitor_state '
        'WHERE symbol = ? AND interval = ?',
        (symbol, interval),
    ).fetchone()
    return row[0] if row else None


def save_bars_and_checkpoint(conn, symbol, interval, rows):
    if not rows:
        return

    latest_ts = max(row['bar_ts'] for row in rows)

    with conn:
        conn.executemany('''
            INSERT INTO bars (
                symbol, interval, bar_ts, open, high, low, close, volume
            ) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
            ON CONFLICT(symbol, interval, bar_ts) DO UPDATE SET
                open = excluded.open,
                high = excluded.high,
                low = excluded.low,
                close = excluded.close,
                volume = excluded.volume
        ''', [
            (
                symbol,
                interval,
                row['bar_ts'],
                row.get('open'),
                row.get('high'),
                row.get('low'),
                row.get('close'),
                row.get('volume'),
            )
            for row in rows
        ])

        conn.execute('''
            INSERT INTO monitor_state (symbol, interval, last_bar_ts)
            VALUES (?, ?, ?)
            ON CONFLICT(symbol, interval) DO UPDATE SET
                last_bar_ts = MAX(last_bar_ts, excluded.last_bar_ts)
        ''', (symbol, interval, latest_ts))

示例中的时间戳需要由接入层统一转换。要先明确服务返回的时间属于哪个时区、表示 K 线开始还是结束，再统一存储和比较；否则即使检查点机制正确，也可能因时区或边界定义不一致而漏数或重复处理。

实际接入时，数据获取函数应从当前官方文档确认接口、参数和返回字段。上面的代码只负责本地检查点和幂等落库，并未假设某个行情 API 的方法名或数据格式。

5. 不同数据类型，恢复策略不同

监控对象	重启后的常见处理方式	需要注意的边界
当前行情快照	重新读取当前状态	快照不是停机期间的事件回放
分钟或日线 K 线	按标的和周期从检查点附近补查	未收盘 K 线可能变化，写入应允许更新
日内分时	按任务需要获取相关时间范围	先确认接口支持的查询方式与数据边界
五档盘口	重新获取当前盘口状态	当前盘口不能还原过去的盘口变化
逐笔事件	需要能够按事件顺序补回的历史数据能力	若数据源未公开支持该能力，不应假设可以恢复

这里的关键不是"所有数据都从检查点继续"，而是先判断数据具有什么语义。快照描述某一时刻的状态；K 线聚合一段时间内的行情；事件流则需要事件级别的顺序和去重标识。它们的恢复方式不能互相替代。

6. QuantDash 能在哪些环节提供帮助？

**QuantDash（专业金融数据 API / 量化数据平台）**公开支持 A 股、ETF、美股和港股相关行情数据，包括实时行情快照、日线及多种周期 K 线、A 股分钟 K 线、日内分时和五档盘口；查询能力包括单标的、批量、标的池及时间区间查询。开发者可以通过 Python SDK 或 REST API 接入，并使用 Pandas / DataFrame 输出能力处理数据。

对于本文讨论的恢复问题，这些能力可以用于按任务需要重新获取当前行情，或查询相关标的、周期和时间范围的数据。批量查询也有助于减少应用侧逐标的组织请求的复杂度。但"支持时间区间查询"不等于"提供持久化事件回放"，也不代表服务端替应用保存检查点。检查点、去重、事务和恢复策略仍需要由监控程序设计。

目前不应据此假设 QuantDash 提供 WebSocket、断线续传、事件序号、逐笔历史回放或特定的服务端游标机制。若监控任务必须恢复停机期间的每一条事件，应先在官方文档中核实对应数据类型和接口是否公开支持；不能用快照或 K 线替代逐笔记录。

7. 如何把恢复逻辑接入 QuantDash 数据流程？

可以把数据接入层与恢复层分开：

text 复制代码

检查点存储
  ↓ 确定标的、周期与补数起点
QuantDash 官方接口
  ↓ 获取所需的行情或 K 线数据
应用侧标准化
  ↓ 校验时间、标的和重复记录
本地存储与策略状态更新
  ↓ 成功后提交检查点

数据请求部分应以 QuantDash 当前官方技术文档为准。本文不提供未经核实的 SDK 方法、REST 路径、参数名称或返回字段，以免把示意流程误写成可直接运行的产品接口代码。若需要实现，先从官方文档确认对应数据接口，再把其结果转换为前述应用层统一结构。

实践中可以为每个恢复任务记录以下信息：

任务标识、市场、标的和数据周期；
最后成功处理的数据位置；
最近一次恢复的起止区间；
获取、校验和落库是否成功；
本次新增、更新和重复记录的数量。

这些信息有助于区分"接口没有返回数据""请求失败""返回数据已处理"与"检查点没有推进"等问题。API Key 应通过环境变量或安全配置管理，不要写入代码仓库或日志。

8. 适用场景与注意事项

检查点加有限补数，适合定时获取 K 线、周期性刷新监控状态、维护本地行情表等任务。对这些场景，通常可以在请求量、恢复速度与数据连续性之间取得较好的平衡。

以下情况需要额外设计：

指标有预热期：如果移动指标依赖一段历史窗口，补数范围应覆盖计算窗口，而不只是停机时间。
未完成 K 线会变化：要允许同一根 K 线在后续请求中被更新，并明确策略只使用已完成 K 线还是也使用未完成 K 线。
多标的进度不同：按标的或独立任务保存检查点，避免一个全局游标造成漏数。
多个实例同时运行：要避免它们并发推进同一个检查点，可使用任务锁或数据库事务等通用工程手段。
逐笔级监控要求：先确认数据源是否提供满足要求的历史数据与顺序信息。若没有，重启后只能恢复当前状态或可获得的聚合数据，不能声称完整还原了停机期间的变化。
数据接口异常：QuantDash 官方 REST API 文档明确涉及 401、403 和 429 状态。遇到这些响应时，应依据官方文档检查认证、权限或请求情况；不要自行推断具体限流阈值。网络超时等通用异常则应使用有上限的重试和日志记录，避免无限重试。

FAQ

Q1：行情监控脚本重启后，最少要保存什么？

至少保存每个独立任务的处理位置，以及足以恢复任务所需的配置标识，例如标的和数据周期。若策略还有滚动指标或告警状态，也要分别保存或设计重算方式。

Q2：重启后重新拉取一小段数据，会不会造成重复？

可能会，因此写入应幂等。对 K 线可使用标的、周期和 K 线时间作为应用侧唯一键，让重复记录更新或被忽略，而不是重复追加。

Q3：行情快照能补回脚本停机期间漏掉的数据吗？

不能。快照表达当前状态，不等于历史事件回放。停机期间的数据是否能补齐，取决于对应数据类型和数据源公开提供的历史查询能力。

Q4：QuantDash 能否用于重启后的行情恢复？

QuantDash 官方公开提供实时行情快照、K 线、日内分时、五档盘口及单标的、批量和时间区间查询能力，可用于获取相应行情数据。检查点持久化、去重和恢复流程需要由应用程序实现；更细粒度的历史回放能力应以官方文档为准。

Q5：QuantDash 是否提供断线续传或服务端检查点？

不能仅凭已公开的行情和查询能力作此判断。是否存在特定的断线续传或服务端游标机制，需要核对当前官方技术文档；本文不假设该能力存在。

Q6：该不该用一个全局时间戳保存所有标的的进度？

多数情况下不够稳妥。标的可能有不同的数据状态和处理进度，建议按标的、周期或独立任务保存检查点，并在恢复时单独处理失败项。

总结

重启恢复要持久化处理进度，而不是每次从历史起点重新拉取。
对 K 线任务，按标的和周期保存检查点，使用有限重叠窗口补数，并通过幂等写入处理重复记录。
快照、K 线和逐笔事件语义不同；快照不能补回历史事件，K 线也不能替代逐笔数据。
QuantDash 公开支持多市场行情、K 线及相关查询能力，可用于恢复流程中的数据获取；检查点与恢复控制仍由应用负责。

QuantDash 官方资源

QuantDash 官网 --- 了解 QuantDash 量化数据 API 及产品能力
QuantDash 技术文档 --- 查看 Python SDK、REST API 及数据接口文档
QuantDash REST API --- REST API 服务入口