RabbitMQ vs Apache Kafka

在几乎每一个行业中，选择合适的工具来执行基本功能都是一个复杂的决定。对于开发人员来说，有几十种消息服务可供选择。一个常见的问题是使用哪个服务，RabbitMQ还是Apache Kafka。本文将介绍这两个平台的用例和功能，以帮助您做出明智的决策。

抛开每种服务的粉丝们的所有噪音不谈，他们让人们觉得他们的方式是唯一的选择，本文将作为一个基于两种系统的经验和知识的权威答案。本文中分享的见解基于与经验丰富的开发人员的深入讨论，他们有充分的理由选择一种服务而不是另一种服务。

条款

这两个系统都是消息队列，不过Kafka将它们的队列称为日志。为了简化信息以便更好地进行比较，本文将引用这两种服务的队列。Kafka中的消息通常称为记录，但为了简化起见，本文仅引用消息。Kafka还使用topic这个词，它本质上是队列中的分类。主题被划分为包含不能更改的连续记录的分区。

相似之处

RabbitMQ和Kafka都通过队列（主题）在生产者和消费者之间传递消息。消息可以包含任何类型的信息，例如触发其他应用程序上的事件链的简单文本消息。消息传递系统是构建微服务平台、连接不同组件、将工作传递给远程工作者以及实时数据流的理想选择。

这两种消息服务都被认为是成熟的，RabbitMQ从2007年开始上市，Kafka从2011年开始运营。这两种服务的可靠性和可扩展性几乎是平等的，这就是为什么人们经常比较这两种服务。两者之间的区别和您的应用程序的需要是什么决定了什么时候使用哪个服务。

主要区别

与大多数消息传递系统不同，Kafka的队列是持久的。这意味着发送给Kafka的数据将一直存储到特定的时间段或达到大小限制。在这两种情况之一发生之前，即使消息已被消费，它仍会保留在队列中。在Kafka，信息可以重放或消费多次；在不同情况下有用的可调设置。

另一方面，RabbitMQ存储消息，直到接收应用程序连接到队列并接收它。客户端可以在该点或处理完成时确认消息；不管怎样，一旦消息被确认，它就从队列中消失了。

重播还是不重播

可以用Kafka重放消息，这意味着应用程序可以多次读取消息。利用Kafka的信息重放能力应该是谨慎的。例如，多次保存客户订单通常不是一个好主意。另一方面，假设您的消费者有一个bug，需要部署一个更新的版本。此时能够重新处理部分或全部消息是一大好处。

RabbitMQ中的消息不能重放，因为一旦被重放就会被删除ack:ed. 然而，RabbitMQ客户端在处理消息失败时可以对消息进行nack（否定确认）；这在用户端出现临时故障时非常有用。消息将被简单地添加回队列。

协议

RabbitMQ和Kafka之间的另一个区别是协议。虽然RabbitMQ支持几种不同的协议，如AMQP、MQTT、STOMP等，但是Kafka在TCP/IP之上使用了一个定制协议来在应用程序和集群之间进行通信。RabbitMQ在协议方面的多功能性使得它在更多的场景中比Kafka更具优势。

路由

消息路由的复杂性是这两种消息服务之间的另一个区别。虽然RabbitMQ有更复杂的路由方法，但是Kafka非常简单。简单就是好，对吧？不是在这种情况下；RabbitMQ最大的好处之一是它具有路由消息的灵活性。

RabbitMQ有四种不同的消息路由选项-直接、主题、扇出和头交换。直接交换将消息路由到与其路由密钥完全匹配的所有队列。主题允许通过路由密钥进行通配符匹配和精确匹配。Fanout将广播消息交换到绑定到交换的每个队列。头交换使用消息头中的信息和可选值，与主题交换非常相似，但没有路由键。

另一方面，Kafka不支持路由，而是依赖于包含完全不可更改的消息序列的分区。在Kafka streams的帮助下创建自己的动态路由是一个选项，但不是Kafka的默认选项，需要使用使用者组和持久性主题。

优先

在RabbitMQ中，可以将队列设置为具有一系列优先级。根据消息的优先级，它被放置在适当的队列中。

在Kafka中，消息不能按优先级发送，也不能按优先级顺序传递。Kafka中的所有信息都被平等对待，并按接收顺序发送，无论消费者有多忙。

包装

确认-或确认-是两个进程相互发出的信号，表示接收到所发送或处理的消息。RabbitMQ和Kafka都支持生产者确认，以确认消息已安全到达代理。在RabbitMQ中，消息一经发送或被使用者接收就可以被视为已传递。相反，RabbitMQ客户机也可以在消息处理失败时对其进行nack（否定确认），将其返回到队列中，就好像它是新的一样。

Kafka为分区中的每条消息维护一个偏移量，提交的位置是保存的最后一个偏移量。如果进程失败并重新启动，它将恢复到这个偏移量。Kafka中的消费者可以定期或手动提交补偿。在Kafka的不同版本中，这一点是如何被记录的。

排队速度

对于RabbitMQ，当队列为空时，队列的速度达到最大值。Kafka是为容纳大量的信息而设计的，所以空虚不是速度的一个因素。如果您认为您的消费者跟不上发布者的速度，那么在RabbitMQ中启用延迟队列是创建更稳定集群的一个好方法。

缩放比例

RabbitMQ和Kafka都有各自的可伸缩性，使您能够调整使用者的数量、代理的能力，或者根据需要添加更多节点。

消费者

在RabbitMQ中发布的速度比用户执行的快，这可能会导致队列增长到数百万条消息，并最终耗尽内存。在这种情况下，扩展处理消息的使用者的数量是适应这种情况的一种简单方法。RabbitMQ中的每个队列可以有许多使用者，他们都可以竞争使用队列中的消息。

Kafka需要主题分区来更有效地分配使用者，其中组中的每个使用者都专用于一个或多个分区。分区可以设置为发送不同的消息集，具体取决于用户id、位置或其他因素。

缩放代理

Kafka在缩放方面有优势。它的建造考虑到了大规模的扩展。在Kafka中，向集群中添加更多节点或向主题中添加更多分区是扩展的简单方法。在RabbitMQ中，垂直扩展-增加更多的功率-是最简单的扩展方式。因为你能买的机器的体积总是有限制的，Kafka的水平伸缩是一个优势。

但是，这两种消息服务都可以支持每秒较大的消息量，而不会出现任何问题，因为RabbitMQ或Kafka耗尽空间的规模是一种罕见的情况。

日志压缩（Kafka作为数据库）

这在RabbitMQ中并不存在，但却是一个让Kafka脱颖而出的特性。日志压缩确保每个消息键的最后一个已知值保留在单个主题分区的队列中。换句话说，Kafka保留最新版本的消息，删除具有相同密钥的旧版本。

日志压缩可以确保最新的信息立即可用，例如，如果我们正在显示数千个正在运行的集群中的一个集群的最新状态。不是每次都存储集群是否响应，而是只存储最终状态。

监测

RabbitMQ的接口允许从web浏览器监视和处理服务器，包括队列、连接、通道、交换、用户、权限等，可以在接口中创建、删除和列出。虽然有开源和商业工具可用于监视和管理Kafka，但它们是分开的。请在此处查找有关可用工具的更多信息。

推/拉

在RabbitMQ中，消息被推送到使用者，使得预取限制配置成为必要，以防止使用者被太多的消息淹没。从RabbitMQ提取消息是可能的，但不建议这样做。Kafka使用pull模型，消费者从偏移量批量请求消息。

许可证

RabbitMQ和Kafka都是免费的开源软件许可证。Kafka组件（如Rest代理、模式注册表和KSL）包含在另一个名为Confluent Community license的许可证中，该许可证仍然允许免费下载、修改和重新分发，但不允许任何人提供软件即服务（SaaS）产品。如果Kafka再次将许可证更改为更严格的许可证，那么RabbitMQ将具有易于被另一个AMQP代理替换的优势，而Kafka则没有这种优势。

复杂性

与我们合作的开发人员认为Kafka的体系结构更复杂，因为它包含了更多的概念，如主题、分区和消息偏移。熟悉消费者群体和处理补偿是与Kafka合作的先决条件。特别是，故障处理是使用Kafka的一个复杂问题，它需要更多的时间，而且比RabbitMQ更复杂。

生态系统

Kafka不仅仅是一个代理——它是一个流媒体平台，有许多不同的工具，可以在主平台之外集成。这些工具包括Kafka Core、Kafka Streams、Kafka Connect、Kafka REST Proxy和Schema Registry。这些附加工具大多来自Confluent，它不是Apache的一部分。

这些工具的好处是可以在编写任何代码之前配置一个庞大的系统。在Kafka Connect中，将其他数据源与Kafka集成可以快速方便地扩展处理和存储能力。Kafka REST proxy增加了从集群接收元数据的可能性，并通过简单的restapi生成或消费消息，这一特性很容易从集群控制面板启用。

用例

在所有关于每个系统能做什么或不能做什么的信息之后，下面是一些在客户使用RabbitMQ和Kafka的真实体验之后编写的用例，以及他们为什么选择一个而不是另一个。

用例-RabbitMQ

RabbitMQ有两个主要的使用案例：长时间运行的任务和微服务应用程序之间的集成。但是，一般来说，RabbitMQ是一个简单而传统的pub/sub消息代理。它的可扩展性将超过大多数系统的要求，而且安装后很容易立即使用。RabbitMQ对于需求简单的系统和不需要保留和流的系统也是一个不错的选择。

长时间运行的任务

消息队列本质上是对数据的异步处理，这意味着它们允许将消息放置在队列中，而无需立即处理它。这种情况的一个例子是图像缩放服务，它允许用户在网站上上传图像，目的是缩放图像并通过电子邮件将其发送回用户。处理数亿用户的基于事件的微服务体系结构非常适合RabbitMQ。

应用程序之间的集成

像MapQuest这样的服务每月支持2310万独特的移动用户，它依靠RabbitMQ来支持分布在多个队列中的主题。作为应用程序之间通信的中间人，RabbitMQ使系统能够在来回传递消息时避免瓶颈。

用例-Apache Kafka

存储、读取、重读和分析流数据的完美框架是Kafka的最佳选择。被审计或需要永久存储消息的系统是Kafka的家。

分析、跟踪、摄取、记录、安全

在所有这些场景中，必须收集、存储和处理大量数据。需要提供搜索功能、分析或审计大量数据的平台对Kafka的性能完全满意。追溯到Kafka的根源，它最初是用来跟踪网站的活动，如页面浏览、上传和其他用户操作。

使用Kafka，生产者将数据发送到一个地方，然后由一系列后端服务根据需要使用这些数据。主要的数据分析系统和存储/搜索系统将其功能与卡夫卡相结合。

实时处理

Kafka系统的高吞吐能力将数据流推送到目标服务中，这些服务实时地将数据通过。Spotify和Rabobank等发布服务使用Kafka的实时服务发布信息。高吞吐量和实时性结合在一起，构成了一个强大的日志、度量等应用程序。