ApsaraMQ for RocketMQ scales in any environment. Producers, messaging servers, and consumers all run in clusters. This cluster-level high availability is what sets ApsaraMQ for RocketMQ apart from other messaging servers.
When a producer sends a message, the messaging server selects a consumer at random. The message is considered successfully consumed after that consumer processes it.
In this topic, "messaging server" refers to the combined infrastructure of name servers and brokers, not brokers alone.
Architecture overview
The following figure shows the system architecture.
Servers
Name server
A name server is a nearly stateless node that provides the naming service: discovering and updating broker information. Name servers can be deployed in a cluster.
Broker
A broker stores and forwards messages. Brokers are classified into primary and secondary brokers:
One primary broker can map to multiple secondary brokers.
Each secondary broker maps to exactly one primary broker.
On startup, a broker registers itself with a name server and then reports topic route information every 30 seconds.
Clients
Producer
Each producer maintains two persistent connections:
| Connection target | Behavior |
|---|---|
| A random name server in the cluster | Regularly reads topic route information |
| The primary broker for the relevant topic | Sends periodic heartbeats |
Consumer
Each consumer also maintains persistent connections to both server types:
| Connection target | Behavior |
|---|---|
| A random name server in the cluster | Regularly gets topic route information |
| Both primary and secondary brokers for the relevant topic | Sends periodic heartbeats to each |
Unlike producers, consumers can retrieve messages from both primary and secondary brokers. The broker configuration determines which consumption rules apply.