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

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

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

根据我的经验，如果你有一个需要查询信息流的应用程序，Kafka和KSql是你最好的选择。如果你想要一个排队系统，你最好使用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)不是竞争的，而是互补的，以及如何将两者集成。

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.

我知道这是一个老问题了，但是在处理数据编校时RabbitMQ可能是一个更好的选择。

在RabbitMQ中，默认情况下，一旦消息被消费，它就会被删除。在Kafka中，默认情况下，消息保存一周。通常将这个时间设置为更长的时间，甚至永远不删除它们。

虽然这两个产品都可以配置为保留(或不保留)消息，但如果CCPA或GDPR合规性是一个问题，我会选择RabbitMQ。