何时在Kafka上使用RabbitMQ ?

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

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

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

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

RabbitMQ的队列在空时是最快的，而Kafka以很小的开销保留大量数据——Kafka是为保存和分发大量消息而设计的。(如果你打算在RabbitMQ中有很长的队列，你可以看看懒惰的队列。)

Kafka是基于水平扩展(通过增加更多的机器来扩展)而构建的，而RabbitMQ主要是为垂直扩展(通过增加更多的能力来扩展)而设计的。

RabbitMQ有一个内置的用户友好界面，可以让你通过浏览器监控和处理你的RabbitMQ服务器。除此之外，还可以处理队列、连接、通道、交换机、用户和用户权限—在浏览器中创建、删除和列出，并且可以手动监控消息速率和发送/接收消息。Kafka有许多开源工具，还有一些商业工具，提供管理和监控功能。我想说，更好地理解RabbitMQ会更容易/更快。

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

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

一般来说，如果你想要一个用于存储、读取(重读)和分析流数据的框架，可以使用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 as a Service的公司工作。

我每周都听到这个问题。RabbitMQ(类似于IBM MQ或JMS或其他消息传递解决方案)用于传统消息传递，Apache Kafka用作流媒体平台(消息传递+分布式存储+数据处理)。两者都是为不同的用例构建的。

你可以在“传统消息传递”中使用Kafka，但不能在Kafka特定的场景中使用MQ。

文章“Apache Kafka vs.企业服务总线——朋友、敌人还是亦敌亦友? (https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)”讨论了为什么Kafka对集成和消息解决方案(包括RabbitMQ)不是竞争的，而是互补的，以及如何集成两者。

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

以一种分布式容错的方式来扩展两者是很困难的，但我想说的是，在RabbitMQ的大规模中，这要困难得多。理解Shovel、Federation、镜像Msg队列、ACK、Mem问题、容错等并不是一件简单的事情。并不是说你在Kafka上不会有Zookeeper等特定的问题，但有更少的移动部分需要管理。也就是说，你可以和RMQ进行多语言交流，这是你和Kafka做不到的。如果你想要流媒体，使用Kafka。如果你想要简单的物联网或类似的大容量数据包传输，请使用Kafka。这关乎聪明的消费者。如果您想要msg的灵活性和更高的可靠性，但成本更高，可能还有些复杂性，请使用RMQ。

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

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

它是水平可伸缩的，容错的，极快的，并运行 在成千上万的公司生产。

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

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

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

另外，现在有很多开源的和企业级的用户界面来管理Kafka集群。有关更多细节，请参阅我的文章 Apache Kafka集群的UI监控工具概述和为什么Apache Kafka?< / >

应该选择哪个消息传递系统，还是应该更改现有的消息传递系统?​

以上问题没有唯一的答案。当你必须决定哪个消息传递系统或是否应该更改现有系统时，一种可能的检查方法是“评估范围和成本”

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

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

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

卡夫卡:主要是事件源需求，当你可能需要处理流(有时是无限的)，大量的数据在一次适当的平衡，重放偏移以确保给定的状态等等。请记住，这种体系结构也带来了更多的复杂性，因为它确实包含了主题/分区/代理/墓碑消息等头等重要的概念。

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

简单来说，当你更喜欢RabbitMQ(或任何队列技术)而不是Kafka时，最明显的用例是:

您有多个消费者从队列中消费，每当队列中有新消息和可用的消费者时，您希望处理此消息。 如果你仔细观察Kafka的工作原理，你会发现它不知道怎么做，因为分区缩放，你会有一个专用于分区的消费者，你会陷入饥饿的问题。使用简单的队列技术可以很容易地避免这个问题。 你可以考虑使用一个线程来从同一个分区分派不同的消息，但同样，Kafka没有任何选择性的确认机制 你能做的最多的就是像那些家伙一样，试着把Kafka转换成一个队列: https://github.com/softwaremill/kmq < / p >

亚尼克

在以下情况使用RabbitMQ:

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

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

对于etl系统来说，Rabbitmq并不是一个受欢迎的选择，它更适合那些需要简单的消息传递系统和更低吞吐量的系统。

我知道这是一个老问题了，但是在处理数据编校时RabbitMQ可能是一个更好的选择。

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

虽然这两个产品都可以配置为保留(或不保留)消息，但如果CCPA或GDPR合规性是一个问题，我会选择RabbitMQ。

简短的回答是“消息确认”。RabbitMQ可以配置为需要消息确认。如果接收方失败，消息将返回队列，另一个接收方可以再次尝试。虽然你可以用自己的代码在Kafka中完成这个任务，但它可以在RabbitMQ中开箱即用。

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

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

rabbit mq不能做的让kafka与众不同的事情是分布式消息处理。现在读一下得票最多的答案，它会更有意义。

为了详细说明，以一个用例为例，您需要创建一个具有超高吞吐量的消息传递系统，例如“点赞”。在facebook和你已经选择兔mq。您创建了一个交换器、队列和一个消费者，所有发布者(在这里是FB用户)都可以发布“喜欢”消息。由于吞吐量很高，您将在消费者中创建多个线程来并行处理消息，但仍然受到消费者运行的机器的硬件容量的限制。假设一个消费者不足以处理所有消息——您会怎么做?

• 你能再增加一个消费者到队列中吗?不，你不能这样做。
• 你能创建一个新的队列并绑定该队列来交换发布“喜欢”消息吗?答案是不能，因为你会有两次消息处理。

这是卡夫卡解决的核心问题。它允许您创建分布式分区(rabbit mq中的Queue)和相互通信的分布式消费者。这确保主题中的消息由分布在各个节点(Machines)中的使用者处理。

Kafka代理确保消息在该主题的所有分区上实现负载平衡。消费者组确保所有消费者彼此交谈，并且消息不会被处理两次。

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

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

从技术上讲，与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 Developer可以轻松地维护和支持使用Rabbit MQ的应用程序。

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