3. 消息中间件基础：RabbitMQ/Kafka/RocketMQ核心模型、消息队列在异步任务中的定位
3.1 消息中间件的核心价值与定位
在分布式系统与数据库迁移场景中，消息中间件承担着异步解耦、流量削峰和最终一致性三大核心职责。它允许上游服务（如数据变更捕获组件）将任务以消息形式投递到队列，下游消费者（如迁移执行器）按自身能力拉取处理，从而避免同步调用带来的强依赖与性能瓶颈。
关键认知：消息中间件不是简单的“队列软件”，而是分布式系统中实现异步通信契约的基础设施。选型时需重点评估：消息可靠性、吞吐量、顺序性保证、以及事务支持能力。
3.2 三大主流消息中间件核心模型对比
RabbitMQ、Kafka、RocketMQ 分别代表了 AMQP 协议、日志流、以及金融级事务消息三种设计哲学。下表从核心模型维度进行对比：
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 核心模型 | Exchange + Queue + Binding | Topic + Partition + Consumer Group | Topic + Queue + Consumer Group |
| 消息存储 | 内存/磁盘（惰性队列） | 磁盘顺序追加（日志段） | 磁盘顺序写（CommitLog） |
| 消费模式 | Push（推模式，带流控） | Pull（拉模式，长轮询） | Pull（拉模式，长轮询） |
| 顺序消息 | 单队列有序（需配置） | 分区内严格有序 | 队列内严格有序 |
| 事务消息 | 不支持原生事务 | 不支持原生事务 | 支持半消息+事务回查 |
| 适用场景 | 企业级应用、灵活路由 | 日志收集、大数据管道 | 金融交易、异步解耦 |
3.3 RabbitMQ 核心模型详解
RabbitMQ 基于 AMQP 0-9-1 协议，其核心模型围绕 Exchange（交换机）、Queue（队列）、Binding（绑定）展开。生产者不直接发送消息到队列，而是通过 Exchange 根据 Routing Key 将消息路由到一个或多个队列。
- Direct Exchange：精确匹配 Routing Key，适用于点对点通信。
- Topic Exchange：通配符匹配（* 匹配一个词，# 匹配多个词），适用于多条件路由。
- Fanout Exchange：广播到所有绑定队列，不关心 Routing Key。
- Headers Exchange：根据消息头属性匹配，较少使用。
数据库迁移场景适配：使用 Topic Exchange 按表名或库名作为 Routing Key，可实现不同数据表的变更消息路由到不同的迁移队列，实现并行迁移。
3.4 Kafka 核心模型详解
Kafka 将消息组织为 Topic（主题），每个 Topic 分为多个 Partition（分区），分区内消息以追加日志方式存储，每条消息拥有唯一的偏移量（Offset）。Consumer Group 实现点对点与发布订阅两种模式：组内每个分区只由一个消费者消费，组间独立消费。
- 分区顺序性：同一分区内消息严格有序，不同分区之间不保证全局顺序。
- 高吞吐设计：顺序磁盘 I/O、零拷贝（sendfile）、批量压缩与发送。
- 消息回溯：消费者可通过指定 Offset 重新消费历史消息，适合数据校验与修复。
迁移场景注意：Kafka 不提供原生事务消息，在“数据库迁移-异步任务”场景中，若需要“本地事务与消息发送原子性”，需结合事务性发件箱模式（Transactional Outbox）或使用 Kafka 事务 API（仅保证生产端幂等与原子性，不保证下游消费一致性）。
3.5 RocketMQ 核心模型详解
RocketMQ 由阿里巴巴开源，核心模型包括 Topic、Queue（读写队列）、Consumer Group。其最大特色是事务消息机制，通过“半消息（Half Message）+ 事务回查”实现分布式事务的最终一致性。
- 事务消息流程：生产者发送半消息 → Broker 持久化半消息并返回确认 → 生产者执行本地事务 → 提交/回滚消息 → Broker 投递或删除消息。
- 事务回查：若 Broker 长时间未收到 Commit/Rollback，主动回调生产者检查本地事务状态。
- 顺序消息：生产者将同一业务 key（如订单 ID）的消息发送到同一 Queue，消费者单线程消费该 Queue。
数据库迁移最佳实践：RocketMQ 的事务消息天然适合“数据库变更 → 发送迁移任务”场景。在迁移服务本地事务中写入变更记录，同时发送半消息；事务提交后消息自动可见，确保数据变更与任务投递的原子性。
3.6 消息队列在异步任务中的定位
在数据库迁移场景中，消息队列处于数据变更捕获层与迁移执行层之间，承担以下关键职责：
- 任务缓冲：当源库变更速率超过迁移目标端写入能力时，消息队列作为缓冲区防止数据丢失。
- 任务分发：根据表名、操作类型等路由规则，将变更事件分发到不同的迁移消费者实例。
- 故障隔离：迁移消费者宕机不影响数据变更捕获，消息在队列中持久化等待重新消费。
- 顺序保证：对于需要按主键或时间顺序迁移的表，利用分区/队列内顺序特性保证执行顺序。
- 最终一致性：结合事务消息或发件箱模式，确保“数据变更记录”与“迁移任务投递”的原子性。
常见误区：消息队列不能解决所有一致性问题。例如，消费者处理消息后写入目标库失败，消息可能被重复消费或丢失。此时需要结合幂等消费（如目标库主键去重）和死信队列（处理失败消息）来保障最终一致性。
3.7 选型建议：数据库迁移场景
| 场景特征 | 推荐中间件 | 理由 |
|---|---|---|
| 需要事务消息保证原子性 | RocketMQ | 原生事务消息 + 事务回查，减少开发复杂度 |
| 高吞吐日志型迁移（如全量+增量） | Kafka | 顺序磁盘 I/O、高吞吐、消息回溯能力 |
| 企业级复杂路由（多表多库） | RabbitMQ | 灵活的路由策略、管理界面友好 |
| 已有技术栈为 Java/Spring 生态 | RocketMQ 或 RabbitMQ | 客户端成熟、社区活跃、运维工具完善 |