📚 课程目录第3章异步任务模型

3、异步任务模型：消息队列、事件驱动架构、任务编排模式概述

在数据库迁移场景中，同步调用无法容忍长时间阻塞、网络抖动或目标库写入延迟。异步任务模型通过解耦任务发起与执行，将迁移操作拆分为可独立重试、可追踪、可编排的消息或事件单元，从根本上保障数据最终一致性。本章聚焦三种核心异步模型：消息队列、事件驱动架构与任务编排模式，分析其原理、适用场景及在迁移一致性中的角色。

3.1 消息队列模型

消息队列（Message Queue, MQ）是异步任务最基础的实现方式。迁移任务作为消息体发送到队列，由消费者按序或按策略拉取执行。MQ 天然提供削峰填谷、发送确认、消费确认与重试机制，是构建可靠异步管道的第一选择。

特性	说明	迁移一致性价值
消息持久化	消息写入磁盘后才返回确认	防止宕机丢消息，保证迁移指令不丢失
消费确认（ACK）	消费者处理完成后显式确认	避免处理中途失败导致消息丢失
重试队列 / 死信队列	失败消息自动重试或转入死信	隔离永久失败消息，不阻塞正常迁移
顺序消息	部分 MQ 支持分区内严格顺序	保证同一分片的数据变更按序执行

实践建议： 在迁移管道中，将每个分片或表的增量变更封装为独立消息，使用分区键（如表名+主键范围）保证顺序，同时设置合理的重试次数（通常 3~5 次）与指数退避间隔，避免无效重试耗尽资源。

3.2 事件驱动架构

事件驱动架构（Event-Driven Architecture, EDA）将迁移状态变更视为事件，由事件总线（Event Bus）或事件流平台（如 Kafka）分发。与 MQ 的“点对点”模式不同，EDA 强调生产者只发布事件，不关心谁消费；消费者订阅感兴趣的事件类型，实现更松散的耦合与更灵活的回放能力。

  核心区别： MQ 侧重任务分发与可靠投递；EDA 侧重状态变更通知与事件溯源。在迁移一致性中，EDA 常用于记录迁移进度快照、触发补偿动作、驱动编排流程。

事件驱动架构在迁移中的典型应用：

迁移进度事件： 每个分片完成全量迁移后发布 SliceMigrated 事件，触发增量同步启动。
校验结果事件： 数据校验通过后发布 ValidationPassed 事件，驱动流量切换决策。
异常事件： 检测到数据不一致时发布 ConsistencyBreach 事件，触发回滚或修复流程。

3.3 任务编排模式

单一异步任务无法满足复杂迁移流程（如全量→增量→校验→切换→回滚）。任务编排模式通过定义 DAG（有向无环图）或状态机，将多个异步任务组合为可观测、可重试、可补偿的工作流。编排引擎负责调度任务执行顺序、传递上下文、处理分支与异常。

3.3.1 常见编排模式对比

模式	描述	迁移场景示例	一致性保障
链式编排	任务按固定顺序串联，前序成功才执行后续	全量迁移 → 增量同步 → 数据校验	严格顺序执行，失败即终止
扇出编排	一个父任务并行触发多个子任务，全部完成才继续	同时迁移多个分片，等待所有分片就绪	等待所有分支成功，避免部分完成
补偿编排	任务失败时执行逆向补偿操作（Saga 模式）	增量同步失败 → 回滚已迁移数据	通过补偿保证最终一致性
状态机编排	任务状态在有限状态间流转，事件驱动状态变更	迁移任务状态：待执行 → 执行中 → 校验中 → 已完成 / 失败	状态持久化，支持断点续传

常见陷阱： 编排层与任务执行层职责混淆。编排引擎只负责调度与状态管理，不应直接执行数据读写；任务执行由独立的工作节点（Worker）完成。否则编排引擎会成为性能瓶颈与单点故障。

3.3.2 状态机编排示例

以下是一个数据库迁移分片的状态机定义，使用 JSON 描述状态与转移条件：

{
  "states": ["PENDING", "FULL_MIGRATING", "FULL_DONE", "INCR_SYNCING", "VALIDATING", "COMPLETED", "FAILED", "ROLLING_BACK"],
  "transitions": [
    { "from": "PENDING",          "event": "startFull",     "to": "FULL_MIGRATING" },
    { "from": "FULL_MIGRATING",  "event": "fullSuccess",   "to": "FULL_DONE" },
    { "from": "FULL_MIGRATING",  "event": "fullFailed",    "to": "FAILED" },
    { "from": "FULL_DONE",       "event": "startIncr",     "to": "INCR_SYNCING" },
    { "from": "INCR_SYNCING",    "event": "incrCaughtUp",  "to": "VALIDATING" },
    { "from": "INCR_SYNCING",    "event": "incrFailed",    "to": "ROLLING_BACK" },
    { "from": "VALIDATING",      "event": "validationPass","to": "COMPLETED" },
    { "from": "VALIDATING",      "event": "validationFail","to": "ROLLING_BACK" },
    { "from": "ROLLING_BACK",    "event": "rollbackDone",  "to": "FAILED" }
  ]
}

3.4 三种模型的协同关系

在实际迁移系统中，三种模型并非互斥，而是分层协同：

消息队列 作为底层传输通道，保证任务可靠投递与顺序消费。
事件驱动 在 MQ 之上构建状态变更通知机制，解耦生产者与消费者。
任务编排 在最上层定义工作流逻辑，通过监听事件驱动状态转移，调度 MQ 中的具体任务。

  典型分层架构： 编排引擎（如 Temporal / Camunda）监听事件总线 → 事件触发状态转移 → 编排引擎向 MQ 发送具体任务指令 → Worker 消费 MQ 执行迁移操作 → 操作结果以事件形式回写总线 → 编排引擎更新状态。这一闭环保证了从指令到执行到反馈的端到端一致性。

3.5 模型选型建议

场景	推荐模型	理由
简单全量迁移，无复杂依赖	消息队列	轻量、可靠、运维成本低
增量变更捕获与多消费者订阅	事件驱动	解耦生产消费，支持事件回放
多阶段迁移，含校验、切换、回滚	任务编排 + 事件驱动	状态可观测，失败可补偿
大规模分片并行迁移	消息队列 + 扇出编排	并行度高，等待所有分片完成