RabbitMQ和Kafka,两种消息队列架构的对比

RabbitMQ和Kafka,两种消息队列架构的对比

出于业务需要,我们对不同的消息队列框架进行了选择和评估,在几个佼佼者中,最终确定了RabbitMQ与Apache Kafka作为候选对象。这两个框架各有其显著的优势和特点,因此,我们在做最后的选择时不得不做出综合的考虑与取舍。在越来越多的服务需要相互通信的分布式环境中,RabbitMQ和Kafka都已成为通信的流行方案。

我们认为这次选择是一个很好的机会,让我们重新审视RabbitMQ和Kafka的变化方式,检查它们的优势是否已经改变,并了解它们如何适应当今的用例。尽管这两种解决方案在架构上采用了截然不同的方法并可以解决非常不同的问题,但是许多人发现自己正在将它们进行比较以找到重叠的解决方案。希望我们的对比和选择,能给其他用户提供一些有用的参考。

RabbitMQ和Apache Kafka是什么

对于要在二者择其一的用户来说,这不是一个问题,但为了进一步比较,还是先简要介绍一番。RabbitMQ通常被概括为“开源分布式消息代理”。用Erlang编写,它有助于在复杂的路由方案中有效地传递消息。它最初是基于流行的AMQP协议构建的,而且还与现有技术高度兼容,而其功能可以通过服务器上启用的插件进行扩展。可以分发RabbitMQ代理并将其配置为在网络或服务器出现故障时可靠。

另一方面,Apache Kafka被描述为“分布式事件流平台”。与其关注于灵活的路由,不如说是促进了原始吞吐量。Kafka用Scala和Java编写,基于“分布式仅追加日志”的思想,该消息将消息写入持久化到磁盘的日志末尾,客户端可以选择从该日志开始读取的位置。同样,Kafka群集可以在多个服务器之间分布和群集,以提高可用性。

RabbitMQ 与 Kafka的对比

尽管它们不是同一服务,但是许多人通常在进行消息队列解决方案选择时,像我们一样最后在这两者之间纠结,想知道它们中的哪一种更好。在对比之后,我们认为这不是一个正确的问题。相反,我们希望能专注于每种服务的优势,分析它们之间的差异,然后确定两种最适合的用例。在这两种框架的功能之外,还应该考虑开发的复杂性和所需的技能。

需求和用例

最初,RabbitMQ和Kafka之间在设计上存在明显的差异,因此,用例也有所差异。RabbitMQ的消息代理设计在具有特定路由需求和按消息保证的用例中表现出色,而Kafka的仅附加日志允许开发人员访问流历史记录和更直接的流处理。尽管这两种技术可以满足的应用场景非常接近,但在某些情况下,一种显然比另一种更好。

但是,目前正在进行的工作将改变这种平衡。RabbitMQ将继续提供其传统的队列模型,同时还将引入一种新的数据结构,该模型以无损的使用语义为仅附加日志建模。这种新的数据结构将像Kafka的持久日志一样工作,并且对于希望扩展其流使用案例的RabbitMQ用户而言,这是一个令人兴奋的方向。尽管此功能将与AMQP协议兼容,但它还将引入基于二进制的流协议。因此,在一定程度上,RabbitMQ的“Kafka”化倾向更为激进。

开发人员经验

两种服务的开发者经验在很大程度上保持不变,由于各自社区的工作,客户端和库保持持续增长。双方的RabbitMQ的和Kafka的客户端库列表增长速度相对接近。随着越来越多的语言和框架变得越来越流行,为任何一种服务找到一个受良好支持的完整库变得越来越容易。

要注意的一件事是Kafka Streams的增长,它是一种客户端库实现,使开发人员可以更轻松地处理流数据。它用于从Kafka读取数据,对其进行处理并将其写入另一个队列的常见用例。此外,ksqlDB非常适合希望利用其对关系数据库的熟悉程度并希望构建流应用程序的开发人员进行检查。

RabbitMQ可以借助Spring Cloud Data Flow等其他组件来完成类似的工作。此外,请注意上一节中提到的RabbitMQ即将进行的流媒体开发,这可以为开发人员打开与RabbitMQ进行交互的新方式。

安全与运营

RabbitMQ附带了一个有用的管理界面来管理用户和队列,而Kafka则依赖于TLS和JAAS。当然,选择RabbitMQ还是Kafka取决于特定要求和用例,但是大多数安全方案都可以成熟应用于这两者。

重要的是要注意Kubernetes在过去几年中的兴起及其对服务运营的影响。为了使基础架构运营商能够在Kubernetes上同时运行RabbitMQ和Kafka,已经进行了大量工作。这使得配置和集群化它们都非常容易地启动和运行。

性能

软件框架的性能有时可能难以量化,因为存在的变量太多,包括服务的配置方式,代码与之交互的方式以及运行的硬件。从网络到内存和磁盘速度,一切都可能极大地影响服务的性能。当然,RabbitMQ和Kafka都针对性能进行了优化,但是您还应确保用例利用它们来最大化效率。

对于RabbitMQ,有一些很棒的how-to资源可用于最大程度地提高性能,例如如何对集群进行基准测试和调整大小。这些指南详细介绍了有关如何配置集群以及代码应如何与集群交互以实现最佳性能的最佳实践。这些建议大部分围绕管理队列大小和连接,以及注意客户端如何使用消息等内容。该RabbitMQ的集群指南还包括建设东西群集时要牢记。

同样,Confluent有一份出色的《生产中的运行Kafka运行指南》,其中涵盖了与构建运行Kafka集群的硬件时以及配置集群本身的方式时相同的许多问题。由于Kafka在JVM之上运行,因此您需要牢记一些事情来避免出错。

如果您对原始数据感兴趣,RabbitMQ团队和Confluent团队最近都发布了各自的基准。两者都包含许多有关如何配置群集以及群集上工作负载的详细信息,因此请确保在读取结果时将这些信息考虑在内。用例和操作也应大大影响您的决策。

结论

决定使用RabbitMQ还是Kafka从来都不是一件容易的事,而且随着这两种技术的日新月异,优势和差别可能会越来越小。您做出的决定可能更取决于具体的应用场景。对我们来说,工业物联网的条件下,使用RabbitMQ可能是更好的选择。

作者
魏智勇(John)
加入讨论

此站点使用 Akismet 来减少垃圾评论。了解我们如何处理您的评论数据

魏智勇(John)

站长,80后,创业者,擅长工业自动化与信息化技术,熟悉各种PLC,组态软件,熟悉计算机技术,熟悉LabVIEW、C,C#,JavaScript程序设计技术。

%d 博主赞过: