我曾被要求评估RabbitMQ而不是Kafka,但发现很难找到一个消息队列比Kafka更适合的情况。有人知道在哪些用例中消息队列在吞吐量、持久性、延迟或易用性方面更适合吗?


当前回答

简短的回答是“消息确认”。RabbitMQ可以配置为需要消息确认。如果接收方失败,消息将返回队列,另一个接收方可以再次尝试。虽然你可以用自己的代码在Kafka中完成这个任务,但它可以在RabbitMQ中开箱即用。

根据我的经验,如果你有一个需要查询信息流的应用程序,Kafka和KSql是你最好的选择。如果你想要一个排队系统,你最好使用RabbitMQ。

其他回答

简短的回答是“消息确认”。RabbitMQ可以配置为需要消息确认。如果接收方失败,消息将返回队列,另一个接收方可以再次尝试。虽然你可以用自己的代码在Kafka中完成这个任务,但它可以在RabbitMQ中开箱即用。

根据我的经验,如果你有一个需要查询信息流的应用程序,Kafka和KSql是你最好的选择。如果你想要一个排队系统,你最好使用RabbitMQ。

你们忘记的一个关键区别是RabbitMQ是基于推的消息系统,而Kafka是基于拉的消息系统。这在消息传递系统必须满足具有不同处理能力的不同类型的消费者的场景中非常重要。使用基于Pull的系统,消费者可以根据自己的能力消费,而推送系统将推送消息,而不管消费者的状态如何,从而将消费者置于高风险之中。

我将根据我的经验提供一个客观的答案,我也将跳过它们背后的理论,假设你已经知道它和/或其他答案已经提供了足够的答案。

RabbitMQ:如果我的需求足够简单,可以通过通道/队列处理系统通信,保留和流不是需求,我会选择这个。例如,当制造系统构建资产时,它会通知协议系统配置合同等等。

Kafka:主要是事件源需求,当你可能需要处理流(有时是无限的),大量的数据在一次适当的平衡,重放偏移以确保给定的状态等等。请记住,这种体系结构也带来了更多的复杂性,因为它确实包含了主题/分区/代理/墓碑消息等头等重要的概念。

我知道这是一个老问题了,但是在处理数据编校时RabbitMQ可能是一个更好的选择。

在RabbitMQ中,默认情况下,一旦消息被消费,它就会被删除。在Kafka中,默认情况下,消息保存一周。通常将这个时间设置为更长的时间,甚至永远不删除它们。

虽然这两个产品都可以配置为保留(或不保留)消息,但如果CCPA或GDPR合规性是一个问题,我会选择RabbitMQ。

RabbitMQ是一种传统的通用消息代理。它使web服务器能够快速响应请求,并将消息传递到多个服务。发布者能够发布消息并使其可用于队列,以便消费者可以检索它们。通信可以是异步的,也可以是同步的。


另一方面,Apache Kafka不仅仅是一个消息代理。它最初是由LinkedIn设计和实现的,用于作为消息队列。自2011年以来,Kafka已经开源,并迅速发展成为一个分布式流媒体平台,用于实现实时数据管道和流媒体应用程序。

它具有水平可扩展性、容错性、极快的速度和可磨合性 在数千家公司生产。

现代组织有各种各样的数据管道来促进系统或服务之间的通信。当相当数量的服务需要实时相互通信时,事情就变得有点复杂了。

The architecture becomes complex since various integrations are required in order to enable the inter-communication of these services. More precisely, for an architecture that encompasses m source and n target services, n x m distinct integrations need to be written. Also, every integration comes with a different specification, meaning that one might require a different protocol (HTTP, TCP, JDBC, etc.) or a different data representation (Binary, Apache Avro, JSON, etc.), making things even more challenging. Furthermore, source services might address increased load from connections that could potentially impact latency.

通过解耦数据管道,Apache Kafka带来了更简单、更易管理的体系结构。Kafka充当了一个高吞吐量的分布式系统,源服务在其中推送数据流,使它们可供目标服务实时提取。

另外,现在有很多开源的和企业级的用户界面来管理Kafka集群。有关更多详细信息,请参阅我的文章Apache Kafka集群的UI监控工具概述和为什么Apache Kafka?


使用RabbitMQ还是Kafka取决于项目的需求。一般来说,如果你想要一个简单的/传统的发布-订阅消息代理,那么选择RabbitMQ。如果你想构建一个事件驱动的体系结构,在此基础上你的组织将实时处理事件,那么选择Apache Kafka,因为它为这种体系结构类型提供了更多的功能(例如Kafka Streams或ksqlDB)。