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

Question

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

Answer 1

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

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

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

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）—朋友，敌人还是Frenemies？（https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/）”讨论了Kafka为何不具有竞争力而是对集成的补充和补充。消息传递解决方案（包括RabbitMQ）以及如何将两者集成。

Answer 3

Kafka和RabbitMQ（使用它们的客户）之间的

5个主要差异：

要选择哪个消息传递系统，还是我们应该更改现有的消息传递系统？

以上问题没有答案。在您必须决定哪个邮件系统或应该更改现有系统时，一种可能的查看方法是“ Evaluate scope and cost​”

Answer 4

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

---

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

  

它是水平可伸缩的，容错的，快速的，可在   在数千家公司中进行生产。

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

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

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

此外，现在还有许多用于管理Kafka集群的开源和企业级用户界面。有关更多详细信息，请参见my answer to this question。

---

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

Answer 5

在以下情况下使用RabbitMQ：

• 您不必处理Bigdata，而是希望使用方便的内置UI进行监控
• 不需要自动复制队列
• 消息没有多位订阅者-与作为日志的Kafka不同，RabbitMQ是一个队列，消息一旦被消耗并收到确认即被删除
• 如果您要求对消息使用通配符和正则表达式
• 如果定义消息优先级很重要

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

Answer 6

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

Answer 7

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

Answer 8

投票最多的答案涵盖了大部分内容，但我想突出用例的观点。卡夫卡能做到兔子mq可以做到的吗，答案是肯定的，但兔子mq能做卡夫卡能做到的一切，答案是否定的。因此，rabbit mq无法做的事情就是使kafka脱颖而出，那就是分布式消息处理。现在，用此方法读回投票最多的答案，它将变得更有意义。详细说来，以一个用例为例，您需要创建一个具有超高吞吐量的消息传递系统，例如Facebook中的“喜欢”，并且您为此选择了Rabbit MQ。您创建了一个交换和队列以及一个使用者，所有发布者（在这种情况下为FB用户）都可以在其中发布“喜欢”消息。由于您的吞吐量很高，因此您将在使用者中创建多个线程以并行处理消息，但是仍然受使用者运行所在计算机的硬件容量的限制。假设一个使用者不足以处理所有消息-您会怎么做？您可以再增加一个消费者排队吗-不，您不能那样做。您可以创建一个新队列并将其绑定到要发布“喜欢”消息的交换队列吗？没有答案，因为您将对消息进行两次处理。这是卡夫卡解决的核心问题。它使您可以创建相互交谈的分布式分区（在Rabbit mq中为Queue）和分布式使用者。这样可以确保您主题中的消息得到分发给各个节点（机器）的使用者的处理。 Kafka代理确保消息在该主题的所有分区之间达到负载均衡。消费者组确保所有消费者彼此交谈，并且消息不会被处理两次。但是在现实生活中，除非您的吞吐量非常高，否则您将不会遇到这个问题，因为Rabbit mq甚至可以在一个用户的情况下也非常快速地处理数据。

Answer 9

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

Answer 10

我将根据我在这两个方面的经验提供客观的答案，并且假设您已经知道和/或其他答案已经提供足够的知识，我还将跳过其背后的理论。

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

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

Answer 11

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

为简单起见，与Kafka相比，您更喜欢RabbitMQ（或任何队列技术）时最明显的用例是：

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

您最能做的就是像那些家伙一样，尝试将Kafka变成一个队列： https://github.com/softwaremill/kmq

Yannick

Answer 12

从技术上讲，与Rabbit MQ提供的功能集相比，Kafka提供了巨大的功能集。

---

如果问题是

Rabbit MQ在技术上是否优于Kafka？

那么答案是

否。

---

但是，如果问题是

从业务角度看，Rabbit MQ是否比Kafka更好？

然后，答案是

在某些业务场景中可能为“是”

---

从业务角度来看，Rabbit MQ可以比Kafka更好，原因如下：

1. 依赖于Rabbit MQ的旧应用程序的维护

2. 实施Kafka所需的员工培训成本和陡峭的学习曲线

3. Kafka的基础设施成本高于Rabbit MQ。

4. 与Rabbit MQ实现相比，对Kafka实现中的问题进行疑难解答。

   • Rabbit MQ开发人员可以轻松维护和支持使用Rabbit MQ的应用程序。

   • Kafka并非如此。 仅开发Kafka的经验不足以维护和支持使用Kafka的应用程序。 支持人员还需要其他技能，例如动物园管理员，网络，磁盘存储。

Answer 13

以分布式容错的方式扩展两者都很困难，但我想证明，使用RabbitMQ进行大规模扩展要困难得多。了解铲子，联合身份验证，镜像消息队列，ACK，内存问题，故障收费等并不是一件容易的事。并不是说您在Kafka上的Zookeeper等也不会遇到特定的问题，但是需要管理的活动部件更少。也就是说，您可以通过RMQ获得Polyglot交换，而与Kafka则没有。如果要流式传输，请使用Kafka。如果您想要简单的物联网或类似的大容量数据包交付，请使用Kafka。这是关于聪明的消费者。如果您希望msg灵活性，更高的可靠性，更高的成本以及某些复杂性，请使用RMQ。

Answer 14

Apache Kafka是为数据管道供电的流行选择。 Apache kafka添加了kafka流以支持流行的etl用例。通过KSQL，可以很轻松地在管道中转换数据，从而使消息可以干净地降落在另一个系统中。 KSQL是Apache Kafka的流SQL引擎。它提供了一个易于使用但功能强大的交互式SQL界面，用于在Kafka上进行流处理，而无需使用Java或Python之类的编程语言编写代码。 KSQL具有可伸缩性，弹性，容错性和实时性。它支持广泛的流操作，包括数据过滤，转换，聚合，联接，窗口和会话化。

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

Rabbitmq在etl系统中不是一个流行的选择，而是在那些需要简单的消息传递系统且吞吐量较小的系统中。

Answer 15

我意识到这是一个古老的问题，但是在处理数据编辑时，RabbitMQ可能是更好的选择的一种情况。

使用RabbitMQ，默认情况下，一旦使用完消息，便将其删除。使用Kafka，默认情况下，邮件会保留一周。通常将其设置为更长的时间，甚至永不删除它们。

虽然可以将这两种产品都配置为保留（或不保留）消息，但是如果要关注CCPA或GDPR，我会选择RabbitMQ。

Answer 16

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

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