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)。

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

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

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(类似于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:

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

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