何时在 Kafka 上使用 RabbitMQ？ [关闭]答案

【问题标题】：When to use RabbitMQ over Kafka? [closed]何时在 Kafka 上使用 RabbitMQ？ [关闭]
【发布时间】：2017-06-28 08:08:02
【问题描述】：

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

【问题讨论】：

主要基于意见，许多好的问题会根据专家经验产生一定程度的意见，但这个问题的答案往往几乎完全基于意见，而不是事实、参考资料或特定专业知识.
@Guillaume 这不一定是真的。 Kafka 有多种语言的客户端：cwiki.apache.org/confluence/display/KAFKA/Clients 此外，Confluent 提供了许多其他语言的高性能开源 Kafka 客户端。查看“Confluent 开源”优惠：confluent.io/product/compare
@MatthiasJ.Sax RabbitMQ 和 kafka 都有很多语言的客户端，但我的意思是关于官方客户端。在您提供的链接中，它是白底黑字：我们正在维护除主代码库外部的 jvm 客户端之外的所有内容。关于 confluent，我确实是一个大用户，但是额外的客户端是通过与语言无关的 rest API 实现的，虽然它的吞吐量与官方 java 客户端不同。
@Guillaume 对于来自社区的“随机”开源客户，我同意；不全是高性能（很难写出一个好的客户端）——这就是为什么我说“这不是必然真的。” ;) 但是，Confluent 提供的 C/C++ 和 Python 客户端具有高吞吐量，并且与 AK Java 客户端一样高效......
我会推荐阅读这个博客：jack-vanlightly.com/blog/2017/12/4/…

标签： apache-kafka rabbitmq message-queue

【解决方案1】：

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

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

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

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

RabbitMQ 的队列在为空时速度最快，而 Kafka 以极少的开销保留大量数据 - Kafka 设计用于保存和分发大量消息。（如果你打算在 RabbitMQ 中排很长的队，你可以看看lazy queues。）

Kafka 从头开始构建时考虑了水平扩展（通过添加更多机器进行扩展），而 RabbitMQ 主要设计用于垂直扩展（通过添加更多功率进行扩展）。

RabbitMQ 具有内置的用户友好界面，可让您从 Web 浏览器监控和处理 RabbitMQ 服务器。除此之外，可以处理队列、连接、通道、交换、用户和用户权限——在浏览器中创建、删除和列出，您可以监控消息速率和手动发送/接收消息。 Kafka 有多个open-source tools, and also some commercial ones，提供管理和监控功能。我想说的是，更好地理解 RabbitMQ 会更容易/更快。

一般来说，如果您想要一个简单/传统的发布-订阅消息代理，显而易见的选择是 RabbitMQ，因为它很可能会比您需要它来扩展更多。如果我的要求足够简单，可以通过通道/队列处理系统通信，并且不需要保留和流式传输，我会选择 RabbitMQ。

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

一般来说，如果您想要一个用于存储、读取（重新读取）和分析流数据的框架，请使用 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 即服务的公司工作。

【讨论】：

“高入口”是什么意思？
high-ingress = 高吞吐量摄取
我质疑你关于 RabbitMQ “主要是为垂直扩展而设计”的观点。怎么会……
水平扩展（通过添加更多机器进行扩展）不会在 RabbitMQ 中为您提供更好的性能。当您进行垂直缩放（通过增加更多功率进行缩放）时，可以获得最佳性能。我知道这一点是因为多年来我一直在使用数千个 RabbitMQ 集群。您可以在 Rabbit 中进行水平扩展，但这意味着您还要在节点之间设置集群，这会减慢您的设置速度。我写了一篇关于 RabbitMQ 中高性能与高可用性最佳实践的指南：cloudamqp.com/blog/2017-12-29-part1-rabbitmq-best-practice.html
"...虽然 Kafka 没有，但它假定消费者会跟踪已消费的内容和未消费的内容。"这是不正确的。 Kafka 会跟踪每个消费者消费的消息。

【解决方案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）以及如何集成两者。

【讨论】：

【解决方案3】：

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

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

以上问题没有一个答案。当您必须决定哪个消息传递系统或应该更改现有系统时，一种可能的审查方法是“Evaluate scope and cost”

【讨论】：

这些信息的来源是哪里？我不同意你关于 RabbitMQ 性能的回答——这取决于队列、连接等的数量。
正确。但平均方差范围与上述相似。在某些情况下，它的表现比上述范围更好或更差。请参阅 Rabbitmq 博客。最新数据点可能已更改rabbitmq.com/blog/2012/04/25/…
@Shishir - 您能否分享更多详细信息/链接来解释不同的消息交换类型 - 直接、扇出、发布/订阅等？这些听起来有助于确定满足给定要求的正确消息传递平台。谢谢
@Shishir 2012 年的链接，可能已经改变，是的。
@AndyDufresne，有点晚了，但这里有一个链接：cloudamqp.com/blog/…

【解决方案4】：

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

【讨论】：

使用RabbitMQ可以实现拉取和推送

【解决方案5】：

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

另一方面，Apache Kafka只是一个消息代理。它最初是由 LinkedIn 设计和实现的，目的是用作消息队列。自 2011 年起，Kafka 开源并迅速演变为分布式流媒体平台，用于实现实时数据管道和流媒体应用。

它具有水平可扩展性、容错性、速度快、运行速度快数以千计的公司生产。

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

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

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

此外，现在有许多用于管理 Kafka 集群的开源和企业级用户界面可用。更多详情参考我的文章Overview of UI monitoring tools for Apache Kafka clusters和Why Apache Kafka?

选择 RabbitMQ 还是 Kafka 取决于您项目的要求。一般来说，如果你想要一个简单/传统的发布-订阅消息代理，那么就选择 RabbitMQ。如果您想构建一个事件驱动的架构，您的组织将在该架构上实时处理事件，那么请选择 Apache Kafka，因为它为这种架构类型提供了更多功能（例如 Kafka Streams 或 ksqlDB）。

【讨论】：

【解决方案6】：

我知道这有点晚了，也许你已经间接地说过了，但同样，Kafka 根本不是一个队列，它是一个日志（正如上面有人所说，基于民意调查）。

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

您有多个消费者从一个队列消费，每当队列中有新消息和可用消费者时，您都希望处理此消息。如果您仔细查看 Kafka 的工作原理，您会发现它不知道如何做到这一点，因为分区扩展，您将有一个专用于分区的消费者，您将陷入饥饿问题。使用简单队列技术可以轻松避免的问题。您可以考虑使用一个线程来调度来自同一分区的不同消息，但同样，Kafka 没有任何选择性确认机制。

你能做的最多的就是像那些人一样尝试将 Kafka 转换为队列： https://github.com/softwaremill/kmq

亚尼克

【讨论】：

【解决方案7】：

在以下情况下使用 RabbitMQ：

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

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

【讨论】：

多订阅者处理得很好，不是在单个队列中，而是分散到多个潜在的动态队列中。 Rabbit 不仅适用于“简单用例”，它适用于完全不同的范式，但其复杂性不亚于需要长期保留的大型数据集。你能扩展消息优先级部分吗？

【解决方案8】：

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

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

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

【讨论】：

【解决方案9】：

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

【讨论】：

[+1] 很好的解释，我相信你在你的项目中一直在使用它们，你能说出一些在安装应用程序消息系统时使用过它们的一些吗？
@GingerHead 我们与一家无线电公司合作，该公司使用 RabbitMQ 作为其 GUI 和易于设置。开发人员可以轻松检查其微服务的状态，这非常棒。同一家公司还将 Kafka 用于需要保留时间超过三天的大容量数据流。如果您有兴趣阅读更多关于这两种技术之间差异的信息，请阅读我写的一篇关于该主题的文章：Kafka vs. RabbitMQ article。

【解决方案10】：

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

【讨论】：

我不同意您如何推断 RMQ 具有“某种复杂性”，就好像说 Kafka 的复杂性较低。

【解决方案11】：

我能想到的唯一好处就是Transactional特性，剩下的都可以用Kafka来完成

【讨论】：

Kafka 有交易

【解决方案12】：

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

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

【讨论】：

【解决方案13】：

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

如果问题是

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

那么答案是

否。

但是，如果问题是

从业务角度来看，Rabbit MQ 是否优于 Kafka？

那么答案是

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

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

依赖 Rabbit MQ 的遗留应用程序的维护
实施 Kafka 所需的员工培训成本和陡峭的学习曲线
Kafka 的基础设施成本高于 Rabbit MQ。
与 Rabbit MQ 实现相比，Kafka 实现中的问题排查困难。
- Rabbit MQ 开发人员可以轻松维护和支持使用 Rabbit MQ 的应用程序。
- 卡夫卡并非如此。仅 Kafka 开发经验不足以维护和支持使用 Kafka 的应用程序。支持人员还需要其他技能，如动物园管理员、网络、磁盘存储。

【讨论】：

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

【讨论】：

【解决方案15】：

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

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

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

【讨论】：

【解决方案16】：

投票最多的答案涵盖了大部分内容，但我想强调用例的观点。 kafka 能做到rabbit mq 能做到的吗，答案是肯定的，但是rabbit mq 能做kafka 做的所有事情，答案是否定的。

rabbit mq 无法让 kafka 与众不同的事情是分布式消息处理。有了这个现在回读投票最多的答案，它会更有意义。

详细来说，举一个用例，您需要创建一个具有超高吞吐量的消息传递系统，例如 facebook 中的“likes”，并且您为此选择了 rabbit mq。您创建了一个交换和队列以及一个消费者，所有发布者（在本例中为 FB 用户）都可以在其中发布“喜欢”消息。由于您的吞吐量很高，您将在消费者中创建多个线程以并行处理消息，但您仍然受到消费者运行机器的硬件容量的限制。假设一个消费者不足以处理所有消息 - 你会怎么做？

您能否再添加一位消费者到队列中 - 不，您不能这样做。
您能否创建一个新队列并将该队列绑定到发布“喜欢”消息的交换机，答案是没有因为您将处理两次消息。

这就是kafka解决的核心问题。它允许您创建分布式分区（rabbit mq 中的队列）和分布式消费者相互交谈。这可确保您在主题中的消息由分布在各个节点（机器）中的消费者处理。

Kafka 代理确保消息在该主题的所有分区中得到负载平衡。消费者组确保所有消费者相互交谈并且消息不会被处理两次。

但在现实生活中，除非你的吞吐量非常高，否则你不会遇到这个问题，因为即使只有一个消费者，rabbit mq 也可以非常快速地处理数据。

【讨论】：

"...你能再添加一个消费者到队列吗 - 不，你不能那样做......"，为什么我们不能添加多个消费者到rabbitmq中的同一个队列？ RabbitMQ 说我们可以here 清楚。消息以循环方式传递给多个消费者。
@SkrewEverything 你绝对可以。整个答案基于一个错误的假设，您不能。
Rabbitmq官网->教程2（工）反驳你