如何从ActiveMQ平滑迁移到Kafka?

2024-09-04 16:38
文章标签 kafka 迁移 activemq 平滑

本文主要是介绍如何从ActiveMQ平滑迁移到Kafka?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

 
参考视频教程:  
 **python进阶训练营  **
如何从ActiveMQ平滑迁移到Kafka?_Kafka

直入主题,不讨论为什么迁移,直接谈迁移方案。

既然是从AMQ(AtiveMQ的简称)迁移到kafka,那么迁移过程中肯定需要做到平滑迁移:对于业务没有影响,对于上下游系统没有依赖。由于系统一般会和多个上游,多个下游通过MQ中间件保持依赖关系,迁移的过程中,肯定要做到各个系统上线没有任何依赖。打个比方订单系统发送topic,会员系统和积分系统都会接收这个topic(会员增加成长值,积分系统加积分)。改造后发布时,订单系统,会员系统,积分系统三个系统上线应该可以任意顺序,任意时间发布上线。

依赖关系

给出具体方案之前,先捋一下各个系统之间的依赖关系。再复杂的系统,和其他系统之间的依赖关系也就如下图所示,假设我们关注的是系统H。它会接受上游系统A和B发送的topic,以及给下游系统X,Y和Z发送topic(说明:下图是系统依赖关系图,而不是实例关系依赖图)。

如何从ActiveMQ平滑迁移到Kafka?_Kafka_02

根据这张架构图,我们将消息分为几个类型:

  • 生产型(1-1)–这种消息由本身系统H发送,下游系统X,Y,Z中任意且只有一个系统消费(AMQ中Queue的使用场景);

  • 生产型(1-N)–这种消息由本身系统H发送,下游系统X,Y,Z中任意多个系统消费(AMQ中VirtualTopic的使用场景);

  • 消费型–这种消息由上游系统例如A或者B发送,系统H负责消费;

  • 自产自消型–这种消息由本身系统H发送,本身系统H负责消费

VirtualTopic

生产型(1-N)消息,不能认为是Topic的使用场景,而应该是VirtualTopic的使用场景(至少大部分情况下)。两者的区别如下图所示(AMQ的VirtualTopic具体用法网上一大堆,这里就不累述了):

如何从ActiveMQ平滑迁移到Kafka?_Kafka_03

如上图所示,系统X有三个实例X-1,X-2,X-3;系统Y有三个实例Y-1,Y-2,Y-3。如果系统H发送一个VirtualTopic,假如名为:
登录后复制

VirtualTopic.PAY_SUCCESS_ORDER。

系统X和系统Y分别接收队列:
登录后复制

VConsumers.memberGroup.VirtualTopic.PAY_SUCCESS_ORDER


登录后复制

VConsumers.pointIssue.VirtualTopic.PAY_SUCCESS_ORDER。

那么系统X的三个实例只会有一个实例接收到
登录后复制

VConsumers.memberGroup.VirtualTopic.PAY_SUCCESS_ORDER,

系统Y的三个实例也只有一个实例接收到
登录后复制

VConsumers.pointIssue.VirtualTopic.PAY_SUCCESS_ORDER。

如果系统H发送一个Topic,假如名为
登录后复制

PAY_SUCCESS_ORDER

那么系统X的三个实例和系统Y的三个实例都会接收到这个Topic。

接下来我们分别讨论这几种消息如何做到平滑迁移(假定系统H就是我们要改造的系统)。

消费型

这类消息由于我们的系统H是消费者,即被动方,我们不确定上游系统A和B的发送方式什么时候从AMQ切换到kafka,另外我们无法预知我们订阅的AMQ存量消息什么时候消费完。所以对于这种类型的消息,系统H在改造时要保留原来的AMQ消息接收方式,同时需要新增kafka消息接收方式即可。

生产型(1-1)

这种场景就是AMQ中Queue的使用场景。这类消息由于我们的系统H是生产者,即主动方。且依赖关系比较简单,就是1对1。但是考虑到下游系统即消费者不确定什么时候加入kafka接收方式。所以,我们重构时AMQ发送方式要保留,kafka发送方式也要新增。但是需要在发送的地方增加一个开关,在两种发送方式之间切换。当下游系统即消费者引入kafka接收方式后,这个开关就可以切换到kafka发送。生产者的AMQ发送方式的代码和开关在下一个版本就可以删除了。同理,这个消费者的AMQ消费方式在下一个版本也可以删除。

生产型(1-N)

这种场景就是AMQ中VirtualTopic的使用场景。这类消息由于我们的系统H是生产者,即主动方。但是依赖关系相比Queue使用场景要复杂一点,因为消费者比较多。考虑到若干个下游系统即消费者不确定什么时候加入kafka接收方式。所以,我们重构时AMQ发送方式要保留,kafka发送方式也要新增。但是需要在发送的地方增加一个开关,在两种发送方式之间切换。当下游系统即消费者全部引入kafka接收方式后,这个开关就可以切换到kafka发送。生产者的AMQ发送方式的代码和开关在下一个版本就可以删除了。同理,若干个消费者的AMQ消费方式在下一个版本也可以删除。

自产自消型

这种类型的消息,即使消息的生产和消费都在我们的系统H中,整个过程我们能够完全掌控。如果不考虑多个实例之间部署的时间差,那么直接将AMQ的发送方式和接收方式全部更新为kafka发送方式和接收方式。例如本地缓存定时刷新这种场景。

如果考虑多个实例之间部署的时间差,那么就比较麻烦了。

1-1

如果自产自消是1-1类型消息,即系统H发送一个Queue,消费者也是系统H,且需要考虑多个实例之间部署的时间差。这个切换过程比较简单。直接将AMQ的发送方式和接收方式全部更新为kafka发送方式和接收方式,整个滚动部署过程如下:

  • 上线前
    重构上线前,所有系统都有AMQ发送方式和AMQ接收方式。自产自消。

如何从ActiveMQ平滑迁移到Kafka?_Kafka_04

  • 实例H1上线后
    实例H1上线后,实例H1是kafka发送方式和接收方式。如果消息是H1发送的,那么只能H1接收。如果消息是H2或者H3发送的,那么H2和H3都可以接收。

如何从ActiveMQ平滑迁移到Kafka?_Kafka_05

  • 实例H2上线后
    实例H2上线后,实例H1和H2是kafka发送方式和接收方式。如果消息是H1或者H2发送的,那么H1和H2都能接收。如果消息是H3发送的,那么H3可以接收。

如何从ActiveMQ平滑迁移到Kafka?_Kafka_06
* 实例H3上线后
实例H3即最后一个上线后,三个实例全部是kafka的发送方式和接收方式。

如何从ActiveMQ平滑迁移到Kafka?_Kafka_07

1-N

如果自产自消是1-N类型消息,即系统H发送一个Topic,消费者也是系统H,且需要考虑多个实例之间部署的时间差。这个切相对麻烦一点。

  1. 需要保留AMQ的接收方式,同时新增kafka接收方式,发布一个版本。

  2. 新增kafka发送方式,删除AMQ发送方式,滚动发布,直到所有实例部署完成。

总结

通过上面的方案设计,即使整个部门,或者整个公司相互之间通过MQ中间件依赖的系统有成百上千个,也可以做到从容不迫,一个系统一个系统慢慢迁移。完全不受其他项目组,不受其他部门的影响。整个过程真正做到平滑迁移。

-END-

近期热文:

*

系统优化总结—系统层面
——————————————————————————————————————————————————————————————————————————————–

*

NIO相关基础篇
—————————————————————————————————————————————————————————————————————————————

*

以Dubbo为例,聊聊如何为开源项目做贡献
—————————————————————————————————————————————————————————————————————————————————-

*

25个面试中最常问的问题和答案
———————————————————————————————————————————————————————————————————————————————–

*

如何使用Spring优雅地处理REST异常?
——————————————————————————————————————————————————————————————————————————————————

*

Spring Cloud Finchley版中Consul多实例注册的问题处理
———————————————————————————————————————————————————————————————————————————————————————–

*

超有趣的几个Linux小命令
———————————————————————————————————————————————————————————————————————————————-

*

JAVA拾遗 — JMH与8个代码陷阱
—————————————————————————————————————————————————————————————————————————————————–

关注我

如何从ActiveMQ平滑迁移到Kafka?_Kafka_08

这篇关于如何从ActiveMQ平滑迁移到Kafka?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1136462

相关文章

每天认识几个maven依赖(ActiveMQ+activemq-jaxb+activesoap+activespace+adarwin)

八、ActiveMQ 1、是什么? ActiveMQ 是一个开源的消息中间件(Message Broker),由 Apache 软件基金会开发和维护。它实现了 Java 消息服务(Java Message Service, JMS)规范,并支持多种消息传递协议,包括 AMQP、MQTT 和 OpenWire 等。 2、有什么用? 可靠性:ActiveMQ 提供了消息持久性和事务支持,确保消

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

ActiveMQ—消息特性(延迟和定时消息投递)

ActiveMQ消息特性:延迟和定时消息投递(Delay and Schedule Message Delivery) 转自:http://blog.csdn.net/kimmking/article/details/8443872 有时候我们不希望消息马上被broker投递出去,而是想要消息60秒以后发给消费者,或者我们想让消息没隔一定时间投递一次,一共投递指定的次数。。。 类似

ActiveMQ—安装配置及使用

安装配置及使用 转自:http://blog.csdn.net/qq_21033663/article/details/52461543 (一)ActiveMQ介绍 ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了

ActiveMQ—Queue与Topic区别

Queue与Topic区别 转自:http://blog.csdn.net/qq_21033663/article/details/52458305 队列(Queue)和主题(Topic)是JMS支持的两种消息传递模型:         1、点对点(point-to-point,简称PTP)Queue消息传递模型:         通过该消息传递模型,一个应用程序(即消息生产者)可以

CentOs7上Mysql快速迁移脚本

因公司业务需要,对原来在/usr/local/mysql/data目录下的数据迁移到/data/local/mysql/mysqlData。 原因是系统盘太小,只有20G,几下就快满了。 参考过几篇文章,基于大神们的思路,我封装成了.sh脚本。 步骤如下: 1) 先修改好/etc/my.cnf,        ##[mysqld]       ##datadir=/data/loc

CentOS下mysql数据库data目录迁移

https://my.oschina.net/u/873762/blog/180388        公司新上线一个资讯网站,独立主机,raid5,lamp架构。由于资讯网是面向小行业,初步估计一两年内访问量压力不大,故,在做服务器系统搭建的时候,只是简单分出一个独立的data区作为数据库和网站程序的专区,其他按照linux的默认分区。apache,mysql,php均使用yum安装(也尝试

Linux Centos 迁移Mysql 数据位置

转自:http://www.tuicool.com/articles/zmqIn2 由于业务量增加导致安装在系统盘(20G)磁盘空间被占满了, 现在进行数据库的迁移. Mysql 是通过 yum 安装的. Centos6.5Mysql5.1 yum 安装的 mysql 服务 查看 mysql 的安装路径 执行查询 SQL show variables like

Golang支持平滑升级的HTTP服务

前段时间用Golang在做一个HTTP的接口,因编译型语言的特性,修改了代码需要重新编译可执行文件,关闭正在运行的老程序,并启动新程序。对于访问量较大的面向用户的产品,关闭、重启的过程中势必会出现无法访问的情况,从而影响用户体验。 使用Golang的系统包开发HTTP服务,是无法支持平滑升级(优雅重启)的,本文将探讨如何解决该问题。 一、平滑升级(优雅重启)的一般思路 一般情况下,要实现平滑

Golang服务平滑重启

与重载配置相同的是我们也需要通过信号来通知server重启,但关键在于平滑重启,如果只是简单的重启,只需要kill掉,然后再拉起即可。平滑重启意味着server升级的时候可以不用停止业务。 我们先来看下Github上有没有相应的库解决这个问题,然后找到了如下三个库: facebookgo/grace - Graceful restart & zero downtime deploy for G