是否有理由在Kafka上使用RabbitMQ？

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

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

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

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

为了了解如何从Kafka中读取数据，我们首先需要了解其消费者和消费者群体。分区使您可以通过将数据拆分到多个节点来并行化主题。分区中的每个记录均由其唯一偏移量分配和标识。此偏移量指向分区中的记录。在最新版本的Kafka中，Kafka为分区中的每个记录维护一个数字偏移量。Kafka中的使用者可以定期自动提交偏移，也可以选择手动控制此提交的位置。RabbitMQ将保留有关已消费/已确认/未确认的消息的所有状态。我发现Kafka的理解比RabbitMQ的理解更为复杂，RabbitMQ的消息一旦被确认，就从队列中删除。

RabbitMQ的队列在空时最快，而Kafka则以很少的开销保留了大量数据-Kafka旨在容纳和分发大量消息。（如果您计划在RabbitMQ中有很长的队列，则可以看看惰性队列。）

Kafka是从头开始构建的，考虑到了水平缩放（通过添加更多机器来缩放），而RabbitMQ主要是针对垂直缩放（通过增加更多功率来缩放）而设计的。

RabbitMQ具有内置的用户友好界面，可让您从Web浏览器监视和处理RabbitMQ服务器。队列，连接，通道，交换，用户和用户权限等可以在浏览器中处理，创建，删除和列出，您可以监视消息速率并手动发送/接收消息。Kafka有许多开源工具，也有一些商业工具，提供管理和监视功能。我想说，更好地了解RabbitMQ会更容易/变得更快。

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

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

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

我每周都会听到这个问题……当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/）”讨论了为什么卡夫卡是没有竞争力的，但互补，整合和信息解决方案（包括RabbitMQ）以及如何将两者集成。

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

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

上述问题没有答案。一种可能的方法来审核时，你必须决定哪些邮件系统，还是你应该改变现有的制度是“ 评估范围和成本 ”

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

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或ksqlDB）。

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

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

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

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

亚尼克

在以下情况下使用RabbitMQ：

• 您不必处理Bigdata，而是希望使用方便的内置UI进行监视
• 无需自动复制队列
• 消息没有多订阅者-因为与Kafka不同，RabbitMQ是一个队列，并且与队列不同，RabbitMQ在使用和确认到达后即被删除
• 如果您有使用通配符和正则表达式发送邮件的要求
• 如果定义消息优先级很重要

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

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

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

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

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

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

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

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系统的流行选择，而是那些需要简单的消息传递系统且吞吐量较低的系统。

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

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

虽然可以将两种产品都配置为保留（或不保留）消息，但是如果您担心CCPA或GDPR符合性，我会选择RabbitMQ。

在吞吐量，持久性，延迟方面，Kafka优于RabbitMQ。如果您期望每秒少于10k的事务，那么可以使用RabbitMQ，但这也取决于您的实现。

我已经在我们的产品中实现了Kafka，该产品可以处理超过70k / sec的事务，并且延迟平均为15ms，几乎没有尖峰达到40ms。主题大小为100kb。

PFB提供有关KAFKA和RabbitMQ的更多数据点：Apache Kafka包含代理本身，而代理本身是最知名和最受欢迎的部分，并且已针对流处理方案进行了设计和突出的销售。除此之外，Apache Kafka最近还添加了Kafka Streams，它将自身定位为Apache Spark，Apache Flink，Apache Beam / Google Cloud Data Flow和Spring Cloud Data Flow等流媒体平台的替代产品。该文档很好地讨论了诸如网站活动跟踪，指标，日志聚合，流处理，事件来源和提交日志之类的流行用例。它描述的那些用例之一是消息传递，它可能会引起一些混乱。因此，让我们对其进行一些解压缩，并弄清哪种消息传递方案最适合Kafka，例如：

从A到B的流没有复杂的路由，具有最大吞吐量（100k / sec +），并按分区顺序至少传送了一次。当您的应用程序需要访问流历史记录时，以分区顺序传送至少一次。Kafka是一个持久的消息存储库，与传统的消息代理相反，Kafka是一种持久的消息存储，可以按需重播事件流，而传统的消息代理将消息一旦发送就从队列中删除。流处理事件源RabbitMQ是一种通用的消息传递解决方案，通常用于允许Web服务器快速响应请求，而不是在用户等待结果时被迫执行占用大量资源的过程。这对于将消息分发给多个收件人以供消费或在高负载（20k + / sec）下平衡工作人员之间的负载也非常有用。当您的需求超出吞吐量时，RabbitMQ提供了很多功能：可靠交付，路由，联合，HA，安全性，管理工具和其他功能的功能。让我们研究一些最适合RabbitMQ的方案：

您的应用程序需要使用现有协议（例如AMQP 0-9-1，STOMP，MQTT和AMQP 1.0）的任何组合。您需要基于每个消息（死信队列等）进行更细粒度的一致性控制/保证。但是，Kafka最近增加了对事务的更好支持。您的应用程序需要点对点，请求/回复以及发布/订阅消息传递方面的多样性，并具有复杂的到消费者的路由，将多个服务/应用程序与非平凡的路由逻辑集成在一起，RabbitMQ还可以有效地解决上述几种Kafka的强大用例，但是附加软件的帮助。当应用程序需要访问流历史记录时，RabbitMQ通常与Apache Cassandra一起使用，对于需要“无限”队列的应用程序，则通常与LevelDB插件一起使用，但是RabbitMQ本身都不提供任何功能。

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

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

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