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


当前回答

RabbitMQ是一个可靠的通用消息代理,支持多种协议,如AMQP、MQTT、STOMP等。它可以处理高吞吐量。RabbitMQ的一个常见用例是处理后台作业或长时间运行的任务,比如文件扫描、图像缩放或PDF转换。RabbitMQ也用于微服务之间,作为应用程序之间通信的一种手段,避免了消息传递的瓶颈。

Kafka是一种消息总线,针对高吞吐量的数据流和重放进行了优化。当你需要移动大量数据、实时处理数据或在一段时间内分析数据时,请使用Kafka。换句话说,就是需要收集、存储和处理数据的地方。例如,当您想要跟踪网络商店上的用户活动并生成建议购买的商品时。另一个例子是用于跟踪、摄取、日志记录或安全的数据分析。

Kafka可以被看作是一个持久的消息代理,应用程序可以对磁盘上的流数据进行处理和再处理。Kafka有一个非常简单的路由方法。如果你需要以复杂的方式将消息路由到用户,RabbitMQ有更好的选择。如果你需要支持离线的批处理消费者或者想要低延迟消息的消费者,可以使用Kafka。

In order to understand how to read data from Kafka, we first need to understand its consumers and consumer groups. Partitions allow you to parallelize a topic by splitting the data across multiple nodes. Each record in a partition is assigned and identified by its unique offset. This offset points to the record in a partition. In the latest version of Kafka, Kafka maintains a numerical offset for each record in a partition. A consumer in Kafka can either automatically commit offsets periodically, or it can choose to control this committed position manually. RabbitMQ will keep all states about consumed/acknowledged/unacknowledged messages. I find Kafka more complex to understand than the case of RabbitMQ, where the message is simply removed from the queue once it's acked.

RabbitMQ的队列在空时是最快的,而Kafka以很小的开销保留大量数据——Kafka是为保存和分发大量消息而设计的。(如果你打算在RabbitMQ中使用很长的队列,你可以看看惰性队列。)

Kafka是基于水平扩展(通过增加更多的机器来扩展)而构建的,而RabbitMQ主要是为垂直扩展(通过增加更多的能力来扩展)而设计的。

RabbitMQ has a built-in user-friendly interface that lets you monitor and handle your RabbitMQ server from a web browser. Among other things, queues, connections, channels, exchanges, users and user permissions can be handled - created, deleted and listed in the browser and you can monitor message rates and send/receive messages manually. Kafka has a number of open-source tools, and also some commercial ones, offering the administration and monitoring functionalities. I would say that it's easier/gets faster to get a good understanding of RabbitMQ.

一般来说,如果你想要一个简单的/传统的发布-订阅消息代理,最明显的选择是RabbitMQ,因为它的扩展性很可能比你需要的要大。如果我的需求足够简单,可以通过通道/队列处理系统通信,并且不需要保留和流,我就会选择RabbitMQ。

在两种情况下我会选择RabbitMQ;对于长时间运行的任务,当我需要运行可靠的后台作业时。以及应用程序内部和应用程序之间的通信和集成,即作为微服务之间的中间人;系统只需要通知系统的另一部分开始处理任务,例如在web商店中处理订单(下订单、更新订单状态、发送订单、付款等)。

一般来说,如果你想要一个用于存储、读取(重读)和分析流数据的框架,可以使用Apache Kafka。它非常适合被审计的系统或需要永久存储消息的系统。这些还可以分解为分析数据(跟踪、摄取、日志记录、安全等)或实时处理的两个主要用例。

更多阅读,用例和一些比较数据可以在这里找到:https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

同时推荐行业论文:“Kafka vs RabbitMQ:两种行业参考发布/订阅实现的比较研究”:http://dl.acm.org/citation.cfm?id=3093908

我在一家同时提供Apache Kafka和RabbitMQ as a Service的公司工作。

其他回答

Apache Kafka is a popular choice for powering data pipelines. Apache kafka added kafka stream to support popular etl use cases. KSQL makes it simple to transform data within the pipeline, readying messages to cleanly land in another system. KSQL is the streaming SQL engine for Apache Kafka. It provides an easy-to-use yet powerful interactive SQL interface for stream processing on Kafka, without the need to write code in a programming language such as Java or Python. KSQL is scalable, elastic, fault-tolerant, and real-time. It supports a wide range of streaming operations, including data filtering, transformations, aggregations, joins, windowing, and sessionization.

https://docs.confluent.io/current/ksql/docs/index.html

对于etl系统来说,Rabbitmq并不是一个受欢迎的选择,它更适合那些需要简单的消息传递系统和更低吞吐量的系统。

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

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

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

Scaling both is hard in a distributed fault tolerant way but I'd make a case that it's much harder at massive scale with RabbitMQ. It's not trivial to understand Shovel, Federation, Mirrored Msg Queues, ACK, Mem issues, Fault tollerance etc. Not to say you won't also have specific issues with Zookeeper etc on Kafka but there are less moving parts to manage. That said, you get a Polyglot exchange with RMQ which you don't with Kafka. If you want streaming, use Kafka. If you want simple IoT or similar high volume packet delivery, use Kafka. It's about smart consumers. If you want msg flexibility and higher reliability with higher costs and possibly some complexity, use RMQ.

我能想到的唯一好处是事务性功能,其余的都可以用Kafka来完成

在以下情况使用RabbitMQ:

你不需要处理大数据,你更喜欢一个方便的内置UI来监控 不需要自动复制队列 消息没有多个订阅者——因为不像Kafka是一个日志,RabbitMQ是一个队列,消息一旦被消费和确认到达就会被删除 如果您有要求使用通配符和正则表达式的消息 如果定义消息优先级很重要

简而言之: RabbitMQ适用于简单的用例,数据流量低,具有优先级队列和灵活的路由选项。 对于海量数据和高吞吐量使用Kafka。