消息队列在线迁移实战 | 最佳实践方案思路

目录

前言

理论基础

在系统维护期停业务迁移

双订阅方案

最优方案

常见问题

---

前言

消息队列（Message Queue，下文简称MQ）是分布式互联网架构中必不可少的核心组件，包括RocketMQ、Kafka、RabbitMQ等在业界广泛使用的产品，在消息分发、异步解耦、削峰填谷、广播通知等领域发挥着巨大的作用。

在MQ的使用过程中，在线对MQ组件进行迁移是一个非常普遍的需求，在如下的几个场景中，都会涉及到MQ的在线迁移：

（1）规格升级。比如将3 Broker的Kafka集群替换成6 Broker的Kafka集群。

（2）更换另一种MQ产品。比如将RabbitMQ替换为性能和扩展性更强的RocketMQ。

（3）使用云服务替换自建MQ集群。比如将自建的RocketMQ集群替换为云上商业版RocketMQ服务。

在MQ迁移的过程中，存在3个非常重要的需求：

• 操作简单。
• 风险可控。
• 不影响业务系统的正常运行。

如何让MQ的在线迁移同时满足这3个重要的需求呢？如何做到平滑切换，切换期间消息不丢失？本文将对几种可行的方式进行深入探讨。

理论基础

        在涉及到MQ在线迁移的所有方案中，都存有一个很重要的原则：对于发往MQ的每一条消息，如果已经被它的消费者成功接收并得到处理，这条消息就不再具有业务含义。已经被成功接收并得到处理的消息，只体现出统计方面的价值，并不需要随着MQ本身的迁移而进行数据迁移。

        在数据库迁移的场景中，新旧DB之间的数据迁移是非常重要的工作，这是因为DB中的数据是持久化的数据，需要伴随着数据库的生命周期而长期存在。而对于MQ而言，消息一旦被消息者接收并得到处理，就不再是持久化的数据，可以直接删除或归档。

        因此在MQ在线迁移的场景中，对已经处理过的消息，是没有数据迁移必要的。这样就将问题简化为：如何在迁移的过程中确保每一条消息被成功接收并得到处理。

在系统维护期停业务迁移