什么时候用RabbitMQ 什么时候用Apache Kafka？

什么时候用RabbitMQ 什么时候用Apache Kafka？

如果您要问自己Apache Kafka是否比RabbitMQ更好，或者RabbitMQ是否比Apache Kafka更可靠，那么我想在这里停下来。 本文将从更广泛的角度讨论这两个方面。 它着重于两个系统提供的功能，并将指导您就何时使用哪个系统做出正确的决定。

网络上的某些文章使Apache Kafka在RabbitMQ面前大放异彩，而其他文章则相反。 我觉得知道是否要使用RabbitMQ或Kafka的决定取决于您的项目需求是很重要的，只有在合适的情况下将它们与正确的设置一起使用时，才能进行真正的比较。

84codes和我从事该行业已有很长时间了，他们通过CloudAMQP服务为RabbitMQ提供了托管解决方案，并通过CloudKarafka服务为Apache Kafka提供了托管解决方案。 由于我已经看到CloudAMQP和CloudKarafka用户如此多的用例和不同的应用程序设置，因此我觉得我可以根据自己的经验在RabbitMQ和Apache Kafka上权威地回答用例问题。

在本文中，我的任务是基于我多年来的许多开发人员到开发人员的聊天中分享见解，并试图传达他们对为什么选择其他特定消息代理服务的想法。

本文使用的术语包括：

• 消息队列是RabbitMQ中的队列（queue），Kafka中的“队列（queue）”被称为日志（log），但是为了简化本文中的信息，我将引用队列，而不是一直切换到“日志”。
• kafka中的一条消息通常被称为一条记录（record），但是同样，我将引用消息以简化此处的信息。
• 当我在Kafka中撰写主题（topic）时，您可以将其视为消息队列中的一种分类。 Kafka主题分为多个分区，每个分区包含不可更改顺序的记录。

两种系统通过队列（queue）或主题（topic）在生产者和消费者之间传递消息。 一条消息可以包含任何种类的信息。 例如，它可以具有有关网站上发生的事件的信息，也可以是触发另一个应用程序上的事件的简单文本消息。

这种系统是连接不同组件，构建微服务，实时数据流（real-time streaming）或将工作传递给远程工作者时的理想选择。

据Confluent称，世界500强公司中有超过三分之一的公司使用Apache Kafka。 Zalando，WeWork，Wunderlist和Bloomberg等各种大型行业也都依赖RabbitMQ。

大问题； 何时使用Kafka，何时使用RabbitMQ？

不久前，我在Stackoverflow上写了一个答案，以回答“是否有理由使用RabbitMQ替换Kafka？”。 答案只有几行，但事实证明，这是许多人发现有用的答案。

我将尝试将答案分解为子答案，并尝试解释每个部分。 首先，我写道-“ RabbitMQ是可靠，成熟的通用消息代理，它支持多种协议，例如AMQP，MQTT，STOMP等。 RabbitMQ可以处理高吞吐量。 它的一个常见用例是处理后台作业或充当微服务之间的消息代理。 Kafka是一种消息总线，针对高输入量数据流和重放进行了优化。 Kafka可以看作是持久的消息代理，应用程序可以在其中处理和重新处理磁盘上的流数据。”

关于“成熟”一词； RabbitMQ在市场上的销售时间仅比Kafka更长（分别为2007年和2011年）。 RabbitMQ和Kafka都是“成熟的”，这意味着它们都被认为是可靠且可扩展的消息传递系统。

消息处理（消息重播）

这是它们之间的主要区别；

与大多数消息系统不同，Kafka中的消息队列是持久的。 发送的数据将被存储，直到经过指定的保留期限（一段时间或大小限制）为止。 该消息会一直保留在队列中，直到超过保留期限/大小限制为止，这意味着该消息一旦被使用就不会被删除。 而是可以多次播放或使用它，该设置可以调整。

在RabbitMQ中，消息一直存储到接收应用程序连接并从队列接收消息为止。 客户端可以在收到消息或完全处理完消息后对其进行确认（确认）。 无论哪种情况，一旦消息被确认，就会从队列中删除。

如果您在Kafka中使用重放，请确保以正确的方式和正确的原因使用重放。 重播在有些时候确实很方便，比如你部署的新版本消费者有bug，你需要处理一些或全部的消息的时候。

协议

我还提到“ RabbitMQ支持多种标准化协议，