4. 消息队列选型：RabbitMQ vs Kafka vs AWS SQS vs Redis Stream

在 Flyway 迁移脚本异步执行架构中，消息队列是连接迁移触发器与执行器、存储迁移命令与状态回传的核心中间件。选型错误会导致延迟升高、消息丢失或运维复杂度失控。以下从 Flyway 异步迁移的典型通信特征出发，对四种主流消息队列进行对比。

4.1 Flyway 异步迁移对消息队列的核心需求

• 至少一次投递：迁移命令不能丢失，允许重复但必须幂等。
• 低延迟（毫秒级）：开发环境快速反馈，CI/CD 流水线不阻塞。
• 消费确认与重试：迁移失败后能重新入队或进入死信队列。
• 顺序保证（可选）：同一数据库的迁移脚本必须按版本顺序执行。
• 运维轻量：团队能独立部署，不依赖外部云服务或复杂集群。

4.2 四种消息队列核心特性对比

4.3 适用场景分析

4.3.1 RabbitMQ — 团队自建、低延迟、灵活路由

• 推荐场景：中小团队自建消息中间件，迁移命令需要按数据库实例路由到不同队列。
• Flyway 适配：使用 Direct Exchange 将迁移命令投递到对应数据库队列，消费者 ACK 后执行迁移。
• 优势：延迟极低，死信队列原生支持，社区插件丰富。
• 劣势：吞吐量受限于单节点，海量迁移脚本堆积时性能下降。

4.3.2 Apache Kafka — 高吞吐、日志持久化、事件溯源

• 推荐场景：大规模多数据库集群（100+ 实例），需要迁移审计日志长期保留。
• Flyway 适配：每个数据库对应一个 Partition，利用 Offset 记录迁移进度，支持 Exactly-once 语义。
• 优势：吞吐量百万级，消息持久化不丢失，天然支持重放。
• 劣势：延迟较高，运维复杂，不适合快速反馈的开发环境。

4.3.3 AWS SQS — 零运维、弹性伸缩、FIFO 顺序

• 推荐场景：AWS 云原生环境，不想维护任何消息中间件。
• Flyway 适配：使用 FIFO 队列保证迁移顺序，Visibility Timeout 控制重试。
• 优势：完全托管，自动弹性，无需关心集群。
• 劣势：依赖 AWS 生态，延迟较高，FIFO 队列 TPS 限制 300/s。

4.3.4 Redis Stream — 极低延迟、轻量级、缓存与队列合一

• 推荐场景：团队已使用 Redis 做缓存，迁移规模不大（< 50 个数据库实例）。
• Flyway 适配：使用 XADD 发布迁移命令，XREADGROUP 消费，XPENDING 监控未确认消息。
• 优势：延迟 < 1ms，部署简单，内存操作快。
• 劣势：持久化弱于 Kafka，大消息堆积时内存压力大。

4.4 消息队列选型决策流程

以下 SVG 展示了从 Flyway 异步迁移需求出发的选型决策树，帮助团队快速锁定目标消息队列。

4.5 选型建议总结

4.6 消息队列与 Flyway 异步执行器的集成模式

以下 SVG 展示了消息队列在 Flyway 异步迁移架构中的位置与数据流，帮助理解选型对整体设计的影响。

4.7 选型检查清单

• 团队运维能力：是否有专人维护 Kafka 集群？如果没有，优先 RabbitMQ 或托管服务。
• 迁移规模：每日迁移命令量是否超过 10 万？超过则考虑 Kafka。
• 延迟要求：开发环境是否需要毫秒级反馈？需要则排除 Kafka 和 SQS。
• 顺序保证：同一数据库的迁移脚本是否必须严格按版本顺序执行？是则使用 FIFO 队列或单分区。
• 死信处理：是否需要原生死信队列？RabbitMQ 和 SQS 开箱即用。
• 云绑定：是否接受绑定特定云厂商？接受则 SQS 是最省心的选择。