Apache ActiveMQ vs. Kafka – Apache ActiveMQ vs. Kafka

1. Overview

1.概述

In distributed architectures, applications usually need to exchange data among themselves. On the one hand, this can be done by communicating directly with each other. On the other hand, to reach high availability and partition tolerance, and to get loose coupling between applications, messaging is an appropriate solution.

在分布式架构中，应用程序通常需要在它们之间交换数据。一方面，这可以通过彼此之间的直接通信来实现。另一方面，为了达到高可用性和分区容忍度，以及在应用程序之间获得松散的耦合，消息传递是一个合适的解决方案。

Therefore, we can choose between multiple products. The Apache Foundation provides ActiveMQ and Kafka, which we’ll compare with each other in this article.

因此，我们可以在多个产品中进行选择。Apache基金会提供了ActiveMQ和Kafka，我们将在本文中对它们进行比较。

2. General Facts

2.一般事实

2.1. Active MQ

2.1.活动的MQ

Active MQ is one of the traditional message brokers, whose goal is to ensure data exchange between applications in a safe and reliable way. It deals with a small amount of data and is therefore specialized for well-defined message formats and transactional messaging.

Active MQ是传统的消息代理之一，其目标是确保应用程序之间以安全可靠的方式进行数据交换。它处理的数据量很小，因此专门用于定义明确的消息格式和事务性消息传递。

We must note that there’s another edition besides this “classic” one: Active MQ Artemis. This next-generation broker is based on HornetQ, whose code was made available to the Apache Foundation by RedHat in 2015. On the Active MQ website, it is said that:

我们必须注意到，除了这个 “经典 “版本，还有另一个版本。Active MQ Artemis。这个下一代代理基于HornetQ，其代码在2015年由RedHat提供给Apache基金会。在Active MQ网站上，据说。

Once Artemis reaches a sufficient level of feature parity with the “Classic” code-base it will become the next major version of ActiveMQ.

一旦Artemis与 “经典 “代码库的功能达到足够水平，它将成为ActiveMQ的下一个主要版本。

So, for the comparison, we need to consider both editions. We’ll differentiate between them by using the terms “Active MQ” and “Artemis”.

因此，为了进行比较，我们需要考虑两个版本。我们将用“Active MQ”和“Artemis”这两个术语来区分它们。

2.2. Kafka

2.2. 卡夫卡

In contrast to Active MQ, Kafka is a distributed system meant for processing a huge amount of data. We can use it for traditional messaging as well as:

与Active MQ相比，Kafka是一个分布式系统，旨在处理大量的数据。我们可以将其用于传统的信息传递以及。

• website activity tracking
• metrics
• log aggregation
• stream processing
• event sourcing
• commit logs

These requirements have gained great importance with the emergence of typical cloud architectures built using microservices.

随着使用微服务构建的典型云架构的出现，这些要求变得非常重要。

2.3. The Role of JMS and the Evolution of Messaging

2.3.JMS的作用和消息传递的演变

The Java Message Service (JMS) is a common API for sending and receiving messages within Java EE applications. It is part of the early evolution of messaging systems, and it’s still a standard today. In Jakarta EE, it was adopted as Jakarta Messaging. So, it might be helpful to understand the core concepts:

Java消息服务（JMS）是Java EE应用程序中发送和接收消息的通用API。它是信息传递系统早期演化的一部分，而且至今仍是一个标准。在Jakarta EE中，它被采纳为Jakarta Messaging。所以，了解核心概念可能会有帮助。

• a Java-native, but vendor-independent API
• the need for a JCA Resource Adapter to implement the vendor-specific communication protocol
• message destination models:
  • Queues (P2P) to ensure message ordering and one-time message processing even in case of multiple consumers
  • Topics (PubSub) as an implementation of the Publish-Subscribe Pattern, which means that multiple consumers will receive messages for the duration of their subscription to the topic
• message formats:
  • Headers as standardized meta information that the broker deals with (like priority or expiration date)
  • Properties as non-standardized meta information that the consumer can use for message processing
  • the Body containing the payload – JMS declares five types of messages, but this is only relevant for using the API, not for this comparison

However, the evolution went in an open and independent direction – independent from the platform of the consumer and producer, and independent from the vendors of messaging brokers. There are protocols defining their own destination models:

然而，演进的方向是开放和独立的–独立于消费者和生产者的平台，独立于消息中介的供应商。有一些协议定义了自己的目的地模型。

• AMQP – binary protocol for vendor-independent messaging – uses generic nodes
• MQTT – lightweight binary protocol for embedded systems and IoT – uses topics
• STOMP – a simple text-based protocol that allows messaging even from the browser – uses generic destinations

Another development is the addition of the previously reliable transmission of individual messages (“traditional messaging”) to the processing of large amounts of data according to the “Fire and Forget” principle through the spread of cloud architectures. We can say that the comparison between Active MQ and Kafka is a comparison of exemplary representatives of these two approaches. For example, an alternative to Kafka could be NATS.

另一个发展是，通过云架构的传播，将以前可靠的单个消息传输（”传统消息传递”）加入到根据 “Fire and Forget “原则处理大量数据的过程中。我们可以说，Active MQ和Kafka之间的比较是这两种方法的典范代表的比较。例如，Kafka的替代方案可以是NATS>。

3. Comparison

3.比较

In this section, we’ll compare the most interesting features of architecture and development between Active MQ and Kafka.

在本节中，我们将比较Active MQ和Kafka在架构和开发方面最有趣的特点。

3.1. Message Destination Models, Protocols, and APIs

3.1.消息目的地模型、协议和API

Active MQ fully implements the JMS message destination model of Queues and Topics and maps AMQP, MQTT and STOMP messages to them. For example, a STOMP message is mapped to a JMS BytesMessage within a Topic. Additionally, it supports OpenWire, which allows cross-language access to Active MQ.

Active MQ完全实现了Queue和Topics的JMS消息目标模型，并将AMQP、MQTT和STOMP消息映射到它们。例如，STOMP消息被映射到Topic内的JMS BytesMessage。此外，它还支持OpenWire，它允许对Active MQ进行跨语言访问。

Artemis defines its own message destination model independently from the standard APIs and protocols and also needs to map them to this model:

Artemis定义了自己的消息目的地模型，独立于标准的API和协议，也需要将它们映射到这个模型上。

• Messages are sent to an Address, which is given a unique name, a Routing Type, and zero or more Queues.
• A Routing Type determines how messages are routed from an address to the queue(s) bound to that address. There are two types defined:
  • ANYCAST: messages are routed to a single queue on the address
  • MULTICAST: messages are routed to every queue on the address

Kafka only defines Topics, which consist of multiple Partitions (at least 1) and Replicas that can be placed on different brokers. Finding the optimal strategy for partitioning a topic is a challenge. We must note that:

Kafka只定义了Topics，它由多个Partition（至少1个）和Replicas组成，可以放在不同的broker上。找到划分主题的最佳策略是一个挑战。我们必须注意到。

• One message is distributed into one partition.
• Ordering is only ensured for messages within one partition.
• By default, subsequent messages are distributed round-robin among the topic’s partitions.
• If we use message keys, then messages with the same key will land in the same partition.

Kafka has its own APIs. Although there’s also a Resource Adapter for JMS, we should be aware that the concepts are not fully compatible. AMQP, MQTT, and STOMP are not supported officially, but there are Connectors for AMQP and MQTT.

Kafka有自己的APIs。虽然也有JMS的资源适配器，但我们应该注意到，这些概念并不完全兼容。官方不支持AMQP、MQTT和STOMP，但有Connectors用于AMQP和MQTT。

3.2. Message Format and Processing

3.2.信息格式和处理

Active MQ supports a JMS standard message format consisting of headers, properties, and the body (as described above). The broker has to maintain the delivery state of every message resulting in lower throughput. Since it’s supported by JMS, consumers can synchronously pull messages from the destination, or messages can be asynchronously get pushed by the broker.

Active MQ支持JMS标准消息格式，包括头、属性和正文（如上所述）。代理商必须维护每条消息的交付状态，导致吞吐量降低。由于JMS的支持，消费者可以同步地从目的地拉取消息，或者由经纪人异步地推送消息。

Kafka does not define any message format — this is entirely the responsibility of the producer. There isn’t any delivery state per message, just an Offset per consumer and partition. An Offset is the index of the last message delivered. Not only is this faster, but it also allows messages to be re-sent by resetting the offset without having to ask the producer.

Kafka并没有定义任何消息格式–这完全是生产者的责任。每条消息没有任何交付状态，只有每个消费者和分区的Offset。一个Offset是最后交付的消息的索引。这不仅更快，而且还允许通过重新设置偏移量来重新发送消息，而不必询问生产者。

3.3. Spring and CDI Integration

3.3.Spring和CDI集成

JMS is a Java/Jakarta EE standard and, as such, is fully integrated into Java/Jakarta EE applications. So, connections to Active MQ and Artemis are easily managed by the application server. With Artemis, we can even use an embedded broker. For Kafka, managed connections are only available when using the Resource Adapter for JMS or the Eclipse MicroProfile Reactive.

JMS是一个Java/Jakarta EE标准，因此，它被完全整合到Java/Jakarta EE应用程序中。因此，与Active MQ和Artemis的连接很容易由应用服务器管理。对于Artemis，我们甚至可以使用嵌入式代理。对于Kafka，只有在使用Resource Adapter for JMS或Eclipse MicroProfile Reactive时才能使用管理连接。

Spring has integration for JMS as well as AMQP, MQTT, and STOMP. Kafka is also supported. With Spring Boot, we can use embedded brokers for Active MQ, Artemis, and Kafka.

Spring集成了JMS以及AMQP、MQTT，和STOMP。还支持Kafka。通过Spring Boot，我们可以为Active MQ、Artemis、和Kafka使用嵌入式经纪人。

4. Use Cases of Active MQ/Artemis and Kafka

4.Active MQ/Artemis和Kafka的使用案例

The following points give us a direction as to when which product can best be used.

以下几点给了我们一个方向，即什么时候可以最好地使用哪种产品。

4.1. Use Cases of Active MQ/Artemis

4.1.Active MQ/Artemis的使用案例

• Process only a small number of messages per day
• High level of reliability and transactionality
• Data transformations on-the-fly, ETL jobs

4.2. Use Cases of Kafka

4.2.Kafka的使用案例

• Process a high load of data
  • Real-time data processing
  • Application activity tracking
  • Logging and monitoring
• Message delivery without data transformation (it would be possible, but not easy)
• Message delivery without transport guarantees (it would be possible, but not easy)

5. Conclusion

5.总结

As we have seen, both Active MQ/Artemis and Kafka have their purposes and, therefore, their justifications. It’s important to know their differences in order to choose the right product for the right case. The following table explains these differences again in brief:

正如我们所看到的，Active MQ/Artemis和Kafka都有它们的目的，因此也有它们的理由。了解它们的区别，以便在正确的情况下选择正确的产品，这一点很重要。下表再次简要地解释了这些差异。