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

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

Kafka和RabbitMQ的5个主要区别:

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

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

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是一种传统的通用消息代理。它使web服务器能够快速响应请求，并将消息传递到多个服务。发布者能够发布消息并使其可用于队列，以便消费者可以检索它们。通信可以是异步的，也可以是同步的。

另一方面，Apache Kafka不仅仅是一个消息代理。它最初是由LinkedIn设计和实现的，用于作为消息队列。自2011年以来，Kafka已经开源，并迅速发展成为一个分布式流媒体平台，用于实现实时数据管道和流媒体应用程序。

它具有水平可扩展性、容错性、极快的速度和可磨合性 在数千家公司生产。

现代组织有各种各样的数据管道来促进系统或服务之间的通信。当相当数量的服务需要实时相互通信时，事情就变得有点复杂了。

The architecture becomes complex since various integrations are required in order to enable the inter-communication of these services. More precisely, for an architecture that encompasses m source and n target services, n x m distinct integrations need to be written. Also, every integration comes with a different specification, meaning that one might require a different protocol (HTTP, TCP, JDBC, etc.) or a different data representation (Binary, Apache Avro, JSON, etc.), making things even more challenging. Furthermore, source services might address increased load from connections that could potentially impact latency.

通过解耦数据管道，Apache Kafka带来了更简单、更易管理的体系结构。Kafka充当了一个高吞吐量的分布式系统，源服务在其中推送数据流，使它们可供目标服务实时提取。

另外，现在有很多开源的和企业级的用户界面来管理Kafka集群。有关更多详细信息，请参阅我的文章Apache Kafka集群的UI监控工具概述和为什么Apache Kafka?

使用RabbitMQ还是Kafka取决于项目的需求。一般来说，如果你想要一个简单的/传统的发布-订阅消息代理，那么选择RabbitMQ。如果你想构建一个事件驱动的体系结构，在此基础上你的组织将实时处理事件，那么选择Apache Kafka，因为它为这种体系结构类型提供了更多的功能(例如Kafka Streams或ksqlDB)。

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

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