科普rabbitmq,rocketmq,kafka三者的架构比较

对比

在这里插入图片描述


在这里插入图片描述

架构对比

在这里插入图片描述


在这里插入图片描述

在这里插入图片描述


从架构可以看出三者有些类似,但是在细节上有很多不同。下面我们就从它们的各个组件,介绍它们:

RabbitMQ

是一种开源的消息队列中间件。下面是RabbitMQ中与其相关的几个概念:

1.生产者(Producer):生产者是消息的发送者,将消息发送到RabbitMQ的消息队列中。

2.消费者(Consumer):消费者是消息的接收者,从RabbitMQ的消息队列中获取消息并进行处理。

3.消息队列(Message Queue):消息队列是RabbitMQ的核心组件,用于存储待处理的消息。生产者将消息发送到队列中,消费者从队列中获取消息进行处理。

4.交换机(Exchange):交换机负责接收生产者发送的消息,并根据一定的规则将消息路由到一个或多个消息队列中。常见的交换机类型包括直连交换机(direct exchange)、主题交换机(topic exchange)、扇形交换机(fanout exchange)等。

5.绑定(Binding):绑定是指将交换机和消息队列进行关联,定义了交换机将消息路由到哪些队列中。绑定通常使用规则(routing key)来匹配消息和队列。

6.路由键(Routing Key):路由键是生产者在将消息发送给交换机时附带的关键字,用于指定消息的路由规则。

RocketMQ

是阿里巴巴开源的分布式消息中间件,下面是 RocketMQ 中与其相关的一些概念:

1.生产者(Producer):生产者负责生成并发送消息到 RocketMQ 中。

2.消费者(Consumer):消费者从 RocketMQ 中订阅并消费消息。

3.主题(Topic):主题是消息的逻辑分类,每个消息都属于一个特定的主题。生产者将消息发送到指定的主题,消费者通过订阅主题来接收相关的消息。

4.消息队列(Message Queue):主题被拆分成多个消息队列,每个消息队列按照顺序存储消息。消费者从消息队列中拉取消息进行消费。

5.消费者组(Consumer Group):消费者组是一组具有相同 Group ID 的消费者实例。每个消息只会被消费者组中的其中一个消费者实例消费,实现负载均衡和高可用性。

6.Broker:Broker 是 RocketMQ 的核心组件,它负责接收、存储和转发消息。一个 RocketMQ 系统通常由多个 Broker 组成,每个 Broker 负责管理若干个消息队列。每个消息队列只属于一个 Broker,但一个 Broker 可以管理多个消息队列。

7.Name Server:Name Server 是 RocketMQ 的命名服务组件,用于管理整个 RocketMQ 系统的元数据信息。生产者和消费者通过 Name Server 定位到对应的 Broker 服务器。Name Server 还负责管理主题、消费者组、路由信息等。

运行流程
1.生产者和消费者在启动时会向Name Server注册自己的信息,包括IP地址、端口号等基本信息,以便于Name Server能够为它们提供服务路由信息,此外broker节点通过心跳机制将自己的信息定时上报到Name Server中
2.当生产者要发送消息时,首先需要通过Name Server获取指定Topic目前可用的Broker(可以是多个),然后根据负载均衡算法选择其中一个Broker发送消息。消息会被刷盘机制持久化存储
3.消息在经过同步刷盘或异步刷盘机制持久化存储之后,会被放入该Topic对应的队列中。
4.消费者在订阅指定的Topic和Tag之后,会从Broker服务器中拉取消息进行消费。消费者首先会向Name Server获取指定Topic目前可用的Broker,然后根据自身消费能力获取消息

Kafka

是由 Apache 软件基金会开源的分布式流处理平台,其核心组件包括以下几个:

1.Broker:Kafka 的核心组件之一,负责存储和处理数据。一个 Kafka 系统通常由多个 Broker 组成,每个 Broker 负责管理一部分数据副本。

2.Topic:Topic 是指数据的类别或主题,每条消息都属于一个特定的主题。生产者将消息发送到指定的主题,消费者通过订阅主题来接收相关的消息。

3.Partition:Partition 是将一个 Topic 分割成多个较小的、有序的数据单元。每个 Partition 存储了 Topic 对应的部分消息数据。分区的好处是可以提高并发处理能力和扩展性。

4.生产者(Producer):生产者负责生成并发送消息到 Kafka 的 Broker。Producer 可以选择将消息发送到指定的 Topic 和 Partition。

5.消费者(Consumer):消费者从 Kafka 的 Broker 订阅并消费消息。可以通过消费者组的方式对消息进行分组,每个消费者组中的消费者共同消费一个 Topic。

6.消费者组(Consumer Group):消费者组是一组具有相同 Group ID 的消费者实例。每个消息只会被消费者组中的其中一个消费者实例消费,实现负载均衡和高可用性。

7.ZooKeeper:Kafka 使用 ZooKeeper 来进行集群管理、元数据存储和领导者选举等操作。ZooKeeper 负责协调 Broker 和其他组件之间的通信。

不同:
在发送消息和拉取消息方面,Kafka、RocketMQ 和 RabbitMQ 有一些区别。

1.RabbitMQ
发送消息:RabbitMQ 中的生产者(Producer)将消息发送到指定的 Exchange。生产者发送消息时可以指定消息的 Routing Key,Exchange 根据 Routing Key 将消息路由到相应的队列。
拉取消息:RabbitMQ 中的消费者(Consumer)通过订阅队列来拉取消息。消费者可以按照默认顺序或自定义顺序消费队列中的消息。消费者可以选择轮询方式拉取消息,也可以使用 Basic.Consume RPC 方法主动拉取消息。

2.RocketMQ
发送消息:RocketMQ 的生产者(Producer)将消息发送到指定的 Topic,并不能直接选择要发送到的队列,而是由 Broker 负责将消息分发到相应的队列中。发送消息时可以选择同步或异步方式。
拉取消息:RocketMQ 的消费者(Consumer)通过订阅 Topic 和指定消费者组(Consumer Group)来拉取消息。RocketMQ 提供了两种消费模式:集群模式(负载均衡消费)和广播模式(每个消费者都会收到全部消息)。消费者可以按照默认顺序拉取消息或指定顺序拉取消息。

3.Kafka:
发送消息:Kafka 中的生产者(Producer)将消息发送到指定的 Topic,并选择要发送到的 Partition。生产者可以异步发送消息,不必等待消息被写入磁盘。
拉取消息:Kafka 中的消费者(Consumer)通过订阅 Topic 来拉取消息。消费者可以自主控制从哪个 Offset(偏移量)开始拉取消息,并可以按照自己的速度消费消息。Kafka 提供了高性能的批量拉取机制,可以一次性拉取多条消息。

前二者可以实现延迟队列,死信队列,而kafka不行。

经典面试题:

1.如何保证消息的可靠性?

本质上都是解决 生成者 ----> mq -----> 消费者 消息在链路中不会被丢失
rabbitmq:
1.生产者确认机制:实现两个方法ReturnCallback,ConfirmCallback 。ReturnCallback是保证消息从交换机到队列。每次发送消息时都需要实现ConfirmCallback,该方式需要生成一个唯一ID,避免ack冲突,ConfirmCallback:保证了消息从生产者到交换机再到队列中,如果没有到队列中会返回nack。
2.队列中消息持久化:RabbitMQ会将消息持久化到磁盘,以确保消息在服务器重启或发生故障时能够得到恢复。前提是在发送消息时,将消息标记为持久化,即设置 MessageProperties.PERSISTENT_TEXT_PLAIN 属性。
3.消费者确认机制:默认确认机制是自动的,消费后自动ack,ack会删除队列指定的消息
4.失败重试机制:发送重试,消费重试

rocketmq
1.发消息时,重要的消息可以使用同步发送,内部已经实现了ack机制,该发送会有返回值可以获取消息的发送状态,增加重试机制
2.消息到达了rockemq之后它内部已经实现了持久化机制,RocketMQ 将消息以日志形式持久化到磁盘中(使用同步刷盘机制
3.消费者通过手动确认机制(ACK)
4.失败重试机制:消费失败默认会回到队列中重新投递

2.如何解决消息重复消费的问题

rabbitmq
1.消费端手动ACK确认机制
在消费端使用RabbitMQ提供的手动ACK确认机制,在消费者成功处理消息后,手动将消息从队列中删除。这样可以确保消息只会被处理一次,避免了重复消费的问题。
2.消费端去重保证机制
可以在消费端处理每条消息之前,通过分布式锁或者数据库唯一索引等方式,判断当前消息是否已经被处理过。如果已经处理过,则忽略该消息;否则正常处理,并将消息标记为已处理。

rocketmq:因为内部的重试机制,很难避免重复消费。一般需要消费端去重保证机制(同上)

3.如何解决消息堆积

一般
限流:限制消息的生产速度
增加消费速度:增加消费者(rocketmq中:<=队列数量),增加线程数消费
增加队列容量
rabbit:惰性队列 增加队列容量
从RabbitMQ的3.6.0版本开始,就增加了Lazy Queues的概念,也就是惰性队列。惰性队列的特征如下:
接收到消息后直接存入磁盘而非内存
消费者要消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储
惰性队列是一种用于减少内存占用的优化策略,它的设计目的是在队列中存在大量未消费的消息时,只有当消息被消费者拉取时才将它们加载到内存中。这样可以降低内存使用,并提高系统的性能和吞吐量。

原文地址:https://blog.csdn.net/qq_56533553/article/details/131696035

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读4.1k次。kafka认证_kafka认证
文章浏览阅读4.8k次,点赞4次,收藏11次。kafka常用参数_kafka配置
文章浏览阅读1.4k次,点赞25次,收藏10次。Kafka 生产者发送消息的流程涉及多个步骤,从消息的创建到成功存储在 Kafka 集群中。_kafka发送消息流程
文章浏览阅读854次,点赞22次,收藏24次。点对点模型:适用于一对一的消息传递,具有高可靠性。发布/订阅模型:适用于广播消息给多个消费者,实现消息的广播。主题模型:适用于根据消息的主题进行灵活的过滤和匹配,处理复杂的消息路由需求。
文章浏览阅读1.5k次,点赞2次,收藏3次。kafka 自动配置在KafkaAutoConfiguration
文章浏览阅读1.3w次,点赞6次,收藏33次。Offset Explorer(以前称为Kafka Tool)是一个用于管理和使Apache Kafka ®集群的GUI应用程序。它提供了一个直观的UI,允许人们快速查看Kafka集群中的对象以及存储在集群主题中的消息。它包含面向开发人员和管理员的功能。二、环境信息系统环境:windows 10版本:2.2Kafka版本:Kafka2.0.0三、安装和使用3.1 下载Offset Explorer 和安装下载到本地的 .exe文件Next安装路径 ,Next。_offset explorer
文章浏览阅读1.3k次,点赞12次,收藏19次。kafka broker 在启动的时候,会根据你配置的listeners 初始化它的网络组件,用来接收外界的请求,这个listeners你可能没配置过,它默认的配置是listeners=PLAINTEXT://:9092就是告诉kafka使用哪个协议,监听哪个端口,如果我们没有特殊的要求的话,使用它默认的配置就可以了,顶多是修改下端口这块。
文章浏览阅读1.3k次,点赞2次,收藏2次。Kafka 是一个强大的分布式流处理平台,用于实时数据传输和处理。通过本文详细的介绍、使用教程和示例,你可以了解 Kafka 的核心概念、安装、创建 Topic、使用生产者和消费者,从而为构建现代分布式应用打下坚实的基础。无论是构建实时数据流平台、日志收集系统还是事件驱动架构,Kafka 都是一个可靠、高效的解决方案。_博客系统怎么使用kafka
文章浏览阅读3.5k次,点赞42次,收藏56次。对于Java开发者而言,关于 Spring ,我们一般当做黑盒来进行使用,不需要去打开这个黑盒。但随着目前程序员行业的发展,我们有必要打开这个黑盒,去探索其中的奥妙。本期 Spring 源码解析系列文章,将带你领略 Spring 源码的奥秘。本期源码文章吸收了之前 Kafka 源码文章的错误,将不再一行一行的带大家分析源码,我们将一些不重要的分当做黑盒处理,以便我们更快、更有效的阅读源码。废话不多说,发车!
文章浏览阅读1.1k次,点赞14次,收藏16次。一、自动提交offset1、概念Kafka中默认是自动提交offset。消费者在poll到消息后默认情况下,会自动向Broker的_consumer_offsets主题提交当前主题-分区消费的偏移量2、自动提交offset和手动提交offset流程图3、在Java中实现配置4、自动提交offset问题自动提交会丢消息。因为如果消费者还没有消费完poll下来的消息就自动提交了偏移量,那么此时消费者挂了,于是下一个消费者会从已经提交的offset的下一个位置开始消费消息。_kafka中自动提交offsets
文章浏览阅读1.6k次。如果生产者发送消息的速度超过发送到服务器的速度,则会导致生产者空间不足,这个时候KafkaProducer的send()方法调用要么被阻塞,要么抛出异常,这个取决于参数max.block.ms的配置,此参数的默认值为60000,即60秒。在默认情况下,生产者发送的消息是未经压缩的。如果应用程序调用send()方法的速度超过生产者将消息发送给服务器的速度,那么生产者的缓冲空间可能会被耗尽,后续的send()方法调用会等待内存空间被释放,如果在max.block.ms之后还没有可用空间,就抛出异常。_kafka producer 参数
文章浏览阅读2.9k次,点赞3次,收藏10次。kafka解决通信问题_kafka3.6
文章浏览阅读1.5k次,点赞9次,收藏11次。上面都配置完了之后可以先验证下,保证数据最终到ck,如果有问题,需要再每个节点调试,比如先调试nginx->rsyslog ,可以先不配置kafka 输出,配置为console或者文件输出都可以,具体这里就不写了。这里做了一个类型转换,因为nginx,request-time 单位是s,我想最终呈现在grafana 中是ms,所以这里做了转换,当然grafana中也可以做。kafka 相关部署这里不做赘述,只要创建一个topic 就可以。
文章浏览阅读1.4k次,点赞22次,收藏16次。Kafka中的enable-auto-commit和auto-commit-interval配置_auto-commit-interval
文章浏览阅读742次。thingsboard规则链调用外部 kafka_thingsboard kafka
文章浏览阅读1.3k次,点赞18次,收藏22次。Kafka_简介
文章浏览阅读1.1k次,点赞16次,收藏14次。在数据库系统中有个概念叫事务,事务的作用是为了保证数据的一致性,意思是要么数据成功,要么数据失败,不存在数据操作了一半的情况,这就是数据的一致性。在很多系统或者组件中,很多场景都需要保证数据的一致性,有的是高度的一致性。特别是在交易系统等这样场景。有些组件的数据不一定需要高度保证数据的一致性,比如日志系统。本节从从kafka如何保证数据一致性看通常数据一致性设计。
文章浏览阅读1.4k次。概述介绍架构发展架构原理类型系统介绍类型hive_table类型介绍DataSet类型定义Asset类型定义Referenceable类型定义Process类型定义Entities(实体)Attributes(属性)安装安装环境准备安装Solr-7.7.3安装Atlas2.1.0Atlas配置Atlas集成HbaseAtlas集成SolrAtlas集成KafkaAtlas Server配置Kerberos相关配置Atlas集成HiveAtlas启动Atlas使用Hive元数据初次导入Hive元数据增量同步。_atlas元数据管理
文章浏览阅读659次。Zookeeper是一个开源的分布式服务管理框架。存储业务服务节点元数据及状态信息,并负责通知再 ZooKeeper 上注册的服务几点状态给客户端。
文章浏览阅读1.4k次。Kafka-Kraft 模式架构部署_kafka kraft部署