3. 量子任务的生命周期管理

在量子云平台上，一个量子任务并不是“点一下运行”就结束的瞬时动作。它从用户提交电路与参数开始，经过排队、资源调度、真机或模拟器执行、状态监控、结果回收，最终被归档或清理，整个过程构成一条有明确状态边界的生命周期。理解这条生命周期，是排查“任务为什么一直排队”“结果为什么拿不到”“配额为什么被占用”等问题的前提。

本节以一台超导量子计算机的典型云平台为例，说明各阶段的状态转换与持久化机制。示例中的任务号、时间、队列深度均为教学假设值，用于说明机制，不代表真实平台实测数据。

一、生命周期状态模型

平台通常为任务定义一组互斥状态，常见包括：CREATED（已创建，尚未提交）、QUEUED（已入队等待）、RUNNING（正在执行）、COMPLETED（执行成功）、FAILED（执行失败）、CANCELLED（用户取消）、EXPIRED（结果过期被清理）。状态之间不是任意跳转，而是受事件驱动：提交事件使 CREATED→QUEUED，调度器分配资源后 QUEUED→RUNNING，执行结束根据返回码进入 COMPLETED 或 FAILED，用户主动撤销进入 CANCELLED，结果保留期到期后进入 EXPIRED。

关键约束是：COMPLETED、FAILED、CANCELLED、EXPIRED 属于终态，终态任务不再被调度器选中；但终态不等于数据立即消失，结果与元数据会按保留策略继续存在一段时间。

二、提交阶段：参数校验与幂等入队

提交阶段的核心不是“把电路发出去”，而是完成参数校验、配额检查和幂等入队。用户通过 SDK 或 REST API 提交时，平台会校验电路深度、量子比特数、测量次数（shots）、目标后端是否可用等。若校验失败，任务不会进入 QUEUED，而是直接返回错误码，避免无效任务占用队列。

幂等性通过 client_request_id 实现：同一用户用相同请求 ID 重复提交，平台只创建一条任务记录，返回同一个 task_id。这在网络重试场景中非常关键，否则一次超时重试可能产生两个真机任务，浪费配额。

POST /api/v1/tasks
{
  "backend": "scq-sim-01",
  "circuit_qasm": "OPENQASM 2.0; ...",
  "shots": 4096,
  "priority": "normal",
  "client_request_id": "req-20240612-7f3a"
}

响应示例：
{
  "task_id": "task-9c2e41",
  "status": "QUEUED",
  "queue_position": 12,
  "estimated_wait_s": 180
}

提交成功后，任务元数据写入任务元数据库，状态置为 QUEUED，同时写入一条事件日志。此时结果存储中还没有数据，只有元数据记录。

三、排队与调度：优先级、配额与资源匹配

排队阶段的任务处于 QUEUED，调度器按策略选择下一个执行对象。常见策略包括：先入先出（FIFO）、优先级队列、公平份额（fair share）和预留时段。优先级通常由用户等级、任务类型（校准任务高于普通实验）和提交时间共同决定。

调度器需要做资源匹配：目标后端是否有空闲量子比特、是否需要校准、当前是否处于维护窗口。若后端不可用，任务可能被重新排队而不是直接失败。调度成功后，任务状态从 QUEUED 变为 RUNNING，并记录 started_at 时间戳。

持久化方面，队列本身可以是内存中的优先队列，但队列位置和调度决策必须落库，否则平台重启后无法恢复。通常做法是：任务元数据持久化，队列状态通过元数据中的 status 和 priority 重建。

四、执行与监控：心跳、超时与状态回写

执行阶段由后端控制器负责。控制器将任务下发到量子控制硬件，采集测量结果，并在执行过程中定期回写心跳。监控系统关注三类信号：任务是否仍在运行、是否超时、是否产生错误码。

若执行时间超过预设阈值（例如 300 秒），平台可将任务标记为 FAILED，错误码为 TIMEOUT。若硬件返回校准漂移或读取错误，则记录具体错误码，便于后续排障。执行成功后，结果写入结果存储，任务状态变为 COMPLETED，并记录 finished_at。

五、结果回收与清理：TTL、配额释放与归档

结果回收阶段，用户通过 task_id 查询结果。平台从结果存储读取测量计数、概率分布和原始比特串，返回给用户。此时任务已处于终态，但结果不会永久保留。平台通常设置 TTL（例如 30 天），到期后结果被删除或归档，任务状态变为 EXPIRED。

清理阶段还需要释放配额。若配额按“运行中任务数”计算，任务进入终态时就应释放；若按“结果存储量”计算，则清理结果时才释放。两种口径必须在平台文档中明确，否则用户会困惑“任务已经完成，为什么配额还没回来”。

六、实践中的状态一致性

生命周期管理最容易出问题的地方是状态不一致：元数据库显示 RUNNING，但控制器已经结束；或者结果已写入，但状态还没更新。解决思路是让状态变更走同一条事件通道，并保证“先写结果、再改状态”或“先改状态、再写结果”的顺序在平台内统一。若采用最终一致性，则需要监控对账任务，定期扫描长时间处于 RUNNING 的任务并修正。

对使用者而言，最实用的做法是：提交后保存 task_id，轮询或订阅状态变更，拿到终态后再取结果；不要假设提交成功就等于执行成功，也不要在结果过期后才去下载。理解这条生命周期，就能在量子云平台上更稳定地编排和执行任务。