在以下情况使用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的公司工作。

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

Kafka和RabbitMQ的5个主要区别:

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

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

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

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

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

To elaborate, take a use case where you need to create a messaging system that has super high throughput for example "likes" in facebook and You have chosen rabbit mq for that. You created an exchange and queue and a consumer where all publishers (in this case FB users) can publish 'likes' messages. Since your throughput is high, you will create multiple threads in consumer to process messages in parallel but you still bounded by the hardware capacity of the machine where consumer is running. Assuming that one consumer is not sufficient to process all messages - what would you do?

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

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

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

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