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(类似于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是一个可靠的通用消息代理，支持多种协议，如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的公司工作。

Kafka和RabbitMQ的5个主要区别:

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

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

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

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