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

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

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

我能想到的唯一好处是事务性功能，其余的都可以用Kafka来完成

你们忘记的一个关键区别是RabbitMQ是基于推的消息系统，而Kafka是基于拉的消息系统。这在消息传递系统必须满足具有不同处理能力的不同类型的消费者的场景中非常重要。使用基于Pull的系统，消费者可以根据自己的能力消费，而推送系统将推送消息，而不管消费者的状态如何，从而将消费者置于高风险之中。

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

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

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

在以下情况使用RabbitMQ:

你不需要处理大数据，你更喜欢一个方便的内置UI来监控 不需要自动复制队列 消息没有多个订阅者——因为不像Kafka是一个日志，RabbitMQ是一个队列，消息一旦被消费和确认到达就会被删除 如果您有要求使用通配符和正则表达式的消息 如果定义消息优先级很重要

简而言之: RabbitMQ适用于简单的用例，数据流量低，具有优先级队列和灵活的路由选项。 对于海量数据和高吞吐量使用Kafka。