如果你问自己是否Apache Kafka比RabbitMQ更好或RabbitMQ是否比Apache Kafka更可靠，我想在这里阻止你。本文将从更广泛的角度讨论这两种情况。它关注的是这两个系统提供的功能，并将指导您做出正确的决定，决定何时使用哪个系统。

web上的一些文章让Apache Kafka在RabbitMQ面前大出风头，而另一些文章则恰恰相反。我们中的很多人可能会因为听了大肆宣传，跟着人群跑而认罪。我觉得重要的是要知道是使用RabbitMQ还是Kafka取决于您项目的需求，只有当您在合适的场景中使用了正确的设置，才能进行真正的比较。

我和84codes在业界工作了很长时间，通过服务CloudAMQP为RabbitMQ提供托管解决方案，通过服务CloudKarafka为Apache Kafka提供托管解决方案。由于我已经看到了CloudAMQP和CloudKarafka用户的许多用例和不同的应用程序设置，我觉得我可以根据我的经验，在RabbitMQ和Apache Kafka上权威地回答用例问题。

在本文中，我的任务是根据多年来开发人员与开发人员之间的许多交谈来分享自己的见解，并试图传达他们关于为什么选择特定的message broker服务而不是其他服务的想法。

本文中使用的术语包括:

消息队列在RabbitMQ中是一个队列，而这个“队列”在Kafka中被称为日志，但是为了简化本文中的信息，我将一直使用队列而不是切换到“日志”。

卡夫卡的信息通常被称为记录，但是，为了简化这里的信息，我将再次提到信息。

当我在Kafka中撰写一个主题时，您可以把它看作是消息队列中的一个分类。卡夫卡主题被分成若干分区，这些分区以不变的顺序包含记录。

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

这种系统非常适合于连接不同的组件、构建微服务、实时数据流或将工作传递给远程工作者。

根据Confluent的数据，超过三分之一的财富500强公司使用Apache Kafka。各种大型行业也依赖于RabbitMQ，如Zalando、WeWork、Wunderlist和Bloomberg。

最大的问题;什么时候使用Kafka，什么时候使用RabbitMQ?

不久前，我在Stackoverflow上写了一个答案来回答这个问题，“有任何理由使用RabbitMQ而不是Kafka吗?”答案只有几行字，但它已经被证明是一个许多人发现有用的答案。

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

关于“成熟”一词;RabbitMQ在市场上出现的时间比Kafka(分别是2007年和2011年)要长。RabbitMQ和Kafka都是“成熟的”，这意味着它们都被认为是可靠的、可扩展的消息传递系统。

消息处理(消息重放)

这是他们之间的主要区别;与大多数消息传递系统不同，Kafka中的消息队列是持久的。发送的数据将一直存储到经过指定的保留期(一段时间或一个大小限制)为止。消息将一直停留在队列中，直到超过保留期/大小限制，这意味着消息被使用后不会被删除。相反，它可以被重放或多次使用，这是一个可以调整的设置。

在RabbitMQ中，消息被存储起来，直到接收应用程序连接并接收到队列外的消息。客户端可以在接收到消息或在完全处理完消息后ack(确认)消息。在任何一种情况下，一旦消息被处理，它就会从队列中删除。

如果您在Kafka中使用重播，请确保您使用它的方式和原因是正确的。将一个事件重复播放多次，而这个事件应该只发生一次;例如，如果您碰巧多次保存客户订单，在大多数使用场景中并不理想。当用户中存在需要部署新版本的bug，并且需要重新处理部分或全部消息时，重播就会派上用场了。

协议

我还提到了“RabbitMQ支持一些标准化协议，如AMQP, MQTT, STOMP等”，其中它本机实现AMQP 0.9.1。使用标准化消息协议允许您将RabbitMQ代理替换为任何基于AMQP的代理。

Kafka在TCP/IP之上使用自定义协议在应用程序和集群之间进行通信。Kafka不能被简单地移除和替换，因为它是唯一实现这个协议的软件。

RabbitMQ支持不同协议的能力意味着它可以在许多不同的场景中使用。

AMQP的最新版本与官方支持的0.9.1版本有很大不同。RabbitMQ不太可能偏离AMQP 0.9.1。该协议的1.0版本于2011年10月30日发布，但尚未获得开发人员的广泛支持。AMQP 1.0可通过插件使用。

路由

答案的下一部分是关于路由的，我写道:“Kafka有一个非常简单的路由方法。如果你需要以复杂的方式将消息传递给用户，RabbitMQ有更好的选择。”

RabbitMQ的主要优点是能够灵活地路由消息。直接或基于正则表达式的路由允许消息到达特定队列，而无需附加代码。RabbitMQ有四种不同的路由选择:直接、主题、扇出和头交换。直接交换路由消息到所有队列，这些队列与所谓的路由密钥完全匹配。扇形交换器可以向绑定到该交换器的每个队列广播一条消息。topics方法类似于direct，因为它使用一个路由键，但是允许通配符匹配和精确匹配。有关不同交换类型的更多信息可以在这里找到。

Kafka不支持路由;Kafka主题被划分为多个分区，这些分区以不变的顺序包含消息。您可以使用消费者组和持久主题来替代RabbitMQ中的路由，在该路由中，您将所有消息发送到一个主题，但让您的消费者组从不同的偏移量订阅。

您可以在Kafka streams的帮助下自己创建动态路由，即动态地将事件路由到主题，但这不是默认特性。

消息优先级

RabbitMQ支持所谓的优先队列，这意味着队列可以被设置为具有一系列优先级。可以在发布消息时设置每个消息的优先级。根据消息的优先级，它被放置在适当的优先级队列中。那么，什么时候可以使用优先队列呢?下面是一个简单的示例:我们每天都在为托管的数据库服务ElephantSQL运行数据库备份。数以千计的备份事件被无序地添加到RabbitMQ中。客户还可以按需触发备份，如果发生这种情况，我将一个新的备份事件添加到队列中，但具有更高的优先级。

在卡夫卡中，消息不能以优先级发送，也不能按优先级顺序发送。无论客户端有多忙，Kafka中的所有消息都按照接收它们的顺序存储和发送。

确认(提交或确认)

“确认”是在通信进程之间传递的信号，表示确认。，接收发送或处理的信息。

Kafka和RabbitMQ都支持生产者确认(RabbitMQ中的发布者确认)，以确保发布的消息已安全到达代理。

当节点向使用者传递消息时，它必须决定是否应将该消息视为由使用者处理(或至少是接收)。客户端可以在接收到消息时或在客户端完全处理完消息后进行ack。

RabbitMQ可以考虑发送出去的消息，也可以等待使用者在收到消息后手动确认。

Kafka为分区中的每条消息维护一个偏移量。提交的位置是保存的最后一个偏移量。如果进程失败并重新启动，这是它将恢复到的偏移量吗?Kafka中的使用者既可以定期地自动提交偏移量，也可以选择手动控制提交的位置。

在不同版本的Apache Kafka中，Kafka是如何记录哪些被使用了，哪些没有被使用的。在早期版本中，使用者跟踪偏移量。

当RabbitMQ客户端不能处理消息时，它也可以nack(否定确认)消息。消息将被返回到它来自的队列中，就像它是一个新消息一样;这在客户端出现临时故障时非常有用。

如何处理队列?

RabbitMQ的队列在空的时候是最快的，而Kafka被设计用来保存和分发大量的消息。Kafka用很少的开销保留大量的数据。

尝试RabbitMQ的人可能没有意识到惰性队列的特性。惰性队列是将消息自动存储到磁盘的队列，从而最大限度地减少RAM的使用，但延长了吞吐量时间。根据我们的经验，惰性队列创建了更稳定的集群，具有更好的预测性能。如果你要一次发送很多消息(例如处理批处理任务)，或者你认为你的用户跟不上发布者的速度，我们建议你启用惰性队列。

扩展

扩展是指增加或减少系统容量的过程。RabbitMQ和Kafka可以以不同的方式伸缩，你可以调整消费者的数量，代理的能力或者向系统中添加更多的节点。

消费者扩展

如果发布速度更快，那么就可以使用RabbitMQ，那么队列将开始增长，最终可能会产生数百万条消息，最终导致RabbitMQ耗尽内存。在这种情况下，您可以扩展处理(消费)您的消息的消费者数量。RabbitMQ中的每个队列可以有许多使用者，而这些使用者都可以“竞争”使用来自队列的消息。消息处理分布在所有活动的使用者中，因此在RabbitMQ中通过简单地添加和删除使用者就可以实现上下伸缩。

在Kafka中，分配使用者的方法是使用主题分区，其中组中的每个使用者专用于一个或多个分区。您可以使用分区机制按业务键(例如，按用户id、位置等)向每个分区发送不同的消息集。

扩展代理

我在stackoverflow的回答中写道;“Kafka是基于水平扩展(添加更多机器)的想法而建立的，而RabbitMQ主要是为垂直扩展(添加更多功能)而设计的。”答案的这一部分是提供有关运行Kafka或RabbitMQ的机器的信息。

在RabbitMQ中，水平伸缩并不总是提供更好的性能。通过垂直扩展(添加更多Power)可以获得最佳性能级别。在RabbitMQ中可以进行水平伸缩，但这意味着必须在节点之间建立集群，这可能会降低设置的速度。

在Kafka中，您可以通过向集群添加更多节点或向主题添加更多分区来扩展。这有时比像在RabbitMQ中那样在现有的机器中添加CPU或内存更容易。

许多人和博客，包括Confluent，都在谈论Kafka在缩放方面有多棒。当然，卡夫卡可以比RabbitMQ扩展得更远，因为对于你能买到的机器的强度总是有限制的。但是，在这种情况下，我们需要记住使用代理的原因。你可能有一个Kafka和RabbitMQ都可以支持的消息量，而没有任何问题，我们大多数人不会处理RabbitMQ耗尽空间的规模。

日志压缩

值得一提的是，在Apache Kafka中，RabbitMQ中不存在的一个特性是日志压缩策略。日志压缩确保Kafka始终保留单个主题分区队列中每个消息键的最后已知值。Kafka只是简单地保留消息的最新版本，并用相同的密钥删除旧版本。

日志压缩可以看作是使用Kafka作为数据库的一种方式。您可以将保留期设置为“永久”，或者对某个主题启用日志压缩，这样数据就会永久存储。

使用日志压缩的一个示例是，在数千个正在运行的集群中显示一个集群的最新状态。我们存储最终状态，而不是存储集群是否一直在响应。可以立即获得最新信息，比如队列中当前有多少条消息。

监控

RabbitMQ有一个用户友好的界面，让你监控和处理你的RabbitMQ服务器从一个网络浏览器。除了其他功能外，队列、连接、通道、交换器、用户和用户权限可以在浏览器中处理(创建、删除和列出)，并且可以手动监控消息率和发送/接收消息。

对于Kafka，我们有很多用于监控的开源工具，也有一些商业工具，提供管理和监控功能。有关Kafka的不同监视工具的信息可以在这里找到。

推或拉

消息从RabbitMQ推送到使用者。配置预取限制以防止令使用者不堪重负(如果消息到达队列的速度比使用者处理它们的速度快)是很重要的。消费者也可以从RabbitMQ获取消息，但不推荐这样做。另一方面，Kafka使用拉取模型，如前所述，消费者从给定的偏移量请求一批消息。

许可证

RabbitMQ最初由Rabbit Technologies Ltd公司创建。该项目于2013年5月成为Pivotal Software的一部分。RabbitMQ的源代码是在Mozilla公共许可下发布的。牌照从未更改(截至2019年11月)。

Kafka最初是由LinkedIn创建的。2011年，它被授予开源地位，并移交给了Apache基金会。Apache Kafka受Apache 2.0许可证的保护。一些经常与Kafka组合使用的组件由另一个名为Confluent Community许可证所涵盖，例如Rest Proxy、Schema Registry和KSL。这个许可证仍然允许人们免费下载、修改和重新分发代码(非常像Apache 2.0所做的)，但是它不允许任何人以SaaS的形式提供软件。

这两个许可证都是免费和开源软件许可证。如果Kafka再一次将许可证更改为更严格的东西，这就是RabbitMQ的优势所在，因为它可以很容易地被另一个AMQP经纪人取代，而Kafka不能。

复杂性

就我个人而言，我认为开始使用RabbitMQ更容易，并且发现它很容易使用。正如我们的一位客户所说;

“我们没有花任何时间学习RabbitMQ，它工作了很多年。在DoorDash的高速增长期间，它无疑降低了大量的运营成本。”Zhaobang Liu Doordash

在我看来，Kafka的架构带来了更多的复杂性，因为它从一开始就包含了更多的概念，比如主题/分区/消息偏移量等等。你必须熟悉消费者群体以及如何处理抵消。

作为Kafka和RabbitMQ操作符，我们觉得在Kafka中处理失败有点复杂。恢复或修复某些东西的过程通常更耗费时间，也更麻烦一些。

卡夫卡的生态系统

Kafka不仅仅是一个经纪人，它是一个流媒体平台，还有很多工具可以在主发行版之外很容易地与Kafka集成。Kafka生态系统由Kafka核心、Kafka流、Kafka连接、Kafka REST代理和模式注册表组成。请注意，Kafka生态系统的大多数附加工具都来自于Confluent，而不是Apache的一部分。

所有这些工具的好处是，您可以在需要编写一行代码之前配置一个巨大的系统。

Kafka Connect让您集成其他系统与Kafka。您可以添加一个数据源，允许您使用来自该数据源的数据并将其存储在Kafka中，或者相反，将主题中的所有数据发送到另一个系统进行处理或存储。使用Kafka Connect有很多可能性，而且很容易上手，因为已经有很多可用的连接器。

Kafka REST代理让您有机会从集群接收元数据，并通过简单的REST API生成和使用消息。可以从集群的控制面板轻松启用该特性。

常见用例——RabbitMQ vs Apache Kafka

关于一个系统能做什么或不能做什么，有很多信息。下面是两个主要用例，描述了我和我们的许多客户是如何考虑和决定使用哪个系统的。当然，我们也看到过这样的情况:客户在构建一个系统时，应该使用一个系统，而不是另一个系统。

RabbitMQ的用例

一般来说，如果您想要一个简单/传统的发布-订阅消息代理，那么RabbitMQ是一个明显的选择，因为它的规模很可能比您所需要的更大。如果我的需求足够简单，可以通过通道/队列来处理系统通信，并且不需要保留和流，我就会选择RabbitMQ。

我选择RabbitMQ主要有两种情况;对于长时间运行的任务，当我需要运行可靠的后台作业时。以及应用程序内部和应用程序之间的通信和集成。e作为微服务之间的中间人，系统只需通知系统的另一部分开始处理一项任务，比如在网上商店的订单处理(下订单、更新订单状态、发送订单、付款等)。

长时间运行的任务

消息队列支持异步处理，这意味着它们允许您在不立即处理消息的情况下将消息放入队列。RabbitMQ非常适合长时间运行的任务。

在我们的RabbitMQ初学者指南中可以找到一个例子，它遵循一个经典的场景，即一个web应用程序允许用户上传信息到一个web站点。该网站将处理这些信息，生成PDF，并通过电子邮件发送给用户。完成本例中的任务需要几秒钟，这就是为什么要使用消息队列的原因之一。

我们的许多客户让RabbitMQ队列充当事件总线，使web服务器能够快速响应请求，而不是被迫当场执行计算密集型任务。

以Softonic为例，他们https://www.cloudamqp.com/blog/2019-01-18 softonic-userstoryy-rabbitmq-eventbasedcommunication.html在一个每月支持1亿用户的基于事件的微服务体系结构中使用了RabbitMQ。

微服务架构中的中间人

RabbitMQ也被许多客户用于微服务体系结构，作为应用程序之间通信的一种方式，避免了传递消息的瓶颈。

例如，您可以阅读Parkster(一个数字停车服务)如何使用RabbitMQ将一个系统分解为多个微服务。

MapQuest是一个大方向服务，每月支持2310万独立移动用户。地图更新被发布到组织和公司的个人设备和软件上。这里，RabbitMQ主题分布在适当数量的队列上。数千万用户通过该框架接收到准确的企业级地图信息。

Apache Kafka的用例

通常，如果您需要一个用于存储、读取(重复读取)和分析流数据的框架，请使用Apache Kafka。它非常适合被审计的系统或需要永久存储消息的系统。这些也可以分解为两个主要用例，用于分析数据(跟踪、摄取、日志记录、安全等)或实时处理。

数据分析:跟踪、摄入、日志记录、安全

在所有这些情况下，需要收集、存储和处理大量的数据。需要洞察数据、提供搜索功能、审计或分析大量数据的公司证明使用Kafka是合理的。

据Apache Kafka的创建者说，Kafka最初的用例是跟踪网站活动，包括页面浏览、搜索、上传或用户可能采取的其他行动。这种类型的活动跟踪通常需要非常高的吞吐量，因为会为每个操作和每个用户生成消息。许多这些活动——实际上是所有的系统活动——都可以存储在Kafka中并根据需要进行处理。

数据生产者只需要将数据发送到单个位置，而后端服务主机可以根据需要使用数据。主要的分析、搜索和存储系统都与Kafka集成。

Kafka可以用来将大量的信息流传输到存储系统中，而且这些天硬盘空间的花费并不大。

实时处理

Kafka作为一个高吞吐量分布式系统;源服务将数据流推入目标服务，目标服务实时拉出数据流。

卡夫卡可以在系统处理许多生产者实时与少数消费者;例如，财务IT系统监控股票数据。

从Spotify到荷兰合作银行的流媒体服务通过Kafka实时发布信息。实时处理高吞吐量的能力增强了应用程序的能力。，使得这些应用程序比以往任何时候都更强大。

CloudAMQP在服务器设置的自动化过程中使用了RabbitMQ，但我们在发布日志和指标时使用了Kafka。

 

	RabbitMQ	Apache Kafka
是什么	RabbitMQ是一种可靠、成熟、通用的消息代理	Apache Kafka是一种为高接入数据流和重放而优化的消息总线
主要用途	用于应用程序内部和应用程序之间通信和集成的消息队列。用于长时间运行的任务，或需要运行可靠的后台作业时。	用于存储、读取(重复读取)和分析流数据的框架。
许可证	开放源码:Mozilla公共许可证	开放源码:Apache License 2.0
Written in	Erlang	Scala (JVM)
第一个版 本发布	2007	2011
持久性	持久化消息，直到在确认接收时丢弃它们为止	在保留期结束后保留带有要删除选项的消息
重播	No	Yes
路由	支持可将信息返回到使用者节点的灵活路由	不支持灵活的路由，必须通过单独的主题来完成
消息优先级	Supported	Not supported
监控	可通过内置UI使用	可以通过第三方工具使用，比如部署在CloudKarafka或通过Confluent
语言支持	支持大多数语言	支持大多数语言
安全认证	支持标准认证和OAuth2	支持Kerberos、OAuth2和标准身份验证

 

原文：https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

本文：http://jiagoushi.pro/node/1187

讨论：请加入知识星球【首席架构师圈】或者加小号【jiagoushi_pro】或者QQ群【11107777】