在以下情况使用RabbitMQ:

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

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

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

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

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

In order to understand how to read data from Kafka, we first need to understand its consumers and consumer groups. Partitions allow you to parallelize a topic by splitting the data across multiple nodes. Each record in a partition is assigned and identified by its unique offset. This offset points to the record in a partition. In the latest version of Kafka, Kafka maintains a numerical offset for each record in a partition. A consumer in Kafka can either automatically commit offsets periodically, or it can choose to control this committed position manually. RabbitMQ will keep all states about consumed/acknowledged/unacknowledged messages. I find Kafka more complex to understand than the case of RabbitMQ, where the message is simply removed from the queue once it's acked.

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

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

RabbitMQ has a built-in user-friendly interface that lets you monitor and handle your RabbitMQ server from a web browser. Among other things, queues, connections, channels, exchanges, users and user permissions can be handled - created, deleted and listed in the browser and you can monitor message rates and send/receive messages manually. Kafka has a number of open-source tools, and also some commercial ones, offering the administration and monitoring functionalities. I would say that it's easier/gets faster to get a good understanding of 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的公司工作。

Scaling both is hard in a distributed fault tolerant way but I'd make a case that it's much harder at massive scale with RabbitMQ. It's not trivial to understand Shovel, Federation, Mirrored Msg Queues, ACK, Mem issues, Fault tollerance etc. Not to say you won't also have specific issues with Zookeeper etc on Kafka but there are less moving parts to manage. That said, you get a Polyglot exchange with RMQ which you don't with Kafka. If you want streaming, use Kafka. If you want simple IoT or similar high volume packet delivery, use Kafka. It's about smart consumers. If you want msg flexibility and higher reliability with higher costs and possibly some complexity, use RMQ.

我每周都听到这个问题。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)不是竞争的，而是互补的，以及如何将两者集成。

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

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

它具有水平可扩展性、容错性、极快的速度和可磨合性 在数千家公司生产。

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

The architecture becomes complex since various integrations are required in order to enable the inter-communication of these services. More precisely, for an architecture that encompasses m source and n target services, n x m distinct integrations need to be written. Also, every integration comes with a different specification, meaning that one might require a different protocol (HTTP, TCP, JDBC, etc.) or a different data representation (Binary, Apache Avro, JSON, etc.), making things even more challenging. Furthermore, source services might address increased load from connections that could potentially impact latency.

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

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

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

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

如果问题是

Rabbit MQ技术上比Kafka更好吗?

那么答案是

No.

但是，如果问题是

从业务角度看Rabbit MQ比Kafka好吗?

那么，答案是

在某些商业场景中，可能是“Yes”

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

Maintenance of legacy applications that depend on Rabbit MQ Staff training cost and steep learning curve required for implementing Kafka Infrastructure cost for Kafka is higher than that for Rabbit MQ. Troubleshooting problems in Kafka implementation is difficult when compared to that in Rabbit MQ implementation. A Rabbit MQ Developer can easily maintain and support applications that use Rabbit MQ. The same is not true with Kafka. Experience with just Kafka development is not sufficient to maintain and support applications that use Kafka. The support personnel require other skills like zoo-keeper, networking, disk storage too.