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并不是一个受欢迎的选择，它更适合那些需要简单的消息传递系统和更低吞吐量的系统。

Kafka和RabbitMQ的5个主要区别:

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

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

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.

投票最多的答案涵盖了大部分内容，但我想强调用例的观点。卡夫卡能做兔子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(类似于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可以配置为需要消息确认。如果接收方失败，消息将返回队列，另一个接收方可以再次尝试。虽然你可以用自己的代码在Kafka中完成这个任务，但它可以在RabbitMQ中开箱即用。

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