我究竟该如何选 vs RabbitMQ Kafka

引见

作为一名有着少量微服务系统处置阅历的软件架构师，我经常遇到一个不时重复的疑问：“我应该经常使用 RabbitMQ 还是 Kafka？”出于某种要素，许多开发人员以为这些技术是可以调换的。只管在某些状况下确实如此，但 RabbitMQ 还是 Kafka 之间存在基本上的差异。

因此，不同的场景须要不同的处置打算，选用失误的打算会重大影响咱们的软件开发设计以及后续保养软件。

本文的目的首先是引见基本的异步信息传递形式。而后继续引见 RabbitMQ 和 Kafka 及其外部结构。第 2 局部重点引见了这些平台之间的关键区别、它们的各种好处和缺陷，以及如何在两者之间启动选用。

异步信息传递形式

异步信息传递是一种信息传递打算，其中消费者的信息生成与消费者的信息处置分别。在信息传递系统中，咱们通常会分为两种重要的信息传递形式：队列形式和发布/订阅形式。

队列形式

在队列形式中，队列暂时将消费者与消费者解耦。多个消费者可以向同一个队列发送信息。而后当消费者处置信息时，信息会被锁定而后从队列中删除，并且不再可用。

附带说明一下，假设消费者无法处置某个信息，信息平台通常会将信息前往到队列，以供其余消费者经常使用。除了解耦之外，队列还准许咱们裁减消费者和消费者，并针对失误处置提供容错才干。

发布/订阅形式

在发布/订阅形式中，单个信息可以由多个订阅者同时接纳和处置。

例如，此形式准许发布者通知一切订阅者系统中出现了某些状况。在 RabbitMQ 中，主题是一种特定类型的 pub/sub 成功（确切地说是一种替换类型），但在本文中，我将主题称为整个 pub/sub 的示意。

普通来说，订阅有两种类型：

RabbitMQ 是信息代理的一种成功 — 通常称为服务总线。它自身支持上述两种信息传递形式。信息代理的其余盛行成功包含 ActiveMQ、ZeroMQ、Azure 服务总线和 Amazon Simple Queue Service (SQS)。一切这些成功都有很多共同点，本文中形容的许多概念实用于其中的大少数。

RabbitMQ 支持开箱即用的经典信息队列。开发人员定义命名队列，而后发布者可以将信息发送到该命名队列。反上来，消费者经常使用相反的队列来检索信息来处置它们。

Message exchanges

RabbitMQ 经过经常使用信息替换机来成功 pub/sub。发布者将其信息发布到信息替换机，不用知道这些信息的订阅者是谁。

每个订阅替换机的消费者都会创立一个队列，而后信息替换机将生成的信息排队以供消费者经常使用。它还可以依据各种路由规定过滤某些订阅者的信息。

值得留意的是，RabbitMQ 支持暂时订阅和耐久订阅。消费者可以经过 RabbitMQ 的 API 选择他们想要经常使用的订阅类型。

因为 RabbitMQ 的架构，咱们还可以创立一种混合方法，其中一些订阅者构成消费者组，这些消费者组以特定队列上竞争消费者的方式共同处置信息。经过这种方式，咱们成功了发布/订阅形式，同时还准许一些订阅者裁减以处置接纳到的信息。

发布/订阅和队列相联合

Apache Kafka

Apache Kafka 是一个散布式流处置平台。

与基于队列和替换的 RabbitMQ 不同，Kafka 的存储层是经常使用分区事务日志成功的。Kafka 还提供了 Streams API 来实时处置流，以及 Connectors API 来轻松与各种数据源集成。不过，这些超出了本文的范围。

云服务商为 Kafka 的存储层提供了代替处置打算。这些处置打算包含 Azure 事情核心，在某种水平上还包含 AWS Kinesis>

消费者经过保养这些分区的偏移量（或索引）并按顺序读取它们来消费信息。

单个消费者可以经常使用多个主题，并且消费者可以裁减，直至与可用分区数量分歧。

因此，在创立主题时，应细心思考该主题的信息传递的预期吞吐量。共同消费某个主题的一组消费者称为消费者组。Kafka 的 API 通常担任消费者组中消费者之间分区处置的平衡以及消费者分区偏移量的存储。

经常使用 Kafka 成功信息传递

Kafka 的外部成功其实很好地反映了 pub/sub 形式。

消费者可以向特定主题发送信息，多个消费者组可以消费同一条信息。每个消费者组都可以独自裁减以处置负载。因为消费者保养其分区偏移量，因此他们可以选用耐久订阅（在从新启动时维持其偏移量）或暂时订阅（即摈弃偏移量并在每次启动时从每个分区中的最新记载从新启动）。

Kafka 其实是不太适宜队列形式的信息传递。当然咱们可以创立一个只要一个消费者组的主题来模拟经典的信息队列。但这有多个缺陷，在本文第 2 局部咱们将详细探讨。

值得留意的是，无论消费者能否消费了这些信息，Kafka 都会将信息保管在分区中直至预先性能的时期段内。这种保管象征着消费者可以自在地重读过去的信息。此外，开发人员还可以经常使用 Kafka 的存储层来成功事情溯源和审计日志等机制。

完结语

只管 RabbitMQ 和 Kafka 有时可以调换，但它们的成功却一模一样。因此，咱们不能将它们视为同一类别工具的成员。一个是信息代理，另一个是散布式流平台。

作为处置打算架构师，咱们应该意识到这些差异，并踊跃思考针对给定场景应经常使用哪些类型的处置打算。