设计一套Kafka到RocketMQ的双写+双读技术方案，实现无缝迁移！

本文主要是介绍设计一套Kafka到RocketMQ的双写+双读技术方案，实现无缝迁移！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1、背景

假设你们公司本来线上的MQ用的主要是Kafka，现在要从Kafka迁移到RocketMQ去，那么这个迁移的过程应该怎么做呢？应该采用什么样的技术方案来做迁移呢？

2、方案

介绍一个MQ集群迁移过程中的双写+双读技术方案。

3、具体逻辑

简单来说，如果你要做MQ集群迁移，是不可能那么的简单粗暴的，因为你不可能说在某一个时间点突然之间就说把所有的Producer系统都停机，然后更新他的代码，接着全部重新上线，然后所有Producer系统都把消息写入到RocketMQ去了

一般来说，首先你要做到双写，也就是说，在你所有的Producer系统中，要引入一个双写的代码，让他同时往Kafka和RocketMQ中去写入消息，然后多写几天，起码双写要持续个1周左右，因为MQ一般都是实时数据，里面数据也就最多保留一周。

当你的双写持续一周过后，你会发现你的Kafka和RocketMQ里的数据看起来是几乎一模一样了，因为MQ反正也就保留最近几天的数据，当你双写持续超过一周过后，你会发现Kafka和RocketMQ里的数据几乎一模一样了。

但是光是双写还是不够的，还需要同时进行双读，也就是说在你双写的同时，你所有的Consumer系统都需要同时从Kafka和RocketMQ里获取消息，分别都用一模一样的逻辑处理一遍。

只不过从Kafka里获取到的消息还是走核心逻辑去处理，然后可以落入数据库或者是别的存储什么的，但是对于RocketMQ里获取到的消息，你可以用一样的逻辑处理，但是不能把处理结果具体的落入数据库之类的地方。

你的Consumer系统在同时从Kafka和RocketMQ进行消息读取的时候，你需要统计每个MQ当日读取和处理的消息的数量，这点非常的重要，同时对于RocketMQ读取到的消息处理之后的结果，可以写入一个临时的存储中。

同时你要观察一段时间，当你发现持续双写和双读一段时间之后，如果所有的Consumer系统通过对比发现，从Kafka和RocketMQ读取和处理的消息数量一致，同时处理之后得到的结果也都是一致的，此时就可以判断说当前Kafka和RocketMQ里的消息是一致的，而且计算出来的结果也都是一致的。

这个时候就可以实施正式的切换了，你可以停机Producer系统，再重新修改后上线，全部修改为仅仅写RocketMQ，这个时候他数据不会丢，因为之前已经双写了一段时间了，然后所有的Consumer系统可以全部下线后修改代码再上线，全部基于RocketMQ来获取消息，计算和处理，结果写入存储中。

这篇关于设计一套Kafka到RocketMQ的双写+双读技术方案，实现无缝迁移！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---