ApsaraMQ for RocketMQ is distributed messaging middleware built on the publish-subscribe model. It decouples producers from consumers through asynchronous message delivery, which makes it suitable for asynchronous decoupling and peak-load shifting in distributed architectures.
If your use case requires real-time responses over synchronous links, use a Remote Procedure Call (RPC) solution instead. Select a product based on your business scenarios and primary requirements.
How messages flow through the system
Every message passes through three stages: production, storage, and consumption.
A producer creates a message and sends it to the ApsaraMQ for RocketMQ server.
The server stores the message in a topic. Within the topic, the message is appended to a queue in sequential order.
A consumer, which belongs to a consumer group, subscribes to the topic and processes the message.
Key concepts
Production
Producer: A lightweight, anonymous runtime entity that creates and sends messages. Producers are typically integrated into the upstream of a business call chain.
Storage
Topic: A logical container for message transmission and storage. Each topic contains multiple queues that enable horizontal scaling.
Lite topic (LiteTopic): A secondary resource under a Lite-type topic. Each lite topic contains one queue by default.
Queue (MessageQueue): The fundamental unit of message storage and transmission, similar to a partition in Kafka. Each queue uses a stream-based, infinite queue structure where messages are stored sequentially.
Message: The smallest unit of data transmission. Messages are immutable after they are initialized, sent, and stored.
Consumption
Consumer group (ConsumerGroup): A logical grouping that manages multiple consumers. All consumers in a group share the same consumption logic and configuration, and they work together to process messages from subscribed topics. This enables horizontal scaling of consumption capacity.
Consumer: A runtime entity that receives and processes messages. Consumers are typically integrated into the downstream of a business call chain. Each consumer must belong to a specific consumer group.
Subscription: A set of rules at the consumer group level that governs message filtering, retry behavior, and consumption progress restoration. Subscriptions are persistent -- they survive server restarts and client disconnects. The exception is filter expressions, which are not persisted.
Synchronous vs. asynchronous communication
Distributed services communicate through two primary patterns: synchronous RPC and asynchronous messaging. ApsaraMQ for RocketMQ uses asynchronous messaging.
Synchronous RPC
In the synchronous RPC model, a caller sends a request directly to a callee, and the callee returns a response immediately.
"Synchronous" here refers to the communication model, not the programming API. An RPC call can use an asynchronous, non-blocking programming style, but the model still requires a direct response from the target endpoint within a specified period.
Asynchronous messaging
In the asynchronous model, a caller converts a request into a message and sends it to messaging middleware. The call completes once the message is sent successfully. The middleware then reliably delivers the message to the downstream service and ensures that the corresponding task is executed.
| Benefit | How it helps |
|---|---|
| Star-shaped topology | Both upstream and downstream services connect only to the middleware, which produces a simple, easy-to-maintain topology. |
| Loosely coupled services | Upstream and downstream services can be upgraded and modified independently. The middleware handles buffering and asynchronous recovery. |
| Peak-load shifting | The middleware often has strong traffic buffering and shaping capabilities, which prevents spikes from overwhelming downstream services. |
Point-to-point vs. publish-subscribe messaging
Messaging middleware uses one of two delivery models. ApsaraMQ for RocketMQ uses the publish-subscribe model.
| Feature | Point-to-point | Publish-subscribe |
|---|---|---|
| Consumer identity | Anonymous -- consumers share a single queue with no independent identity | Independent -- each consumer group has its own identity |
| Delivery pattern | One-to-one -- consumers compete for messages, and each message is processed by exactly one consumer | One-to-many -- each consumer group receives a copy of every message |
| Scalability | Simpler to implement | More extensible -- supports multiple independent downstream consumers |
Point-to-point model
In the point-to-point model (also called queue-based messaging), the queue is the only communication identifier between upstream and downstream. Multiple consumers compete for messages in the queue, and each message is processed by only one consumer.
Publish-subscribe model
In the publish-subscribe model, each consumer group has an independent identity. Messages in the same topic can be delivered to multiple consumer groups, and each group receives a copy of all messages. Different consumer groups do not affect each other.