RabbitMQ vs Kafka:正面交锋(1)

简介: 值得注意的是,无论消费者是否消费了这些消息,Kafka 都会将消息保留在分区中直至预先配置的时间段内。这种保留意味着消费者可以自由地重读过去的消息。此外,开发人员还可以使用 Kafka 的存储层来实现事件溯源和审计日志等机制。

本文翻译自国外论坛 medium,原文地址:medium.com/better-prog…,原文作者:Eran Stiller

介绍

作为一名有着大量微服务系统处理经验的软件架构师,我经常遇到一个不断重复的问题:“我应该使用 RabbitMQ 还是 Kafka?”出于某种原因,许多开发人员认为这些技术是可以互换的。虽然在某些情况下确实如此,但 RabbitMQ 还是 Kafka 之间存在根本上的差异。

因此不同的场景需要不同的解决方案,选择错误的方案会严重影响我们的软件开发设计以及后续维护软件。

本文的第一部分将介绍基本的异步消息传递模式以及 RabbitMQ 和 Kafka 的内部结构实现。第二部分重点介绍了这些平台之间的关键区别、它们的各种优点和缺点,以及如何在两者之间进行选择。

第一部分:异步消息传递模式

异步消息传递是一种消息传递方案,其中生产者的消息生成与消费者的消息处理分离。在消息传递系统中,我们通常会分为两种主要的消息传递模式:队列模式和发布/订阅模式。

队列模式

在队列模式中,队列暂时将生产者与消费者解耦。多个生产者可以向同一个队列发送消息。然后当消费者处理消息时,消息会被锁定然后从队列中删除,并且不再可用。

队列模式通常就是一个消息只能被一个消费者处理。

image.png

附带说明一下,如果消费者无法处理某个消息,消息平台通常会将消息返回到队列,以供其他消费者使用。除了解耦之外,队列还允许我们扩展生产者和消费者,并针对错误处理提供容错能力。

发布/订阅模式

在发布/订阅模式中,单个消息可以由多个订阅者同时接收和处理。

image.png

例如,此模式允许发布者通知所有订阅者系统中发生了某些情况。在 RabbitMQ 中,主题是一种特定类型的 pub/sub 实现(确切地说是一种交换类型),但在本文中,我将主题称为整个 pub/sub 的表示。

一般来说,订阅有两种类型:

  • 临时订阅,其中订阅仅在使用者启动并运行时才有效。一旦消费者关闭,他们的订阅和尚未处理的消息就会丢失。
  • 持久订阅,只要未显式删除,订阅就会得到维护。当消费者关闭时,消息平台会维持订阅,稍后可以恢复消息处理。

RabbitMQ

RabbitMQ 是消息代理的一种实现 — 通常称为服务总线。它本身支持上述两种消息传递模式。消息代理的其他流行实现包括 ActiveMQ、ZeroMQ、Azure 服务总线和 Amazon Simple Queue Service (SQS)。所有这些实现都有很多共同点,本文中描述的许多概念适用于其中的大多数。

Queues

RabbitMQ 支持开箱即用的经典消息队列。开发人员定义命名队列,然后发布者可以将消息发送到该命名队列。反过来,消费者使用相同的队列来检索消息来处理它们。

Message exchanges

RabbitMQ 通过使用消息交换机来实现 pub/sub。发布者将其消息发布到消息交换机,不用知道这些消息的订阅者是谁。

每个订阅交换机的消费者都会创建一个队列,然后消息交换机将生成的消息排队以供消费者使用。它还可以根据各种路由规则过滤某些订阅者的消息。

image.png

值得注意的是,RabbitMQ 支持临时订阅和持久订阅。消费者可以通过 RabbitMQ 的 API 决定他们想要使用的订阅类型。

由于 RabbitMQ 的架构,我们还可以创建一种混合方法,其中一些订阅者形成消费者组,这些消费者组以特定队列上竞争消费者的形式共同处理消息。通过这种方式,我们实现了发布/订阅模式,同时还允许一些订阅者扩展以处理接收到的消息。

image.png


Apache Kafka

Apache Kafka 是一个分布式流处理平台。

与基于队列和交换的 RabbitMQ 不同,Kafka 的存储层是使用分区事务日志实现的。 Kafka 还提供了 Streams API 来实时处理流,以及 Connectors API 来轻松与各种数据源集成。不过,这些超出了本文的范围。

云服务商为 Kafka 的存储层提供了替代解决方案。这些解决方案包括 Azure 事件中心,在某种程度上还包括 AWS Kinesis Data Streams。Kafka 的流处理功能还有特定于云的开源替代方案,同样,这些也超出了本文的范围。

Topics

Kafka 没有实现队列的概念。Kafka 将记录集合存储在称为主题的类别中。

对于每个主题,Kafka 都会维护一个分区的消息日志。每个分区都是一个有序的、不可变的记录序列,其中不断附加消息。

Kafka 在消息到达时将其附加到这些分区。默认情况下,它使用循环分区器在分区之间均匀地传播消息。

生产者可以修改此行为以创建逻辑消息流。例如在多租户应用程序中,我们可能希望根据每条消息的租户 ID 创建逻辑消息流。在物联网场景中,我们可能希望将每个生产者的身份不断映射到特定分区。确保来自同一逻辑流的所有消息映射到同一分区,以保证它们按顺序传递给消费者。

image.png

消费者通过维护这些分区的偏移量(或索引)并按顺序读取它们来消费消息。

单个消费者可以使用多个主题,并且消费者可以扩展,直至与可用分区数量一致。

因此,在创建主题时,应仔细考虑该主题的消息传递的预期吞吐量。共同消费某个主题的一组消费者称为消费者组。Kafka 的 API 通常负责消费者组中消费者之间分区处理的平衡以及消费者当前分区偏移量的存储。

image.png

使用 Kafka 实现消息传递

Kafka 的内部实现其实很好地反映了 pub/sub 模式。

生产者可以向特定主题发送消息,多个消费者组可以消费同一条消息。每个消费者组都可以单独扩展以处理负载。由于消费者维护其分区偏移量,因此他们可以选择持久订阅(在重新启动时维持其偏移量)或临时订阅(即丢弃偏移量并在每次启动时从每个分区中的最新记录重新启动)。

Kafka 其实是不太适合队列模式的消息传递。当然我们可以创建一个只有一个消费者组的主题来模拟经典的消息队列。但这有多个缺点,在本文第二部分我们将详细讨论。

值得注意的是,无论消费者是否消费了这些消息,Kafka 都会将消息保留在分区中直至预先配置的时间段内。这种保留意味着消费者可以自由地重读过去的消息。此外,开发人员还可以使用 Kafka 的存储层来实现事件溯源和审计日志等机制。

目录
相关文章
|
4月前
|
消息中间件 Java Kafka
消息传递新纪元:探索RabbitMQ、RocketMQ和Kafka的魅力所在
【8月更文挑战第29天】这段内容介绍了在分布式系统中起到异步通信与解耦作用的消息队列,并详细探讨了三种流行的消息队列产品:RabbitMQ、RocketMQ 和 Kafka。其中,RabbitMQ 是一个基于 AMQP 协议的开源消息队列系统,支持多种消息模型;RocketMQ 则是由阿里巴巴开源的具备高性能、高可用性和高可靠性的分布式消息队列,支持事务消息等多种特性;而 Kafka 作为一个由 LinkedIn 开源的分布式流处理平台,以高吞吐量和良好的可扩展性著称。此外,还提供了使用这三种消息队列发送和接收消息的代码示例。总之,这三种消息队列各有优势,适用于不同的业务场景。
75 3
|
1月前
|
消息中间件 大数据 Kafka
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
本文深入探讨了消息队列的核心概念、应用场景及Kafka、RocketMQ、RabbitMQ的优劣势比较,大厂面试高频,必知必会,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
|
1月前
|
消息中间件 存储 监控
ActiveMQ、RocketMQ、RabbitMQ、Kafka 的区别
【10月更文挑战第24天】ActiveMQ、RocketMQ、RabbitMQ 和 Kafka 都有各自的特点和优势,在不同的应用场景中发挥着重要作用。在选择消息队列时,需要根据具体的需求、性能要求、扩展性要求等因素进行综合考虑,选择最适合的消息队列技术。同时,随着技术的不断发展和演进,这些消息队列也在不断地更新和完善,以适应不断变化的应用需求。
103 1
|
2月前
|
消息中间件 存储 监控
说说如何解决RocketMq消息积压?为什么Kafka性能比RocketMq高?它们区别是什么?
【10月更文挑战第8天】在分布式系统中,消息队列扮演着至关重要的角色,它不仅能够解耦系统组件,还能提供异步处理、流量削峰和消息持久化等功能。在众多的消息队列产品中,RocketMQ和Kafka无疑是其中的佼佼者。本文将围绕如何解决RocketMQ消息积压、为什么Kafka性能比RocketMQ高以及它们之间的区别进行深入探讨。
104 1
|
4月前
|
消息中间件 存储 监控
RabbitMQ、Kafka对比(超详细),Kafka、RabbitMQ、RocketMQ的区别
RabbitMQ、Kafka对比(超详细),Kafka、RabbitMQ、RocketMQ的区别,设计目标、适用场景、吞吐量、消息存储和持久化、可靠性、集群负载均衡
RabbitMQ、Kafka对比(超详细),Kafka、RabbitMQ、RocketMQ的区别
|
4月前
|
消息中间件 存储 关系型数据库
Kafka 与 RabbitMQ 如何选择使用哪个?
Kafka 与 RabbitMQ 如何选择使用哪个?
55 1
|
4月前
|
消息中间件 Kafka Apache
kafka vs rocketmq: 不要只顾着吞吐量而忘了延迟这个指标
这篇文章讨论了Apache RocketMQ和Kafka的对比,强调RocketMQ在低延迟、消息重试与追踪、海量Topic、多租户等方面进行了优化,特别是在小包非批量和大量分区场景下的吞吐量超越Kafka,适合电商和金融领域等高并发、高可靠和高可用场景。
142 0
|
2月前
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
103 1
|
2月前
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
55 1
|
4月前
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
345 9