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

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

从技术上讲，与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.

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

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

You have multiple consumers consuming from a queue and whenever there is a new message in the queue and an available consumer, you want this message to be processed. If you look closely at how Kafka works, you'll notice it does not know how to do that, because of partition scaling, you'll have a consumer dedicated to a partition and you'll get into starvation issue. Issue that is easily avoided by using simple queue techno. You can think of using a thread that will dispatch the different messages from same partition, but again, Kafka does not have any selective acknowledgment mechanisms.

你能做的最多的就是像那些家伙一样，试着把Kafka转换成一个队列: https://github.com/softwaremill/kmq

雅尼克

投票最多的答案涵盖了大部分内容，但我想强调用例的观点。卡夫卡能做兔子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也可以非常快地处理数据。

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

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的公司工作。