有没有理由使用RabbitMQ而不是Kafka？

Question

我被要求评估RabbitMQ而不是Kafka,但发现很难找到一个比Kafka做得更好的原因.有谁知道它在吞吐量,耐用性,延迟或易用性方面是否真的更好？

Answer 1

RabbitMQ是一个可靠的通用消息代理,支持多种协议,如AMQP,MQTT,STOMP等.它可以处理高吞吐量和常见用例,因为它可以处理后台作业或作为微服务之间的消息代理.Kafka是一种针对高入口数据流和重放进行了优化的消息总线.

Kafka可以看作是一个持久的消息代理,应用程序可以在其上处理和重新处理磁盘上的流数据.Kafka有一种非常简单的路由方法.如果您需要以复杂的方式将消息路由到您的消费者,RabbitMQ有更好的选择.如果您需要支持可能处于脱机状态的批量使用者,或者需要支持低延迟消息的消费者,请使用Kafka. 

RabbitMQ将保留关于消费/已确认/未确认消息的所有状态,而Kafka则不会,它假设消费者记录已消费的内容.RabbitMQ的队列在空闲时排队最快,而Kafka保留大量数据且开销很小--Kafka用于保存和分发大量消息.(如果你计划在RabbitMQ中拥有很长的队列,你可以看看懒惰的队列.)

Kafka是从头开始构建的,具有水平扩展(通过添加更多机器来扩展),而RabbitMQ主要用于垂直扩展(通过增加更多功率来扩展).

RabbitMQ具有用户友好的界面,可让您从Web浏览器监控和处理RabbitMQ服务器.除此之外,还可以处理队列,连接,通道,交换,用户和用户权限 - 在浏览器中创建,删除和列出,您可以手动监控消息速率和发送/接收消息.Kafka经理尚未像RabbitMQ Management界面那样发达.我会说,对RabbitMQ有一个很好的了解会更容易/更快.

更多阅读和一些比较数据可以在这里找到:https://www.cloudkarafka.com/blog/2016-12-05-apachekafka-vs-rabbitmq.html

同时推荐行业论文:"Kafka与RabbitMQ:两个行业参考发布/订阅实施的比较研究":http://dl.acm.org/citation.cfm？id = 3093908

我在一家提供Apache Kafka和RabbitMQ即服务的公司工作.

Answer 2

我每周都会听到这个问题......虽然RabbitMQ(如IBM MQ或JMS或其他一般的消息传递解决方案)用于传统消息传递,但Apache Kafka被用作流媒体平台(消息传递+分布式存储+数据处理).两者都是针对不同的用例而构建的.

您可以将Kafka用于"传统消息传递",但不能将MQ用于特定于Kafka的方案.

文章" Apache Kafka与企业服务总线(ESB) - 朋友,敌人或敌人？(https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)"讨论为什么Kafka没有竞争力但是对集成和消息解决方案的补充(包括RabbitMQ)以及如何整合两者.

Answer 3

Kafka和RabbitMQ（使用它们的客户）之间的5个主要区别：

选择哪种消息传递系统，或者我们应该更改现有消息传递系统？

上述问题没有答案。在必须决定哪个邮件系统或应该更改现有系统时，一种可能的审查方法是“ 评估范围和成本？”

Answer 4

你们忘记的一个关键区别是RabbitMQ是基于推的消息传递系统，而Kafka是基于拉的消息传递系统。这在消息传递系统必须满足具有不同处理能力的不同类型的使用者的情况下非常重要。使用基于Pull的系统，消费者可以根据他们的能力进行消费，而无论消费者的状态如何，推送系统都会推送消息，从而使消费者处于高风险中。

Answer 5

在以下情况下使用 RabbitMQ：

• 您不必处理大数据，并且更喜欢方便的内置 UI 进行监控
• 不需要自动复制队列
• 消息没有多个订阅者 - 由于与作为日志的 Kafka 不同，RabbitMQ 是一个队列，一旦消费和确认到达，消息就会被删除
• 如果您有对消息使用通配符和正则表达式的要求
• 如果定义消息优先级很重要

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

Answer 6

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

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

它具有水平可伸缩性，容错性，快速快速性，可在数千家公司中投入生产。

现代组织具有各种数据管道，可促进系统或服务之间的通信。当一定数量的服务需要彼此实时通信时，事情会变得更加复杂。

由于需要各种集成才能实现这些服务的相互通信，因此架构变得复杂。更准确地说，对于包含m个源服务和n个目标服务的体系结构，需要编写nxm个不同的集成。而且，每种集成都带有不同的规范，这意味着可能需要不同的协议（HTTP，TCP，JDBC等）或不同的数据表示形式（二进制，Apache Avro，JSON等），这使事情更具挑战性。此外，源服务可能会解决来自连接的增加的负载，这可能会影响延迟。

通过解耦数据管道，Apache Kafka导致了更简单和可管理的体系结构。Kafka充当高吞吐量分布式系统，其中源服务推送数据流，使数据流可用于目标服务以实时提取它们。

此外，现在还提供了许多用于管理Kafka群集的开源和企业级用户界面。有关更多详细信息，请参阅我的文章Apache Kafka集群的UI监视工具概述以及为什么选择Apache Kafka？

是否选择RabbitMQ或Kafka取决于您项目的要求。通常，如果您希望使用简单/传统的发布/订阅消息代理，请使用RabbitMQ。如果您想构建一个事件驱动的体系结构，您的组织将在该体系结构上实时处理事件，那么请选择Apache Kafka，因为它为该体系结构类型提供了更多功能（例如，Kafka Streams和/或KSQL）。 。

Answer 7

简短的回答是“消息确认”。RabbitMQ 可以配置为需要消息确认。如果接收方失败，消息将返回队列，另一个接收方可以重试。虽然您可以使用自己的代码在 Kafka 中完成此操作，但它可以开箱即用地与 RabbitMQ 配合使用。

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

Answer 8

我将根据我的经验提供客观的答案，假设您已经知道和/或其他答案已经提供足够的知识，我还将跳过它们背后的理论。

RabbitMQ：如果我的需求足够简单，可以处理通过通道/队列进行的系统通信，则不需保留和流式传输，我会选择这一点。例如，当制造系统构建资产时，它确实会通知协议系统以配置合同等。

Kafka：主要是事件源需求，当您可能需要处理流（有时是无限的）时，一次要适当平衡大量数据，重播偏移量以确保给定状态等等。请记住，这种架构也带来了更多的复杂性，因为它确实包含了诸如主题/分区/经纪人/墓碑消息等概念，这是头等重要的事情。

Answer 9

我知道现在有点晚了，也许您已经间接地说过了，但是再说一次，Kafka根本不是队列，它是一个日志（正如上面的人所说，基于调查）。

为简单起见，与Kafka相比，应首选RabbitMQ（或任何队列技术）的最明显的用例是以下一种：

您有多个使用者从一个队列中消费，并且只要队列中有新消息且有一个可用的使用者，就希望处理此消息。如果仔细观察Kafka的工作方式，您会注意到它不知道如何执行该操作，因为分区扩展，您将有一个专门用于分区的使用者，并且您将陷入饥饿问题。使用简单的队列技术可以轻松避免此问题。您可以考虑使用将从同一分区分派不同消息的线程，但是同样，Kafka没有任何选择性的确认机制。

您最多可以做的就是那些家伙，并尝试将Kafka转换为队列：https : //github.com/softwaremill/kmq

亚尼克

Answer 10

如果您有复杂的路由需求并希望使用内置 GUI 来监控代理，那么 RabbitMQ 可能最适合您的应用程序。否则，如果您正在寻找消息代理来处理高吞吐量并提供对流历史的访问，那么 Kafka 可能是更好的选择。

Answer 11

我能想到的唯一好处是事务功能，其余的都可以通过使用 Kafka 来完成

Answer 12

以分布式容错方式扩展两者都很难，但我认为使用 RabbitMQ 大规模扩展要困难得多。了解 Shovel、Federation、Mirrored Msg Queues、ACK、Mem 问题、容错等并非易事。并不是说 Kafka 上的 Zookeeper 等不会有特定问题，但需要管理的活动部件较少。也就是说，您可以与 RMQ 进行多语言交换，而与 Kafka 则没有。如果你想要流式传输，请使用 Kafka。如果您想要简单的 IoT 或类似的大容量数据包传输，请使用 Kafka。这是关于聪明的消费者。如果您想要 msg 的灵活性和更高的可靠性以及更高的成本和可能的一些复杂性，请使用 RMQ。