All Products
Search
Document Center

ApsaraMQ for RocketMQ:Domain model overview

Last Updated:Oct 27, 2025

This topic describes the domain model of ApsaraMQ for RocketMQ.

Service positioning

ApsaraMQ for RocketMQ is a middleware product for distributed architectures. It uses an asynchronous communication method and a publish-subscribe messaging model.

For more information about communication methods and messaging models, see Communication methods and Messaging models.

ApsaraMQ for RocketMQ provides the benefits of asynchronous communication, such as a simple system topology and weak coupling between upstream and downstream systems. It is primarily used in scenarios such as asynchronous decoupling and peak-load shifting.

For synchronous links that require real-time call results, use Remote Procedure Call (RPC) solutions.

Select a product based on your business scenarios and primary requirements.

Domain model of ApsaraMQ for RocketMQ

Domain model

As shown in the preceding figure, the lifecycle of a message in ApsaraMQ for RocketMQ consists of three main parts: message production, message storage, and message consumption.

Producers create messages and send them to the ApsaraMQ for RocketMQ server. The messages are stored in topics on the server. Consumers then consume the messages by subscribing to the topics.

Message production

Producers (Producer): Runtime entities in ApsaraMQ for RocketMQ that create messages. Producers are typically integrated into the upstream of a business call chain. Producers are lightweight and anonymous.

Message storage

  • Topics (Topic): Logical containers in ApsaraMQ for RocketMQ for message transmission and storage. A topic consists of multiple queues. The queues within a topic are used to store messages and enable horizontal scaling.

  • Lite topics (LiteTopic): In ApsaraMQ for RocketMQ, if a topic is of the Lite type, you can create secondary resources called lite topics under it. By default, each lite topic consists of one queue.

  • Queues (MessageQueue): The fundamental units for message storage and transmission in ApsaraMQ for RocketMQ. They are similar to partitions in Kafka. ApsaraMQ for RocketMQ uses a stream-based, infinite queue structure to store messages. Messages within a queue are stored sequentially.

  • Messages (Message): The smallest unit of transmission in ApsaraMQ for RocketMQ. Messages are immutable after they are initialized, sent, and stored.

Message consumption

  • Consumer groups (ConsumerGroup): A logical grouping of consumers in the publish-subscribe model of ApsaraMQ for RocketMQ. Consumer groups are used to centrally manage multiple underlying consumers. All consumers in the same consumer group must have the same consumption logic and configuration. They work together to consume messages from subscribed topics, which enables horizontal scaling of consumption capacity.

  • Consumers (Consumer): Runtime entities in ApsaraMQ for RocketMQ that consume messages. Consumers are typically integrated into the downstream of a business call chain. A consumer must be assigned to a specific consumer group.

  • Subscriptions (Subscription): A set of rules that define message filtering, retries, and consumption progress in the publish-subscribe model of ApsaraMQ for RocketMQ. Subscriptions are managed at the consumer group level. A consumer group defines a subscription to control how its consumers filter messages, retry consumption, and restore consumption progress.

    In ApsaraMQ for RocketMQ, subscriptions are persistent, except for filter expressions. This means that the subscription relationship is retained even if the server restarts or a client disconnects.

Communication methods

In a distributed system architecture, complex systems are often divided into multiple independent modules, such as microservices. These modules must communicate with each other remotely. The two most common communication patterns are synchronous Remote Procedure Calls (RPCs) and asynchronous communication that uses a middleware proxy.

Synchronous RPC call model

Synchronous call

In the synchronous RPC call model, different systems communicate directly. A caller sends a request to a callee, and the callee must immediately return a response.

Important

The term "synchronous" in this context does not refer to the programming API. RPC can also use an asynchronous, non-blocking programming style. However, the model still requires a direct response from the target endpoint within a specified period.

Asynchronous communication model

Asynchronous call

In the asynchronous communication model, subsystems are loosely coupled and do not connect directly. The caller converts a request into an asynchronous event, which is a message, and sends it to a middleware proxy. The call is considered complete after the message is successfully sent. The proxy is then responsible for reliably delivering the message to the downstream system and ensuring that the corresponding task is executed. This type of proxy is typically a message-oriented middleware.

Asynchronous communication offers the following benefits:

  • Simple system topology

    Because both the upstream and downstream systems communicate with the middleware proxy, the system has a star-shaped topology that is easy to maintain and manage.

  • Weak coupling between upstream and downstream systems

    The systems are loosely coupled, which makes the architecture more flexible. The middleware proxy handles tasks such as buffering and asynchronous recovery. This allows upstream and downstream systems to be upgraded and modified independently of each other.

  • Peak-load shifting

    Message-based middleware proxies often have strong traffic buffering and shaping capabilities. This prevents traffic peaks from overwhelming downstream systems.

Messaging models

The primary messaging models for message-oriented middleware are the point-to-point model and the publish-subscribe model.

Point-to-point model

Point-to-point model

The point-to-point model, also called the queue-based messaging model, has the following features:

  • Anonymous consumption: The queue is the only identifier for communication between upstream and downstream systems. Downstream consumers cannot declare an independent identity when they retrieve messages from the queue.

  • One-to-one communication: Due to anonymous consumption, even if there are multiple downstream consumers, they lack independent identities. As a result, they compete for messages in the queue. Each message can be processed by only one consumer. This means the point-to-point model facilitates one-to-one communication.

Publish-subscribe model

Publish-subscribe model

The publish-subscribe model has the following features:

  • Independent consumption: Compared to the anonymous consumption of the queue-based model, consumers in the publish-subscribe model have their own identity, typically called a consumer group. Different consumer groups are independent and do not affect each other.

  • One-to-many communication: Because each group has an independent identity, messages in the same topic can be processed by multiple consumer groups. Each consumer group can receive a copy of all the messages. Therefore, the publish-subscribe model enables one-to-many communication.

Comparison of transmission models

The point-to-point and publish-subscribe models each have their own advantages. The point-to-point model is simpler, while the publish-subscribe model offers greater extensibility. ApsaraMQ for RocketMQ uses the publish-subscribe model and therefore provides the features of this model.