有没有理由使用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） - 朋友，敌人或敌人？ （https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/）“讨论为什么Kafka没有竞争力但是对集成和消息传递解决方案（包括RabbitMQ）的补充以及如何集成两者。

Answer 3

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

选择哪种邮件系统或者我们应该更改现有的邮件系统？

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

Answer 4

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

---

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

它具有水平可扩展性，容错性，快速性，并在数千家公司的生产中运行。

现代组织拥有各种数据管道，便于系统或服务之间的通信。当合理数量的服务需要实时相互通信时，事情会变得复杂一些。

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

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

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

---

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

Answer 5

我能想到的唯一好处是交易功能，休息都可以通过使用Kafka来完成

Answer 6

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

Answer 7

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

RabbitMQ：如果我的要求很简单，通过频道/队列来处理系统通信，我会选择这个，保留和流媒体不是必需的。对于例如当制造系统构建资产时，它确实通知协议系统配置合同等。

Kafka：事件采购要求主要是，当您可能需要处理流（有时是无限的），大量数据一次适当平衡，重放偏移以确保给定状态等等。请记住，这种体系结构也带来了更多的复杂性，因为它确实包含诸如主题/分区/代理/逻辑删除消息等概念作为第一类重要性。

Answer 8

我知道它有点晚了，也许你已经间接说过了，但是卡夫卡根本就不是一个队列，它是一个日志（就像上面有人说的那样，基于民意调查）。

为简单起见，当您更喜欢使用RabbitMQ（或任何队列技术）而不是Kafka时，最明显的用例如下：

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

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

雅尼克

Answer 9

在分布式容错方式下扩展两者都很难，但是我会假设使用RabbitMQ进行大规模扩展要困难得多。理解Shovel，联盟，镜像消息队列，ACK，Mem问题，容错等并不是一件轻而易举的事。并不是说你在Kafka上也不会有与Zookeeper等有关的具体问题，但是要管理的移动部分较少。也就是说，你得到了与RMQ的Polyglot交换，而你没有Kafka。如果你想要流媒体，请使用Kafka。如果您想要简单的物联网或类似的高容量数据包传输，请使用Kafka。这是关于聪明的消费者。如果您希望msg灵活性和更高的可靠性以及更高的成本和可能的复杂性，请使用RMQ。