在以下情况使用RabbitMQ:

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

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

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

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

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

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

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

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

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

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

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.