Architecture
Last updated: 2025-07-15 17:42:40
This document describes the deployment architecture of TDMQ for RocketMQ to help you better understand its architectural principles.
Deployment Architecture
The system deployment architecture of TDMQ for RocketMQ is shown in the following diagram:
The TDMQ for RocketMQ 5.x introduces the new gRPC protocol and Proxy components, implementing an architecture featuring separation of computation and storage separation. This significantly changes both the Ops and usage of RocketMQ.
The concepts involved are as follows:
Producer cluster: A client-side application responsible for producing and sending messages.
Consumer cluster: A client-side application responsible for message subscription and consumption.
NameServer cluster: A server-side application responsible for routing address location and Broker heartbeat registration. To ensure high availability, it is deployed across AZs by default.
Heartbeat registration: The NameServer acts as a registration center. Machines of each role must report its status to the NameServer regularly. If a machine does not report within a certain time window, the NameServer will presume it to be faulty and remove it from the availability list.
Route addressing: Every NameServer stores both the complete routing information of the Broker cluster and the queue information for client queries. Producers and consumers use the NameServer to acquire route information of the entire Broker cluster, which then allows for message delivery and consumption.
Proxy cluster: A brand-new resilient stateless proxy service deployed across AZs by default to ensure high availability. It splits the responsibilities of the 4.x Broker, extracting computation logic such as client protocol adaptation, permission management, and consumption managemt.
Broker cluster: Compared with the 4.x series, the Broker in the 5.x series is more focused on the continuous enhancements of storage capabilities. To ensure high availability, it is deployed across AZs by default.
The core concepts are as follows:
Producer cluster: Client-side application, which is responsible for producing and sending messages.
Consumer cluster: Client-side application, which is responsible for subscribing to and consuming messages.
Nameserver cluster: server-side application, which is responsible for address routing and broker heartbeat registration.
Heartbeat registration: Nameserver acts as the registration center. Machines in each role must regularly report their status to Nameserver. If a machine fails to report beyond the timeout period, Nameserver will consider it faulty and unavailable and remove it from the available list.
Address routing: Each Nameserver stores the entire routing information of the Broker cluster and the queue information used for client queries. Producers and consumers obtain the routing information of the entire Broker cluster through Nameserver to deliver and consume messages.
Broker cluster: Server application, which is responsible for receiving, storing, and delivering messages. It supports primary-secondary multi-copy mode where the deployment of secondary nodes is optional. The actual high reliability of data in the production environment on the public cloud directly depends on the three copies of the cloud disk.
Management cluster: Server application that is a visual management and control console. It is responsible for operating the entire cluster, such as source data sending/receiving and management.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback