Backend Development 22 min read

Core Concepts and Common Patterns of RabbitMQ

This article explains the purpose of message queues, outlines RabbitMQ's architecture, describes common MQ patterns such as simple, work, fan‑out, direct, and topic, and discusses reliability features like transactions, confirms, dead‑letter queues, TTL, clustering, and ordering guarantees.

Wukong Talks Architecture
Wukong Talks Architecture
Wukong Talks Architecture
Core Concepts and Common Patterns of RabbitMQ

1. Why Use a Message Queue (MQ)

Message middleware is mainly used for asynchronous processing, application decoupling, traffic shaping, and log handling.

1.1 Asynchronous Processing

Instead of blocking a user registration flow with email/SMS sending, the system can publish the notification tasks to an MQ and let the mail and SMS services consume them independently.

1.2 Application Decoupling

By inserting an MQ between services (e.g., order and inventory), failures in one service do not directly affect the other.

1.3 Traffic Shaping

During a flash‑sale, an MQ can absorb a burst of requests and release them at a sustainable rate.

1.4 Log Processing

Web UI requests can be forwarded to an MQ for asynchronous log aggregation.

1.5 Drawbacks of Introducing an MQ

System availability depends on the broker’s stability.

Complexity increases (e.g., handling idempotency, duplicate consumption, and reliable delivery).

2. Common Message Queue Products

ActiveMQ, RabbitMQ, RocketMQ, and Kafka are the most widely used. RabbitMQ offers high concurrency and a rich management UI but is built with Erlang.

3. RabbitMQ Basics

RabbitMQ implements the AMQP protocol. Key components include:

Broker : the server process.

Exchange : routes messages to queues based on rules.

Queue : stores messages.

Binding : links an exchange to a queue.

Routing Key : used by the exchange for routing.

VHost : virtual broker for isolation.

Producer : publishes messages.

Consumer : receives messages.

Channel : a virtual connection within a TCP link.

4. RabbitMQ Working Modes

4.1 Simple Mode

One producer, one consumer; messages are removed after consumption. Requires manual ACK to avoid memory leaks.

4.2 Work (Competing Consumers) Mode

Multiple consumers share a queue. Two distribution strategies:

Round‑robin (auto‑ack enabled).

Fair dispatch (manual ACK, consumers process at their own pace).

4.3 Fan‑out (Publish/Subscribe) Mode

Messages are broadcast to all bound queues without a routing key.

4.4 Direct Routing Mode

Messages are delivered only to queues whose binding key exactly matches the routing key.

4.5 Topic Mode

Routing keys support wildcards ( # for one or more words, * for a single word) enabling pattern‑based routing.

4.6 Reliability Mechanisms

4.6.1 Transaction and Confirm

Producers can use AMQP transactions (channel.txSelect/txCommit/txRollback) or the more common confirm mode, where each published message receives an ACK or NACK.

4.6.2 Persistence

Set durable=true on queues and deliveryMode=2 on messages to survive broker restarts.

4.6.3 Consumer Acknowledgment

Disable auto‑ack and acknowledge manually after successful processing to prevent message loss.

4.7 Dead‑Letter and Delayed Queues

Dead‑letter queues capture rejected or expired messages. TTL can be applied to queues or individual messages; combining TTL with a dead‑letter exchange creates a delayed queue.

Map
args = new HashMap<>();
args.put("x-message-ttl", 6000); // ms
channel.queueDeclare(queueName, durable, exclusive, autoDelete, args);
AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder();
builder.expiration("6000");
AMQP.BasicProperties properties = builder.build();
channel.basicPublish(exchangeName, routingKey, mandatory, properties, "msg body".getBytes());

4.8 Clustering

RabbitMQ supports single‑node, classic cluster, and mirrored (HA) cluster modes. Mirrored queues replicate data across nodes, providing fault tolerance at the cost of network bandwidth.

4.9 Push vs Pull Consumption

Push mode (basicConsume) delivers messages automatically; pull mode (basicGet) requires the consumer to request messages, resulting in higher latency.

5. Design Considerations for a Custom MQ

Key aspects include scalability (adding partitions/brokers), sequential disk writes for high throughput, replication for high availability, and guaranteeing zero loss through persistence and acknowledgments.

References

Message ordering: https://www.jianshu.com/p/02fdcb9e8784

RabbitMQ dead‑letter queues: https://www.cnblogs.com/mfrank/category/1514703.html

RabbitMQ message push: https://blog.csdn.net/qq_40837310/article/details/109033000

ClusteringTTLMessage QueueRabbitMQasynchronous processingMessage RoutingDead Letter Queue
Wukong Talks Architecture
Written by

Wukong Talks Architecture

Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.