内容下发与回传流程

一次内容投放会跨越运营后台、媒体处理、任务中心、消息通道和终端设备。把它建模成状态明确的任务，比“保存后直接发一条 MQTT 消息”更容易追踪和恢复。

完整链路

sequenceDiagram
  participant O as 运营后台
  participant A as 业务 API
  participant S as 对象存储 / 转码
  participant M as 任务中心
  participant Q as MQTT
  participant D as 设备

  O->>A: 上传素材并创建播放计划
  A->>S: 保存文件并生成可播放版本
  S-->>A: 返回素材版本与地址
  A->>M: 为目标设备创建投放任务
  M->>Q: 发布任务摘要
  Q-->>D: 通知新任务
  D->>A: 拉取任务详情与签名地址
  D->>S: 下载并校验素材
  D->>A: 上报接收和下载结果
  D->>D: 按排期播放
  D->>A: 上报播放与异常记录
  A-->>O: 汇总状态和统计

为什么通知与详情分开

MQTT 消息适合传递“小而及时”的通知，不适合承载完整播放计划或长期有效的下载凭证。消息中只包含任务编号、版本和必要摘要，设备再通过鉴权 API 拉取详情，可以减少消息大小并集中处理权限与过期时间。

任务状态

建议将任务状态拆成以下阶段：

pending：任务已创建，等待发布；
published：通知已发送到消息系统；
received：设备确认收到任务；
downloaded：素材已下载并通过校验；
active：计划已在设备生效；
completed：播放周期结束；
failed：下载、校验或执行失败。

状态变更采用幂等上报。同一回执重复到达时只能更新时间和附加信息，不能重复累计播放次数。

离线与重试

设备离线时保留待下发任务，重连后主动同步当前版本；
下载失败使用退避重试，并保留上一份可用内容；
计划变更时递增版本，终端只接受更新版本；
播放记录可以本地暂存，恢复网络后按批次补传；
服务端根据设备和记录编号去重，避免补传造成重复统计。

排查顺序

出现“后台已发布但终端没变化”时，可以按任务链路依次检查：计划是否生效、媒体是否就绪、任务是否生成、MQTT 是否发布、设备是否收到、素材是否下载、终端是否切换版本。每一步都应有独立状态和时间戳。