Introduction to Message Queues, JMS, MQ, and Kafka

The article introduces the concept of message queues, comparing them to a parcel locker that stores messages until consumers retrieve them, and explains why they are essential for asynchronous processing, performance improvement, and reducing system coupling.

1. Message Queue Introduction

Using a parcel delivery analogy, a message queue acts like a locker where producers drop messages and consumers pick them up at their convenience.

1.1 What is a Message Queue

A message queue is a container that stores messages until they are needed, enabling inter‑process or intra‑process communication.

We can think of a message queue as a storage container for messages that can be retrieved when needed.

1.2 Uses of Message Queues

Message queues improve system performance through asynchronous processing, help smooth traffic spikes, and lower coupling between components.

Example: user registration involves four steps (fill form, submit, email notification, SMS notification). Synchronous execution takes time a+b+c+d, while using a message queue reduces the critical path to a+b+queue‑overhead.

Reducing System Coupling

When multiple companies integrate with a single system, direct integration creates high coupling; a message queue decouples them by providing a shared channel.

1.3 Two Messaging Models

Point‑to‑Point

Each message is sent to a specific queue and consumed by a single receiver.

Publish‑Subscribe

Publishers send messages to a topic; all subscribed consumers receive the message anonymously.

2. JMS Introduction

Java Message Service (JMS) is a Java API for messaging middleware, similar to JDBC for databases. It enables asynchronous communication between Java applications.

JMS defines a standard for creating, sending, receiving, and reading messages, reducing coupling and increasing reliability.

2.1 JMS Message Model

The model mirrors the point‑to‑point and publish‑subscribe patterns already described.

2.2 JMS Consumption

Synchronous: the consumer calls receive() and blocks until a message arrives.

Asynchronous: the consumer registers a listener; the provider invokes onMessage() when a message is available.

2.3 JMS Programming Model

The JMS API resembles JDBC. For example, a SqlSessionFactory builds a session, which then executes database operations.

sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
SqlSession openSession = sqlSessionFactory.openSession(true);
ProjectMapper mapper = openSession.getMapper(ProjectMapper.class);
mapper.queryAllTaskByInit("init");

JMS workflow:

ConnectionFactory creates a Connection.

Connection creates a Session.

Session creates producers and consumers.

Producers send messages.

Consumers receive messages.

3. MQ Overview

JMS is an interface, not a concrete technology. Implementations include ActiveMQ, RabbitMQ, and RocketMQ (partial). Kafka is not a JMS implementation.

3.1 AMQP Protocol

AMQP (Advanced Message Queuing Protocol) defines how messages are transferred between producers, exchanges, queues, and consumers.

3.2 RabbitMQ Model

RabbitMQ consists of a server side (queues and exchanges) and a client side (producers and consumers). Exchanges can be direct, fanout, topic, or headers.

Direct: routes to queues with matching routing keys.

Fanout: broadcasts to all bound queues.

Topic: routes based on pattern‑matched routing keys.

4. Kafka

Kafka is a distributed log system that differs from JMS. It uses producers, consumers, topics, partitions, and brokers, with Zookeeper for coordination.

4.1 Kafka Architecture

Key terms:

Producer – sends messages to a broker.

Consumer – reads messages from a broker.

Topic – logical category of messages, split into partitions.

Broker – a Kafka server in a cluster.

Partition – ordered, append‑only log within a topic.

Offset – position of a message inside a partition.

4.2 High Availability

Multiple brokers form a cluster.

Topics are divided into partitions spread across brokers.

Each partition has replicas; one replica is the leader.

Clients read from the leader; writes are replicated to followers.

If a broker fails, another replica becomes the new leader.

In summary, the article distinguishes between generic message queues, the JMS specification, its Java implementations, and non‑JMS systems like Kafka, providing a solid foundation for understanding asynchronous messaging in modern architectures.