MQ消息中间件在线迁移方案

MQ消息中间件在线迁移方案

MQ消息中间件在线迁移方案

• • 一. 迁移的问题点分析
  • 二. 迁移方案分析
  • • 方案1: 同时切换
    • 方案2: 生产者双写
    • 方案3: 消费者双读
    • 方案4: 盲转发消费

说明: 这里以rabbitMq迁移到rocketMq为示例.

一. 迁移的问题点分析

• 1.生产者和消费者无法保证同时切换

场景一: 如果生产者先切换, 消费者可能会漏消费rocketMq的消息

场景二: 如果消费者先切换, 消费者可能会漏消费rabbitMq的消息

• 2.多生产者/多消费者切换排期跨度较大

场景一: 多个生产者/一个消费者, 如何保证多个生产者不同排期切换平滑稳定过渡, 不漏消费/不重复消费

场景二: 一个生产者/多个消费者, 如何保证多个消费者不同排期切换平滑稳定过渡, 不漏消费/不重复消费

• 3.消费端消费不幂等, 不能接受重复发送/消费

场景一: 如果一个生产者/多个消费者这种场景, 消费者切换排期不一致. 选择的是生产者双写方案, 就要考虑这个问题

• 4.广播模式的消费如何保证漏消费/重复消费

• 5.在线迁移(服务不下线), 同一个消费者集群节点之间可能会有重复消费

二. 迁移方案分析
方案1: 同时切换

• 步骤

1. 生产者先切换: 直接从rabbitMq切换到rocketMq
2. 生产者验证完成后消费者再切换, 但是消费起点必须指定为FROM_MIN_OFFSET

• 适用场景

1. 消费者或生产者规模较小, 可以快速切换

2. 消费者或生产者可以保证同时切换

• 注意点

1. 这里说的同时切换, 指的是切换间隔时间比较短, 消费延迟可以接受
2. 消费者的consumerGroup必须是第一次消费这个topic, 否则无法保证FROM_MIN_OFFSET生效

方案2: 生产者双写

• 步骤

1. 生产者上线, 两边都发送
2. 所有消费者开始按各自排期迁移到rocketMq
3. 生产者切换为单写(切换开关&去除rabbitMq代码)

• 适用场景

1. 单一生产者/多个消费者
2. 消费者无法统一排期
3. 消费者必须保证幂等

• 注意点

1. 消费者必须保证幂等: 消费者切换时会有重复消费(集群多节点无法保证同时上/下线)
2. 消息量不是很多, 消费资源(消息存储)和网络带宽
3. 迁移过的业务消费者, 需要及时删除rabbit队列, 否则会堆积影响这个rabbit

方案3: 消费者双读

• 步骤

1. 消费者全部先上线, 两边都消费
2. 生产者直接切换
3. 消费者切换到仅rocketMq消费(切换开关&去除rabbitMq代码)

• 适用场景

1. 适用各种场景: 单一生产者/多个消费者或者多个生产者/单一消费者
2. 消费端不用保证幂等, 因为同一条消息生产者只会发送一次, 且都会被消费

• 注意点

稳定, 但时间跨度可能较长, 适用于排期较松

方案4: 盲转发消费

和同时切换方案类似, 区别是新增一个消费者用来转发

• 步骤

1. 生产者先切换: 直接从rabbitMq切换到rocketMq
2. 生产者验证完成后消费者再切换, 消费起点必须指定为FROM_MIN_OFFSET
3. 中转消费者接到rocketMq消息后, 再转发到原来的rabbitMq的exchage中
4. 所有业务消费者迁移完成后, 去除中转消费者

• 适用场景

1. 适用各种场景: 单一生产者/多个消费者或者多个生产者/单一消费者
2. 消费方需要保证幂等, 保证重复消费没有问题
3. 各接入方不用统一排期

• 注意点

1. 这种方案可能会重复发送: (业务消费者切换期间, 会同时接收生产者和转发的同一条消息)
2. 迁移过的业务消费者, 需要及时删除rabbit队列, 否则会堆积影响这个rabbit