在以下情况使用RabbitMQ:

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

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

我每周都听到这个问题。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。

我将根据我的经验提供一个客观的答案，我也将跳过它们背后的理论，假设你已经知道它和/或其他答案已经提供了足够的答案。

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

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

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

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

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

在以下情况使用RabbitMQ:

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

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