Apache Kafka is a popular choice for powering data pipelines. Apache kafka added kafka stream to support popular etl use cases. KSQL makes it simple to transform data within the pipeline, readying messages to cleanly land in another system. KSQL is the streaming SQL engine for Apache Kafka. It provides an easy-to-use yet powerful interactive SQL interface for stream processing on Kafka, without the need to write code in a programming language such as Java or Python. KSQL is scalable, elastic, fault-tolerant, and real-time. It supports a wide range of streaming operations, including data filtering, transformations, aggregations, joins, windowing, and sessionization.

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

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

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

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

我知道有点晚了，也许你已经间接地说过了，但是，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

雅尼克

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

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

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

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

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