更新时间:2026-09-16 GMT+08:00
分享

迁移业务

RocketMQ迁移是指将生产与消费消息的客户端切换为连接新RocketMQ实例,主要涉及到以下两类场景:

  • 业务上云且不希望业务有中断。

    在上云过程中,连续性要求高的业务,需要平滑迁移,不能有长时间的中断。

  • 在云上变更业务部署。

    单AZ部署的RocketMQ实例,不具备AZ之间的容灾能力。用户对可靠性要求提升后,需要迁移到多AZ部署的实例上。

迁移方案概述

表1 迁移方案概述

迁移方案

优点

缺点

先迁生产,再迁消费(不迁移数据)

  • 业界通用的迁移方案,操作步骤简单,无需安装其他组件。
  • 迁移过程由业务侧自主控制。
  • 可确保消息消费的顺序性。
  • 切换过程存在延时,消费端需要先消费完原RocketMQ消息,然后才能消费新RocketMQ消息。
  • 迁移完消费业务后,新RocketMQ可能存在消息积压。

同时消费,后迁生产(不迁移数据)

  • 操作步骤简单,无需安装其他组件。
  • 同时消费原RocketMQ和新RocketMQ消息,确保消息能及时消费,无消息积压。

在迁移生产的开始阶段,同时消费原RocketMQ与新RocketMQ,会导致部分消息之间的生产顺序无法保证,存在消息乱序的问题。

约束与限制

  • RocketMQ实例迁移过程中,需要确保源端和目标端的网络互通。
  • 迁移过程中,消费端需要支持消息幂等处理,避免重复消费导致业务异常。
  • 如果原RocketMQ实例开启了SSL,新实例也需要同步配置SSL,确保客户端连接正常。
  • 迁移过程中,需要确保消费组的消费进度正确同步,避免消息丢失或重复消费。

迁移准备

  1. 配置网络环境。
    RocketMQ实例分内网地址以及公网地址两种网络连接方式。如果使用公网地址,则消息生产与消费客户端需要有公网访问权限,并配置如下安全组。
    表2 安全组规则(RocketMQ实例4.8.0版本)

    方向

    协议

    端口

    源地址

    说明

    入方向

    TCP

    8200

    RocketMQ客户端所在的IP地址或地址段。

    使用TCP协议,通过公网访问元数据节点的端口。

    入方向

    TCP

    10101-10199

    使用TCP协议,通过公网访问业务节点的端口。

    表3 安全组规则(RocketMQ实例5.x版本)

    方向

    协议

    端口

    源地址

    说明

    入方向

    TCP

    8200

    RocketMQ客户端所在的IP地址或地址段。

    使用TCP协议,通过公网访问实例的端口。

    入方向

    TCP

    8081

    使用gRPC协议,通过公网访问实例的端口。

    入方向

    TCP

    10101

    使用TCP协议,通过公网访问业务节点的端口。

  2. 创建目标RocketMQ实例。

    目标RocketMQ的规格不能低于原业务使用的RocketMQ规格。具体请参考购买RocketMQ实例

  3. 在目标RocketMQ实例中创建Topic。

    在目标RocketMQ实例上创建与原RocketMQ实例相同配置的Topic,包括Topic名称、消息类型等,具体请参考创建RocketMQ Topic。您也可以通过导入导出元数据的方式批量迁移Topic信息,具体请参考迁移其他RocketMQ的元数据到RocketMQ实例

  4. 在目标RocketMQ实例中创建消费组。

    在目标RocketMQ实例上创建与原RocketMQ实例相同配置的消费组,包括消费组名称、是否允许以广播模式消费等,具体请参考创建RocketMQ消费组。您也可以通过导入导出元数据的方式批量迁移消费组信息,具体请参考迁移其他RocketMQ的元数据到RocketMQ实例

迁移方案一:先迁生产,再迁消费(不迁移数据)

先将生产消息的业务迁移到新RocketMQ,原RocketMQ不会有新消息生产。待原RocketMQ的消息全部消费完后,再将消费消息业务迁移到新RocketMQ,开始消费新RocketMQ的消息。

本方案为业界通用的迁移方案,操作步骤简单,迁移过程由业务侧自主控制,整个过程中消息不会存在乱序问题,适用于对消息顺序有要求的场景。但是该方案中需要等待消费业务执行完毕,存在一个时间差的问题,部分数据可能存在较大的端到端时延。

  1. 将生产客户端的RocketMQ连接地址修改为新RocketMQ实例的连接地址。
  2. 重启生产业务,使得生产者将新的消息发送到新RocketMQ实例中。
  3. 观察各消费组在原RocketMQ的消费进度,直到原RocketMQ中数据都已经被消费完毕。
  4. 将消费客户端的RocketMQ连接地址修改为新RocketMQ实例的连接地址。
  5. 重启消费业务,使得消费者从新RocketMQ实例中消费消息。
  6. 观察消费者是否能正常从新RocketMQ实例中获取数据。
  7. 迁移结束。

迁移方案二:同时消费,后迁生产(不迁移数据)

消费业务启用多个消费客户端,分别向原RocketMQ和新RocketMQ消费消息,然后将生产业务切到新RocketMQ实例,这样能确保所有消息都被及时消费。

本方案中消费业务会在一段时间内同时消费原RocketMQ和新RocketMQ消息。由于在迁移生产业务之前,已经有消费业务运行在新RocketMQ实例上,因此不会存在端到端时延的问题。但在迁移生产的开始阶段,同时消费原RocketMQ与新RocketMQ,会导致部分消息之间的生产顺序无法保证,存在消息乱序的问题。此场景适用于对端到端时延有要求,却对消息顺序不敏感的业务

  1. 启动新的消费客户端,配置RocketMQ连接地址为新RocketMQ实例的连接地址,消费新RocketMQ实例中的数据。

    原有消费客户端需继续运行,消费业务同时消费原RocketMQ与新RocketMQ实例的消息。

  2. 修改生产客户端,RocketMQ连接地址改为新RocketMQ实例的连接地址。
  3. 重启生产客户端,将生产业务迁移到新RocketMQ实例中。
  4. 生产业务迁移后,观察连接新RocketMQ实例的消费业务是否正常。
  5. 等待原RocketMQ中数据消费完毕,关闭原有消费业务客户端。
  6. 迁移结束。

相关文档