我知道现在有点晚了，也许你已经间接地说了，但再说一遍，Kafka根本不是一个队列，它是一个日志（正如上面有人说的，基于民意调查）。
为了简单起见，当您更喜欢rabbitmq（或任何队列技术）而不是kafka时，最明显的用例如下：
您有多个使用者正在从队列中消费，每当队列中有新消息和可用使用者时，您都希望处理此消息。如果仔细观察kafka是如何工作的，您会发现它不知道如何做到这一点，因为分区扩展，您将有一个专门用于分区的使用者，您将陷入饥饿问题。容易避免的问题

我每周都听到这个问题。。。rabbitmq（如ibm mq或jms或其他消息传递解决方案）用于传统消息传递，apache kafka用作流平台（消息传递+分布式存储+数据处理）。两者都是为不同的用例而构建的。
您可以将kafka用于“传统消息传递”，但不能将mq用于kafka特定的场景。
文章“ApacheKafka与企业服务总线（esb）-朋友、敌人还是朋友(https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)“讨论为什么kafka不是竞争对手，而是集成和消息传递解决方案（包括rabbitmq）的补充，以及如何将两者集成。

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

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

rabbitmq是一个可靠的通用消息代理，支持多种协议，如amqp、mqtt、stomp等，它可以处理高吞吐量。rabbitmq的一个常见用例是处理后台作业或长时间运行的任务，例如文件扫描、图像缩放或pdf转换。rabbitmq也用于微服务之间，它作为应用程序之间通信的一种手段，避免了传递消息的瓶颈。
kafka是一种消息总线，它针对高吞吐量的数据流摄取和重放进行了优化。当您需要移动大量数据、实时处理数据或分析一段时间内的数据时，请使用kafka。换句话说，就是需要收集、存储和处理数据的地方。一个例子是，当你想跟踪一个网店上的用户活动，并生成建议购买的项目。另一个例子是用于跟踪、摄取、记录或安全的数据分析。
kafka可以看作是一个持久的消息代理，应用程序可以在其中处理和重新处理磁盘上的流数据。Kafka有一个非常简单的路由方法。如果需要以复杂的方式将消息路由到用户，rabbitmq有更好的选择。如果需要支持可能脱机的批处理使用者或希望以低延迟接收消息的使用者，请使用kafka。 
为了理解如何读取Kafka的数据，我们首先需要了解它的消费者和消费群体。分区允许您通过在多个节点上拆分数据来并行化主题。分区中的每个记录都由其唯一的偏移量分配和标识。这个偏移量指向分区中的记录。在最新版本的kafka中，kafka为分区中的每条记录维护一个数字偏移量。kafka中的使用者可以定期自动提交偏移量，也可以选择手动控制提交的位置。rabbitmq将保留有关已使用/已确认/未确认消息的所有状态。我发现kafka比rabbitmq的情况更难理解，rabbitmq的情况是消息一旦确认就从队列中删除。
rabbitmq的队列是空的时最快的，而kafka以很少的开销保留大量数据-kafka是为保存和分发大量消息而设计的(如果您计划在rabbitmq中使用很长的队列，您可以查看惰性队列。）
kafka是从头开始构建的，考虑到了水平缩放（通过添加更多的机器来缩放），而rabbitmq主要是为垂直缩放而设计的（通过添加更多的功率来缩放）。
rabbitmq有一个内置的用户友好界面，允许您从web浏览器监视和处理rabbitmq服务器。除此之外，还可以处理队列、连接、通道、交换、用户和用户权限—在浏览器中创建、删除和列出，并且您可以监视邮件速率和手动发送/接收邮件。kafka有许多开源工具，也有一些商业工具，提供管理和监控功能。我想说，更好地理解rabbitmq会更容易/更快。
一般来说，如果您想要一个简单/传统的pub-sub消息代理，那么明显的选择是rabbitmq，因为它很可能比您需要它来扩展的规模更大。如果我的需求足够简单，可以通过通道/队列处理系统通信，并且不需要保留和流式传输，那么我会选择rabbitmq。
我选择rabbitmq主要有两种情况；对于长时间运行的任务，当我需要运行可靠的后台作业时。以及应用程序内部和应用程序之间的通信和集成，即作为微服务之间的中间人；一个系统只需要通知系统的另一部分就可以开始处理一个任务，比如在webshop中处理订单（下单、更新订单状态、发送订单、付款等）。
一般来说，如果您想要一个用于存储、读取（重读）和分析流数据的框架，请使用apachekafka。它非常适合被审计的系统或需要永久存储消息的系统。这些还可以分解为两个主要用例，用于分析数据（跟踪、摄取、日志记录、安全性等）或实时处理。
更多阅读、用例和一些比较数据可以在这里找到：https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html
还推荐行业论文：“kafka与rabbitmq：两种行业参考发布/订阅实现的比较研究”：http://dl.acm.org/citation.cfm?id=3093908
我在一家同时提供ApacheKafka和rabbitmq服务的公司工作。

你们忘了的一个关键区别是rabbitmq是基于推的消息传递系统，而kafka是基于拉的消息传递系统。在消息传递系统必须满足具有不同处理能力的不同类型的使用者的场景中，这一点非常重要。使用基于pull的系统，消费者可以根据自己的能力进行消费，而推送系统将推送消息，而不考虑消费者的状态，从而使消费者处于高风险中。

rabbitmq是一种传统的通用消息代理。它使web服务器能够快速响应请求并向多个服务传递消息。发布者能够发布消息并将其提供给队列，以便消费者能够检索它们。通信可以是异步的，也可以是同步的。
另一方面，apachekafka不仅仅是一个消息代理。它最初是由linkedin设计和实现的，目的是充当消息队列。自2011年以来，kafka一直是开源的，并迅速发展成为一个分布式流媒体平台，用于实现实时数据管道和流媒体应用程序。
它具有横向可扩展性、容错性和快速性，并在数千家公司的生产中运行。
现代组织有各种各样的数据管道来促进系统或服务之间的通信。当一个合理数量的服务需要彼此实时通信时，事情就变得更加复杂了。
体系结构变得复杂，因为需要各种集成来实现这些服务的交互通信。更准确地说，对于包含m个源服务和n个目标服务的体系结构，需要编写n x m个不同的集成。而且，每个集成都有不同的规范，这意味着可能需要不同的协议（http、tcp、jdbc等）或不同的数据表示（binary、apacheavro、json等），使事情变得更具挑战性。此外，源服务可能会处理可能影响延迟的连接增加的负载。
apachekafka通过解耦数据管道，实现了更简单、更易管理的体系结构。kafka充当了一个高吞吐量的分布式系统，其中源服务推送数据流，使它们可供目标服务实时拉取。
另外，现在有很多用于管理kafka集群的开源和企业级用户界面可用。有关更多详细信息，请参阅我的文章ApacheKafka集群ui监视工具概述以及为什么选择ApacheKafka？
选择rabbitmq还是kafka取决于项目的需求。一般来说，如果您想要一个简单/传统的pub-sub消息代理，那么可以使用rabbitmq。如果您想构建一个事件驱动的体系结构，您的组织将在该体系结构之上实时处理事件，那么可以使用apachekafka，因为它为这种体系结构类型提供了更多功能（例如kafka streams或ksqldb）。